CSS types not injecting into iframes

[quoid]

CSS type userscripts are not injecting into sub-frames. When a parent frame has a sub frame that requests a css file, the css is injected into the parent frame, not the requesting sub frame.

Should check for frameId on the API_ADD_STYLE_SYNC request.

related: #151

[lslqtz]

Now I know that Safari may not support frameId.

If that's right, would this parameter allFrames help alleviate the problem? But the question is whether Safari does not support this parameter either. The problem I can imagine is that it will cause two functions (@match and @include) to fail for the embedded iframe.

Anyway, thanks for the discovery, hope Safari will support these sooner.

[quoid]

If that's right, would this parameter allFrames help alleviate the problem?

Possibly, I will test that when trying to solve this issue. Thanks for the suggestion.

[quoid]

@lslqtz

I changed the way css injected in the above commit. Instead of using tabs.insertCSS, a style element is created and added to the head of the document (similar to how css injection happened prior to the update).

It seems that allFrames would not be a good solution, so I had to come up with something else. I doubt Safari will ever support cssOrigin or frameId for insertCSS, but I did see scripting.insertCSS has support for it's equivalent frameId value, which is the target object. However, it still lacks support for origin and I am not ready to make the move to manifest V3.

Note: that the execution of the Javascript that create the style element in the document happens in the isolated content script scope, so it shouldn't be blocked by content security policies.

[ACTCD]

It seems that UserCSS is the same as UserScript, in addition to the CSP problem, there is also the problem of injection timing. When UserCSS cannot be injection in stabilized and early enough timing, users will face unpleasant rendering flickering problems, and when UserScript cannot be injection in stabilized and early enough timing, cannot prevent some aggressive behaviors of page scripts.

It seems that currently solving these problems can only be achieved by some Mitm tools, it is not the best layer to solve the browsing experience, but it seems to be the only way to ensure these problems are solved in stable and early enough, and without being affected by browsing limits and constraints of the extension API. I still hope users to be able to personalize and optimize their browsing experience by solving most problems in simply scripting environment at the browser level.

[ACTCD]

I would like to update here with some new information that I have read. According to WWDC2022 Apple's introduction to the newly introduced APIs in manifest v3, and their updated related documentation page shows:

[manifest v3]
scripting.executeScript
injectImmediately not supported.
scripting.insertCSS
origin, allFrames, frameIds not supported.
scripting.removeCSS
origin, allFrames, frameIds not supported.

[manifest v2]
tabs.executeScript
matchAboutBlank, runAt not supported.
tabs.insertCSS
matchAboutBlank, runAt, cssOrigin, allFrames, frameId not supported.
tabs.removeCSS
frameId, allFrames, matchAboutBlank, cssOrigin not supported.

[quoid]

I am both unsurprised and shocked that such integral parts of the API are still lacking.