Maniphest T198759

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

Assigned To

None

Authored By

	Krinkle
	Jul 3 2018, 8:33 PM

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

viwiki-vector-regular.mov1 MBDownload

viwiki-vector-safemode.mov1 MBDownload

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.

Related Objects

Mentioned In: T203844: Edit tab slides underneath the More tab, then slides back out
Mentioned Here: T56919: [collapsibleTabs] Tabs (Read / View Source / Search) wrap to next line and cover content if screen width < ~700px
T71729: [collapsibleTabs] If a tab's width changes after initial page load, endless animation loop can happen

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

Krinkle added subscribers: • matmarex, Volker_E, Jdlrobson.Jul 3 2018, 8:33 PM

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

Krinkle moved this task from Limbo to Watching on the Performance-Team (Radar) board.Jul 18 2018, 12:16 AM

Krinkle added a project: Web-Team-Backlog-Archived.Jul 18 2018, 12:19 AM

Jdlrobson moved this task from Incoming to Needs Prioritization on the Web-Team-Backlog-Archived board.Jul 23 2018, 2:33 AM

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.

• matmarex mentioned this in T203844: Edit tab slides underneath the More tab, then slides back out.Sep 7 2018, 8:43 PM

Jidanni merged a task: T203844: Edit tab slides underneath the More tab, then slides back out.Sep 7 2018, 9:07 PM

Jidanni subscribed.

In T198759#4447292, @Jdlrobson wrote:

[..] 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.

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 T198759#4579007, @Jidanni wrote:

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.

Krinkle moved this task from Watching to Perf issue on the Performance-Team (Radar) board.Jan 21 2019, 12:44 AM

Krinkle moved this task from Perf issue to Perf recommendation on the Performance-Team (Radar) board.Jan 21 2019, 12:57 AM

Jdlrobson moved this task from Needs triage to Logo and header on the Vector (legacy skin) board.Jan 15 2020, 6:22 PM

Jdlrobson moved this task from Logo and header to Menus on the Vector (legacy skin) board.Jan 15 2020, 7:50 PM

Jdlrobson moved this task from Untriaged to Discuss further on the Web-Team-Backlog-Archived (Tracking) board.Sep 30 2021, 9:21 PM

Jdlrobson moved this task from Discuss further to Move to Backlog on the Web-Team-Backlog-Archived (Tracking) board.Oct 7 2021, 8:41 PM

LGoto edited projects, added Web-Team-Backlog-Archived; removed Web-Team-Backlog-Archived (Tracking).Oct 7 2021, 9:10 PM

Jdlrobson moved this task from Menus to Bugs on the Vector (legacy skin) board.Apr 25 2022, 9:44 PM

Jdlrobson claimed this task.Apr 25 2022, 10:22 PM

Jdlrobson edited projects, added Web-Team-Backlog-Archived (Kanbanana-FY-2021-22); removed Web-Team-Backlog-Archived.

LGoto triaged this task as Low priority.Apr 26 2022, 5:36 PM

Jdlrobson removed Jdlrobson as the assignee of this task.Apr 28 2022, 6:31 PM