Last modified: 2014-05-08 09:01:50 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 42452 - Sidebar display problems after changing menu headings from h5 to h3, possible caching issue
Sidebar display problems after changing menu headings from h5 to h3, possible...
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
General/Unknown (Other open bugs)
1.20.x
All All
: High major with 1 vote (vote)
: 1.20.x release
Assigned To: Nobody - You can work on this!
: ops, platformeng
: 42680 (view as bug list)
Depends on: 43227
Blocks:
  Show dependency treegraph
 
Reported: 2012-11-26 17:26 UTC by Chris McMahon
Modified: 2014-05-08 09:01 UTC (History)
17 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---
mah: Backport_to_Stable-


Attachments
garbled display on beta labs in Chrome (22.33 KB, image/png)
2012-11-26 17:26 UTC, Chris McMahon
Details
Fresh screenshot from Chrome (743.73 KB, image/png)
2012-12-03 20:22 UTC, Dario Taraborelli
Details
Screenshot of header issues (on main page) (401.40 KB, image/png)
2012-12-04 04:07 UTC, Matthew Flaschen
Details
Navigation menu in Japanese wikipedia displayed incorrectly on the side bar (44.11 KB, image/png)
2012-12-14 20:00 UTC, Mohamed
Details

Description Chris McMahon 2012-11-26 17:26:48 UTC
Created attachment 11424 [details]
garbled display on beta labs in Chrome

As of just now, I am unable to log in directly to beta labs with an existing account. 

With an account already logged in globally, the display of pages is garbled, see screen shot.
Comment 1 Andre Klapper 2012-11-26 17:39:53 UTC
URL highly welcome.
Comment 2 Chris McMahon 2012-11-26 17:42:42 UTC
sorry, figured it would be clear in context:  http://en.wikipedia.beta.wmflabs.org
Comment 3 Bartosz Dziewoński 2012-11-26 17:44:15 UTC
Ten bucks says this is caused by I9a2ebd50 being merged. Try clearing your browser's cache, if you didn't already.
Comment 4 Bartosz Dziewoński 2012-11-26 17:47:47 UTC
http://en.wikipedia.beta.wmflabs.org/wiki/Main_Page looks like on your screenshot to me. It looks like the HTML is in a pre-I9a2ebd50 version (with <h5> headings), but the CSS is in a post-I9a2ebd50 version (styles for h3).

Doing a http://en.wikipedia.beta.wmflabs.org/wiki/Main_Page?action=purge didn't fix the issue.
Comment 5 Andre Klapper 2012-11-26 17:57:00 UTC
I had tried http://deployment.wikimedia.beta.wmflabs.org/ . ;)

en.wikipedia.beta.wmflabs.org/wiki/Main_Page looks okayish when being logged in with Firefox 16.0.2, but I literally got
     <centralnotice-template-welcome>
a few times (not always).

As it loads slowly it might be yet another one of all those CSS off-and-on
errors lately.
Comment 6 Ryan Kaldari 2012-11-28 21:38:44 UTC
I saw similar behavior on test.wiki and Commons after switching to wmf5, but it went away after hard refresh.
Comment 7 Chris McMahon 2012-11-28 22:34:01 UTC
The garbled display affects the main pages of http://meta.wikimedia.org and http://wikimediafoundation.org also, as well as certain other pages like http://test.wikipedia.org/wiki/Wikipedia:Create_a_new_page .

