User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1b) Gecko/20020819 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1b) Gecko/20020819 It seems that Mozilla is shifting parts of images in relation to mouseover events. I'll include a test case with two slightly different scenarios--one in which there is a div with the :hover CSS stuff set up, which seems to be shifting the image *behind* it--the other which is a fairly standard javascript 'rollover' effect, where the 'highlighted' image appears, shifted to the left a bit. Note that I've had varying effects depending on the browser window size, but on my Debian unstable box using the latest nightly Mozilla build I just reproduced both effects in both a maximized and unmaximized window. However, just now in verifying my last statement, I realized that it seems the problem may only accour when the browser window width is an odd number of pixels. Maybe some kind of rounding error--up in one place and down in another? Anyway, results seem to be most consistent at window widths 800+ (which has to do partly, I'm sure, with the width of the elements and their positioning on the page). Note that I tried this in Windows XP with today's (yesterday's?) nightly build, and could reproduce the tab's shifting, but not the 'ecen home' one--perhaps because I didn't try hard enough, perhaps for some other reason. The test case could probably be simpler; sorry. P.S. It looked to me like bug #112664 might be the same bug--I hope I haven't done something terrible in submitting a seperate report--I wasn't sure we were talking about the same issue. Anyway, thanks! Mozilla's great! Reproducible: Sometimes Steps to Reproduce: 1.move the mouse over either the left tab or the 'ecen home' image in the test case. 2.watch part of the background (apparently the part associated with the div containing the tab content) shift to the left (in the first case) or the 'ecen home' highlight image appear, shifted to the left (in the second). 3.if it doesn't, try adjustnig the size of your browser window. Actual Results: The images (or parts thereof) shift to the left. Expected Results: They shouuld have stayed in the same positions. I was using Mozilla 1.1 beta when I discovered it, with the Modern theme. I've reporduced it here in today's (Aug. 19'02) (or rather, yesterday's, I suppose) nightly build, using the old Netscape-ish theme. As I mentioned above, this may be a duplicate of bug #112664. Hope I don't mess y'all up by filing a seperate report. I'm putting 'normal' in the severity field, but this bug really does make--well, at least *my* web page menu/mouseover effects--look rather uglier than in, say, TOB (That Other Browser--IE ; ).

I hope this works--er, doesn't work ; ).

Seeing the shift to. But this looks more lika a single pixel roundig error. Adding this one to the tracking bug 134942.

This is a simplified testcase. I removed the javascript rollover stuff, as I was unable to duplicate that problem (it must have been fixed--thanks, folks!). The image shifting under a div tag with the :hover stuff set still occurs, though--verified in 1.1 in Linux and Build 2002100808 (nightly build installed on Oct. 8'02) on Windows XP. Mouseover the green box and watch the part of the image that lies beneath the box shift. Note that it only seems to happen on odd (?) window widths--if you don't see the shift, try resizing the window 1px narrower. HTH, Thanks. --Daniel

I'm not seeing this in beonex 0.8.1 on windows, nor phoenix from november 1. so it seems to indeed be only a linux problem. as a note: in the phoenix build, the green box is not vertically aligned with the image, but it is fine in beonex. perhaps this needs its own bug or you were relying on a quirk that has been corrected.

Using build ID 20030531 on mandrake 9.0. I can't reproduce this. The image in the second testcase doesn't shift when I move my mouse over it. For what it's worth, I rarely see single-pixel roundoff errors on this system, though I regularly see them on a sparcstation at work. Daniel, can you reproduce this with a current copy of mozilla?

Kenneth-- Unfortunately I am able to confirm this in the June 2'03 nightly build (2003060208) on my Sid Debian GNU/Linux system. However, I *couldn't* get it to break on Windows XP with the same build. As mentioned previously, it only appears to work at certain window sizes--I can't reproduce it in a maximized window now but do get the shifting every couple of window sizes I try, and once I've found a windows size that works I can refresh the page and then reproduce the shift 100% reliably from what I can tell. I'm guessing, therefore, that there's nothing special about the window being maximized other than that the combination of screen resolution and window decoration leaves me with a window with an 'immune' size. This same sort of shifting is occuring in the latest build on my Linux system (but not in Windows XP) on *text* links on the department home page I've been working on, if that helps. The page is www.ee.byu.edu--mouseover on particularly the text links on the light blue bar at the top and the light blue bar at the bottom (others, too, perhaps) shows a similar shifting behavior. I don't know if the two are related or not. Thanks very much for looking into this--if there's anything else you'd like me to post, please let me know.

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b) Gecko/20050205 Firefox/1.0+ The second testcase is WFM in the sense that I can't get the image to shift.

> The second testcase is WFM in the sense that I can't get the image to shift. I'm also unable to reproduce it in the Firefox 1.0 version from Debiuan unstable. I haven't seen this problem on live websites for some time now, either, that I can recall. Sounds like it's fixed! Thanks! P.S. I'm not an expert at this Bugzilla stuff, and it's been a while since I read the instructions and what-not---am I (the person who submitted the bug) supposed to do something to close the bug or does somebody official do that?

I actually do not know, in the sense that I ought to but don't. I leave closing and modifying bugs to others, but I think that the original Reporter has certain powers. See Bug 225896 "Should be possible to open an unix/Berkeley mbox mailfile by drag-and-drop" where I got it wrong, and Bug 203784 "Browser crash following deep recursion in [@ PR_GetCurrentThread]" where I (believe that) I got it right. In most bug databases ONLY the reporter can close a bug. Bugzilla is definitely not like that!

Well... I went ahead and marked it resolved, worksforme. It let me do it, so maybe that's an indication that I'm allowed to and maybe not. Anyway, consider this my apology if I messed things up for anyone! Thanks for such a great browser! :).