1615151 - Audit we never use chrome offset in OOP iframes (or drop chrome offset entirely)

Status: RESOLVED FIXED

(Core :: DOM: UI Events & Focus Handling, task, P3)

Description

[Hiroyuki Ikezoe (:hiro)]

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

[Chris Peterson [:cpeterson]]

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

[Neha Kochar [:neha]]

Hiro, should we try removing it to see if anything fails?

Comment 3

[Hiroyuki Ikezoe (:hiro)]

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

Comment 4

[Hiroyuki Ikezoe (:hiro)]

The try result looks reasonable (unless I am missing some).

Comment 5

[Hiroyuki Ikezoe (:hiro)]

Attachment: Bug 1615151 - Don't set the chrome offset for OOP iframe's browser. r?hsivonen

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/9755f95ce005
Don't set the chrome offset for OOP iframe's browser. r=hsivonen

Comment 7

[Razvan Maries]

https://hg.mozilla.org/mozilla-central/rev/9755f95ce005