1569198 - Firefox crashes when refreshing Flash content and NVDA is running

Status: RESOLVED INVALID

(Core :: Disability Access APIs, defect, P5)

Description

[Simona Badau, Desktop QA]

Attachment: 2019-07-26_16h53_17.mp4

Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:70.0) Gecko/20100101 Firefox/70.0
Build ID: 20190726094308
Shockwave Flash 32.0 r0
NVDA: 2019.1.1
Graphics: Intel(R) HD Graphics 530

Prerequisites:
have the NVDA screen reader tool running

Steps to reproduce:

1. Open Firefox
2. Navigate to a web site that uses Flash, like: http://waterlife.nfb.ca
3. Run Adobe Flash -> Allow -> click the Reload current page (or hit the F5 keyboard)

Expected results:
Flash content is reloaded.

Actual results:
Firefox freezes, you need to kill Firefox from the Task Manager. Please see the attached video.
Here are some crash reports found in about:crashes
https://crash-stats.mozilla.org/report/index/7ad3bef7-db3a-4fad-994d-d0e400190726
https://crash-stats.mozilla.org/report/index/2662519c-3950-49a0-894a-d406a0190726

I could reproduce this issue on Firefox 68.0.1, on the Firefox 69 beta 8 and on the latest Nightly.

Comment 1

[Chris Peterson [:cpeterson]]

Thanks, Simona. I don't think bug is a regression from bug 1519434, but that change landed in Firefox 69 but you can reproduce this NVDA issue in Firefox 68.0.1.

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

Bugbug thinks this bug is a regression, but please revert this change in case of error.

Comment 3

[Marcia Knous [:marcia]]

The stack traces don't appear to be useful, [@ EMPTY: no crashing thread identified; ERROR_NO_MINIDUMP_HEADER ].

Flash version is plugin (web) Filename: NPSWF64_32_0_0_223.dll

Comment 4

[Patricia Lawless]

Hi Jamie, can we get a priority on this one? (regression triage). Thanks!

Comment 5

[James Teh [:Jamie]]

Attachment: Stacks for content and plugin processes.

Are we absolutely certain this only occurs with NVDA running? This seems to be a deadlock between the Firefox content process and the plugin process. The content process sends a sync message to create a new plugin instance, but in answering that, the plugin process tries to send a message to the content process that it requires audio device changes. Since the content process is blocked on the message to create a new instance, we get a deadlock.

Comment 6

[James Teh [:Jamie]]

Simona, can you confirm whether this can be reproduced without NVDA running?
Jim, any thoughts on comment 5? There doesn't appear to be anything a11y related in the stack. The only thing worth noting is that the main parent process is blocked on an a11y query to the content process, which is in turn blocked because the content main thread is making the sync plugin call. If the plugin process is trying to talk to the main parent process somewhere, that'd certainly deadlock. I'm not quite sure how the plugin IPC stuff works. I gather PPluginModuleChild is in the plugin process and PPluginModuleParent is in the content process, with neither being in the main parent process. However, I could well be missing something.

Comment 7

[Simona Badau, Desktop QA]

(In reply to James Teh [:Jamie] from comment #6)

Simona, can you confirm whether this can be reproduced without NVDA running?

I can't reproduce this issue when NVDA isn't running. I can reproduce this issue only with NVDA running.

Comment 8

[Jim Mathies [:jimm]]

(In reply to Simona Badau from comment #7)

(In reply to James Teh [:Jamie] from comment #6)

Simona, can you confirm whether this can be reproduced without NVDA running?

I can't reproduce this issue when NVDA isn't running. I can reproduce this issue only with NVDA running.

Can you please post your about:support text?

Maybe we're getting different flash drawing models based on the local hardware. That can in turn cause flash to do odd things, like create child windows in certain cases.

Comment 9

[Simona Badau, Desktop QA]

Attachment: aboutSupport.txt

Comment 10

[:Gijs (he/him)]

Doesn't look like this is a regression in our code, or at least, if it is, it must be from before 68?

Comment 11

[Chris Peterson [:cpeterson]]

Sounds like there are three variables here: Firefox version, Flash version, and NVDA version.

Should we try using mozregression to bisect older Firefox versions?

You can also try installing older Flash versions from Adobe's download archives, though that is a major pain because you must run Adobe's Flash uninstaller before you run the Flash installer to downgrade Flash. Search for "Flash Player archives":

https://helpx.adobe.com/flash-player/kb/archived-flash-player-versions.html

Comment 12

[scottaohara]

I can reproduce this issue with JAWS running as well. Sometimes it works, but have recently come across similar issues on other websites where having JAWS or NVDA running will cause a website with a flash player to make Firefox completely unresponsive until forceful restart via the task manager.

Can also confirm that other websites tested do not cause Firefox to freeze if a screen reader is not running.

Comment 13

[James Teh [:Jamie]]

While this issue is pretty nasty, Flash is EOL at the end of this year and this looks like it's going to be pretty difficult to diagnose and fix. I don't think it makes sense to invest time toward working on this.

Comment 14

[Marcela (Please NI request to Brindusa Tot)]

Considering comment 13 and due to Flash is no longer supported, I'll close this issue Resolved-invalid.
https://www.adobe.com/ro/products/flashplayer/end-of-life.html
https://support.mozilla.org/en-US/kb/end-support-adobe-flash