Closed
Bug 1366567
Opened 7 years ago
Closed 7 years ago
HTTP transactions don't always have the correct content outer window id set
Categories
(Core :: Networking: HTTP, defect, P1)
Core
Networking: HTTP
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: mayhemer, Assigned: mayhemer)
References
Details
(Whiteboard: [necko-active])
No description provided.
Updated•7 years ago
|
Assignee: nobody → honzab.moz
Whiteboard: [necko-active]
![]() |
Assignee | |
Comment 1•7 years ago
|
||
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.
![]() |
Assignee | |
Comment 2•7 years ago
|
||
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.
You need to log in
before you can comment on or make changes to this bug.
Description
•