Open
Bug 1513673
Opened 7 years ago
Updated 3 years ago
nsHttpChannel::AsyncOpen2 (mixed content blocker) runs observable JS while in stable state
Categories
(Core :: DOM: Security, enhancement, P3)
Core
DOM: Security
Tracking
()
NEW
People
(Reporter: jya, Unassigned)
References
(Blocks 1 open bug)
Details
(Whiteboard: [domsecurity-backlog])
Not sure if it's a DOM::Security issue or a DOM::Image nsHttpChannel::AsyncOpen2 is called from various spots, of interest from HTMLImageElement::LoadSelectedImage which is a task queued on the stable state queue.
And we end up there:
https://searchfox.org/mozilla-central/rev/3160ddc1f0ab55d230c595366662c62950e5c785/netwerk/protocol/http/nsHttpChannel.cpp#6147
which will load NS_CheckContentLoadPolicy and end up running some JS
a stack trace can be seen here:
https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=216630809&repo=try&lineNumber=51735
Comment 1•7 years ago
|
||
Looks like the mixed content blocker trying to update the addressbar icon/state.
This is old code. is the assertion new? did something else change that triggered it?
Flags: needinfo?(jyavenard)
Summary: nsHttpChannel::AsyncOpen2 runs observable JS while in stable state → nsHttpChannel::AsyncOpen2 (mixed content blocker) runs observable JS while in stable state
Reporter | ||
Comment 2•7 years ago
|
||
(In reply to Daniel Veditz [:dveditz] from comment #1)
> Looks like the mixed content blocker trying to update the addressbar
> icon/state.
>
> This is old code. is the assertion new? did something else change that
> triggered it?
There's no systematic assertion (for now) and rare crashes could be triggered (as seen in bug 1443429).
It's reviewing the code that pointed out to this problem.
As it is, AsyncOpen2 can run in stable state and will make the state "non-stable) see bug 1513582 for more details.
Flags: needinfo?(jyavenard)
Comment 3•7 years ago
|
||
(In reply to Jean-Yves Avenard [:jya] from comment #2)
There's no systematic assertion (for now) and rare crashes could be
triggered (as seen in bug 1443429).
It's reviewing the code that pointed out to this problem.
Since this is not a pressing issue at the moment I'll put it in the backlog for now. If this becomes more serious and we see more crashes we can change the priority of it.
Priority: -- → P3
Whiteboard: [domsecurity-backlog]
Updated•3 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•