Page MenuHomePhabricator

[collapsibleTabs] If a tab's width changes after initial page load, endless animation loop can happen
Open, LowPublic

Description

If the "View history" tab changes size such that becomes too large where it before was not, an endless animation loop of collapse-expand-collapse-etc can be triggered. A resize could be caused by an ordinary zoom (frequently resizing the pixel width of the element by a few pixels), by a change in browser text size preferences (likely to significantly change the width), or by a user script modifying the text content of the element.

This appears to be caused by expandCondition in Vector.js using a cached version of the element's width (collapsibleTabs.data's expandedWidth passed as the eleWidth argument), while collapseCondition is checking .width() each time.

This happens when you enable Editing mode: show both tabs is enabled in preferences in VisualEditor and visit https://www.mediawiki.org/wiki/User:Martin_Urbanec?uselang=fr at certain screen resolutions. Demonstrated in image below:


Version: unspecified
Severity: normal

Details

Reference
bz69729
Related Gerrit Patches:

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
matmarex triaged this task as Low priority.Dec 16 2014, 4:52 PM
matmarex set Security to None.
Krinkle lowered the priority of this task from Low to Lowest.Feb 10 2015, 3:49 AM

Changing the value of existing tabs is not supported. Can you provide an example or use case where this happens?

Such customisations (if desired) should be done upstream as part of Vector, or at least done server-side (e.g. by changing the MediaWiki namespace message for it, or by creating a hook in your LocalSettings configuration).

Changing the value of existing tabs is not supported. Can you provide an example or use case where this happens?
Such customisations (if desired) should be done upstream as part of Vector, or at least done server-side (e.g. by changing the MediaWiki namespace message for it, or by creating a hook in your LocalSettings configuration).

Given T108588, does VisualEditor change the tabs on client-side? If so, this definitely isn't "Lowest" priority.

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptAug 10 2015, 4:06 PM
Ciencia_Al_Poder raised the priority of this task from Lowest to Normal.Sep 5 2015, 1:25 PM
Ciencia_Al_Poder added a subscriber: Ciencia_Al_Poder.

Changing the value of existing tabs is not supported. Can you provide an example or use case where this happens?
Such customisations (if desired) should be done upstream as part of Vector, or at least done server-side (e.g. by changing the MediaWiki namespace message for it, or by creating a hook in your LocalSettings configuration).

Reported again in T111601, Cokersed shows a nice video of it http://elric.ga/files/out-1.ogv

I see that on initial page load, there are 2 "edit" tabs with the same text: Править. Then, once the page finishes loaded, the text of the "not-ve edit" is changed to Править вики-текст

I've inspected a bit of JS and I see that it seems to be changed by VisualEditor

https://ru.wikipedia.org/static/1.26wmf21/extensions/VisualEditor/modules/ve-mw/init/targets/ve.init.mw.DesktopArticleTarget.init.js

			// Alter the edit tab (#ca-edit)
			if ( $( '#ca-view-foreign' ).length ) {
				if ( tabMessages[ action + 'localdescriptionsource' ] !== null ) {
					$caEditLink.text( mw.msg( tabMessages[ action + 'localdescriptionsource' ] ) );
				}
			} else {
				if ( tabMessages[ action + 'source' ] !== null ) {
					$caEditLink.text( mw.msg( tabMessages[ action + 'source' ] ) );
				}
			}

If that's not supported, Visual Editor shouldn't be doing that, right?

Well, that VE thing seems to be tracked on T108588 instead

This comment was removed by Krinkle.

If that's not supported, VisualEditor shouldn't be doing that, right?

Indeed. That JavaScript is there in case the server failed to do it correctly (or in case of cached html). Looks like the ru.wikipedia.org configuration is not supported correctly by the server-side equivalent of that code.

https://github.com/wikimedia/mediawiki-extensions-VisualEditor/blob/667d8d9935/VisualEditor.hooks.php#L136-L175

	$tabMessages = $config->get( 'VisualEditorTabMessages' );
	..
	if ( .. ) {
		$editTabMessage = $tabMessages[$action . 'localdescriptionsource'];
	} else {
		$editTabMessage = $tabMessages[$action . 'source'];
	}
saper added a subscriber: saper.Oct 12 2015, 5:26 PM

I got this today when reviewing changes from article's history one by one and the FlaggedRevs' "Pending edits" tab probably interfered.

Isarra moved this task from Backlog to Bugs on the Vector board.Apr 7 2016, 1:05 AM
Krinkle removed a subscriber: Krinkle.Apr 7 2016, 11:40 PM
Jdlrobson lowered the priority of this task from Normal to Low.Nov 24 2016, 7:11 PM
Jdlrobson updated the task description. (Show Details)

