1427304 - FF ESR freezes clicking on the microphone with the JAWS screen reader on

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect)

Description

[Vijay]

Attachment: TNAV-20289-testnav_crashes_clicking_on_the_mic_button.swf

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.84 Safari/537.36

Steps to reproduce:

1. Bring up JAWS JAWS 18, 17 or 16
2. Go to this ur : https://www.webrtc-experiment.com/RecordRTC/
3. Chose "Microphone" then clicked "Start recording". When the microphone icon appears, click on it. 


Actual results:

 Firefox browser froze. 


Expected results:

It should have let the user access the microphone icon

Comment 1

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

Hi, sorry for the post-holiday delay. Could you confirm if this is still a problem in Firefox 59 (Nightly?)

Comment 2

[Vijay]

Hello,

Yes, I can still reproduce it on FirefoxNightly 59.0a1 (2018-01-15) (64-bit)

Comment 3

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

Looks like Windows 7. Bryce, can I trouble you to see if you can repro on your windows box?

Comment 4

[Bryce Seager van Dyk [:bryce] (he/him) - Not reading bugmail]

I used the most recent version of JAWS I could find from here: https://www.freedomscientific.com/Downloads/JAWS

I see very high CPU usage in Firefox (and several other programs). When trying to repro this, I see Firefox lock before I could even get to the prompt on the page mentioned. Profile run below:

https://perfht.ml/2DfrT3u

Took quite some time for the UI to become responsive again to end the run. Looks like the main thread is being saturated by accessibility related calls. Watching the attached .swf it looks like the hang takes place after opening the mic, and on different test page. I wonder if it's the a11y calls there also rather than WebRTC.

Vijay, do you ever see issues like this when using JAWS but not interacting with microphone input?

Comment 5

[Vijay]

Hello Bryce,

I haven't come across such issues using just JAWS.

Comment 6

[Bryce Seager van Dyk [:bryce] (he/him) - Not reading bugmail]

I'm going to move this to the accessibility component: based on the above profile I think the issue lies there.

Comment 7

[Marco Zehe (:MarcoZ)]

JAWS and E10S Firefox are currently incompatible, so the profile probably shows us what we already know from other bugs. But am going to NI Davidb to confirm, since I can't use the profiler (too visual).

Comment 8

[David Bolter [:davidb] (NeedInfo me for attention)]

Yeah sort of expected. The STR is interesting and Jamie might be interested.

Comment 9

[James Teh [:Jamie]]

(In reply to Vijay from comment #0)
> When the microphone
> icon appears, click on it.

I'm totally blind, so I can't see your video. When you say "microphone icon", do you mean the sharing indicator that has a tool tip saying "Your microphone is being shared. Click here to control sharing."?

Technical: Repeatedly calling accParent on the "alert" accessible for the sharing indicator (id: webrtcIndicator) will send the client into an infinite loop. The parent of the alert is a window accessible and the parent of that window accessible is the alert... and thus it continues forever. That is very likely to cause a client to freeze, and if it's an in-process client like JAWS, it'll probably take down the whole browser.

Comment 10

[James Teh [:Jamie]]

The HWND for the alert accessible is itself a child of another HWND. Unfortunately, both HWNDs answer with the alert accessible when you request OBJID_CLIENT. There are two possible solutions:
1. The alert accessible and its descendants should use the outer HWND for all events and for the IA2 windowHandle property. (Currently, they use the inner HWND.)
2. accParent on the alert accessible should return the window accessible for the outer HWND, not the inner HWND.

What is special about this XUL <window> that causes it to get wrapped in an outer HWND? David, who can we ask about this?

Comment 11

[David Bolter [:davidb] (NeedInfo me for attention)]

Not sure, Neil do you know?

Comment 12

[Neil Deakin]

It looks like the microphone box is a regular window but opened with popup=yes as one of window.open flags. This is an outdated flag that we've never really supported. It makes a window behave like a popup (for example, it becomes a WS_POPUP style on Windows), but it doesn't work that well since everywhere else assumes that this will be a <panel> and not a <window>.

The window is also opened with dialog=yes.

I'm not sure why there are two HWNDs here. Is one of them for the parent window?

Comment 13

[James Teh [:Jamie]]

(In reply to Neil Deakin from comment #12)
> I'm not sure why there are two HWNDs here. Is one of them for the parent
> window?

Accessibility seems to think both HWNDs are associated with the webrtcIndicator window. Does this even have a parent window?

Comment 14

[Vijay]

Hi, any update on this?

Comment 15

[James Teh [:Jamie]]

I spent a while looking into this again. It seems that when a window is opened with popup=yes, it gets two HWNDs. The outer one has WS_POPUP, the inner one does not. The root widget is associated with the inner HWND. If I remove popup=yes (obviously not practical), there is only one HWND.

I'm going around in circles trying to figure out how to detect this. Is there some easy way I can detect this popup=yes case via the root widget or similar?

Implementation note: I think the best solution here is to have accParent bypass the inner window accessible.

Comment 16

[James Teh [:Jamie]]

Neil, any thoughts on comment 15?

Comment 17

[James Teh [:Jamie]]

The root widget for these popup windows returns null for GetParent(), but they have a "native" parent. I don't really understand why, but I think the parent widget gets passed as a native parent for some reason in nsBaseWidget::CreateChild:
https://searchfox.org/mozilla-central/rev/9aa7bebfd169bc2ead00ef596498a406e56bbb85/widget/nsBaseWidget.cpp#420
As to why we create a child, I think this is because we don't attach the nsDocumentViewer to the top level widget for popup windows (eWindowType_popup):
https://searchfox.org/mozilla-central/rev/9aa7bebfd169bc2ead00ef596498a406e56bbb85/layout/base/nsDocumentViewer.cpp#3648

Comment 18

[James Teh [:Jamie]]

Attachment: Bug 1427304: Return the oleacc window accessible for the outer HWND of windows created with popup=yes.

Comment 19

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/f65636dc2b12
Return the oleacc window accessible for the outer HWND of windows created with popup=yes. r=yzen

Comment 20

[Alexandru Michis [:malexandru]]

https://hg.mozilla.org/mozilla-central/rev/f65636dc2b12