Page MenuHomePhabricator

[wmf.8] Misplaced 'x' on the first load on Watchlist page
Closed, DuplicatePublic


The misalignment affects drop-down menus as well, e.g.

Event Timeline

I added @Volker_E, @SBisson and @Pginer-WMF to this ticket and the OOUI tag. Is this an OOUI issue or something Collab Team needs to fix?

We are graduating Watchlist out of beta on all wikis next week. I'd really like to have this fixed before then.

Trizek-WMF added a subscriber: Trizek-WMF.

I've seen that in production.

FYI, production has a similar problem in Monobook.

I tried to reproduce this, but the issue was not present in beta or production using Chrome, Firefox and Safari on Mac. This is what I see:

The steps to reproduce it:

  • reload the page, all display issues will be gone
  • change the skin to Vector - the watchlist will be displayed very similarly to the first load of monobook skin:

  • reload the page - all UI issues are gone.

However, keep in mind that it's not reproducible for the same user in the same user session. You'll need a different user to see it again, or try to log in to a different browser.

The issue exists in production (wmf.8) - only on Watchlist. The steps - changing the skin from Vector and then back - reliably reproduce the issue.

Etonkovidova renamed this task from [betalabs] Misplaced 'x' on the first load on Watchlist page to [wmf.8] Misplaced 'x' on the first load on Watchlist page .Jun 21 2018, 10:52 PM
Vvjjkkii renamed this task from [wmf.8] Misplaced 'x' on the first load on Watchlist page to tpaaaaaaaa.Jul 1 2018, 1:02 AM
Vvjjkkii raised the priority of this task from Low to High.
Vvjjkkii updated the task description. (Show Details)
Vvjjkkii removed a subscriber: Aklapper.
CommunityTechBot renamed this task from tpaaaaaaaa to [wmf.8] Misplaced 'x' on the first load on Watchlist page .Jul 2 2018, 4:30 AM
CommunityTechBot lowered the priority of this task from High to Low.
CommunityTechBot updated the task description. (Show Details)
CommunityTechBot added a subscriber: Aklapper.

Also reported in T200288: Related changes filters' cancel buttons are mispositioned - the steps to reproduce (change from Vector skin and then back) are the same.

While working on a different bug, I stumbled upon this issue locally, and I found myself in the highly envious position of having two otherwise identical browser tabs, one with and one without this bug.

It turns out that there are two CSS rules competing to set the padding on this element:

/* Rule A: */
.oo-ui-tagItemWidget.oo-ui-widget-enabled .oo-ui-buttonElement-button {
    padding-top: 1.42857143em;
    padding-bottom: 1.42857143em;

/* Rule B: */
.oo-ui-buttonElement-frameless.oo-ui-iconElement > .oo-ui-buttonElement-button {
    padding-top: 2.14285714em;
    padding-bottom: 2.14285714em;

From context, it's clear that rule A is meant to override rule B, and I've confirmed experimentally that the 1.42em padding value is the "right" one (makes the button look right). However, note that rule A and rule B have exactly the same specificity (they both involve 3 class selectors and 1 child/descendant selector; in fact they're almost exactly the same shape), so which one wins depends on which one gets loaded last. It appears that B usually loads before A, but in my tab where things were broken, A had loaded before B.

Debug mode reveals that rule A comes from resources/lib/oojs-ui/oojs-ui-widgets-wikimediaui.css (in the oojs-ui-widgets.styles module) and rule B comes from resources/lib/oojs-ui/lib/oojs-ui-core-wikimediaui.css (in the oojs-ui-core.styles module). These modules do not depend on each other directly. Here's the dependency tree.

  -> oojs-ui-widgets.styles
  -> oojs-ui-core
       -> oojs-ui-core.styles

This means that, if oojs-ui is loaded dynamically (not with addModuleStyles) and oojs-ui-widgets.styles is executed by the client-side loader, it might load before oojs-ui-code.styles does. I think the solution to this is to add a dependency between the two, and we might need to do that for the other style modules as well. Alternatively, we could make rule A more specific in OOUI itself, but there are bound to be lots of cases like that, and I don't think it's reasonable to force OOUI to tolerate loading its styles in the wrong order.

@Krinkle could you validate my reasoning here? Is it sensible for us to add dependencies between style modules to ensure that they load in the correct order when loaded by the client-side loader? (When loaded with addModuleStyles, they'll either load in the order they were added or in alphabetical order, but both happen to be fine here.)

...and I should have read the rest of T195544, because in T195544#4492949 @matmarex figured out the exact same thing two weeks ago.