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)

enhancement

Tracking

()

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

(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]
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.