Closed Bug 1408638 Opened 2 years ago Closed 2 years ago

Crash in mozilla::a11y::RootAccessible::GetPrimaryRemoteTopLevelContentDoc

Categories

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

58 Branch
x86_64
Windows 10
defect
Not set
critical

Tracking

()

VERIFIED FIXED
mozilla58
Tracking Status
firefox-esr52 --- unaffected
firefox56 --- unaffected
firefox57 --- verified
firefox58 --- verified

People

(Reporter: alice0775, Assigned: Jamie)

References

Details

(Keywords: crash)

Crash Data

Attachments

(2 files)

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
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?
Flags: needinfo?(surkov.alexander)
Assignee: nobody → jteh
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
Attached file about_support.txt
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.
This is the #7 Windows topcrash in Nightly 20171013220204.
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.
Flags: needinfo?(surkov.alexander)
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 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!
Attachment #8918704 - Flags: review?(mzehe) → review+
Pushed by mzehe@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/e36b5e90262d
Ensure accessible isn't defunct in Windows RootAccessibleWrap::accNavigate. r=MarcoZ
cool to see bug ni? bugs fixed before you looked at ni :) thank you for the fast fix, Jamie!
https://hg.mozilla.org/mozilla-central/rev/e36b5e90262d
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla58
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+
Attachment #8918704 - Flags: approval-mozilla-beta+
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
Flags: needinfo?(jteh)
Reproduced and verified using the STR in Comment #8 on Windows 10 x64 with Firefox 58.0a1 (id: 20171019222141) and Firefox Beta 57.0b10.
Status: RESOLVED → VERIFIED
(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.
Flags: needinfo?(jteh)
You need to log in before you can comment on or make changes to this bug.