Closed Bug 1676020 Opened 4 years ago Closed 2 years ago

Title tooltips flash off immediately

Categories

(Core :: Widget: Gtk, defect, P3)

Product:
Core
Component:
Widget: Gtk
Version:
Firefox 81
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
103 Branch
Tracking Flags:
Tracking Status
firefox-esr91 --- wontfix
firefox-esr102 --- fixed
firefox101 --- wontfix
firefox102 --- wontfix
firefox103 --- fixed

People

(Reporter: naddy, Assigned: emilio)

References

(Regression)

Details

(Keywords: regression)

Attachments

(2 files)

big-titlebar-context.png
165.56 KB, image/png
Details
Bug 1676020 - Fix client offset computation on X11. r=karlt,stransky
48 bytes, text/x-phabricator-request
dmeehan
: approval-mozilla-esr102+
Details | Review

User Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:82.0) Gecko/20100101 Firefox/82.0

Steps to reproduce:

Starting with Firefox 81, title tooltips for web content are not properly displayed for me. A canonical test case would be the mouseover text of xkcd.com, but something as simple as <span title="foo bar">foo bar</span> will do.

It only occurs with web content. Tooltips for the browser UI are not affected.

It is 100% reproducible for me. It also happens with a new profile.

I observe this on two different machines, a desktop and a laptop, running FreeBSD and OpenBSD, respectively. Apparently most people on these platforms cannot reproduce the problem. There is one other FreeBSD user who can.

The problem has been introduced with this change:
"Avoid unnecessary coordinate conversions when showing tooltips,"
https://hg.mozilla.org/mozilla-central/rev/9b17a5aeded6590078ba7bad625d126a9cf3edd0

When I rebuild the latest Firefox 82.0.2 with the above change reverted, the problem is gone.

Printf-debugging in docshell/base/nsDocShellTreeOwner.cpp shows that the tooltip disappears because ChromeTooltipListener::HandleEvent() receives a "mouseout" event and calls HideTooltip(). With the abovementioned change reverted, these "mouseout" events do not happen.

Actual results:

The tooltip is shown and immediately hidden again. This happens so quickly that the tooltip text can't be read.

Expected results:

The tooltip should be displayed until the mouse is moved.

Are you running at something other than 100% zoom?

(In reply to Robert Longson [:longsonr] from comment #1)

Are you running at something other than 100% zoom?

I am not. I also verified that "scaleFactor", which was used in the coordinate conversion, was 1.0.

Regressed by: 1566422
Has Regression Range: --- → yes

On an amd64 machine, fresh FreeBSD 12.2-RELEASE which has Firefox 82.0.2, new profile, I also see the flashing tooltips, with something as simple as <html><a title=tooltip>text</a></html>, while hovering over "text".

I'm also experiencing this same issue on Debian Linux using the Notion window manager. Another user reported the same issue with the Sawfish window manager, which I was able to reproduce under Xephyr. I don't see this issue with the Fluxbox window manager. A known workaround is to enter full-screen mode. See our discussion on https://github.com/raboof/notion/issues/295 for more details.

I independently hg bisect-ed to the same patchset that Christian identified (9b17a5aeded6), which is how I found this report.

Christian and Bill, which window managers were you using?

Flags: needinfo?(naddy)

I use ctwm as my window manager.

Using full screen mode does not eliminate the flashing tooltips for me.

BTW, I upgraded to 82.0.3 and the problem is (not surprisingly) still there.

I use mwm.
A quick test with other window managers at hand shows that the problem also exists with twm and fvwm 2.2.5.

I don't see the issue with cwm.

Flags: needinfo?(naddy)

Another data point: Tooltips close to the bottom of the screen (less than an inch on my screen) do not flash, even though tooltips elsewhere on the page do. People might want to check if this is just me, or whether it's generic. And it might not just be the one edge....

Great point, Bill. I see the same thing near the bottom of my screen: when the tooltips are drawn above the cursor instead of below, they stick around. When looking at that, I noticed the tooltip above the cursor seemed a bit too far above the cursor (about 45 real pixels above my cursor). Then I noticed that my context menu in the page area also seems to be offset awkwardly in height. I found that by changing the size of the Notion window manager title bar font, this placement error increases. This affects even the changeset before the one in question. Conversely, by making the title bar font unreadably small, the tooltip flashing problem goes away (even in Firefox 82).

I've attached a screenshot showing a titlebar that is about 630px high, causing a context menu that is offset by nearly the same amount. This was taken with changeset f56158e0fd57 built from source, just before the changeset that started the tooltip flashing. I right-clicked where the cursor is in the screenshot, and the menu appeared about 630px higher than it should have. This was running under the Notion window manager with a slightly modified theme:

 de.defstyle("tab", {
      font = "xft:Source Sans Pro:size=400",
      ...
 }

So, I think the problem here is whatever is causing the popups (including tooltips and the context menu) to be offset by the size of titlebar.

I also see that the bug only occurs for tooltips drawn "below" the cursor. The application I'm using draws variable sized tooltips and, if I position a line just right, the shorter ones on the line flash "below" the cursor and the longer ones stick above the cursor. Note that "below"--a close examination shows that the flashing tooltips are actually positioned slightly above the cursor, so that the cursor actually is within the tooltip. Maybe someone who knows the source can fudge it to position the tooltip so that it is actually below the cursor and then test to see if the problem is still there. (I downloaded the source last night, but I'm not sure my machine is even big enough to compile it. :) )

