Closed
Bug 1226691
Opened 9 years ago
Closed 9 years ago
Support modifying headers in chrome.webRequest.onHeadersReceived
Categories
(WebExtensions :: Untriaged, defect, P2)
WebExtensions
Untriaged
Tracking
(Not tracked)
RESOLVED
DUPLICATE
of bug 1232849
People
(Reporter: george, Assigned: ma1)
References
(Blocks 1 open bug)
Details
(Whiteboard: [webRequest] triaged)
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.86 Safari/537.36
Steps to reproduce:
https://developer.mozilla.org/en-US/docs/Mozilla/JavaScript_code_modules/WebRequest.jsm#Chrome_incompatibilities
I am requesting the ability to modify headers in onHeadersReceived. This would allow for similarity to the Chrome WebRequest extension API.
Actual results:
Can't modify request.
Expected results:
The ability to modify the request.
Component: Untriaged → WebExtensions
Product: Firefox → Toolkit
Whiteboard: [webRequest]
Updated•9 years ago
|
Flags: blocking-webextensions?
Priority: -- → P2
Whiteboard: [webRequest] → [webRequest] triaged
Updated•9 years ago
|
Assignee: nobody → g.maone
Flags: blocking-webextensions? → blocking-webextensions+
Assignee | ||
Updated•9 years ago
|
Assignee | ||
Comment 1•9 years ago
|
||
https://developer.mozilla.org/en-US/docs/Mozilla/JavaScript_code_modules/WebRequest.jsm#Chrome_incompatibilities is quite out of date:
* We do support onBeforeRedirect (bug 1215197, my first patch landed after quite a long time :) )
* We currently support requestId (bug 1163862)
* Fixing bug 1163862 also allowed redirecting from onBeforeRequest, while bug 1231512 should take care of onHeadersReceived (we should add WebExtensions-specific tests, though)
* Supporting for modifying headers in onHeadersReceived existed, but was broken by bug 1232849 which, on the bright side, has already a patch waiting for review ;)
* onErrorOccurred is tracked by bug 1252596, which I'm gonna fix soon
So I think this very bug is either a dupe of bug 1232849 or a bug in the documentation of WebRequest.jsm, which is actually a pain to keep in sync because the most "visible" work happens on the WebExtensions surface, even if this module is still its back-end (same happens for tests, which nowadays are written directly against the chrome.webRequest wrapper).
Status: UNCONFIRMED → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
Updated•6 years ago
|
Product: Toolkit → WebExtensions
You need to log in
before you can comment on or make changes to this bug.
Description
•