This is not VE-specific, right? Anything that adjusts the tabs after the PHP layer is done with it, like FlaggedRevs and some gadgets, has this problem?

This is not VE-specific, right? Anything that adjusts the tabs after the PHP layer is done with it, like FlaggedRevs and some gadgets, has this problem?

True, the VE-specific bug (see T71729#1611561) is T108588

No, FlaggedRevs doesn't do that, and is not affected. To my knowledge, VisualEditor is the only tool that's causing this.

As far as I can tell (T108588#1640647) FlaggedRevs prevents VE from using the desired labels for editing tabs on server side, thus forcing VE to modify them on client side, triggering this bug.

matmarex added a subscriber: abian.

Judging by the number of reports, this has started happening more frequently for some reason.

1u added a comment.Dec 31 2016, 3:24 AM

Judging by the number of reports, this has started happening more frequently for some reason.

Indeed.

As I don't get the effect in the link of the initial description here is an other example:
https://de.wikipedia.org/wiki/Datei:Karte_Gemeinde_Gommiswald_2013.png.
The animation-loop happens from the start (without changing window-width).

Firefox v.50: 1173px to 1428px
Chromium v.53: 1113px to 1341px (witch are quite average widths)

I've tried to reproduce locally without success

File:Opening Karte_Gemeinde_Gommiswald_2013.png?uselang=de with private browsing, with latest master of MediaWiki and Vector, with InstantCommons enabled, and adding this to LocalSettings.php to mimick the addition of the third tab (to avoid installing VisualEditor):

function test_onSkinTemplateNavigation_Universal( &$sktemplate, &$links ) {
        $links['views']['whatever'] = [
                'class' => 'collapsible',
                'text' => 'Lokalen Beschreibungsquelltext hinzufügen',
                'href' => '#'
        ];

        if ( isset( $links['views']['edit'] ) ) {
                $links['views']['edit']['primary'] = true;
        }
}

$wgHooks['SkinTemplateNavigation::Universal'][] = 'test_onSkinTemplateNavigation_Universal';

In one tab, dewiki page, in other tab my local wiki. On dewiki the bug happens, on my local wiki it doesn't. Texts and dimensions of the tabs are the same. The generated HTML for both (before running JavaScript) is equivalent.

So the only variable that is left here that might cause the problem is Visual Editor. But why?

I noticed the problem today for the first time on my PC (Chromium), before I had experienced it only on the tablet. It happened with a user page on de.wiki that derived from meta, a similar case as the above mentioned.

I'm getting this on my non-existent user page (which is copied from Meta) at mediawiki.org in Firefox 50, with "Show me both editor tabs" enabled. I can't trigger it without this setting. With that setting, on a non-existent userpage, there are three long descriptions in tabs at the top of the page, and the last hides and un-hides repeatedly.

My browser window right now is about 1428 pixels wide. To trigger it in English, I need to zoom in twice. The default zoom triggers it in Russian. Zooming in once or twice triggers it with the UI set to German. So (the point of this message) if you aren't seeing it in your browser, then you might try enabling two tabs, switching to a couple of different languages with ?uselang=xx, and/or zooming in and out a couple of steps.

Grabbing some popcorn and selecting the <li id="ca-edit"> element in Firefox' dev tools, things seem to happily jump around between three states: display: list-item with right: 0px not being applied, replaced by display: block with left: 0px not being applied and vice versa; plus only very occasionally also the 3rd screenshot with div.vectorTabs not being in the game at all:


F5228098

pajz added a comment.Jan 5 2017, 7:05 PM

This has also been reported to us in OTRS, and I can easily reproduce it (at least in incognito mode) on local file description pages like https://de.wikipedia.org/wiki/Datei:Otzenrathpano2.jpg?uselang=de. So I'd also like to echo that this issue is easy to run into at the moment, which makes me wonder if this should really be treated as a low-priority issue.

Change 331919 had a related patch set uploaded (by Bartosz Dziewoński):
collapsibleTabs: Stop the tabs from collapsing back and forth forever

https://gerrit.wikimedia.org/r/331919

This doesn't fix the issue entirely, but it should reduce it to mildly annoying. The tabs might still collapse back-and-forth once, but after that happens the code will update some internal calculations, and it should prevent the tabs from flapping forever.

Change 331919 merged by jenkins-bot:
collapsibleTabs: Stop the tabs from collapsing back and forth forever

https://gerrit.wikimedia.org/r/331919

That will be deployed next week, per the usual schedule. This task is not entirely fixed -- the tabs will still expand and collapse once on page load if you're using an unfortunate screen resolution. But correcting that is more difficult :/

MGChecker added a subscriber: MGChecker.
Jdlrobson moved this task from Backlog to Later on the Readers-Web-Backlog (Tracking) board.
Stryn awarded a token.Sep 11 2018, 7:44 PM