Waterfox: Cannot download blob: URL with e10s enabled

[laniakea64]

Environment

Waterfox 56.2.3
Linux x86_64
new profile

Steps to reproduce

1) Create a test WebExtension of these 3 files, and install it:

manifest.json

{
  "manifest_version": 2,
  "name": "Blob Test",
  "version": "1.0",
  "author":"laniakea64",

  "description": "Test download of blob URLs as a settings export",

  "options_ui": {
    "page": "options.html",
    "browser_style": true,
    "open_in_tab": true
  },

  "applications": {
    "gecko": {
      "id": "{cc57dad9-6fb2-4215-a734-8c0682d9d056}"
    }
  }
}

options.html

<script src="options.js"></script>
<button id="export">Export test</button>

options.js

let dummySettings={
  foo: 1,
  bar: "test"
};

function exportData() {
  let b = new Blob([JSON.stringify(dummySettings)], {type:'application/json'});
  let a = document.createElement('a');
  a.style.display='none';
  a.href = URL.createObjectURL(b);
  a.setAttribute('download', 'settings.json');
  document.body.appendChild(a);
  a.click();
  document.body.removeChild(a);
}


window.addEventListener('DOMContentLoaded', function() {
  document.getElementById('export').addEventListener('click', exportData, false);
}, false);

2) Tools > Add-ons Manager > Blob Test > Preferences, click "Export test"

Expected results

Should be prompted to download settings.json

Actual results

If e10s is disabled, it works fine. If e10s is enabled, the tab just goes blank and spins, and I never see the prompt for download. The spinning happens at/after the a.click().

MDN confirms that the e10s-disabled behavior is the correct behavior - https://developer.mozilla.org/en-US/docs/Web/HTML/Element/a#attr-download

Although HTTP(s) URLs need to be in the same-origin, blob: URLs and data: URLs are allowed so that content generated by JavaScript, such as pictures created in an image-editor Web app, can be downloaded.

Firefox 56.0.2 has the same issue. Firefox 62.0.2 doesn't hang, but it doesn't work either - it displays the data in the JSON viewer. Looks like the change in Firefox behavior occurred between Firefox 58 and 59.

Even if the current Firefox's behavior is the best we can do, that's still an improvement.

[Lorienna]

• https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=a538864efb28ae4c73f5abc979a182a971fe0d85&tochange=bbb02c1fccd69fa18900c5f57ee0261c341d4749

• Bug 1420419 - Extension page unresponsive when visiting a blob URL

[grahamperrin]

https://github.com/MrAlex94/Waterfox/commit/b1231ac8b9fe6a2aa639142966a1e1ac66408e6b

https://github.com/MrAlex94/Waterfox/commit/e03f3d5909f898594c5ccc387f8bd55c2199ea43

[Lorienna]

@grahamperrin, thanks :)

@laniakea64, switching extensions.webextensions.remote to true should help.

[laniakea64]

@grahamperrin Unfortunately those commits aren't part of Waterfox master.

@Lorienna Thanks, that helps a lot! With that change I get completely expected behavior even with e10s enabled.

Are there any known issues with flipping this pref?

[Lorienna]

@laniakea64 You're welcome.

Are there any known issues with flipping this pref?

Apparently, it might cause some rendering issues and break some addons.

[grahamperrin]

about:config?filter=extensions.webextensions.remote

Related Mozilla bugs include:

• 1190679 - (webext-oop) Run WebExtensions out of process – _Assigned_
• 1357487 - Turn on OOP extensions by default on Linux – _VERIFIED FIXED in Firefox 63_.

[grahamperrin]

aren't part of Waterfox master.

:-) I'm no longer sure how to tell whether something that was committed is actually effective. Bearing in mind the word 'master' for both commits.

[laniakea64]

I'm no longer sure how to tell whether something that was committed is actually effective.

I looked at what files were changed, then manually compared the changes in the commit(s) to the same lines/files in master.

[laniakea64]

Apparently setting extensions.webextensions.remote to true has the major drawback that console message from extensions don't get logged anywhere if the Browser Console isn't open at the very moment they're logged. This makes troubleshooting harder than it needs to be, so without a fix for this, flipping the pref is not really a solution for me. :frowning_face:

I tried porting over the patches from bug 1420419 to Waterfox, to at least get rid of the hang when extensions.webextensions.remote is false. In testing these patches I discovered that relevant changes to profiles may require a complete quit of Waterfox, then restart, before fully taking effect.

Testing my main profile, unfortunately the patches don't fix the hang for me. But with a new profile, the patches do fix the hang. Some troubleshooting found that it's apparently because I have Waterfox set to use 2 content processes. If I set to 1, then restart Waterfox as above, then the patches do their job in my main profile.

Why would multiple content processes result in circumventing the bug 1420419 patches?

Edit: Firefox 59 uses multiple content processes by default, and does not require setting to a single content process for this to work. I guess really fixing the hang requires more than just the bug 1420419 patches.

[Lorienna]

Would the patches work if you refresh a copy of your main profile in Safe Mode (see https://redd.it/9uzqru) and then increase the number of content processes?

Apparently setting extensions.webextensions.remote to true has the major drawback that console message from extensions don't get logged anywhere if the Browser Console isn't open at the very moment they're logged.

Are they logged somewhere in the current Firefox releases where extensions.webextensions.remote is true by default?

[laniakea64]

Would the patches work if you refresh a copy of your main profile in Safe Mode (see https://redd.it/9uzqru) and then increase the number of content processes?

It doesn't work in a clean profile, so I doubt this would help.

Are they logged somewhere in the current Firefox releases

Looks like not in Firefox 63.0.1. And same as with Waterfox, setting extensions.webextensions.remote to false fixes this problem.

I discovered that I can see the logged console messages for a specific addon if I go to about:debugging and debug the specific addon. But that doesn't show console messages from ALL the add-ons. And it only works for WebExtensions, it doesn't work with webext-hybrid addons.

[Lorienna]

@bakulf :wave: Hi, could you provide some insight into the issue we have here, please?

[laniakea64]

Although Waterfox Current was affected by this, it is no longer a significant issue in Waterfox Current, since:
1) extensions.webextensions.remote defaults to true,
2) some commit(s) in https://github.com/MrAlex94/Waterfox/compare/980ef6dbf7c115cd127b3388f961c6e322846dc1...2eef046647a7bc6309090d8f2231928dc33683d0 range caused setting extensions.webextensions.remote to false to break some extensions (I suspect https://github.com/MrAlex94/Waterfox/commit/a86fce2a1c89c6ecd41d5e92c4020728db52b0ac but don't have time to check),
3) the console messages issue with setting extensions.webextensions.remote to false is moot in Waterfox Current, since it doesn't support webext-hybrid - https://github.com/MrAlex94/Waterfox/issues/946