Whitelisting cross origin requests loaded from cross origin iframes breaks with Nightly's fission enabled

[ghost]

Prerequisites

• I performed a cursory search of the issue tracker to avoid opening a duplicate issue
  • Your issue may already be reported.
  • I also searched the existing issues at https://github.com/gorhill/uMatrix/issues
• This is not a support issue or a question
  • Support issues and questions are handled at /r/uMatrix
• I tried to reproduce the issue when...
  • uMatrix is the only extension
  • uMatrix with default lists/settings
  • using a new, unmodified browser profile
• I am running the latest version of uMatrix
• I checked the documentation to understand that the issue I report is not a normal behavior
• I used the logger to rule out that the issue is caused by my ruleset

Description

When loading an external iframe which loads requests from yet another domain, uMatrix blocks requests from the 3rd domain as if it were using the ruleset for the website in the iframe, not the website you loaded the frame from.

A specific URL where the issue occurs

(warning, may contain nsfw ads or links)
https://horriblesubs.info/ (or any site with a disqus embed I presume will work)

Steps to Reproduce

1. Fresh profile, Firefox Nightly, with pref "fission.autostart" set to true.
2. Visit https://horriblesubs.info/ and whitelist disqus.com (including frames) and disquscdn.com (multiple refreshes required)
3. The Disqus frame will not load, the logger will show the script request from disquscdn.com as coming from disqus.com as opposed to horriblesubs.info. The matrix ui shows a 1 under c.disquscdn.com though, as if it were loaded and whitelistable under the horriblesubs.info scope. Whitelisting disquscdn.com globally or on the disqus.com scope fixes the issue.

Ruleset

horriblesubs.info disqus.com * allow
horriblesubs.info disqus.com frame allow
horriblesubs.info disquscdn.com * allow

Supporting evidence

Your environment

• uMatrix version: uMatrix 1.3.17rc4
• Browser Name and version: Firefox Nightly 69.0a1 64bit 20190705161030
• Operating System and version: Windows 10 64bit Version 1903

[uBlock-user]

That doesn't happen on my end even without turning fission.autostart to true --

Nvm, it was content blocking trolling me.

[uBlock-user]

I cannot reproduce --

[ghost]

Mozregression, single build, moz-central, load 1.3.17rc4 umatrix.xpi, do not set fission.autostart to true, run build from 2019-07-05, navigate to https://horriblesubs.info/, whitelist disqus.com (and frames), hard refresh, whitelist disquscdn.com, hard refresh, scroll down the page to make sure the frame loads. result: disqus loads properly, logger shows
09:40:24 | horriblesubs.info |   | script | https://c.disquscdn.com/next/embed/lounge.load.3e8af7959bccec171b9bea4c5ef5f78f.js | 3p

same steps, except do set fission.autostart to true. disqus does not load, logger shows
09:43:21 | disqus.com | -- | script | https://c.disquscdn.com/next/embed/lounge.load.3e8af7959bccec171b9bea4c5ef5f78f.js | 3p

Edit: bonus step, go to about:support and make sure you see an entry "webIsolated=https://horriblesubs.info" under Remote Processes to make sure that fission is indeed active.

Now change scope to global, allow disqus.com (and frames) and disquscdn.com, hard refresh. Disqus loads.

Works every time for me.

[uBlock-user]

single build, moz-central

Are you running a bleeding-edge build of Firefox ?

same steps, except do set fission.autostart to true. disqus does not load

Done all that, no change, on my end it shows correctly as expected, that's why cannot reproduce.

[ghost]

Are you running a bleeding-edge build of Firefox ?

I did state in the title "Nightly", and the buildid in the original post is dated yesterday, so yes. The reason I reported it is because it seemed more like something that needed to be fixed on the umatrix side.

[uBlock-user]

I did state in the title "Nightly"

Bleeding-edge is different, it's not Nightly, but rather an untested, build dumped directly after compilation on moz-central servers.

Bleeding-edge builds are downloaded from https://treeherder.mozilla.org/#/jobs?repo=autoland

[ghost]

Bleeding-edge is different, it's not Nightly, but rather an untested, build dumped directly after compilation on moz-central servers.

Oh, no, not using autoland or building my own, sorry. Just regular Nightly.

[gorhill]

it seemed more like something that needed to be fixed on the umatrix side

How can you conclude this from using a new feature hidden being a new about:config entry in what is expected to be the least stable built of a browser? Chromium already supports per-process frames and I cannot reproduce any issue with stable Chromium.

[uBlock-user]

FYI fission is a core component of Firefox which recently went in development, so if its happening on your build, I won't be surprised. It's unstable and not supposed to be enabled via about:config in the first place.

[ghost]

How can you conclude this from using a new feature hidden being a new about:config entry in what is expected to be the least stable built of a browser? Chromium already supports per-process frames and I cannot reproduce any issue with stable Chromium.

I assumed that either that was the implementation they're going with and umatrix would need to adjust, or that at the very least, when umatrix itself is showing that scripts from discuscdn.com are whitelisted, that the logger would show the same and allow the scripts through. Considering fission is going to be implemented in firefox sooner or later, I didn't figure it would hurt to be quick (relatively) about reporting things. Sorry if I've wasted your time.

[uBlock-user]

Fission related bugs - https://bugzilla.mozilla.org/buglist.cgi?f1=cf_fission_milestone&o1=equals&v1=Future

[gorhill]

I didn't say I won't investigate, just that it's pointless to conclude anything before investigating.

[gorhill]

The issue is that the parentFrameId (ref) of the Disqus CDN request is set to -1 by Nightly instead of the frame id of the Disqus frame.

There is code which was added in the past in uMatrix to deal in a special way with network requests which parentFrameId is -1 while the page hostname is different than the documentUrl, to fix issues with workers (ref).

So essentially, there is no way to fix this without breaking the other issue. The webRequest documentation is clear, parentFrameId should be properly set, fission or not, while now its value tells extensions that the frame is not being embedded in a parent document.