Audit we never use chrome offset in OOP iframes (or drop chrome offset entirely)
Categories
(Core :: DOM: UI Events & Focus Handling, task, P3)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox85 | --- | fixed |
People
(Reporter: hiro, Assigned: hiro)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
We don't set the chrome offset for OOP iframes basically, but it's possible that we set it in BrowserParent::UpdateDimensions via BrowserParent::UpdatePosition calls.
I am not aware of any issues caused by this incorrect (I believe) chrome offset value, but we should make sure we don't use this value.
|
||
Comment 1•4 years ago
|
||
Tracking for Fission riding the trains to Beta (M7)
We're pretty sure we don't use this value. If we don't know of any user-visible bugs today, we don't need to fix before Fission Nightly (M6).
|
||
Comment 2•3 years ago
|
||
Hiro, should we try removing it to see if anything fails?
|
Assignee | |
Comment 3•3 years ago
|
||
I am not sure we can remove it entirely, a place I know of it will be problematic is we use the value as a fallback value at the moment when we haven't got the transform information from APZ. The chrome offset value is totally wrong in OOP iframe, but it's correct in the top level content document. So I am going to not set the offset in OOP iframes instead.
Let's see how it goes.
https://treeherder.mozilla.org/jobs?repo=try&revision=ec92cae19d14937d2bac5a630e857457785e3493
|
|
Assignee | |
Comment 4•3 years ago
|
||
The try result looks reasonable (unless I am missing some).
|
|
Assignee | |
Comment 5•3 years ago
|
||
Pushed by hikezoe.birchill@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/9755f95ce005 Don't set the chrome offset for OOP iframe's browser. r=hsivonen
|
||
Comment 7•3 years ago
|
||
| bugherder | ||
Description
•