The default bug view has changed. See this FAQ.

Centered DOM elements shift 1 pixel depending on EVEN or ODD browser width

NEW
Unassigned

Status

()

Core
Layout
7 years ago
6 years ago

People

(Reporter: Omar, Unassigned)

Tracking

({regression})

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

7 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6

I have a Flash element on a page that is centered in a fixed width div. That div is within another div that is centered to the body of my page. When the browser is resized, the Flash element seems to jump back and forth a pixel. With further testing, I was able to determine that the behavior was consistent for all even browser widths and also for all odd browser widths. (Just a note, this led me to believe it may be a sign of a rounding issue determining where the left edge of the element should be.) I have created a simplified page where you can see the same behavior: http://files.widgetbox.com/test/pixel_shift_test.html, and here it is on our production site: http://www.widgetbox.com/widget/tmzcom

Reproducible: Always

Steps to Reproduce:
1. Make HTML structure like http://files.widgetbox.com/test/pixel_shift_test.html
2. Open page in browser (v 3.6 only) either adjust your browser's width, or hover over the links I have on the page to adjust the width to an EVEN or ODD pixel exactly.
3.See Flash file shift 1 pixel back and forth (notice right border is cut off)
Actual Results:  
The widget on the page is shifted back and forth clipping its right border by 1 pixel

Expected Results:  
The widget should stay positioned where it is, completely visible and not shift. The expected behavior can be seen in FF <3.5 on OSX.

I found that adjusting the flash file with a margin of -1px in the case where it is shifted over seems to work, but is a total workaround, and we don't really have the option of attaching resize listeners to everyone's page who uses our widgets.

Comment 1

7 years ago
dupe of bug 546071 ?
(Reporter)

Comment 2

7 years ago
That other issue seems to be focused around overflow:hidden as evident in the test cases that were checked in w/ the FIX. I like the sound of the function that was added in the FIX, "CalcWidgetBounds" as it sounds like it might fix my issue as well. I'll try the latest build and see how it goes. I'd like to leave this bug as a separate issue until I can verify it really is a dupe.
(Reporter)

Comment 3

7 years ago
Installed FF Minefield nightly and did not see any difference in the display of Flash under the above circumstance.

Updated

7 years ago
Duplicate of this bug: 551012

Updated

7 years ago
Duplicate of this bug: 551012
(Reporter)

Comment 6

7 years ago
This only happens in Firefox 3.6 and greater on OSX
Version: unspecified → 3.6 Branch

Comment 7

7 years ago
Now that bug 546071 has been checked in on trunk, can you check if you still can reproduce this issue with the latest nightly build ?

http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/

Comment 8

7 years ago
I can still reproduce the bug with the 3.7 pre release version. Doesn't seem to have made any different for this matter

