Closed Bug 644952 Opened 9 years ago Closed 7 years ago

Bookmarks Sidebar mousover tooltip incorrect if preference layout.css.devPixelsPerPx;1.17 is user set


(Core :: XUL, defect, minor)

Windows XP
Not set



Tracking Status
firefox23 --- verified
firefox24 --- verified
firefox25 --- verified


(Reporter: John99, Assigned: jfkthame)



(Keywords: regression, Whiteboard: [bugday-20110401])


(4 files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv: Gecko/20110319 Firefox/3.6.16 ( .NET CLR 3.5.30729; .NET4.0E)
Build Identifier:  -2.0/rev/6be9e31d01b4

This is only with bookmarks displaying in the sidebar, and after preference layout.css.devPixelsPerPx; has been set to a none default value.Specifically I have tried with value 1.17.
I can reproduce this consistently, but it only occurs on some bookmarks not all bookmarks.

The tooltip relates to bookmarks above the one that has mouse hover. The tooltip appearing contradicts the details on botton left where the status bar.  used to be. 

I have included a couple of screenshots.

Reproducible: Always

Steps to Reproduce:
1.You will need some saved or recently saved bookmarks, as examples I have used some of the default bookmarks.
2. Set the user preference layout.css.devPixelsPerPx; to 1.17 ( I have not tested other values )
3. Display the menu toolbar, then for the sidebar select bookmarks
4. Hover the mouse pointer over bookmarks, some of the bookmarks will give contradictory information at the tooltip. 

Actual Results:  
On some bookmarks the tooltip information clearly does not match the bookmark that is hovered over, the information does match some other bookmark higher up the listing. 

The tooltip information should also match the statusbar type information, it does not, but the statusbar type information is correct and matches the bookmark that has mouse over.

Expected Results:  
The tooltip information should relate to the bookmark on which the mousepointer is hovering.
The information displayed in the tooltip should match the information in the bottom left where the status bar information used to be.

This is a truly minor bug, and many users will not now attempt in firefox 4 to use the sidebar bookmarks, even then it only appears if a layout preference has been set. The bug is of interest only if it relates to more serious issues.

This is not happening in firefox 3.6.16, ( ) it is happening in Firefox 4.( target i686-pc-mingw32 )
I did use safemode and a new profile.

I will add a couple of annotated screenshots. The bookmarks I used were some of the default ones, as I tried to make an easily recreated test. 

I discovered this problem because another user reported the problem on a Mozilla support page, the user reporting the problem also included a screenshot illustrating this problem. 

The support forum threads are (&  )
Version: unspecified → 4.0 Branch
Build identifier: Mozilla/5.0 (Windows NT 6.1; rv:2.0) Gecko/20100101 Firefox/4.0

Anthony or John, can you get us a regression range?
Ever confirmed: true
Whiteboard: [bugday-20110401]
The bug occurs on firefox 4.0 and on the latest nightly (02 april 2011).

But, on my XP comp, i have to set the value to >2, otherwise it won't be applied to firefox.
We still need a regression window for when this happened.  Please use the tool in comment 4 to find a regression range for this bug.
(In reply to comment #4)
> Anthony or John, can you get us a regression range?  

Not too sure how to use that tool, I did download & install the mozilla build & C++ before noting that documents had a discrepancy in system requirements <a href="">1/2 to 1GB</a> or System RAM of <a href="">2 to 4GB</a> I suspect my legacy XP machine with 1GB will not be up to running this. 

If it helps I did download a compiled Firefox 4b12 that shows the bug, build info shown as
The requirements can be ignored; they are for building Firefox from source.

All the tool does (and it will only take 15-20 mins) is download nightly builds of Firefox and after each ask good or bad; until a 24 hour range is found.
Meant to add:
Just follow the instructions at the top of this page, no need to download anything else (including C++):
Thanks Ed, tried that initially without success. Rather than clutter the bug I posted in the newsgroup Then realised I just was not following through the instructions, will try again later today.
Ok hopes this helps

Fault first appears in 4.0b6pre

Edited results ~
$ mozregression --good=2010-06-01 --bad=2011-12-28

Downloading nightly...

running nightly from 2011-03-15: bad
running nightly from 2010-10-22: bad
running nightly from 2010-08-11: good
running nightly from 2010-09-16: bad	- this crashed
running nightly from 2010-08-29: good	
running nightly from 2010-09-07: good
running nightly from 2010-09-11: bad   - this displayed no tool tip over the bookmarks
running nightly from 2010-09-09: good
running nightly from 2010-09-10: good

Last good nightly: 2010-09-10 First bad nightly: 2010-09-11

In that range is bug 588070; which may/may not be the cause, but is the only thing that leapt out. Marking provisionally blocking that for investigation.

CCing Neil.
I found out that the Places tooltip handler is picking up incorrect event coordinates, so it ends up showing the tooltip for the wrong tree row.

Interestingly the XUL tooltip listener is able to get the correct coordinates a) for showing the tooltip and b) for the internal code that shows tooltips for cropped cells in, say, the Bookmarks Manager (as opposed to the sidebar).

