Page MenuHomePhabricator

Vector menu tabs animates in-and-out twice instead of once before settling
Open, Needs TriagePublic

Description

I can consistently reproduce this in latest stable Chrome, using the link https://vi.wikipedia.org/wiki/User:Krinkle?uselang=en. It happens both logged-in, and logged-out as well as in safemode (disables site scripts/styles).

https://vi.wikipedia.org/wiki/User:Krinkle?uselang=en&safemode=1


The initial rendering shows the tabs are too wide to fit on one line, and just as before and as it has for years, this means it renders on the next line initially.

Then, the vector.js code is applied, which is meant to move some of the tabs to the "More" menu, and animate the width as it goes.

What actually happens is that this animation occurs correctly, but then it animates again in the opposite direction (undoing what it just did), and then it animates again for a third time, to re-apply the correction.

This whole show takes about two seconds during page load.

Event Timeline

Krinkle created this task.Jul 3 2018, 8:33 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJul 3 2018, 8:33 PM
Schnark added a subscriber: Schnark.Jul 4 2018, 8:48 AM

Is this really a regression? According to T71729#2937052 this has always been the case since the animation at least doesn't happen infinitely.

This did remind me of T71729 also. It's been a known problem (at least to me) for some time. The unclear thing to me is what we want to do about it (if anything)

In this particular case, this seems like a mixture of problematically long labels, some superfluous(?) animations and no agreement/documentation of supported breakpoints in https://www.mediawiki.org/wiki/Compatibility, all of which I'd want some guidance on before web looking into this.

[..] The unclear thing to me is what we want to do about it (if anything)
In this particular case, this seems like a mixture of problematically long labels, [..] and no agreement/documentation of supported breakpoints [..]

I think what we should do about it, is fix the bug :)

The logic in question is about how much space the items in question need, and how much space there is available on the user's screen. This is entirely dynamic, and meant to be. It applies to labels long and short, and it applies to devices wide and narrow.

So even if we'd document something like "we don't fix bugs relating to desktop windows narrower than 700px", it wouldn't close this task. And I'd argue, we should never document something like that because it's trivial to eliminate that entire class of bugs by simply making 700px the minimum <body> width. That way, users with unsupported narrow windows will still get a wider page (with scrollbars).

The source of the problem is that the size-adjustment logic appears to be reacting to its own reaction. That's a bug, and I think that's quite fixable. If in the investigation we find other problems or obstacles, we can cross that bridge when we come to it.

Jidanni added a comment.EditedSep 12 2018, 11:44 PM

And here on http://wiki.osgeo.org/wiki/Taiwan_datums
we observe the final results end up in the wrong spot,
blocking the title.

And here on http://wiki.osgeo.org/wiki/Taiwan_datums
we observe the final results end up in the wrong spot,
blocking the title.

In this situation the tabs can not collapse any further. Until recently, the "Read" and "Edit" ("View source") tabs would never be allowed to collapse – this was changed in MediaWiki 1.31 (T56919), but that wiki is running MediaWiki 1.25. This is the expected behavior for this version.