Created attachment 10025
IE7 'Jump to' display

Attached:

Probably related to Resource Loader changes

Both Erik and I have seen our edit toolbar completely disappear on some page loads. Shift-reload didn't seem to fix it for me on Chrome; I had to pull open a new tab.

I think this is probably caused by JS/CSS delivery hiccups. This probably can't be reproduced consistently, right?

If this occurs again, pull up the developer tools tab showing individual requests (Net tab in Firebug, Timeline tab in Chrome), and look for strange response codes (response codes that aren't 200 or 304). Also look for JS errors in the console.

FF not tabbing to links is consistent.
IE7 "Jump to" incorrect display is consistent.
Strange behavior in expanded/collapsed link lists is more consistent than inconsistent in Chrome at least.

(In reply to comment #4)

I think this is probably caused by JS/CSS delivery hiccups. This probably can't
be reproduced consistently, right?

If this occurs again, pull up the developer tools tab showing individual
requests (Net tab in Firebug, Timeline tab in Chrome), and look for strange
response codes (response codes that aren't 200 or 304). Also look for JS errors
in the console.

Disregard this, I'm totally off here.

(In reply to comment #0)

Chrome and Firefox and IE7:
Reload page several times. Collapsible headers "Community/Beyond the Web/etc."
are expanded briefly before final state.

This is a flash of unstyled content, right? I can fix that easily.

Firefox and IE7: best behavior. Previously expanded headers remain expanded
after reload.

That's what it's supposed to do, yeah.

Chrome: Final state of those expanded lists may be collapsed or expanded in
seemingly random way.
Expanded header shows expanded (arrow points right) after reload but is not.
See screen shot. (note: it is possible that this happens in other browsers, but
I observed it in Chrome particularly.)

That's very strange. Do you get JS errors in the debugging console when this happens?

Firefox: tabs through headers and textboxes but not links. Does not tab to
hidden "Jump to:navigation search" links.

Is that a regression from 1.18? If not it's probably just a Firefox issue, not a MediaWiki issue.

IE7: same behavior as Chrome, but "Jump to" links are shown badly. See screen
shot.

That's probably an IE7-specific CSS issue, I'll investigate.

The described behavior seems to match very closely what I saw in translatewiki.net while I was testing with $wgResourceLoaderExperimentalAsyncLoading = true;. Sometimes scripts didn't load at all, sometimes the collapsible sidebars were all open or all collapsed, arrow could be pointing one way etc.

Hope this helps.

Created attachment 10030
Toolbar buttons vertically misaligned, seen on MediaWiki.org (Chrome/Ubuntu)

More fun that's probably related: buttons on the advanced toolbar, when expanded, are sometimes vertically misaligned.

Attached:

To clarify: This falls into the "not always reproducible" category and only occurs on some edit loads. When it does, I'm not getting any JS errors, nor any unusual response codes for any request.

In twn it usually happened after post requests. No JS errosr either.

OK, after lots more random pageloads:

1. I cannot reproduce the issue with the misaligned buttons if I deactivate the "Parser Playground" gadget. That gadget adds a "Rich editor" tab (similar to the "Advanced" tab) to the toolbar. Sometimes that tab does appear, sometimes it doesn't appear, and sometimes the buttons are misaligned, and sometimes they are not.

2. Similarly, sometimes I see a flash of the old toolbar (eww), and sometimes I do not.

3. Similarly, in the same page request, sometimes I see the issue with the sidebar (arrows indicating expansion of sidebar elements without them actually being expanded), sometimes I do not.

I've saved an HAR file from Chrome for one of those page requests which led to the broken toolbar view if it's any help in debugging.

Chrome 17:
No visual breakage, but got this error:
Failed to load resource: http://meta.wikimedia.org/w/index.php?action=raw&ctype=text/css&smaxage=0&title=MediaWiki:vector.css/en
the server responded with a status of 404

IE8:
Repeated error: 'mw not defined', gadgets not working.

Firefox 10:
No errors.

The sidebar issue should be fixed now.

The weird sidebar collapsing issues should be fixed by r111809 from werdna.

content hidden as private in Bugzilla

(In reply to comment #1)

Created attachment 10025 [details]
IE7 'Jump to' display

This is due to the page-html being cached by 1.18 and loaded with references to 1.19 bits.wikimedia.org serving stylesheets. This is recorded as bug 34504 and is not ResourceLoader or IE7 related.

Attached:

Rob and I are both able to still reproduce occasional incorrect sidebar collapse/expand state (in Chrome/Ubuntu) on repeatedly loading e.g. http://commons.wikimedia.org/wiki/Commons:Community_portal

Testing in Chrome/Ubuntu...

I can't reproduce incorrect sidebar state on numerous reloads of http://commons.wikimedia.org/wiki/Commons:Community_portal

It always seems to flash first fully expanded, then collapse down to what I last left it as. I have seen no inconsistent states as in attachment 10024, nor any unexpected changes of state from expanded to collapsed or vice-versa.

Are you guys seeing the same problem as in that screenshot, or something else?

Can't repro it anymore either. May have been a server-side caching issue or related to some gadgetry. I'd say let's close it for now.

In Firefox, i do not have toolbar and editbar icons.

I downgraded to a former version, to arbitray revision 111700.

svn up -r111588 solved that, so it happened between 111700 and 112100 (toolbar not loaded)

Thomas, I cannot repro that on trunk or in production. Which Firefox version is this? Do you see it in a production wiki? Which edit toolbar, the old (Monobook) one, or the new (Vector) one?

Hi Erik!!

I run 10.0.2 the latest.
I noticed the problem about yesterday or the day before.
I downgraded all my installations to r111588.
The problem is fully reproducible for me, on totally different installation. On is a huge enterprise wiki installation. I just double-checked: the svn trunk version shows the problem, downgrading to 111588 repairs the problem.

All tests were done with freshly restarted and clean browsers (Ctrl-F5; Ctrl+Shift+Del (Chronik löschen)).

The problem must have been introduced between r111588 (i used that, because of my last commit to core) and the current 112xxx version.

e-greetings from Berlin

I can confirm that I have trouble loading the classic toolbar on trunk.

That seems to be a highly specific issue with the classic toolbar and should be reported as a separate bug.

(In reply to comment #23)

I can confirm that I have trouble loading the classic toolbar on trunk.

That seems to be a highly specific issue with the classic toolbar and should be
reported as a separate bug.

done as https://bugzilla.wikimedia.org/show_bug.cgi?id=34662

(In reply to comment #11)

3. ... sometimes I see the issue with the sidebar

(arrows indicating expansion of sidebar elements
without them actually being expanded), sometimes I do not.

I'm seeing this problem on
https://pt.wikibooks.org/w/index.php?title=Especial:P%C3%A1gina_em_branco&uselang=en&debug=1
using Google Chrome 17.0.963.56, but the only portlet affected is the "Correlatos", which is created by our
https://pt.wikibooks.org/wiki/MediaWiki:Gadget-Correlatos.js?oldid=233236
(as a workaround for bug 708, and using a custom - and apparently broken - code to workaround bug 23515)

(In reply to comment #25)

I believe the code from
https://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/Vector/modules/ext.vector.collapsibleNav.js?view=markup#l173
should be

) {
	$(this)
		.addClass( 'expanded' )
		.removeClass( 'collapsed' )
		.find( 'div.body' )
		.hide() // bug 34450
		.show();
} else {
	$(this).addClass( 'collapsed' )
		.removeClass( 'expanded' );
}

to make sure it gets one, and only one, of the classes, because currently the error happens because the div get both classes:

<div id="p-interproject" class="portal collapsed expanded"><h5 tabindex="5">Correlatos</h5>...

or none of them.

(In reply to comment #26)

r112601

Closing this bug so that individual reports can be filed for individual problems.

[adding the Tracking-Neverending project to tasks blocking (now deprecated) T4007 as part of T93366]