So I guess there's something not right with the way the XUL popup manager generates the event coordinates for the popupshowing event for a tooltip when the application isn't using 1:1 device pixels per CSS pixel.
This is also seen on Firefox 5.0a2, (/20110416 Firefox/5.0a2)but I suppose that is to be expected. 
(Would it be appropriate to edit Version affected from "4.0 Branch" to "Trunk"? )
Trunk is at 6.0a1; but the branch for Aurora (5.0a2) only happened recently, so I would imagine it's unlikely this issue has been fixed by chance since then. For completeness if you get a sec, please try using the latest nightly and if the issue still occurs, change to trunk (I've changed it to 5 branch for now) - thanks!
Version: 4.0 Branch → 5 Branch
Thanks Ed, confirmed issue occurs in current nightly ( /20110421 Firefox/6.0a1 )so have now amended to Trunk
Version: 5 Branch → Trunk
Attached image Firefox 7 screenshot.
Tooltip problem is shown. (Possibly some other problem also occurring with displayed page alignment when sidebar is open)
Confirmed, as expected bug continues in Firefox 8, recent nightly: Mozilla/5.0 (Windows NT 5.1; rv:8.0a1) Gecko/20110709 Firefox/8.0a1 ID:20110709030751
Moving to Core:XUL given comment 13.
Component: Bookmarks & History → XUL
Product: Firefox → Core
QA Contact: bookmarks → xptoolkit.widgets
I can confirm it too. My layout.css.devPixelsPerPxis is -1.0. I've been seeing this problem on the Windows 7 x64 Nightly for a few weeks. I usually read Livemarks through the Bookmarks panel. The misplaced tooltips make it unusable.

Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:24.0) Gecko/20130515 Firefox/24.0
One more piece of information: my Windows text size under Control Panel\Appearance and Personalization\Display is set to Medium - 125%
I have the same issue.

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:22.0) Gecko/20100101 Firefox/22.0
layout.css.devPixelsPerPxis is -1.0

The issue doesn't exist in the Linux version:
Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:22.0) Gecko/20100101 Firefox/22.0
Today I noticed that now my sidebar Livemark tooltips show up correctly in Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:25.0) Gecko/20130717 Firefox/25.0. Though layout.css.devPixelsPerPx is still -1.0.
Look like this is fixed by fix for:
The issue seems to be fixed in:

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:23.0) Gecko/20100101 Firefox/23.0
(In reply to Alexander Usyskin from comment #25)
> Look like this is fixed by fix for:

Certainly seems to be the case. I'm marking this resolved fixed by bug 890374. Please reopen if you can still reproduce this in Firefox 23 or later. Please note that this is not and will not be fixed for Firefox 22.
Closed: 7 years ago
Depends on: 890374
Resolution: --- → FIXED
Assignee: nobody → jfkthame
Target Milestone: --- → mozilla25
Reproduced FF 22. Verified fixed FF 23.0.1, 26.0a1 (2013-09-09) Win 7
Keywords: verifyme
Verified fixed FF 24b10, 25.0a2 (2013-09-12) Win 7
You need to log in before you can comment on or make changes to this bug.