Modifing XHR request created in content script not work

RESOLVED WORKSFORME

Status

P3
normal
RESOLVED WORKSFORME
a year ago
3 months ago

People

(Reporter: crimsteam, Unassigned)

Tracking

55 Branch

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [webRequest] triaged)

Attachments

(1 attachment)

(Reporter)

Description

a year ago
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:53.0) Gecko/20100101 Firefox/53.0
Build ID: 20170413192749

Steps to reproduce:

I import content script via manifest, set   "permissions": ["webRequest","webRequestBlocking","<all_urls>"] and try intercept xhr request making in content script by background script via browser.webRequest.onBeforeRequest to redirect to another page but its failed, my original xhr request is executed. The same is when I try canceling request, it still executed.

Problem not exist when I make XHR in background script, redirecting and canceling works fine. Blocking this mechanism for xhr in content script is intentional?
(Reporter)

Comment 1

a year ago
Hmm, sorry, directly invoking xhr in background script also failed, but works if we do it manually by click on icon:
browser.browserAction.onClicked.addListener(make_xhr);
My make_xhr is the same code in background script, content script and browser action handler, but only xhr from the last was intercepted. I see that onBeforeRequest handler catch this request but returned object with "cancel" or "redirectUrl" properties has no influence on it.
(Reporter)

Comment 2

a year ago
Next observations:
- in background script it works but we must add some delay for XHR, without that we not invoke onBeforeRequest handler, so:

browser.webRequest.onBeforeRequest.addListener();
make_xhr;

not work, but this work:

browser.webRequest.onBeforeRequest.addListener();
setTimeout(function(){make_xhr}, 0);

- in content script it always not work, even when we use some delay, and I also noticed that obj intercepted by onBeforeRequest handler has undefined for originUrl and documentUrl properties:
{requestId: "49", url: "http://www.test.com/", originUrl: undefined, documentUrl: undefined, method: "GET", tabId: -1, type: "xmlhttprequest", timeStamp: 1493614787142, frameId: 0, parentFrameId: 0 }

When it works we see:
{ requestId: "50", url: "http://www.test.com/", originUrl: "moz-extension://71aca46d-8c43-40b8-…", documentUrl: "moz-extension://71aca46d-8c43-40b8-…", method: "GET", tabId: -1, type: "xmlhttprequest", timeStamp: 1493614893326, frameId: 284, parentFrameId: 284 }

Updated

a year ago
Whiteboard: [webRequest] investigate
Flags: needinfo?(mixedpuppy)
Modifying an xhr from a content script is not necessarily intentionally blocked, but it is rather complicated and not a priority.

Notes for self and/or future:

WebRequest.jsm canModify checks loadingPrincipal.URI.  As the principal in this case is an expanded principal, that is null and and modification of the request is prevented.  This would take some wrangling of sub-principals in C++ to make work.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(mixedpuppy)
Priority: -- → P3
Whiteboard: [webRequest] investigate → [webRequest] triaged
Created attachment 8863579 [details] [diff] [review]
content xhr test

test for future reference
(Reporter)

Comment 5

a year ago
One more thing, obj in onBeforeRequest for content script xhr request also contains "tabId: -1", it should be not tabID where this script was running? From doc:
"tabId
    integer. ID of the tab in which the request takes place. Set to -1 if the request isn't related to a tab"
https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/webRequest/onBeforeRequest
Now we can't diagnose from which tab the request comes (we don't have expose tabID in content script directly, we can get this through the message channel, but it takes some extra time).
unable to reproduce with the attached test after updating for today's code.
Status: NEW → RESOLVED
Last Resolved: 5 months ago
Resolution: --- → WORKSFORME

Updated

3 months ago
Product: Toolkit → WebExtensions
You need to log in before you can comment on or make changes to this bug.