RFP: orientation spoofs and iframes
Categories
(Core :: CSS Parsing and Computation, defect)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox149 | --- | fixed |
People
(Reporter: thorin, Assigned: pierov)
References
(Blocks 1 open bug)
Details
Attachments
(3 files)
In Bug 1607032 and Bug 1918202 we limited device orientation spoofs to primary results (based on our screen dimension spoofs) - there is no additional entropy as it's still based on our spoofed values - it was to make our spoof "spec compliant" and benign (non-paradoxical). Note that android uses a different angle value to desktops
This is similar to Bug 1885101 where we had to patch iframes to return the spoofed screen etc dimensions: i.e Match screen and window properties with top window.
Something similar is happening here - we're not adjusting the iframe's expected value based on our spoofs
- On desktop it always seems to report
{"mozOrientation":"portrait-primary","orientation.angle":90,"orientation.type":"portrait-primary"}regardless of the iframe's dimensions
STR:
- control
- disable RFP and have device on desktop in landscape mode
- run PoC
- everything should match e.g.
{"mozOrientation":"landscape-primary","orientation.angle":0,"orientation.type":"landscape-primary"}
- enable RFP
- make the window landscape (so RFP spoofs as landscape, which you already are)
- run PoC
- document (top window) is fine (landscape), but the three different sizes iframes all report portrait
| Reporter | ||
Updated•6 months ago
|
| Reporter | ||
Comment 1•6 months ago
|
||
Updated•6 months ago
|
Comment 2•5 months ago
|
||
The severity field is not set for this bug.
:boris, could you have a look please?
For more information, please visit BugBot documentation.
Updated•5 months ago
|
| Assignee | ||
Comment 3•2 months ago
|
||
I think I found the problem: GetTopInnerSizeForRFP() needs to always be called with the top browsing context, i.e., bc->Top()->GetTopInnerSizeForRFP() instead of bc->GetTopInnerSizeForRFP(), which is what the various orientation calls do.
I could send a patch to change all of them (as well as a test based on Thorin's attachment), but I don't understand whether the name is just a bit unlucky, or if a mechanism for actually setting the actual top size is missing.
Emilio: I've seen that you commented as a reviewer on Bug 1885101 where this was added, perhaps can you answer my question?
Comment 4•2 months ago
|
||
Hmm, agreed that the name is a bit unlucky. What other fields do is adding a slightly more convenient accessor that goes through Top(), e.g. here.
Maybe do that? Maybe combined with a rename of TopInnerSizeForRFP to something else, but I don't have any good suggestion off-hand.
| Assignee | ||
Comment 6•2 months ago
|
||
Also, rename the TopInnerSizeForRFP for better clarity.
Comment 8•2 months ago
|
||
| bugherder | ||
| Reporter | ||
Comment 9•2 months ago
|
||
verified fixed on desktop, can't test on android yet, which has different angles
Description
•