| Nemo_bis | |
| Sep 10 2015, 2:51 PM |
| F2567769: 2015-09-11 00_36_28.gif | |
| Sep 11 2015, 8:02 AM |
| F2565796: pasted_file | |
| Sep 10 2015, 5:18 PM |
| F2565792: pasted_file | |
| Sep 10 2015, 5:18 PM |
| F2565311: personal-tools-doubled.png | |
| Sep 10 2015, 2:51 PM |
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:
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | Mooeypoo | T112104 Echo icon FOUC (tracking) | |||
| Resolved | Legoktm | T111821 Echo flyout icon flashes color change from white to black in MonoBook skin | |||
| Resolved | eranroz | T112168 Notification icon flashes from white to black to white | |||
| Resolved | Mooeypoo | T112218 Echo icons change size slightly during load | |||
| Resolved | Mooeypoo | T112773 Echo notifications: "Your alerts" tooltip placed under Messages |
The messages icon should never disappear on you...it'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.
| PHP | |
| JS |
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?
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 :
https://gerrit.wikimedia.org/r/237619
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
@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
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:
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. :-)