Last modified: 2014-09-17 06:57:58 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T72756, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 70756 - MediaViewer: Closing MediaViewer results in black, undismissable page
MediaViewer: Closing MediaViewer results in black, undismissable page
Status: RESOLVED FIXED
Product: MediaWiki extensions
Classification: Unclassified
MultimediaViewer (Other open bugs)
unspecified
All All
: Unprioritized normal (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on: 70772
Blocks:
  Show dependency treegraph
 
Reported: 2014-09-12 05:55 UTC by Dan Garry
Modified: 2014-09-17 06:57 UTC (History)
5 users (show)

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


Attachments
What it looks like if you close MediaViewer. Yes, I uploaded a screenshot of a black tab. (388.39 KB, image/png)
2014-09-12 05:55 UTC, Dan Garry
Details

Description Dan Garry 2014-09-12 05:55:55 UTC
Created attachment 16450 [details]
What it looks like if you close MediaViewer. Yes, I uploaded a screenshot of a black tab.

1) Go to https://wikimediafoundation.org/wiki/Template:Staff_and_contractors#Fundraising_Operations
2) Click on the picture for "Juli Matthews of Swagbot". MediaViewer is loaded.
3) Click the X to close MediaViewer.

Expected result: MediaViewer closes.
Obtained result: That tab is now a completely black screen, and it cannot be dismissed.
Comment 1 Tisza Gergő 2014-09-12 12:46:54 UTC
Weird... https://wikimediafoundation.org/wiki/Staff_and_contractors?showall=1 works but the template does not.
Comment 2 Tisza Gergő 2014-09-12 12:51:25 UTC
Tracked in Mingle as https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/891
Comment 3 Tisza Gergő 2014-09-12 12:58:16 UTC
Same issue as https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/825 : the domready handler in mmv.bootstrap.autostart.js is never called, even though the $(document).ready(handler) call itself is executed.
Comment 4 Tisza Gergő 2014-09-12 13:11:53 UTC
Well, not quite the same issue because that was Firefox-specific and this can be reproduced in Chrome. But the underlying issue is the same: something removes domready event handlers.

Given that the error is specific to this page, it might be related to the script embedded in the template to show/hide departmental lists (which works on the staff page but errors out on the template page). I really don't see how though. The error can be reproduced in debug mode, so it can't be errors in one script affecting other scripts due to ResourceLoader concatenating them.
Comment 5 Tisza Gergő 2014-09-12 13:47:36 UTC
It seems that fundamental jQuery behavior differs between the two pages. On [[wmf:Staff and contractors]]:

$(document).ready( function() { console.log('!'); });
// !

On [[wmf:Template:Staff and contractors]]:

$(document).ready( function() { console.log('!'); });
// no output

so some script might be messing with jQuery internals.
Comment 6 Tisza Gergő 2014-09-12 14:17:20 UTC
More specifically, $.ready.promise().done(cb) fires on the staff page but not the template page, even though $.ready.promise().state() returns
Comment 7 Tisza Gergő 2014-09-12 14:17:46 UTC
... "resolved" on both pages.
Comment 8 Tisza Gergő 2014-09-12 15:15:55 UTC
This is jQuery bug #10251 [1] (wontfixed). Basically, when a $(document).ready() handler has an error, all subsequent handlers fail to run. Given that gadgets are usually loaded before exceptions, this is bad and a generic solution is needed; but since that looks hard, and this issue affects MediaViewer in a rather severe way (a couple users complained about a BSOD - they were probably using broken user scripts which prevented the loading of the MediaViewer event handler which removes the black overlay), we should probably implement a local workaround.

[1] http://bugs.jquery.com/ticket/10251
Comment 9 Gerrit Notification Bot 2014-09-12 17:20:25 UTC
Change 160028 had a related patch set uploaded by Gergő Tisza:
Make sure event handlers are set up even if onready handler is lost

https://gerrit.wikimedia.org/r/160028
Comment 10 Gerrit Notification Bot 2014-09-15 08:19:03 UTC
Change 160028 merged by jenkins-bot:
Make sure event handlers are set up even if onready handler is lost

https://gerrit.wikimedia.org/r/160028
Comment 11 Gerrit Notification Bot 2014-09-15 10:00:29 UTC
Change 160413 had a related patch set uploaded by Gergő Tisza:
Make sure event handlers are set up even if onready handler is lost

https://gerrit.wikimedia.org/r/160413
Comment 12 Gerrit Notification Bot 2014-09-15 10:00:52 UTC
Change 160415 had a related patch set uploaded by Gergő Tisza:
Make sure event handlers are set up even if onready handler is lost

https://gerrit.wikimedia.org/r/160415
Comment 13 Gerrit Notification Bot 2014-09-15 10:01:55 UTC
Change 160413 merged by jenkins-bot:
Make sure event handlers are set up even if onready handler is lost

https://gerrit.wikimedia.org/r/160413
Comment 14 Gerrit Notification Bot 2014-09-15 10:02:06 UTC
Change 160415 merged by jenkins-bot:
Make sure event handlers are set up even if onready handler is lost

https://gerrit.wikimedia.org/r/160415
Comment 15 Tisza Gergő 2014-09-15 15:36:54 UTC
Works after pushing out the patch via SWAT.

The underlying issue (local site JS onready handlers throwing errors will prevent onready handlers of extensions from being called) is tracked as bug 70772.
Comment 16 Erik Moeller 2014-09-17 06:57:58 UTC
Confirmed fixed (tested in FF32 and Chrome35).

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


Navigation
Links