getComputedStyle doesn't reflect injected stylesheet during page load inside an iframe
Categories
(Core :: DOM: CSS Object Model, defect)
Tracking
()
People
(Reporter: eight04, Unassigned)
Details
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.169 Safari/537.36
Steps to reproduce:
- Install https://github.com/eight04/webextension-test/tree/iframe-get-computed-style as an unpacked extension
- Visit https://cards.barclaycardus.com/
- Press F12 and open the console
Actual results:
During the first load, I get something like:
The second load (F5):
Look at the report on authenticate/home/..., which shows ["", "", "", "1", "1"]. It seems that getComputedStyle doesn't recalculate the style during the page load.
If you open the iframe to a new tab then it works fine.
Expected results:
On Chrome Version 78.0.3903.0 (Official Build) canary (64-bit):
Off-topic: In our extension, we need to detect if the page is blocking inline styles. Is there a more reliable way other than this one?
Didn't know that images are not allowed. Here are the links:
The first load:
https://i.imgur.com/qxWWSC0.png
The second load (F5):
https://i.imgur.com/zLHYDsL.png
Chrome:
https://i.imgur.com/EcARcmT.png
|
||
Comment 2•5 years ago
|
||
Reproduced the issue by comparing results between https://cards.barclaycardus.com/ and the authenticate iframe opened in new tab (step1 extension in debug mode ) using 71.0a1 20190910095613, 70.0b4 20190905174512 and 69.0 20190827005903 with Ubuntu 16.04/ Windows 10.
Won't rush to dupe it since I'm uncertain if it's the case, but IMO, this report is similar to bug 1471231, so in order to get a confirmation on this, I'm going to initially triage it to DOM: CSS Object Model.
Emilio, could you please take a look over this? Might be you could also advise on the eight04 off-topic question:
Off-topic: In our extension, we need to detect if the page is blocking inline styles. Is there a more reliable way other than this one?
|
||
Comment 3•5 years ago
|
||
Yeah, it seems like the iframe is hidden during page load, so we don't compute styles in there, which is fundamentally bug 1471231.
This is a somewhat long-standing Gecko limitation, but it's also a long-standing specification issue: it's unclear how media-queries should evaluate in a display: none iframe, for example.
Blink / WebKit seem to just mint a 0x0 viewport, etc... But minting values like screen size / resolution in a multi-monitor setup looks pretty fishy.
Anyhow, I guess what you want is to know if whether the inline styles are applied at all, as in, whether a frame is sandboxed or inline style is blocked via CSP, right?
If so, yeah, there's a better way to do it: Appending an empty style element to the document, and checking for yourStyleElement.sheet being non-null should be way better, not causing useless style recalcs (which will improve performance, specially if you want to know this during page load), and as a side-effect it would avoid depending on this behavior (the CSSWG, including Google folks, showed interest for adopting Gecko's behavior here, see the discussions in https://github.com/w3c/csswg-drafts/issues/1548).
If there's a case that that check doesn't account for, I'd be curious to know :)
PS: From the test-case, I suspect the extension is stylus? If so, nice work, I really like it ^.^
checking for yourStyleElement.sheet being non-null
Thanks, we will try it.
I suspect the extension is stylus?
Yes :D
Description
•