Page MenuHomePhabricator

Echo icon FOUC (tracking)
Closed, ResolvedPublic


The annoying part is that in my experience the icons are very distracting, in that they keep changing aspect: at one time they are gray with black icon, an instant aftewards the icons become white, then one of the two icons disappears (maybe because I visited a Flow board), etc.

My eye doesn't need to be constantly attracted to those icons.

Chrome 47.0.2507.0 on OS X 10.11:

Event Timeline

Nemo_bis created this task.Sep 10 2015, 2:51 PM
Nemo_bis raised the priority of this task from to Needs Triage.
Nemo_bis updated the task description. (Show Details)
Nemo_bis added a project: Notifications.
Restricted Application added a project: Collaboration-Team-Triage. · View Herald TranscriptSep 10 2015, 2:51 PM
Restricted Application added a subscriber: Aklapper. · View Herald Transcript

The messages icon should never disappear on's only shown once you have a message (user talk edit or flow notification currently), but shouldn't go away. What wiki did that happen on?

Separately from the icon switching from white to black, the dimensions of the badges also change very slightly, and it seems like the text gains bold styling. This applies to all skins, not just MonoBook.


Separately from the icon switching from white to black, the dimensions of the badges also change very slightly, and it seems like the text gains bold styling. This applies to all skins, not just MonoBook.

There are two issues here. The flashing, and the slight size jumping.

The size jumping happens because the nojs version generates a link tag <a> that we then style to look like an ooui button. Then the JS version replaces it with the OOUI button, which is comprised of nested <divs> and <a> etc, and despite our attempts to make them look the same, the browser seems to resist. We got them as close to being the same as possible. We are continuing to try and get them better, but it seems to be a really hard task. We are *temporarily* solving this issue by giving the user an indication that they're looking at the nojs version (which, if clicked, will result in taking them to the Special:Notifications page rather than open the popup) by making the initial nojs rendering slightly transparent until the actual button loads. Obviously this won't happen if you're looking at the actual nojs version.

The second issue is the flashing black icons. This is extremely weird issue. The nojs loads with white inverted buttons, and the ooui button also has white inverted buttons, except it *first* loads a black icon and then changes it to inverted -- which causes the "jump" to be visible.

That (second) problem seems to me to be an issue with OOUI's inverted icon priority. @matmarex, could it be that the rule to load the inverted buttons happens "too late" ? that is, that we are actually loading a non-inverted icon first, then switching to inverted? Can we fix this?

The Echo popup definition calls for inverted buttons immediately; it *should* load them correctly, but it jumps. I can't help but wonder if this is an issue with ooui style loading? Are we in Echo loading them out of sync maybe?

ori triaged this task as High priority.Sep 11 2015, 8:02 AM
ori updated the task description. (Show Details)
ori set Security to None.

Change 237619 had a related patch set uploaded (by Eranroz):
Fix for T112104

Root cause: When we create OOUI element not all its classes are assigned to the elements and are only added later due to OO.ui.debounce.
A workaround is to call updateElementClasses before replacing elements as :

someone more familiar with OOUI may find a better way to do it

Change 237619 had a related patch set uploaded (by Nemo bis):
Avoid flashes: late debounce causes annoying flashes

ori added a comment.Sep 12 2015, 7:47 PM

IMO this is borderline revert-worthy. Please fix ASAP.

@eranroz solution should have fixed things. (thanks!) . We need to verify quickly and cherry pick.

We can concentrate on a better way to do this upstream in ooui later.

I just verified @eranroz's commit fixes things. We should consider cherry picking.

That will solve the blinking. The slight variation in sizing is dealt with in T112218: Echo icons change size slightly during load

Nearly everything in master has already been backported to 1.26wmf22.

Ideally the elements should be created in backend side and not in client side, and then OOUI should bind to those elements on page load (e.g give OOUI config that contains {$element: ALREADY_CREATED_ELEMENT}). Injecting OOUI widget to personal links requires changes in how skins work (specifically personal_urls expects "text" and doesn't allow "html"; there doesn't seem to be other relevant hooks here), but considering the alternatives I think it is the best option.

Alternatives solutions:

  1. Keep playing with CSS until we get same look as OOUI - This is hard to do in a cross-browsers/cross-skins. This will likely break easily when OOUI change
  2. Execute echo.init before page load as a top module, and I'm not sure it would work.

Semi-related issue (to the Echo icons in general) at T112494: The ooui-UI echo-icons looks like they are dfferent size. (This seems like a semi-reasonable task to note it in. :-)

Catrope renamed this task from Echo icons in personal tools keep blinking to Echo icon FOUC (tracking).Sep 15 2015, 5:47 PM
Catrope assigned this task to Mooeypoo.
Quiddity closed this task as Resolved.Jul 13 2016, 10:03 PM

Believed to be resolved.

Restricted Application added a project: Growth-Team. · View Herald TranscriptOct 28 2018, 3:57 AM