The garbled display is visible in Firefox and IE9 but those pages look normal in Chrome.
Comment 8 Chris McMahon 2012-11-28 22:35:46 UTC
changing Product/Component to Mediawiki/General since this issue made it out of beta labs to production
Comment 9 Alex Monk 2012-11-28 22:40:37 UTC
(In reply to comment #7)
> The garbled display is visible in Firefox and IE9 but those pages look normal
> in Chrome.

It's broken for me in Chrome as well. (24.0.1290.1 dev on Ubuntu)
Comment 10 Ryan Kaldari 2012-11-28 22:47:32 UTC
Problem seems to be that ResourceLoader is failing to load some new CSS that is needed unless you use 'debug=true' in the URL.
Comment 11 Ryan Kaldari 2012-11-28 23:45:34 UTC
Fixed with https://gerrit.wikimedia.org/r/#/c/35817/ and
https://gerrit.wikimedia.org/r/#/c/35819

Reopen if there are still any residual issues.
Comment 12 Ryan Kaldari 2012-12-03 20:22:26 UTC
Seeing this on en.wiki while logged in. The HTML isn't cached, as it's displaying the broken items as h3s (the newer tag). The problem seems to be that ResourceLoader isn't delivering the updated CSS. This might just be the 5 minutes of doom, but I'm not sure when the deployment happened.
Comment 13 Dario Taraborelli 2012-12-03 20:22:58 UTC
Created attachment 11456 [details]
Fresh screenshot from Chrome
Comment 14 spage 2012-12-03 20:36:52 UTC
I'm not seeing the big headings, but I am seeing the same incorrect misbehaving headings in the left-hand nav: indented "Navigation" , "Interaction" instead of "Support", and no expand/contract arrows on "Interaction" and "Toolbox".
Comment 15 Ryan Kaldari 2012-12-03 20:49:15 UTC
Touched and synced the startup.js and ext.vector.collapsibleNav.css files.
Seems to be working correctly now.
Comment 16 Ryan Kaldari 2012-12-03 21:53:19 UTC
Seems to be fixed for most people. One report of problematic display even after clearing cache:
"I tried to purge the cache but still no change. Using safari on iPad. Monobook."

Otherwise, seems to be resolved. Lowering severity.
Comment 17 Matthew Flaschen 2012-12-04 04:07:25 UTC
Created attachment 11459 [details]
Screenshot of header issues (on main page)

It seems to be resolved for me.

For the record, I took the attached (cropped to relevant part) at ~ 2012-12-05 02:49.
Comment 18 Dan Rosenthal 2012-12-04 05:54:41 UTC
I still have the hidden navigation tabs at the top in monobook. I did not have this yesterday. Clearing cache, force reloading, closing and restarting browser, and purging the server cache, all did nothing. According to reports on village pump technical and other places, I'm not the only one.

Chrome, XP Pro.
Comment 19 Andre Klapper 2012-12-04 13:30:15 UTC
*** Bug 42680 has been marked as a duplicate of this bug. ***
Comment 20 Oliver Keyes 2012-12-04 17:51:39 UTC
Still appearing for me too (as in, appeared ~5 seconds ago).
Comment 21 Ryan Kaldari 2012-12-05 00:28:59 UTC
We backported the new CSS to wmf4 and deployed it to the remaining wikis today. This should minimize the breakage due to stuck server caches, but I wouldn't be surprised if some people still report the problem tomorrow.
Comment 22 Ryan Kaldari 2012-12-05 23:04:37 UTC
Getting reports of this bug on pl.wiki:
https://pl.wikipedia.org/wiki/Wikipedia:Kawiarenka/Kwestie_techniczne#Menu_nawigacyjne

Specifically: http://iv.pl/images/90157415975042120178.jpg

Note the user is logged in and apparently debug=true fixes the issue (according to folks on IRC).
Comment 23 Ryan Kaldari 2012-12-06 00:24:26 UTC
Reported on German Wikipedia as well: https://de.wikipedia.org/wiki/Wikipedia:Fragen_zur_Wikipedia#Navigationsmen.C3.BC

Just to summarize the situation...

This bug consists of 3 different potential problems, 2 of which have been successfully resolved:

1. Users getting updated CSS, but cached HTML - fixed with https://gerrit.wikimedia.org/r/#/c/35817/ and https://gerrit.wikimedia.org/r/#/c/35819

2. Users getting updated HTML, but outdated client-side-cached CSS ("5 minutes of doom") - fixed by deploying CSS a day before the HTML changes. (Our CSS files are supposed to expire after 5 minutes at the most on the client-side.)

3. Users getting updated HTML, but outdated server-side-cached CSS (that is over 5 minutes old). This is the one we haven't solved. The problem is difficult to reproduce reliably, and seems to fade away on its own. Users who experience this problem state that they are logged in, have cleared their browser cache, and purged the pages. The problem has been reported across a wide range of browsers and from users in both the US and Europe. If we accept these reports as accurate, the only explanation I can come up with is that some WMF servers are holding onto old caches of CSS and JS pages after they have been updated and synced from fenari. (Anecdotal reports from mobile and fundraising developers lead me to believe that this affects JS as well as CSS.) Although the current incarnation of this problem was merely cosmetic, it has the potential to cause major site breakage. We may want to have someone from Ops investigate further if possible.
Comment 24 JulesWinnfield-hu 2012-12-06 11:35:32 UTC
Missing css on https://hu.wikipedia.org/wiki/Lohr_Ferenc
"Navigation menu" is displayed in lower left corner on every page with HTTPS. With simple http, or with debug=1 it gets correct css and is not displayed.
Comment 25 JulesWinnfield-hu 2012-12-06 11:39:43 UTC
(In reply to comment #24)
Only with Chrome. Windows 7 64-bit, Vector, logged in and logged out.
Comment 26 Cyberpower678 2012-12-06 12:01:18 UTC
I believe I have the solution.  Clearing the cache alone won't do it.  Everything must be cleared from the browser as reset as if the browser were browsing for the first time.  Clear the history, cache, temporary Internet files, browsing data, and cookies.  I hope this helps.
Comment 27 JulesWinnfield-hu 2012-12-06 15:38:15 UTC
(In reply to comment #24)
Resolved deleting the browser cache.
Comment 28 Ryan Kaldari 2012-12-06 18:32:01 UTC
In the case of people fixing the problem by clearing their cache, there are two possible explanations:
1. The CSS files had bad cache headers (didn't expire in 5 minutes)
2. The request for new CSS files happened to hit a server that was correctly serving the new files, rather than a server that was serving the old files.

I suspect the later for 3 reasons: Cyberpower mentions they had to completely reset their browser, including cookies. This would have created a new session and reset whatever server they were stuck to. Also several people have mentioned that clearing their browser cache did not fix the problem for them. Finally, I haven't seen any bad cache headers myself and I've been looking at them frequently.
Comment 29 Ryan Kaldari 2012-12-07 00:14:31 UTC
At 00:10 UTC today (Thursday in the US, Friday in Europe) Ryan Lane cleared all the varnish caches used by bits. If anyone is still noticing this bug, let me know.
Comment 30 Andre Klapper 2012-12-11 15:10:29 UTC
Kaldari: Is there anything left to do here, or can we assume that this is FIXED now?

Summarizing recommended actions for affected users again:
* http://en.wikipedia.org/wiki/Wikipedia:Bypass_your_cache
* Add ?action=purge to the web address
* Add ?debug=true to the web address
Comment 31 Andre Klapper 2012-12-11 15:11:55 UTC
[Only very few affected users left => removing blocking 38865]
Comment 32 Ryan Kaldari 2012-12-11 18:26:30 UTC
Andre: Unfortunately, I have no idea as I don't yet know what the underlying problem actually was. It would require a dedicated debugging effort to solve and I've already spent too much time on this I'm afraid. This is really an issue that should be handled by platform or ops, but I haven't had any luck getting other people interested in looking at it. I think you can close this bug, but I won't be surprised if it is reopened that next time an interface change is deployed.
Comment 33 Bartosz Dziewoński 2012-12-14 13:54:31 UTC
Per http://lists.wikimedia.org/pipermail/wikitech-l/2012-December/065126.html this is still happening.
Comment 34 Mohamed 2012-12-14 20:00:56 UTC
Created attachment 11517 [details]
Navigation menu in Japanese wikipedia displayed incorrectly on the side bar

as an example of the bug described here http://lists.wikimedia.org/pipermail/wikitech-l/2012-December/065126.html
Comment 35 Andre Klapper 2012-12-17 10:07:55 UTC
Mohamed: Please clarify if you've tried all three steps listed in comment 30.
Comment 36 Ryan Kaldari 2012-12-17 19:10:07 UTC
?debug=true always fixes the problem temporarily, but isn't a real solution.

I've also heard that clearing cookies (resetting your session) fixes it for some people.
Comment 37 Umherirrender 2012-12-18 16:00:49 UTC
Gerrit change #34702 (bug 42354) changed all h5 to h3, but that breaks the collapsible navigation in Vector for cached html, because Gerrit change #35817 only contains css.

Please add for 1.21 a backward compatible javascript to avoid the need of mass purge of cached html for [anon] users (also needed for third party wikis).

Gerrit change #30361 also contains a javascript change, with is not backported in Gerrit change #35819 (and that is for 1.21wmf5 only, but cache lives longer than 14 days?)
Comment 38 Andre Klapper 2012-12-18 16:09:02 UTC
(In reply to comment #37)
> Gerrit change #34702 (bug 42354) changed all h5 to h3, but that breaks the
> collapsible
> navigation in Vector for cached html, because Gerrit change #35817 only
> contains css.

That sounds a lot like bug 43227. Maybe should be handled there.
Comment 39 Helder 2012-12-20 19:43:42 UTC
(In reply to comment #37)
> Gerrit change #34702 (bug 42354) changed all h5 to h3, but that breaks the
> collapsible
> navigation in Vector for cached html, 
...and also the hack used by dozen of wikis to workaround bug 708:
https://pt.wikipedia.org/wiki/MediaWiki:Gadget-InterprojectLinks.js
I just fixed two (on ptwiki and ptwikibooks), but there are copies on other wikis...
Comment 40 Bartosz Dziewoński 2012-12-23 13:08:09 UTC
(In reply to comment #37)
> Please add for 1.21 a backward compatible javascript to avoid the need of
> mass
> purge of cached html for [anon] users (also needed for third party wikis).

I0a05ed39 should fix this.
Comment 41 Bartosz Dziewoński 2013-01-05 00:42:09 UTC
Okay, I *think* this has been entirely fixed for now, with everything that should support both h3 and h5 supporting them both. If something is still not perfect, do speak up and I'll go and fix it.

Also, MediaWiki core and extension Vector both need releases (Vector to include the fix for bug 43227, MediaWiki to update bundled Vector). I am hoping that people who handle this are CC'd here.

So, unless this is supposed to stay open as a catch-all for further cache-related issues, it should probably be closed. (And the summary badly needs clarifying in either case.)
Comment 42 Chris McMahon 2013-01-07 15:22:29 UTC
Closing per comments. New issues along this line to go under new reports.
Comment 43 Ryan Kaldari 2013-01-10 00:25:41 UTC
New incarnation of this bug at bug 43805.
Comment 44 Nemo 2013-03-04 19:34:34 UTC
Still has to be backported to 1.20, if needed (for 1.20.4; it didn't make it to 1.20.3).

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links