Injected content script XHR calls made in background context?

Hello,

I am seeing a very interesting thing which broke my add-on. From the release version 48 (? suspect something to do with the e10s changes). I start to see that all my injected script’s XHR fail to do anything, not even showing up in the network panel of the dev tools.

This has nothing to do with the permission, as I have tested with <all_urls> so I definitely have host permission, all other aspects of injected scripts work except XHRs.

I stripped down my add-on to the bare and things still doesn’t work. Then I realized that I was using relative path for sending the XHRs - e.g. /hello instead of https://www.example.org/hello. This used to work well, now I am forced to fetch the full URL and then compose to the right path in full for any XHRs.

This is very annoying, as I expect injected content script to exist in the content page context and function just like one embedded in the original page - then XHRs would work with relative path.

Digging further, I found out that all the XHRs made in injected script don’t show in the network panel of the dev tools any more. Instead, I found them showing up in the debugging dev tools for add-ons: moz-extension:///_generated_background_page.html.

This lead me to believe that now Firefox run all the XHRs of the injected content script in the context of the background script?

This explains why the relative request path no longer work as it is not in the context of that content page any more.

Does any one know why this is the case? I am sure there are more people using XHRs that got hit with this change. It also affects the browser behavior to a 401 Unauthorized response, before (and in Chrome) I will see a builtin browser pop up asking you to input credentials and it will send the same requests automatically with your credentials, now the first request just fail after getting a 401 - I guess the background script can’t trigger the browser pop up for authentication.

Thanks very much!

Some code for demo, based off borderify.js:

manifest.json

{
  "description": "Adds a solid red border to all webpages matching mozilla.org. See https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Examples#borderify",
  "manifest_version": 2,
  "name": "Borderify",
  "version": "1.0",
  "homepage_url": "https://github.com/mdn/webextensions-examples/tree/master/borderify",
  "icons": {
    "48": "icons/border-48.png"
  },
  "permissions": [
    "tabs", "<all_urls>"
  ],
  "background": {
    "scripts": ["background.js"]
  },
  "browser_action": {
    "browser_style": true,
    "default_title": "XHR Test"
  }
}

background.js

browser.browserAction.onClicked.addListener(function(tab) {
    browser.tabs.executeScript({file: "borderify.js"}); 
});

borderify.js

/*
Just draw a border round the document.body and send an XHR
*/
document.body.style.border = "5px solid red";

var xhttp = new XMLHttpRequest();
xhttp.onreadystatechange = function() {
    if (this.readyState == 4 && this.status == 200) {
       console.log(xhttp.responseText);
    }
};
xhttp.open("GET", "https://developer.mozilla.org/en-US/Add-ons/WebExtensions/What_are_WebExtensions", true);  // if URL is relative it just don't do anything, and no error given
xhttp.send(); // this will show up in network panel of the add-on debugging dev tools not the dev tool of the tabs you activated this add-on

This sounds similar to my issue with XMLHttpRequest…
https://discourse.mozilla-community.org/t/webextension-xmlhttprequest-issues-no-cookies-or-referrer-solved/11224

1 Like