Bug 387561 - Images and links shift on mouseover
Summary: Images and links shift on mouseover
Alias: None
Product: Fedora
Classification: Fedora
Component: firefox
Version: 8
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Gecko Maintainer
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2007-11-16 20:02 UTC by Steevithak
Modified: 2018-04-11 08:08 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2007-11-21 14:04:45 UTC
Type: ---

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Mozilla Foundation 20802 0 None None None Never

Description Steevithak 2007-11-16 20:02:43 UTC
Description of problem:

Images and links displayed in Firefox shift left or right one pixel when the
mouse cursor passes over them. This does not happen on my previous version of
Fedora. Possibly related problem is that the display of fonts looks horrible
compared to other GTK+ apps. Every looks crisp on my display except typefaces
rendered in Firefox, which look blurry and shift around unexpectedly as the
mouse cursor moves past. Don't know if it's a bug in Firefox or GTK+.

Version-Release number of selected component (if applicable):


How reproducible:

Very. Happens 100% of the time.

Steps to Reproduce:
1. View a web page with images and text links.
2. Move mouse cursors over them. 
3. Cringe in horror at the annoying shifting.
Actual results:

Images and links shift back and forth by 1px. Typefaces are render badly.

Expected results:

Images and links remain where the web designers put them. Fonts should look nice
and clear like other GTK+ apps.

Additional info:

I'll try to get some screen capture that illustrate the problem and upload them

Comment 1 Steevithak 2007-11-16 20:16:31 UTC
I ran across a report of a similar problem with Firefox on Kubuntu, though it
involves vertical shifts in images/text in the Firefox UI itself rather than
horizontal shifts in web page content. If a GTK+ problem is responsible, though,
this bug report might be related.


Comment 2 Steevithak 2007-11-16 21:13:40 UTC
Unfortunately, it doesn't appear possible to create a screen capture of the
problem. Even though there's a clear visual shift in images and text on the live
browser, the before and after screen capture are always identical. Just to make
sure I'm not crazy or hallucinating, I've had several other people look at the
phenomenon and we all agree on what we're seeing. Perhaps the inability to do a
screen capture of the issue reveals something about the cause? 

Comment 3 Christopher Aillon 2007-11-19 17:47:39 UTC
Can you go to System>Preferences>Look&Feel>Appearance and in the fonts tab,
click on Details, and make sure you have 96dpi?  Other than that suggestion, I
have no idea as to how to possibly begin debugging this.  Everything appears
normal for me; I don't see any shifting on mouseover on any pages....

Comment 4 Steevithak 2007-11-19 18:54:38 UTC
It currently reads 100dpi. I haven't adjusted it. 100dpi must be the value it
determined during the install, which seems correct. It's a Viewsonic VP2030b
with a 16.1" x 12.1" panel that has 1600x1200 native resolution. The video card
is an ATI RV380 (Radeon X600) using the radeon driver. The desktop and all the
other GTK+ programs I've tried look beautiful. It's only Firefox that has
problems. Just for kicks, I've manually adjusted it to 96dpi. Interestingly, I
could see the fonts shrinking on everything but Firefox as I adjusted it. Guess
I'll have to shutdown Firefox and restart to get it to pick the change. I'll
post the results momentarily.

Comment 5 Steevithak 2007-11-19 19:02:22 UTC
After restarting Firefox with the resolution set to 96dpi, the shifting effect
seems to have vanished. The type still looks a little fuzzy compared to other
GTK+ programs but at least it's not jumping around on the page. So, this seems
like a suitable work-around for now.

The weird thing is that my Laptop, which also runs Fedora, doesn't have this
problem. It has a 1920x1200 display that's 140dpi. Does this mean there's a bug
that only affects 100dpi screens? On the other hand, my Laptop has nVidia
graphics hardware and uses the nv driver. Maybe the bug only affects 100dpi +
radeon driver setups?

Comment 6 Matěj Cepl 2007-11-19 23:19:32 UTC
Can I get output of the command

xdpyinfo |grep resolution


Comment 7 Steevithak 2007-11-19 23:33:16 UTC
[rsr@rodan ~]$ xdpyinfo | grep resolution

  resolution:    100x100 dots per inch

And, just in case it's helpful:

[rsr@rodan2 ~]$ xdpyinfo | grep dimensions

  dimensions:    1600x1200 pixels (408x306 millimeters)

Comment 8 Christopher Aillon 2007-11-20 15:27:58 UTC
The DPI should not be set to anything other than 96dpi.  See

This is not a bug in X or Firefox or anything.  Just the defaults for GNOME
which is covered elsewhere in upstream GNOME.

Comment 9 Steevithak 2007-11-20 17:04:46 UTC
While I agree that setting the display DPI to 96 eliminates the shifting, the
display is not a 96dpi device. Setting the DPI to an incorrect value sounds more
like a work-around than a good default practice. As display resolutions continue
to improve, this is likely to crop up more often. In this case, 96 is close
enough to the correct value of 100 that it's not a problem. But, as I noted
above, my laptop has a 140dpi display, so setting it to 96dpi would introduce
something like a 30% error in the scales of everything displayed (at least by my
understanding of how this stuff works).

Comment 10 Matěj Cepl 2007-11-21 14:06:47 UTC
caillon is right. This bug is real, but most certianly won't be fixed by the Red
Hat support. If you want to fight for fixing of this bug, then please do so
upstream. I would suggest https://bugzilla.mozilla.org/show_bug.cgi?id=20802,
but there is a lot of other bugs related to this issue in the upstream bugzilla.

Comment 11 Steevithak 2007-11-21 17:02:52 UTC
Thanks! That makes sense actually, since all the other GTK+ apps look fine when
the actual dpi is used. I'll take a look at the mozilla bug.

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