1315763 - Slow Script warning caused by Flash during DOM fullscreen transition can cause window to become unresponsive

Status: RESOLVED WORKSFORME

(Core Graveyard :: Plug-ins, defect)

Description

[Mike Conley (:mconley) (:⚙️)]

STR:

1) To simulate a slower machine that would hit the slow script timeout, open about:config and set dom.max_script_run_time to 1. (This means that a script running for 1 second or more should cause the slow script dialog)
2) Restart Firefox
3) Make sure Flash is installed and enabled.
4) Visit http://www.rtve.es/noticias/mas-24/#
5) Wait for the page to load, and if necessary, Click-to-play to allow the video element to display
6) Click on the Fullscreen button in the bottom right corner of the video player
7) When the slow script dialog comes up, click "Stop script" (or "Continue" - it really doesn't matter at this point).
8) Hit Escape to exit fullscreen mode

Expected results: Window should still accept events and be in more or less the same state as when we entered fullscreen mode.

Actual results: Window is completely unresponsive to user events. :/

There appears to be a few things wrong here:

1) The Flash plugin is kicking off some kind of horrific script thing where it's converting stuff to XML. See https://cleopatra.io/#report=81e9d8d1f4b5a51ddabf188066f31e3557b8ad1c&selection=0,2300,18,3847,172,73,3848,2328 for details.
2) The slow script dialog during the fullscreen transition appears to be no-bueno for events targeted at that window, at least for plugins. Note that if there were other windows open before the bug is triggered, those windows will still be responsive.
3) I believe the Flash plugin is using the DOM fullscreen API, and not the native fullscreen stuff.

Comment 1

[Mike Conley (:mconley) (:⚙️)]

Hey xidorn, do you know if we're prepared to handle the case where the slow script dialog suddenly appears during (or just before) the fullscreen transition?

Comment 2

[Xidorn Quan [:xidorn] UTC+10]

I tested on Firefox Developer Edition on Windows, and I don't see the actual result. The window is still responsive to me. Probably that is a platform specific issue? Are you on Mac or Linux?

I don't think we have any code to handle that case, and I'm not sure about the mechanism of slow script dialog. Does it just block the task queue of the main thread?

Comment 3

[Mike Conley (:mconley) (:⚙️)]

(In reply to Xidorn Quan [:xidorn] (UTC+10) from comment #2)
> I tested on Firefox Developer Edition on Windows, and I don't see the actual
> result. The window is still responsive to me. Probably that is a platform
> specific issue? Are you on Mac or Linux?

I reproduced this on Windows 10 and Windows 7. Were you able to get the slow script warning when you tried reproducing the bug?

I'm also not too familiar with how the slow script dialog works. We're able to interrupt long-running JS at particular points and paint the dialog, but that's about all I know.

Comment 4

[Xidorn Quan [:xidorn] UTC+10]

I am able to get the slow script warning, but after all the steps, the window is still responsive, no matter whether I click the stop or wait.

Comment 5

[Mike Conley (:mconley) (:⚙️)]

Hm. RyanVM, who would be a good person from QA to try to find reliable STR here?

Comment 6

[Ryan VanderMeulen [:RyanVM]]

Let's start with Michelle since her team handles QA for plugins.

Comment 7

[Michelle Funches - QA]

Currently investigating - started on this yesterday based on comments in bug 1315763. I will update as soon as I can.

Comment 8

[Michelle Funches - QA]

Pardon: I started investigating this based on the comments in bug 1291688

Comment 9

[Michelle Funches - QA]

Please reference full testing notes at https://public.etherpad-mozilla.org/p/Bug_1315763_RTVE_%26_Flash
I can consistently reproduce the problem on the Acer laptop which is the first OS in the ether-pad.
Tested on Windows 10 32bit OS ; Windows 10 64bit OS with Firefox 32bit and 64 bit
Please let me know of any additional information/testing that you need.

Comment 10

[Mike Conley (:mconley) (:⚙️)]

Which version of Firefox did you use, Michelle?

Comment 11

[Michelle Funches - QA]

All the test were with Aurora. The Acer Aurora 32bit and on the other platforms Aurora 32 & 64 bit.

Comment 12

[Mike Conley (:mconley) (:⚙️)]

(In reply to Michelle Funches - QA from comment #11)
> All the test were with Aurora. The Acer Aurora 32bit and on the other
> platforms Aurora 32 & 64 bit.

Are you able to reproduce with Nightly?

Comment 13

[Michelle Funches - QA]

I will test Nightly and update asap

Comment 14

[Michelle Funches - QA]

Mike I updated the etherpad with the following info for the Nightly testing:

Windows 10 32bit OS: Same behavior observed in Nightly Build ID 2016111030211 however the 2 Adobe processes shut down faster, approx 5 sec vs. the 30 seconds or longer I observed in Aurora.

Windows 10 64bit OS Firefox 32bit: Behavior observed in Nightly Build ID 20161110030211: Failing to see the Slow script message, it has never displayed, config value is set at 1. Extremely long to allow access to full screen control. Once available I can still move in and out of full screen with out loss of functionality.

Windows 10 64bit OS  Firefox 64 bit: Behavior observed in Nightly Build ID 20161110030211: I do see the Slow script message, config value is set at 1. Extremely long to allow access to full screen control. Once available I can still move in and out of full screen however I will eventually experience a  loss of functionality. I will loose access to the control bar, I cannot escape full screen, but this part I cannot consistently reproduce. The behavior is similar to what I see when lose functionality on the Windows 10 32bit OS.

Comment 15

[Mike Conley (:mconley) (:⚙️)]

Hey xidorn, are you able to reproduce using DevEdition?

Comment 16

[Xidorn Quan [:xidorn] UTC+10]

As I've said in comment 2, no I cannot reproduce using DevEdition. I do see the slow script warning, but whatever I click, everything is still responsive after exiting fullscreen.

Comment 17

[Benjamin Smedberg]

I'm going to close this out. There's a similar bug 1315088: I'mm going to try and construct a reduced case for that one.