Alternative solution to toolbar flicker.

#2542050: Toolbar implementation creates super annoying re-rendering. is much better (no flicker at all) since it's pretty invasive I thought this had better chances to make it earlier in the meantime.

There are various improvements over core solution, mainly there is only one reflow insead of the current 3 (coming from: toolbar, menu tray, and escapeAdmin). It does kinda spoil the experience on Firefox since there is currently no flicker there, with this patch it's at the same level as chrome. 1 reflow.

  • Hide the toolbar by default so computation is done before the toolbar is rendered, hence only one reflow
  • Assume browser has JS enabled (same strategy as the has_js cookie killer patch #229825: backport "$_COOKIE['has_js'] must die" patch to 7.x) (the js class is added too late for .js-hide to be useful)
  • Use requestAnimationFrame() to batch style changes. Init behavior goes from 60ms to under 20ms on desktop. IE10+ only though.
  • Mess with weights of the toolbar scripts to make sure it's always rendered early, prevent toolbar render delay when there is a ckeditor on the page for exemple. Won't need this when #2367655: Control the list of behaviors run by Drupal.attachBehaviors goes somewhere.
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

nod_ created an issue. See original summary.

nod_’s picture

add 2 new classes .js-hide-early, .js-show-early That suppose the js is activated on the client. That way it doesn't mess with dropbuttons and the rest of things that gets ugly when the .js class is not present yet.

Status: Needs review » Needs work

The last submitted patch, 2: core-toolbar-flicker-2850708-2.patch, failed testing.

nod_’s picture

Status: Needs work » Closed (duplicate)

#2542050-113: Toolbar implementation creates super annoying re-rendering. is a great solution, closing this. we should look at requestAnimationFrame seriously to improve perfs later.