[regression][nightly] Crash in developer tools console
Categories
(Core :: Privacy: Anti-Tracking, defect, P1)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr68 | --- | unaffected |
firefox74 | --- | unaffected |
firefox75 | --- | unaffected |
firefox76 | --- | verified |
firefox77 | --- | verified |
People
(Reporter: hiwatari.seiji, Assigned: timhuang)
References
(Regression)
Details
(Keywords: regression)
Attachments
(4 files)
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:76.0) Gecko/20100101 Firefox/76.0
Steps to reproduce:
- Open browser
- Right-Click -> Inspect Element
- Switch to Console tab
- Type a letter
Actual results:
Firefox crashed
Expected results:
Firefox should (probably) not have crashed :)
Reporter | ||
Comment 1•5 years ago
|
||
Backtrace I attempted to retrieve by running firefox nightly in gdb, and using bt full.
Reporter | ||
Comment 2•5 years ago
|
||
Screen capture of the crash.
(I've got no idea what the first two huge context menus were... that's the first time I've seen them. Maybe I right-clicked too early?)
Comment 3•5 years ago
|
||
Bugbug thinks this bug should belong to this component, but please revert this change in case of error.
Comment 4•5 years ago
|
||
Reporter's regression window from commemt#0 attachment:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=9b889a0ecb01af368c509d33cbba63514a9a0635&tochange=120c7c6a1961c2caf92d3eb2859048f50c23fc54
Updated•5 years ago
|
Reporter | ||
Comment 5•5 years ago
|
||
Hints:
This reproduces 100% of the time with my profile.
I was not able to reproduce it with a clean profile.
Assignee | ||
Comment 6•5 years ago
|
||
I suspect that this crash is introduced by this diagnostic assert.
Would you mind to upload the output log of Firefox? Thanks.
Reporter | ||
Comment 7•5 years ago
|
||
I'm afraid I don't know what you mean by output log.
If you mean what is written to stdout, stderr:
#n ######## periodic GC
#n ######## periodic GC
ExceptionHandler::GenerateDump cloned child 11143
ExceptionHandler::SendContinueSignalToChild sent continue signal to child
ExceptionHandler::WaitForContinueSignal waiting for continue signal...
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Maybe also the corresponding crashreport can help you. It at least points at the same line of code you did. (225)
Assignee | ||
Comment 8•5 years ago
|
||
Oh great, that's exactly what I meant.
The assertion is hit when we try to report a block for a system privilege window. It's weird since we should stop storage access check for about: URI, see here. The devtool window should use an about: URI, so it should not run into the assertion. But, for certain reason, the URI here is not an about: URI, so we hit the assertion later.
The reason why this assertion was not hit before Bug 1612378 is that the permission manager would allow anything for the system principal when we check the ContentBlockingAllowList permission. However, we change not to use the permission manager but use a pre-calculate flag. This flag would only be calculated for the document channel, so the chrome window won't have this flag since it is not loaded by the document channel. So, we would fail on the ContentBlockingAllowList check and end up with a block with a system privilege window. Which causes us to hit this assertion.
I am wondering if we should return early if we are checking storage access for a system privilege window in InternalStorageAllowedCheck. Because we should always allow access for a system privilege window.
What do you think, baku?
Updated•5 years ago
|
Assignee | ||
Comment 9•5 years ago
|
||
We turn the MOZ_DIAGNOSTIC_ASSERT() in NotifyBlockingDecision() to
MOZ_ASSERT() to prevent further crashes for users. And we will
investigate why this assertion is hit and check it back to a diagnostic
assertion once we figure out the reason.
Updated•5 years ago
|
Comment 11•5 years ago
|
||
Assignee | ||
Comment 12•5 years ago
|
||
The root cause of both this bug and bug 1623044 is the same. I think we should first change the assertion in this bug and further investigate this issue in Bug 1623044.
Updated•5 years ago
|
Comment 13•5 years ago
|
||
bugherder |
Updated•5 years ago
|
Updated•5 years ago
|
Updated•5 years ago
|
Comment 14•5 years ago
|
||
Unfortunately we can't reproduce the issue on clean profile, so therefore we won't be able to actually verify it it was fixed.
Hiwatari, could you please look over this on Beta and Nightly? (https://www.mozilla.org/en-US/firefox/channel/desktop/). Thanks!
Reporter | ||
Comment 15•5 years ago
|
||
I can't get it to crash again.
Seems to be fixed - at least for my profile.
Thanks!
Comment 16•5 years ago
|
||
(In reply to Catalin Sasca, QA [:csasca] from comment #14)
Unfortunately we can't reproduce the issue on clean profile, so therefore we won't be able to actually verify it it was fixed.
Hi Catalin,
You can try setting network.cookie.cookieBehavior
to 1, and see if you can reproduce this issue.
Comment 17•5 years ago
•
|
||
Thanks Hiwatari, and thanks Dimi Lee for the pref. I was able to reproduce the issue that way on Firefox Nightly (2020-03-26) under Ubuntu 18.04 (x64).
It is fixed on Firefox 76.0b8 and Nightly 77.0a1 (2020-04-23). Tests were performed under Windows 7 (x64), Ubuntu 18.04 (x64) and macOS 10.15.4.
Description
•