Closed Bug 1625251 Opened 5 months ago Closed 5 months ago

[regression][nightly] Crash in developer tools console

Categories

(Core :: Privacy: Anti-Tracking, defect, P1)

76 Branch
defect

Tracking

()

VERIFIED FIXED
mozilla76
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)

Attached file mozregression.log

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 :)

Attached file backtrace.log

Backtrace I attempted to retrieve by running firefox nightly in gdb, and using bt full.

Attached video screencapture.mkv

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?)

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Component: Untriaged → Console
Product: Firefox → DevTools

Hints:
This reproduces 100% of the time with my profile.
I was not able to reproduce it with a clean profile.

I suspect that this crash is introduced by this diagnostic assert.

Would you mind to upload the output log of Firefox? Thanks.

Flags: needinfo?(hiwatari.seiji)

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)

Flags: needinfo?(hiwatari.seiji)

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?

Flags: needinfo?(amarchesini)
See Also: → 1625395
Priority: -- → P1

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.

Assignee: nobody → tihuang

Is it a dup of bug 1623044 ?

Flags: needinfo?(amarchesini)
Pushed by tihuang@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/11de4f35419b
Stop using MOZ_DIAGNOSTIC_ASSERT when checking blocking decision. r=baku

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.

Status: UNCONFIRMED → RESOLVED
Closed: 5 months ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 76
See Also: → 1623044
Component: Console → Privacy: Anti-Tracking
Product: DevTools → Core
Target Milestone: Firefox 76 → mozilla76
Flags: qe-verify+

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!

Flags: qe-verify+ → needinfo?(hiwatari.seiji)

I can't get it to crash again.
Seems to be fixed - at least for my profile.
Thanks!

Flags: needinfo?(hiwatari.seiji)

(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.

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.

Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.