1408638 - Crash in mozilla::a11y::RootAccessible::GetPrimaryRemoteTopLevelContentDoc

Status: VERIFIED FIXED

(Core :: Disability Access APIs, defect)

Description

[Alice0775 White]

This bug was filed from the Socorro interface and is 
report bp-d334b66c-f004-4130-8ba4-fc6ef0171014.
=============================================================

Reproducible: unknown

Steps To Reproduce:
1. Create new profile
2. Launch with the profile
3. Open Library window and Import Bookmarks from jsonlz4
4. Close the Library window

Comment 1

[James Teh [:Jamie]]

This is related to my patch in bug 1407475. If I'm reading this right, RootAccessible::GetPrimaryRemoteTopLevelContentDoc tries to get the DocShell, but it's null. What I don't understand is why it would be null. I can just check for that, but do I need to be concerned about the fact that it's null? Is that supposed to be possible? Alex, any ideas?

Comment 2

[Alice0775 White]

Reproducible: almost 100%

Steps To Reproduce:
1. Open https://bugzilla.mozilla.org/show_bug.cgi?id=564934 or large page( eg. http://www.ecma-international.org/ecma-262/7.0/index.html)
2. While the page is loading
2-1. Help > About Nightly
2-2. Close the about dialog
3. if not crash, repeat step 2

Comment 3

[Alice0775 White]

Attachment: about_support.txt

Comment 4

[James Teh [:Jamie]]

It's worth noting that this depends on the accessibility client in use. Not all clients cause this code to be called and I also don't know for sure *when* it is being called. I've tried to reproduce this manually using your steps and quickly calling the code in question, but I can't reproduce it. I'm going to try to patch it and provide a try build.

Comment 5

[Nicholas Nethercote [inactive]]

This is the #7 Windows topcrash in Nightly 20171013220204.

Comment 6

[James Teh [:Jamie]]

Ah. This is getting called on a window that has been closed, so the accessible is defunct and thus mDocumentNode is null. Sorry for the noise, Alex.

Comment 7

[James Teh [:Jamie]]

Attachment: Bug 1408638: Ensure accessible isn't defunct in Windows RootAccessibleWrap::accNavigate.

Bug 1407475 added support for accNavigate(NAVRELATION_EMBEDS) for e10s.
However, it's possible for a client to call this on the root accessible for a window which was since closed.
Therefore, we must check whether the root accessible is defunct before trying to retrieve the tab document.

Review commit: https://reviewboard.mozilla.org/r/189510/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/189510/

Comment 8

[James Teh [:Jamie]]

STR (with NVDA Python console):
1. In Firefox, press control+n to open a new window.
2. Press NVDA+control+z to open the NVDA Python console. (The foreground accessible at this point will be captured.)
3. Alt+tab back to the new Firefox window you just opened in step 1. Do *not* close the NVDA Python Console.
4. Close this second Firefox window.
5. Alt+tab back to the NVDA Python Console.
6. Enter this command:
fg.IAccessibleObject.accNavigate(0x1009, 0)

Without the patch, this crashes.
With the patch, it doesn't. :)

Comment 9

[Marco Zehe (:MarcoZ)]

Comment on attachment 8918704 [details]
Bug 1408638: Ensure accessible isn't defunct in Windows RootAccessibleWrap::accNavigate.

https://reviewboard.mozilla.org/r/189510/#review194720

r=me thanks!

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/e36b5e90262d
Ensure accessible isn't defunct in Windows RootAccessibleWrap::accNavigate. r=MarcoZ

Comment 11

[alexander :surkov (:asurkov)]

cool to see bug ni? bugs fixed before you looked at ni :) thank you for the fast fix, Jamie!

Comment 12

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

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

Comment 13

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Comment on attachment 8918704 [details]
Bug 1408638: Ensure accessible isn't defunct in Windows RootAccessibleWrap::accNavigate.

This crash fix is needed to uplift fix for bug 1407475, Beta57+

Comment 14

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-beta/rev/ce581d83a38e

Comment 15

[Alexandru Simonca [:asimonca], Release Desktop QA]

Hi,
I was trying to reproduce this bug to see if it was fixed and I got some tab crashes but their signature is different than this one. The odd thing is that I used the STRs from Comment #2. James, any thoughts?

Here are the reports:

https://crash-stats.mozilla.com/report/index/a4031ba7-b914-4103-840d-080450171020
https://crash-stats.mozilla.com/report/index/fa3b0aac-3d83-40f0-b159-8f29b0171020
https://crash-stats.mozilla.com/report/index/0d5421cf-674e-48aa-87f1-e17970171020
https://crash-stats.mozilla.com/report/index/0d5421cf-674e-48aa-87f1-e17970171020
https://crash-stats.mozilla.com/report/index/eaea7c20-190f-402b-bc91-8e0270171020

Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:58.0) Gecko/20100101 Firefox/58.0

Comment 16

[Alexandru Simonca [:asimonca], Release Desktop QA]

Reproduced and verified using the STR in Comment #8 on Windows 10 x64 with Firefox 58.0a1 (id: 20171019222141) and Firefox Beta 57.0b10.

Comment 17

[James Teh [:Jamie]]

(In reply to Alexandru Simonca, QA (:asimonca) from comment #15)
> I was trying to reproduce this bug to see if it was fixed and I got some tab
> crashes but their signature is different than this one. The odd thing is
> that I used the STRs from Comment #2. James, any thoughts?

Unfortunately, these crash reports are now gone. Sorry I missed this. I guess if they turn out to be a problem, a new bug will get filed.