Open Bug 1596140 Opened 5 years ago Updated 1 year ago

Wrong div title tooltip showing up when displaying several tooltips in a row

Categories

(Core :: XUL, defect, P3)

72 Branch
defect

Tracking

()

UNCONFIRMED

People

(Reporter: sdescarpentries, Unassigned)

Details

Attachments

(2 files)

Attached file wrong_tooltip_bug.html

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0

Steps to reproduce:

Load the attached .html page in Firefox 72.0a1 2019-11-12.
Hovers the div A, when every goes well it shows an "A" tooltip.
Then go down to B.
Then go down to C.

Actual results:

Chances are that the tooltip for C will be B.
(you may have to try a few times 2-3… but it can also show up the 1st time).

Expected results:

Each div should have its own tooltip, each time.

I cannot reproduce the problem in 72.0a1 (2019-11-14) (64 bits) on Win10 1909.

I tried with 72.0a1 (2019-11-14) (64 bits) on GNU/Linux Debian 10.1, XFCE, to title bar, dark theme.

I had the correct tooltips going backward from A to C.
Then went from C to B, and no more tooltips.
I tried several times, reloaded the page several time, then tried from C (nothing), B (got C tooltip).

But it's not the only problem, as I had difficulties to click on the Help menu to confirm the Nightly version I used for the test.
The highlighting of the menus have an offset regarding the mouse pointer position, which could explain the tooltip problem in the short configuration I provided.

As it is not the configuration with wich I discovered this problem, I provide a new test case.
With "wrong_tooltip_bug_2.html" I went from C to A. Got C tooltip, B tooltip, but no A.
Then changed tab to write the previous line, went back to the test tab, went from A to C, got no tooltip on A and B, and got a tooltip on C with showing a B…
No other manipulations where needed this time.

Add some <br/> between the <div> to avoid current mouse pointer offset problem.

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

Hi,

I have tested your issue on latest FF release 70.0.1, Beta 71.0b9 and latest Nightly build 72.0a1 (2019-11-15) and could not reproduce it using Windows 10 and Ubuntu 18.04, dark theme and default theme.

If the issue is still reproducible on your end, can you please retest this using latest FF release and latest Nightly build (https://nightly.mozilla.org/) and report back the results? When doing this, please use a new clean Firefox profile (https://goo.gl/AWo6h8), maybe even safe mode (https://goo.gl/AR5o9d), to eliminate custom settings as a possible cause.

Further, I am assigning a component to this issue in order to involve the development team and get an opinion on this. If is not the correct component please feel free to change it to an appropriate one.

Thanks for the report.

Component: Untriaged → DOM: Core & HTML
Flags: needinfo?(sdescarpentries)
Product: Firefox → Core
  • Using a new empty profile avoids the problem.
  • Restarting Firefox current nightly with my normal profile but in safe mode avoids the problem.
  • Deactivating all my addons manually does not solve the problem.
  • Restarting Firefox with all the addons deactivated does not solve the problem.
  • Deinstalling 30% of my addons did not solve the problem.

The symptoms of no-tooltips or tooltip-from-another-element and selection-not-right-under-the-cursor of the mouse still seems linked.

I've lost all my pinned tabs deactivating Firefox Multi-Account Container.
I can't narrow down to which addon might cause the troubles.
I'm using dark theme and compact density.
I don't now what safe mode is doing better than deactivating my addons, but it looks like the solution is here.

Flags: needinfo?(sdescarpentries)

Couldn't reproduce the issue. Neither with current Nightly nor with the current developer edition.

Component: DOM: Core & HTML → XUL

The priority flag is not set for this bug.
:bgrins, could you have a look please?

For more information, please visit auto_nag documentation.

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

Setting priority is no longer part of current triage processes, clearing needinfo.

Flags: needinfo?(bgrinstead)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: