Closed
Bug 1408638
Opened 7 years ago
Closed 7 years ago
Crash in mozilla::a11y::RootAccessible::GetPrimaryRemoteTopLevelContentDoc
Categories
(Core :: Disability Access APIs, defect)
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)
(deleted),
text/plain
|
Details | |
(deleted),
text/x-review-board-request
|
MarcoZ
:
review+
ritu
:
approval-mozilla-beta+
|
Details |
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
Assignee | ||
Comment 1•7 years ago
|
||
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 | ||
Updated•7 years ago
|
Assignee: nobody → jteh
Reporter | ||
Comment 2•7 years ago
|
||
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
Reporter | ||
Comment 3•7 years ago
|
||
Assignee | ||
Comment 4•7 years ago
|
||
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•7 years ago
|
||
This is the #7 Windows topcrash in Nightly 20171013220204.
Assignee | ||
Comment 6•7 years ago
|
||
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)
Comment hidden (mozreview-request) |
Assignee | ||
Comment 8•7 years ago
|
||
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•7 years ago
|
||
mozreview-review |
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+
Comment 10•7 years ago
|
||
Pushed by mzehe@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/e36b5e90262d
Ensure accessible isn't defunct in Windows RootAccessibleWrap::accNavigate. r=MarcoZ
Comment 11•7 years ago
|
||
cool to see bug ni? bugs fixed before you looked at ni :) thank you for the fast fix, Jamie!
Comment 12•7 years ago
|
||
bugherder |
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla58
status-firefox57:
--- → affected
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+
Updated•7 years ago
|
status-firefox56:
--- → unaffected
status-firefox-esr52:
--- → unaffected
Comment 14•7 years ago
|
||
bugherder uplift |
Comment 15•7 years ago
|
||
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)
Comment 16•7 years ago
|
||
Reproduced and verified using the STR in Comment #8 on Windows 10 x64 with Firefox 58.0a1 (id: 20171019222141) and Firefox Beta 57.0b10.
Updated•7 years ago
|
Assignee | ||
Comment 17•7 years ago
|
||
(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.
Description
•