Closed Bug 1561570 Opened 4 months ago Closed 4 months ago

Tooltips for elements in WebExtensions sidebar are misplaced after entering a fullscreen video

Categories

(Core :: DOM: Content Processes, defect)

68 Branch
All
Windows
defect
Not set

Tracking

()

VERIFIED FIXED
mozilla69
Tracking Status
firefox-esr60 --- unaffected
firefox-esr68 --- wontfix
firefox67 --- unaffected
firefox68 --- wontfix
firefox69 --- verified
firefox70 --- verified

People

(Reporter: Fanolian+BMO, Assigned: kats)

References

(Regression)

Details

(Keywords: nightly-community, regression, reproducible)

Attachments

(3 files)

Attached image sidebar tooltip.png

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:69.0) Gecko/20100101 Firefox/69.0
Build ID: 20190625215814

After entering and exiting fullscreen of a video, the tooltip when hovering on an element in a WebExtension's sidebar is no longer placed under the cursor.
The issue is much worse when the sidebar is put on the right side.

Steps to reproduce

  1. Start Nightly 2019-05-07 build or onwards.
  2. Install a WebExtension that utilizes sidebar, e.g. Tree Tabs.
  3. Open a tab containing a video, e.g. https://interactive-examples.mdn.mozilla.net/media/examples/flower.webm.
  4. Hover on the tab on Tree Tabs tabbar. Tooltip should appear under the cursor.
  5. Enter fullscreen through video control.
  6. Exit fullscreen.
  7. Hover on the tab on Tree Tab tabbar again.

Actual result

(Please refer to the attached screenshot. It is taken with another extension Tree Style Tab.)
Tooltip appears afar from the cursor.

Expected result

Tooltip should appear under the cursor.

Notes

  1. Entering a tab fullscreen (F11) does not exhibit the issue. Actually it fixes the problem (see point 2).
  2. WORKAROUND: Re-activating the extension, either by closing/re-opening sidebar, disabling/re-enabling the extension, switching to another sidebar item and back, F11, etc., will fix the issue.
  3. Tooltips from other Nightly's default sidebar items, e.g. Bookmarks, History, are not affected.

This may affect all WebExtensions that utilizes sidebar. I tested Tree Tabs, Tree Style Tab, Sidebery, Side View, Open in Sidebar and they are all affected.

Has Regression Range: --- → yes
Has STR: --- → yes
Flags: needinfo?(kats)
Regressed by: 1062609

Hm, the change pointed to by bisection seems very unrelated to the symptoms you're describing. But I can take a look.

Assignee: nobody → kats
Flags: needinfo?(kats)
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true

I was able to repro on Windows easily with Tree Style Tab and the Rick Astley video on Youtube (you need a video with a long enough title that it's not completely visible in TST for the tooltip to show up).

I re-bisected using 2019-05-05 as "good" and 2019-05-08 as "bad", and got this range:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=036a4b9e84262578b682d6e36ac60416db334d07&tochange=4abfc5c2a4ee418302a99a2662a78f88b84d44b9

Which makes a lot more sense in that it actually deals with transform matrices and might plausibly be related.

Status: ASSIGNED → NEW
Component: Layout → DOM: Content Processes
Regressed by: 1533673
No longer regressed by: 1062609

Verified the regressor in a local build by restoring the early-exit from https://hg.mozilla.org/integration/autoland/rev/4abfc5c2a4ee418302a99a2662a78f88b84d44b9#l1.16

This also explains why I was only seeing this on Windows and not on Mac, since it's specific to the GPU process.

OS: Unspecified → Windows
Hardware: Unspecified → All

The transform matrix being provided by APZ to BrowserParent/BrowserChild is the same before entering and after exiting fullscreen mode, which seems correct to me. But the BrowserChild's GetChromeOffset() goes from nonzero before entering fullscreen to zero after exiting fullscreen (I think because it gets a RecvUpdateDimensions call while in fullscreen but not after exiting fullscreen. So prior to my patch BrowserChild would be using the zero translation matrix after exiting fullscreen, and with my patch it's using the APZ translation matrix which is nonzero.

Effectively I think my patch exposed a "two bugs canceling each other out" scenario that was pre-existing in the code, by eliminating one of the bugs.

Triggering the UpdateDimensions message on fullscreenchange seems to fix the problem, but I don't know this code well enough to say if there's a better fix closer to the root cause that might catch other similar cases. I'll put up a patch with my fix and if somebody has a better suggestion I'm happy to try it.

Apparently the GetChromeOffset() in BrowserChild becomes stale after exiting
fullscreen, but it's not clear to me what is supposed to keep it updated. So
this patch adds a fullscreenchange event listener that updates it. If we
encounter other scenarios where this happens maybe we can find a better way
to do this but without more knowledge of the scenarios this is the best option
I have.

Pushed by kgupta@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/4f8400c7d8e5
Ensure the BrowserChild is updated with the new chrome offset after fullscreen changes happen. r=rhunt
Status: NEW → RESOLVED
Closed: 4 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla69

Thank you.

Status: RESOLVED → VERIFIED

Verified and confirmed the fix on both Windows 64- bit and Ubuntu 64 -bit on FF Nightly 70.0a1 (20190710215049) and FF Beta 69.0b3 (20190708182549).

On FF 68.0 (20190705220548) the issue was reproducible, as expected.

Extensions tested with: Tree Tabs and SideBerry.
Tested with the original example video and also on YouTube videos on each browser version.
Please see the attached GIF.

This seems edge-case enough that we probably don't need to worry about it for ESR68, but I'm willing to listen if anyone strongly disagrees with that.

You need to log in before you can comment on or make changes to this bug.