1318900 - [e10s a11y] Browser hang up when Open View Source if accessibility is activated on Win10

Status: RESOLVED WORKSFORME

(Core :: XPCOM, defect)

Description

[Alice0775 White]

[Tracking Requested - why for this release]: Page and UI hang

Build Identifier:
https://hg.mozilla.org/mozilla-central/rev/f09e137ead39230eaa94f47988ccce2cfcda4195
Mozilla/5.0 (Windows NT 10.0; WOW64; rv:53.0) Gecko/20100101 Firefox/53.0 ID:20161119030204

The problem is happen on Aurora52.0a2 and Nightly53.0a1.
The problem does not happen on Firefox53b1.
The problem does not happen if e10s is disabled.


Reproducible: very often (30/100)

Steps To Reproduce:
1. Clear Cache
2. Open web page (e.g., https://developer.mozilla.org/en-US/Add-ons/Code_snippets )
3. Right click on the page, Choose "View Page Source"
4. Wait finishing to load page

5. Try one or all of the following
5-1. Quickly scroll up and down with scrollbar or mouse wheel
5-2. Switch to the original tab
5-3. Close the "View Page Source" tab

6. Repeat Steps 1 to 5 if necessary


Actual Results:
   Browser will hang up for a long period at step 5


Expected Results:
   Not so

Comment 1

[Alice0775 White]

Regression window:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=bd9dc9379305055245e0751095b6e6bdeb214b32&tochange=fab432069073857f66824c73353a6067fb493286

Regressed by: fab432069073	Olli Pettay — bug 1306591, add secondary event queue to let high priority messages to be processed sooner, r=billm

Comment 2

[Alice0775 White]

Setting accessibility.force_disabled=1(it needs restart) seems fix the problem

Comment 3

[Alice0775 White]

Attachment: WinDbg log

Comment 4

[Alice0775 White]

Attachment: WinDbg log (2nd attempt)

Comment 5

[Alice0775 White]

And sometimes, it takes extremely long time to show the source. UI locks while loading of the source.

Comment 6

[Alice0775 White]

Attachment: about:support

Comment 7

[Alice0775 White]

FYI, Japanese IME(MS-IME and ATOK2016) is installed on Windows10.

Comment 8

[Andrew Overholt [:overholt]]

Maybe Bill or Thinker can take a look with Olli on vacation this week.

Comment 9

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

Aaron or Jim, could you take a look at this? Olli's patch changed around the order in which we process events so that vsync events are processed sooner. Looking at the windb log Alice posted, I see some a11y code on the stack (which I assume was captured when the 5 second hang happened):

006fdec8 599e5625 xul!mozilla::a11y::AccessibleWrap::FireWinEvent(class mozilla::a11y::Accessible * aTarget = 0x00000004, unsigned int aEventType = 0)+0x42 [c:\builds\moz2_slave\m-cen-w32-ntly-000000000000000\build\src\accessible\windows\msaa\accessiblewrap.cpp @ 1242]
006fdedc 58df9ce9 xul!mozilla::a11y::DocAccessibleParent::RecvShowEvent(class mozilla::a11y::ShowEventData * aData = 0x006fdf2c, bool * aFromUser = 0x006fdefd)+0x118 [c:\builds\moz2_slave\m-cen-w32-ntly-000000000000000\build\src\accessible\ipc\docaccessibleparent.cpp @ 68]
006fdf44 58dcd5c7 xul!mozilla::a11y::PDocAccessibleParent::OnMessageReceived(class IPC::Message * msg__ = 0x190a0f10)+0x229 [c:\builds\moz2_slave\m-cen-w32-ntly-000000000000000\build\src\obj-firefox\ipc\ipdl\pdocaccessibleparent.cpp @ 175]
006fecf8 58410c0d xul!mozilla::dom::PContentParent::OnMessageReceived(class IPC::Message * msg__ = 0x190a0f10)+0x4b [c:\builds\moz2_slave\m-cen-w32-ntly-000000000000000\build\src\obj-firefox\ipc\ipdl\pcontentparent.cpp @ 3069]
006fed14 58410ebf xul!mozilla::ipc::MessageChannel::DispatchAsyncMessage(class IPC::Message * aMsg = 0x000a0f10)+0x50 [c:\builds\moz2_slave\m-cen-w32-ntly-000000000000000\build\src\ipc\glue\messagechannel.cpp @ 1744]
006fed7c 584111b4 xul!mozilla::ipc::MessageChannel::DispatchMessageW(class IPC::Message * aMsg = 0x190a0f10)+0xb7 [c:\builds\moz2_slave\m-cen-w32-ntly-000000000000000\build\src\ipc\glue\messagechannel.cpp @ 1684]
006fed94 5841114f xul!mozilla::ipc::MessageChannel::RunMessage(class mozilla::ipc::MessageChannel::MessageTask * aTask = 0x190a0ef0)+0x53 [c:\builds\moz2_slave\m-cen-w32-ntly-000000000000000\build\src\ipc\glue\messagechannel.cpp @ 1573]

Comment 10

[Julien Cristau [:jcristau]]

tracking for 52 as a recent regression

Comment 11

[(No longer employed by Mozilla) Aaron Klotz]

This is... problematic when it comes to a11y code, as a whole bunch of a11y stuff that sends IPC messages is dispatched at vsync. OTOH, a11y also sends IPC calls immediately while handling some DOM events.

Since vsync now has priority, there are going to be a11y messages that are now being sent out of order.

I have strong suspicions that this is why I'm hitting assertions and am currently unable to land bug 1314707.

Comment 12

[(No longer employed by Mozilla) Aaron Klotz]

What's the solution here? Do we disconnect the NotificationController from the refresh driver and use something else?

Comment 13

[Olli Pettay [:smaug][[e-mail]]]

vsync priority shouldn't have caused "out of order". The order could have been anything before too.
Sure, it may have made it more likely.

Comment 14

[Alice0775 White]

Attachment: workaround.png

I found a workaround. Disabling "ATOKインサイト" fixes the hang.

Comment 15

[(No longer employed by Mozilla) Aaron Klotz]

What does this workaround do, exactly?

Comment 16

[(No longer employed by Mozilla) Aaron Klotz]

(ie, what are the options that you toggled supposed to do?)

Comment 17

[Alice0775 White]

(In reply to Aaron Klotz [:aklotz] from comment #16)
> (ie, what are the options that you toggled supposed to do?)

I am not sure, but
ATOK2016 scans whole texts in the current application. So that ATOK will suggest candidate words using normal dictionary and the scanned texts when I type few characters.
I imagine that ATOK seems to be using something a11y API for that purpose.

Comment 18

[Marcia Knous [:marcia]]

Tracking 53+ for this regression. Looks as if we still need an owner for this one.

Comment 19

[Ryan VanderMeulen [:RyanVM]]

(In reply to Aaron Klotz [:aklotz] from comment #11)
> I have strong suspicions that this is why I'm hitting assertions and am
> currently unable to land bug 1314707.

I've noticed that's since landed and been uplifted to 52. Maybe worth retesting?

Comment 20

[Alice0775 White]

[Tracking Requested - why for this release]:

Reproduced on 2016-11-19 build.

And nolonger reproduce on Nightly53.0a1(2017-01-11) and Aurora52.0a2(2017-01-11).

Comment 21

[Ryan VanderMeulen [:RyanVM]]

Thanks as always, Alice! :)