Page MenuHomePhabricator

MediaViewer: Closing MediaViewer results in black, undismissable page
Closed, ResolvedPublic

Description

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.


Version: unspecified
Severity: normal

Attached:

Details

Reference
bz70756

Event Timeline

bzimport raised the priority of this task from to Needs Triage.Nov 22 2014, 3:55 AM
bzimport added a project: MediaViewer.
bzimport set Reference to bz70756.
bzimport added a subscriber: Unknown Object (MLST).
Deskana created this task.Sep 12 2014, 5:55 AM
Tgr added a comment.Sep 12 2014, 12:58 PM

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.

Tgr added a comment.Sep 12 2014, 1:11 PM

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.

Tgr added a comment.Sep 12 2014, 1:47 PM

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.

Tgr added a comment.Sep 12 2014, 2:17 PM

More specifically, $.ready.promise().done(cb) fires on the staff page but not the template page, even though $.ready.promise().state() returns

Tgr added a comment.Sep 12 2014, 2:17 PM

... "resolved" on both pages.

Tgr added a comment.Sep 12 2014, 3:15 PM

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

gerritadmin wrote:

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

gerritadmin wrote:

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

gerritadmin wrote:

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

gerritadmin wrote:

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

gerritadmin wrote:

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

gerritadmin wrote:

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

Tgr added a comment.Sep 15 2014, 3:36 PM

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.

Confirmed fixed (tested in FF32 and Chrome35).

Gilles moved this task from Untriaged to Done on the Multimedia board.Dec 2 2014, 8:53 AM
Restricted Application added a subscriber: Matanya. · View Herald TranscriptSep 18 2015, 9:15 PM