(In reply to comment #7)
> Now that bug 546071 has been checked in on trunk, can you check if you still
> can reproduce this issue with the latest nightly build ?
> 
> http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/
(Reporter)

Comment 9

7 years ago
I get the same results as Fredrik. 3.7 does not fix the issue.
(Reporter)

Comment 10

7 years ago
Any update on this? It something that we are having to explain daily to customers and is resulting in support costs for our organization.

Comment 11

7 years ago
It looks like nobody is assigned to this bug.

Is there already a bug filed with Adobe?

Comment 12

7 years ago
(In reply to comment #10)
> Any update on this? It something that we are having to explain daily to
> customers and is resulting in support costs for our organization.

I've already lost time to this bug thinking it was something I did wrong when clients complained. Please fix! THANKS!
(Reporter)

Comment 13

7 years ago
Upping importance, hopefully someone can help out with this.
Severity: normal → major
Priority: -- → P2
Priority should only be set by developers please. resetting to --
See https://bugzilla.mozilla.org/page.cgi?id=fields.html#priority

It might get more attention if in a component other than general. But I don't know if layout is the correct place
Severity: major → normal
Component: General → General
Priority: P2 → --
Product: Firefox → Core
QA Contact: general → general
Version: 3.6 Branch → unspecified
Component: General → Layout
QA Contact: general → layout
regression range:
fails
Gecko/20090722 Minefield/3.6a1pre
http://hg.mozilla.org/mozilla-central/rev/02f8bf10f441

works
Gecko/20090721 Minefield/3.6a1pre
http://hg.mozilla.org/mozilla-central/rev/f2a58ffcd00c

http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=f2a58ffcd00c&tochange=02f8bf10f441

possibly bug 352093 or bug 339548 ?

I don't see any obvious dupe, so confirming.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression
Created attachment 440989 [details]
minimal test case

the flash movie is centered (text-align: center) in the window;
resize the window to see the right hand border (inside the flash movie) appear/disappear
Can you retest tomorrow? I landed the fix for bug 556052 which might fix this.
(In reply to comment #17)
> Can you retest tomorrow? I landed the fix for bug 556052 which might fix this.

Can't test. Thing crashes whenever it tries to load the test page.
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.3a5pre) Gecko/20100423 Minefield/3.7a5pre
http://hg.mozilla.org/mozilla-central/rev/fe937d72a9ce
Works for me (no crash, no missing border) in my debug build with revision 1cab05410c6c.
Dunno, it crashes over here with a default profile. I filed bug 561519 for that.
Flash 10,1,53,21.
OK, I was able to check now by changing the mime-type for the <embed> (thanks :benWa for pointing it out).
With the 20100424 nightly build, there are no problems anymore.

Roc, do we want to land that fix on Gecko 1.9.2.x ?
I suspect this bug affects quite a bit of sites.
Just try http://www.adobe.com/software/flash/about/ for example.
Yeah, but there's a regression from bug 556052 so let me fix that first and make sure everything's OK on trunk!
(Reporter)

Comment 23

7 years ago
Thanks for looking at this issue. I am relieved that you are able to reproduce the problem. I'm trying to help out by testing the latest nightly, but I can't seem to be able to install the latest version Flash Player. Any advice?

Comment 24

7 years ago
Has there been any progress on this issue?  It's causing me some major problems!

Comment 25

7 years ago
This is not fixed in 3.6.10 -- but, I tried 4.0 Beta 6 and it appears to be fixed there. So, if you want to forgo annoying Flash bugs, stick with 3.5.x until 4.0 is released (hopefully November).

Comment 26

7 years ago
I also spent many hours thinking this was something I was doing. I really need this fixed. The left border of my header is part of my flash banner. My banner does not work if it is not flush on that side.

This is for a design company. So In other words, I cannot launch my site until it's fixed. Cant believe I just now noticed it.

Works fine in all other browsers.
I only see two dups. We could try backporting bug 556052 but we'd have to make sure it didn't trigger bug 561388 on the branch. It was fixed by retained layers on trunk which certainly can't land on the branch.

Comment 28

6 years ago
I came up with a javaScript workaround that seems to be working without causing much issue. I am using this on a homepage where the offset bug was noticable on a flash banner area, but excluding it from the remainder of the site.

If it helps any developers cool, if you notice any problems I have yet to stumble upon let me know. It forces the window to snap to an odd number of pixels when it detects "Firefox" in the user agent string and you are also on a Mac.

Because of how the resize function works in Firefox vs. most other browsers (ie, the event firing after you stop dragging) it actually performs very smoothly.

<!-- FORCE BROWSER WIDTH TO ODD NUMBER -->

<script Language="JavaScript">
var isFireFox=new Boolean();
if (navigator.userAgent.indexOf("Firefox")!=-1) {
	if (navigator.platform == "MacIntel" || navigator.platform == "MacPPC") {
		isFireFox = true;
	} else {
		isFireFox = false;
	}
} else { 
	isFireFox = false;
}
function isEven(value){
	if (value%2 == 0)
		return true;
	else
		return false;
}
var width;
window.onresize = function() {
	if (isFireFox) {
		width = window.innerWidth;
		if (isEven(width)) {
		  self.resizeTo(width-1, window.outerHeight);
		}
	}
};
</script>

Comment 29

6 years ago
I'm experiencing this problem too, only Firefox 3.6 on OSX. works fine on windows pcs. 

DrunkenCyclist your js fix works like a charm, thanks! Good hack for now until this bug is fixed.
You need to log in before you can comment on or make changes to this bug.