[Affected versions]:

• 66.0b5 (20190204181317)
• 67.0a1 (20190206215551)

[Affected platforms]:

• Ubuntu 18.04 x64

[Steps to reproduce]:

1. Launch Firefox
2. Go to Menu-Customize
3. Drag some items to the Tab bar
4. Enable the Title bar
5. Click the Done button
6. Hover on the customized items inside the Tab bar

[Expected result]:

• Each item is highlight independently following the mouse hover action.

[Actual result]:

• Items are highlighted randomly.

[Regression range]:

• Last good revision: 1c227ac918eb1ab0b702d4424603faeb836f2b1c
  First bad revision: 64d38928ff5a59fb8214a0ee2472dccd6f16705d
  Pushlog:
  https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=1c227ac918eb1ab0b702d4424603faeb836f2b1c&tochange=64d38928ff5a59fb8214a0ee2472dccd6f16705d

[Additional Notes]:

• Dragging multiple items inside the Tab bar is not an essential condition, the issue can be observe on the Open a new tab button only.

Looks like the regression range pointed out to bug 1521012. Martin, can you please take a look? Thank you!

I tried to reproduce on latest nightly on Fedora 29 and Ubuntu 18.04 (VM) but the highlight is correct.

Close icon in tab is also not highlighted when hover over it. And mouse click does not work on the close icon.
It works if mouse pointer is located in near the bottom of the icon.

I see the same as Alice on Ubuntu 18.04 without moving anything into the tab bar, simply having the system titlebar enabled causes the tab bar click zones to be vertically misaligned. Ubuntu 18.10 is unaffected.

(In reply to Martin Stránský [:stransky] from comment #2)

I tried to reproduce on latest nightly on Fedora 29 and Ubuntu 18.04 (VM) but the highlight is correct.I reproduced this issue on two different machines with Ubuntu 18.04 installed.

I reproduced this issue on two different machines with Ubuntu 18.04 installed.

Other notes:

• I was not able to see the hover problem on Ubuntu 16.04.
• With Menu bar enabled the issue is not reproducible.
• Closing and reopening the browser with the same profile seams to fix the hover inconsistency.

Enabling the menu bar moves the problem from the tab bar to the menu bar which cannot be interacted with at all until the browser is restarted.

Does the behavior depend on profile state? When a fresh profile is created, can that be reproduced? My steps are (on Ubuntu 18.04):

1. Download latest nightly
2. Create a new profile
3. Launch it (titlebar is disabled by default)
4. Everything works fine and I can't reproduce it

For instance do you use WebRender?

STR:

1. Create clean Nightly 67 profile.
2. Enable native system titlebar (default disabled).
3. Hover cursor over top edge of an inactive tab and note lack of hover appearance.
4. Restart browser and note the bug no longer occurs.
5. Toggle off/on native system titlebar and note the bug reappears.
6. Enable menu bar and note that it is now affected rather than tab bar.

It also happens on Ubuntu 18.10 contradictory to my Comment #4 but the misalignment is not as large as 18.04.

Yes, I can see it now, Thanks. I'll look at it when I'm back from PTO.

This also locks the clickable region for all open windows, so if they are later resized and made bigger, the new areas cannot be interacted with. Newly created windows are unaffected.

Yes, I'm going to work on that, I can reproduce with steps from comment 9.

(In reply to Kestrel from comment #11)

This also locks the clickable region for all open windows, so if they are
later resized and made bigger, the new areas cannot be interacted with.
Newly created windows are unaffected.

That's very good point, Thanks. Yes, looks like there's an input shape leftover from CSD window mode although I can't find any.

I have a minimal testcase, filed as https://gitlab.gnome.org/GNOME/gtk/issues/1689

This should be fixed by Bug 1529713 for Gnome now.

(In reply to Martin Stránský [:stransky] from comment #16)

This should be fixed by Bug 1529713 for Gnome now.

Yes, this is fixed for me on latest Nightly (20190225014816) on Ubuntu 18.10.

Hey Martin, anything we can uplift here for 66? If not seems like we can close this out as works for me and live with the 66 issue.

(In reply to Jim Mathies [:jimm] from comment #18)

Hey Martin, anything we can uplift here for 66? If not seems like we can
close this out as works for me and live with the 66 issue.

I'm watching nightly for possible regressions and I'll create a minimal patch for 66 next week if everything goes well.

Did everything get into 66? Can the rest be deferred to 67?

(In reply to Liz Henry (:lizzard) (use needinfo) from comment #20)

Did everything get into 66? Can the rest be deferred to 67?

Yes, we're fine here, gnome (where the titlebar is enabled by default) is covered by Bug 1529713 for 66.

This works for me on 66.0b13 and 67.0a1 (2019-03-06) and has been verified by Bug 1529713 Comment #11.

Please leave it open - it's still here on WM which uses client side decorations (Mate/KDE for instance).

Martin, will the remaining fixes for this get in time for uplift to beta 67?

(In reply to Neha Kochar [:neha] from comment #24)

Martin, will the remaining fixes for this get in time for uplift to beta 67?

I don't think so. The bug is not on Firefox side - it's a bug in Gnome and I don't see any progress there.

Hi Martin, should we close this one? (alternatively, will it be fixed for 68?)

Bulk change to wontfix for 68 (P3+ carryover with needinfo).

Closing as we can't fix that.