I see that the entire screen coordinates for mouse events are incorrect. See the example on https://developer.mozilla.org/en-US/docs/Web/API/MouseEvent/screenY that displays the coordinates. Under Notion and Sawfish (at least) with exaggerated window title sizes, the screenY coordinate incorrectly excludes the size of the window title.

This is the ~/.sawfish/custom file I was testing with, changing the 200 to different values:

(custom-set-typed-variable (quote styletab-c:title-dimension) (quote 200) (quote symbol))
(custom-set-typed-variable (quote default-frame-style) (quote StyleTab) (quote frame-style))

Run this or similar:

Xephyr :9 -screen 1280x1280 
sawfish --display=:9

I didn't see erroneous mouseY coordinates with the Fluxbox window manager, running with ~/.fluxbox/overlay:

window.title.height: 100

I believe we need to find the source of these erroneous coordinates. Since small titlebars don't appear to have the tooltip flashing issue, I think that would solve all of it.

Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:82.0) Gecko/20100101 Firefox/82.0

Hi,

I will move this over to a component so developers can take a look over it. If this is not the correct component please feel free to change it to an appropriate one.

Thanks for the report.

Component: Untriaged → DOM: Navigation
Product: Firefox → Core

(In reply to Alin Ilea from comment #11)

I will move this over to a component so developers can take a look over it. If this is not the correct component please feel free to change it to an appropriate one.

Hi Alin, I think the component "Window Management" would be a closer fit than "DOM: Navigation". Could you or someone update it? I don't seem to have permission. Thanks.

Severity: -- → S3
Flags: needinfo?(kmadan)
Priority: -- → P3

I've also been experiencing this bug (using Sawfish on XFCE, though discussion here makes it sound as if Sawfish is the important part). I managed to do an afternoon of investigation of my own and raise bug #1680920 before finding this existing issue.

I have one thing to add to the commentary above. I tried to replicate ongardie's findings by making a window have a ludicrously huge title bar. But unlike them, I told Sawfish to reset the frame style of just one window instead of changing the WM-wide default. So I had an existing Firefox window on which tooltips were appearing a few pixels too high so that the mouse pointer was inside them, and immediately dismissing themselves. I reset that one window to the StyleTab frame style (in Sawfish) and ran (setq styletab-c:title-dimension 200) in sawfish-client.

Initially there was no change at all: the tooltips popped up in exactly the same place as they had in my usual frame style. But then I dragged the reconfigured window, and after that, now the tooltips are 200 pixels up in the air, so they miss the mouse pointer again and don't auto-disappear.

I speculate that Firefox didn't notice any difference at the moment the frame style was reconfigured, but when the window moved, it updated its idea of where its own top left corner was on the screen. So it's not querying the top left frame corner at the moment of putting up the popup; it's cached it from the last time it noticed its own window moving.

(Coming here from https://bugzilla.redhat.com/show_bug.cgi?id=2026317.)

I'm seeing the same issue. I have also independently narrowed down the regression to Firefox 81. I also confirm that, if the mouse and the link are positioned near the bottom of the screen, such that the tooltip is displayed above the mouse pointer, the tooltip does not flash off.

I can reproduce the issue in icewm (1.3.7-9.el7). I cannot reproduce it in gnome-shell (3.28.3-34.el7_9).

The issue affects the latest ESR release (91.4.0esr).

(In reply to ongardie from comment #4)

A known workaround is to enter full-screen mode.

Entering full screen mode with F11 works the issue around for me as well (on icewm).

(In reply to ongardie from comment #10)

I see that the entire screen coordinates for mouse events are incorrect. See the example on https://developer.mozilla.org/en-US/docs/Web/API/MouseEvent/screenY that displays the coordinates. Under Notion and Sawfish (at least) with exaggerated window title sizes, the screenY coordinate incorrectly excludes the size of the window title.

I see the exact same symptom under IceWM, and not just with exaggerated window title sizes, but with my normal TitleBarHeight=20 setting in my icewm theme. For example, when the Y coordinate of my mouse pointer is 950, the screenY demo linked above reports it as 930.

Staring a bit at https://hg.mozilla.org/mozilla-central/rev/9b17a5aeded6590078ba7bad625d126a9cf3edd0, here's my theory:

  • The code in browser/base/content/browser.js (that is, the conversion from widget-relative coordinates back to screen-relative coordinates) had been correct, but (perhaps) unnecessary.
  • The code in docshell/base/nsDocShellTreeOwner.cpp had been broken for out-of-process frames, possibly; however, for in-process frames, it must have had a very important property. Namely, my theory is that self->mMouseScreenY and screenDot.y were both broken on the less widely used window managers (both values being off by WM title bar height), however, the subtraction between them canceled out this error. In other words, for in-process frames at the least, the difference (the widget-relative) coordinates were ultimately correct. (Assuming scaleFactor=1 anyway.)

Eliminating the subtraction unmasked the bias in self->mMouseScreenY.

(In reply to Laszlo Ersek (RH) from comment #15)

The issue affects the latest ESR release (91.4.0esr).

https://hg.mozilla.org/mozilla-central/rev/9b17a5aeded6590078ba7bad625d126a9cf3edd0 cleanly reverts on top, and that solves the issue for me.

FWIW, the problem is still present in Firefox 100.

I was just pointed to this bug - I've had the same thing and had assumed it was something broken in my profile, but hints here have shown it's my windowmanager.

I'm running pekwm, and the advice about fullscreen as a workaround works for me too. From that, I determined that removing the window decorations (border and titlebar) ALSO acted as a workaround.

From that, I've been able to do some experimenting.

With an 18 pixel high titlebar, and a four pixel boxer (on all four border - including the top where the 18pixel titlebar is), then tooltips flash off immediately, except at the bottom of the screen when firefox places the tooltip above the cursor. In that situation, the tooltip remains on fine.

Toggling the border (so: only an 18pixel titlebar at the top), and tooltips stay on all the time.
Instead, toggling the titlebar (so 4pixel boxer on all four sides), and tooltips also stay on.

Reducing the titlebar to 17 pixel height: same behaviour.

Reducing the titlebar to 16 pixel height: the problem no longer occurs even with both borders AND titlebar enabled (ie, 20 pixel decoration at top, and 4 pixel decoration on all other sides.

Trying in the other direction:

  • a 20 pixel titlebar, and no border = no problem
  • a 21 pixel titlebar, and no border = problem occurs (except at bottom of screen)

With this, I hope I've demonstrated that there is a specific threshold of window decoration size below which the problem does not occur - this means I have a long-term workaround for myself, and hopefully additional information for developers.

Note that I have not experimented with wider/thinner borders, only 4px or none.

tl;dr:

  • a ≤20 pixel vertical displacement of the window by the windowmanager -> fine.
  • a ≥21 pixel vertical displacement... -> problem.

This testing was done with firefox 100.0.2, and pekwm 0.1.17 on Ubuntu 20.04

Redirect a needinfo that is pending on an inactive user to the triage owner.
:hsinyi, since the bug has recent activity, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(u608768) → needinfo?(htsai)

FWIW I've been running firefox in RHEL-7.9 for 6 months now with the upstream commit noted in comment 18 reverted. A few days ago, RHEL7 updated firefox from 91.4.0 to 91.10.0 -- I'm now building the new version with the revert rebased.

FWIW, I'm running 101.0, using the ctwm window manager, and still have the problem.

Hey Emilio, Kashav seemed to not have a chance to look a bit at this regression. Do you perhaps have quick thoughts on this? (Asking as you were the reviewer for bug 1566422). Thanks.

Flags: needinfo?(htsai) → needinfo?(emilio)

Okay, so, for reference... This only seems to happen in some X11 window managers. Most importantly, it doesn't happen on either Wayland nor GNOME / KWin.

I can repro in ctwm. Looking.

Assignee: nobody → emilio
Flags: needinfo?(emilio)

The root cause of the issue is that screen coordinates in the child
process are not quite right.

E.g, with a window on the top left, with window manager borders of 5px
each, the screenX on a simple test-case like:

<!doctype html>
<pre id="log"></pre>
<script>
  const log = document.getElementById("log");
  document.addEventListener("mousemove", function(e) {
    log.innerText = `${e.screenX}, ${e.screenY}\n`;
  });
</script>

Shows screenX of 0 instead of the expected frame border width which is
correct for e.g., document.documentElement.screenX in the browser
toolbox (parent process).

It seems this is because we don't have a correctly-computed client
offset (the client offset is zero, when instead it should be
(border-width, titlebar-height).

The coordinate space of mBounds is weird AF, but it seems it is expected
that mBounds.TopLeft() are the top left of the outer window, while
mBounds.Size() is the inner size, and mClientOffset is what compensates
between the two.

I've tested this on GNOME and KDE (though nowadays those use borderless
windows, so client offset should ~always be zero), on ctwm (which is
where I could reproduce the issue), and on Sway (which has borders but
it's Wayland. As expected we end up with a client offset of zero there).

The implementation of RecomputeClientOffset() should ensure that we work
with an internally-consistent coordinate space.

Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true

(In reply to Emilio Cobos Álvarez (:emilio) from comment #26)

Created attachment 9280152 [details]

I can confirm that this fixes the problem for me. Firefox 101.0, mwm as window manager.

Pushed by ealvarez@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/8f9e7afa0819
Fix client offset computation on X11. r=stransky,jhorak

https://hg.mozilla.org/mozilla-central/rev/8f9e7afa0819

Status: ASSIGNED → RESOLVED
Closed: 2 years ago
status-firefox103: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 103 Branch

This bug should be in the Widget: Gtk component.

Flags: needinfo?(emilio)

Sure

Component: DOM: Navigation → Widget: Gtk
Flags: needinfo?(emilio)

Please nominate this for ESR102 approval when you get a chance.

Flags: needinfo?(emilio)

Comment on attachment 9280152 [details]
Bug 1676020 - Fix client offset computation on X11. r=karlt,stransky

ESR Uplift Approval Request

  • If this is not a sec:{high,crit} bug, please state case for ESR consideration: Relatively simple fix, fixes basic functionality in some Linux setups.
  • User impact if declined:
  • Fix Landed on Version: 103
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): It simplifies the code and is not too complex of a patch.
Flags: needinfo?(emilio)
Attachment #9280152 - Flags: approval-mozilla-esr102?

Comment on attachment 9280152 [details]
Bug 1676020 - Fix client offset computation on X11. r=karlt,stransky

Approved for 102.1esr.

Attachment #9280152 - Flags: approval-mozilla-esr102? → approval-mozilla-esr102+

Confirming for posterity that the Firefox 103 (rolled out by normal self-upgrade means) fixes this in my environment too :)

Yes, same here. A great relief! Of course now it will take me weeks to get out of the habit of triggering my usual workaround :-) but many thanks.

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

Attachment

General

Creator:
Created:
Updated:
Size: