started going through a bit of reporter data based on sicking's concerns about site compatability for fx3. spotted a few comments that need to be investigated before we turn into an engineering bug or evangelism... several like this: "Favorite" buttons are not properly placed in FF3 (Beta3 installed). Placement is fine in FF2 and IE. I confirmed the different layout on the page between firefox 2 and 3. fx3 "stacks" the favorite voting buttons, then show pictures. nominating until we know more. fx2 shows a voting button, then a picture; button, then picture, etc....
I don't see an obvious difference between my FF3 nightly and Safari. Maybe I'm not looking in the right place? The ratings (cheezburgers) for comments on individual posts seem to be be padded up ~1 line of text from where I'd expect, leading to some extra whitespace in comment headers, but Safari also shows things that way.
Created attachment 307367 [details] I can haz screenshot Oh, I see now. There's a brown "Favorites" button that seems to be entirely missing in FF3, but is there in FF2. It's missing on both the front page and individual posts. http://icanhascheezburger.com/2008/03/04/funny-pictures-and-a-cookie/
It ahows up just fine under build 2008030404.
take that back, the front page doesn't work. It has them in a continuous line like the windows screen.
On Windows XP I see only a stack of 10 buttons on top when I change the useragent to IE. The regression from one individual button to a stack happened around November 2005.
OS: Mac OS X → All
Hardware: PC → All
Version: unspecified → Trunk
Attachment #307367 - Attachment description: I can has screenshot → I can haz screenshot
Created attachment 307679 [details] Testcase #1 if(navigator.userAgent.indexOf('MSIE') > 0 || navigator.userAgent.indexOf('Firefox') > 0) ... Changing 'Firefox' to 'Gecko' makes the buttons appear near the top of the page. After fixing that it boils down to what 'element.innerHTML' evaluates to for dynamically inserted DOM nodes. In Firefox 2 we don't include them, now we do. The attached testcase shows an alert with the innerHTML that is being tested in the script, it affects where the buttons end up. Tech Evang?
Component: Layout → General
QA Contact: layout → general
Uh? What do we do different for element.innerHTML? We've always serialized all nodes, no matter if they were created during parsing or through the DOM.
So the only reason non-Firefox Gecko browsers are getting the "right" content here is purely by accident? :-p That's not good either, and this should probably block 334967 because their sniffing is seriously busted.
Sounding like this is an evangelism issue. -'ing, but please re-nom if not the case.
Flags: blocking1.9? → blocking1.9-
(In reply to comment #8) You're right, my mistake. There are multiple elements in the document with id="md". The difference is that getElementById() now always returns the first element in the document (fixed by bug 403868), whereas Fx2 returns the latest(?) element added to the DOM, or something. -> Evang
Assignee: nobody → english-us
Component: General → English US
Product: Core → Tech Evangelism
QA Contact: general → english-us
Summary: funky firefox 3 layout on icanhascheezburger.com → icanhascheezburger.com - funky firefox 3 layout on icanhascheezburger.com
Version: Trunk → unspecified
The favorite button is visible.
You need to log in before you can comment on or make changes to this bug.