Closed Bug 1366567 Opened 4 years ago Closed 4 years ago

HTTP transactions don't always have the correct content outer window id set

Categories

(Core :: Networking: HTTP, defect, P1)

defect

Tracking

()

RESOLVED WONTFIX

People

(Reporter: mayhemer, Assigned: mayhemer)

References

(Blocks 1 open bug)

Details

(Whiteboard: [necko-active])

No description provided.
Assignee: nobody → honzab.moz
Whiteboard: [necko-active]
I can observe this for the top level load (having tabid=0, pretty bad, but understandable since there simply may not be a window for it soon enough) and probably xhr induced loads (again, tabid=0, have to confirm where from those loads are coming exactly).

Since there are also OCSP loads not having a window id (tabid=0) I think a simple workaround may be to simply never consider tabid=0 as background and only throttle such loads when explicitly set the Throttleable class.  Updates and other requests made by chrome code also have tabid 0.  Some of them we may want to throttle (updates), some not.  Hence, I would rather go with explicit marking then treating all tabid=0 loads as bck loads.
I was mistaken about content originated transactions not having an id.

I can only confirm this for a top level load in a newly open tab (there is simply no window at the moment we are creating the channel).

Regarding bug 1365307 this has been worked around very simply.

Regarding connection manager's allocation algorithm, we are OK too, since such loads are 'urgent-start', hence no limit for them (would be considered background tab loads)

WONTFIXing based on that.
No longer blocks: 1365307
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.