Closed Bug 1561570 Opened 1 year ago Closed 1 year ago

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


(Core :: DOM: Content Processes, defect)

68 Branch
Not set



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


(Reporter: Fanolian+BMO, Assigned: kats)




(Keywords: nightly-community, regression, reproducible)


(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.
  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.


  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)
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:

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

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

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
Ensure the BrowserChild is updated with the new chrome offset after fullscreen changes happen. r=rhunt
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla69

Thank you.


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.

I'm still experiencing this problem on Firefox 73.0.1 (64-bit) under macOS 10.14.6

(In reply to Justin Kaeser from comment #14)

I'm still experiencing this problem on Firefox 73.0.1 (64-bit) under macOS 10.14.6

Please file a new bug for it. The same problem may be caused by different things and if you're seeing it again it will need a fresh investigation.

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