Forward nsILoadInfo.requestBlockingReason to the parent process for both old and new redirect channels
Categories
(Core :: Networking, defect, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox71 | --- | fixed |
People
(Reporter: mayhemer, Assigned: mayhemer)
References
Details
(Whiteboard: [necko-triaged])
Attachments
(1 file)
This means to include nsILoadInfo.requestBlockingReason
in LoadInfoToChildLoadInfoForwarder/MergeChildLoadInfoForwarder
functions.
![]() |
Assignee | |
Updated•6 years ago
|
![]() |
Assignee | |
Comment 1•6 years ago
|
||
Updated•6 years ago
|
![]() |
Assignee | |
Comment 2•6 years ago
|
||
![]() |
Assignee | |
Comment 3•6 years ago
|
||
(In reply to Honza Bambas (:mayhemer) from comment #2)
Rather try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=97b3589a5bb3c0cf51e700e02865e9372879b825
(This is try for Diff 1) - fails number of mochi and wp tests. More work to do :/
![]() |
Assignee | |
Comment 4•6 years ago
|
||
running toolkit/components/extensions/test/xpcshell/test_ext_redirects.js
locally, we fail here:
https://searchfox.org/mozilla-central/rev/23f836a71cfe961373c8bd0d0219ec60a64b3c8f/ipc/glue/BackgroundUtils.cpp#942
aLoadInfo->GetReservedClientInfo() is some.
added in Bug 1441932
either we can't do a source channel load info's merge in HttpChannelParent::RecvRedirect2Verify
or this is something unexpected. Andrew?
note that another solution for this bug is to send up just the reason and set it on the source channel li, separately.
![]() |
Assignee | |
Comment 5•6 years ago
|
||
OK, I'm going to land the latest version which only updates the blocking-reason and nothing else. The latest try looks good:
https://treeherder.mozilla.org/#/jobs?repo=try&collapsedPushes=511147%2C509985%2C511151&revision=8891a6d25d62145143da7fe2bb3ead7b3d30f567
Comment 7•6 years ago
|
||
bugherder |
Description
•