Open Bug 1392182 Opened 2 years ago Updated 2 years ago

Label CompleteResumeRunnable

Categories

(Core :: Networking, enhancement, P3)

enhancement

Tracking

()

People

(Reporter: bevis, Assigned: kershaw)

References

(Blocks 1 open bug)

Details

(Whiteboard: [necko-triaged])

The CompleteResumeRunnable shows up recently in the top unlabeled runnable list:
https://gist.github.com/bevis-tseng/d8a918cb53112a82357c872ce15ee790
We'll need this one to be labeled in priority, thanks!
(Only 2 % of runnables are unlabeled now!)
Kershaw, do you think you could find time to do this?  You've already fixed a lot of labeling bugs, so it should be fairly easy for you.  Feel free to bounce back.
Assignee: nobody → kechang
Whiteboard: [necko-active]
@bevis, do you know how to reproduce this issue?

The event target used to dispatch CompleteResumeRunnable is actually assigned at HttpChannelChild::SetEventTarget [1]. Unfortunately, it's not always successful to get a labeled event target by nsContentUtils::GetEventTargetByLoadInfo.
So, we need to know who opens this http channel and figure out why we can't get an event target from load info.

[1] https://searchfox.org/mozilla-central/rev/18c16ebf818abb86805ce08a6e537e4cd826f044/netwerk/protocol/http/HttpChannelChild.cpp#2427
Flags: needinfo?(btseng)
According to the comment inside |nsContentUtils::GetEventTargetByLoadInfo|, it could be an add-on XHR.

Hi :billm,

Does it make sense to fallback this use case with SystemGroup?
That's is if all the add-on script run in SystemGroup, then we could label this runnable using SystemGroup as well.
If web content could be touched by add-on script, it seems that there is not much we can do here.

BTW, the ratio of unlabeled CompleteResumeRunnables to all CompleteResumeRunnables is about 0.66% according to the telemetry analysis.
Flags: needinfo?(btseng) → needinfo?(wmccloskey)
Note: labeling percentage improvement of fixing this bug is 0.0185791288429%, current labeling status is 98.14%, goal is 99%:
https://gist.github.com/bevis-tseng/5ea8ae73c7260e0166924ea7c8c9c63d
Without actually knowing what is causing these loads, I'd rather not use SystemGroup here. If it really is caused by add-ons, then the percentage should decrease on beta when legacy add-ons are completely disabled.
Flags: needinfo?(wmccloskey)
Bulk priority update: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: -- → P1
Kershaw: needed for 57, or is this a P2?
Flags: needinfo?(kechang)
Whiteboard: [necko-active]
This is a P2.
Flags: needinfo?(kechang)
Priority: P1 → P2
Whiteboard: [necko-triaged]
Priority: P2 → P3
You need to log in before you can comment on or make changes to this bug.