Hello My website is alternatorsnstarters.co.uk and the pictures I have on the page are not wrapping to the left or right making my site all jumbled up. Previous versions of firefox were fine until I updated to firefox 5 and I can only assume that text wrapping is not supported. I use Microsoft Office Live for my website. Please can you get this sorted as 46% of my customers use firefox.
Track down using Linux: Last good nightly: 2010-08-27 First bad nightly: 2010-08-28 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=e1d55bbd1d1d&tochange=6e3f6d18c124
Setting html5.parser.enable false makes "Mozilla/5.0 (X11; Linux x86_64; rv:8.0a1) Gecko/20110708 Firefox/8.0a1" a Works For Me.
Sorry I'm not following any of this. Do I need to do something.
Firefox is trying to get more and more standard compliant, and the fact that the page gets broken when the HTML5 parser is enabled indicates that the page contains something breaking the standards. Of course this may be a bug in the HTML5 parser instead, but often this kind of Firefox bugs ends up with someone pointing to the relevant parts of the standards. Your page does not use valid XHTML 1.0 Transitional although it claims to do so. The W3C Markup Validation Service reports 157 errors and 1 warning: http://validator.w3.org/check?uri=alternatorsnstarters.co.uk The WDG HTML Validator says "The maximum number of errors was reached. Further errors in the document have not been reported": http://htmlhelp.com/cgi-bin/validate.cgi?url=http%3A%2F%2Falternatorsnstarters.co.uk%2F&warnings=yes And Validome also reports a lot of XHTML errors: http://www.validome.org/validate/?uri=http://alternatorsnstarters.co.uk/ I good start could be to ensure that your page validates without errors and warnings. That will make it easier to find the alleged bug, and probably also more people will feel motivated to "dig in the dirt" if Firefox has problems with a valid HTML / XHTML page.
But the site opened correctly in your last version of Firefox.
I'll investigate tomorrow, if nobody else does
The page is served as text/html but claims in the content to be xhtml. Perhaps serving the page as application/xhtml+xml would help (assuming it really is xml)
Robert, this stuff is definitely not XML. Henri, in Fx3.6 the first "Ford Fiesta 1.3 Alternator" image ends up as a descendant of the <span id="ctl00_IWS_WH_CPH_Content_FooterXslControl2">. This span is styled float:left. In particular, the image's parent is a div, whose parent is a span whose parent is the floated span. In Fx4, the image's parent chain is a bunch of <font> tags, then the div, but the div's parent is a <font>. The <span>s both got closed when the <div> was hit. Oddly, Chrome dev shows the old rendering, even though they also have an HTML5 parser.... so it might be a bug in their code or in ours.
Oh, and confirming.
Though an attempt to copy just the relevant code from the page makes Chrome render it the same as us, so something weird is going on there....
The thought had crossed my mind, but I don't think the nesting in this case is deep enough to trigger that issue. I could be wrong; that's where Henri comes in. ;)
Hello It all sounds like dego talk to me. At the end of the day it was fine in the previous firefox version but not in the lastest version which tells me something has been missed out of the programming. Is this any nearer in getting resolved.
(In reply to comment #13) > Is this any nearer in getting resolved. Nobody knows exactly whats going on yet. Please wait, be patient, and don't repeat your previous comments.
I have managed to resolve the issue. The problem was some (not all) of my pictures. I simply re-sized them and now it works.
Did you change the image files only or the html file too? Closing as INCOMPETE at this stage, it's impossible to track down the problem now.
> Is this any nearer in getting resolved. Julian, you reported this at a point when it was already late Friday night for the parser maintainer and he had presumably gone home for the weekend. So I don't expect that he'll look at this bug until sometime on Monday. If there's still a web page that shows the problem at that point, that would be very useful. It doesn't have to be your actual site's front page, of course; if you can just put a copy of what things used to be like somewhere that would work fine...
Created attachment 545067 [details] Local copy from July 8 2011 This is my local copy, but the bug shows up even in Firefox 3.6.18 with this one. At the moment there's also a cached copy available from Google: http://webcache.googleusercontent.com/search?q=cache:AWKJqpjGkq4J:alternatorsnstarters.co.uk/+&cd=1&hl=en&ct=clnk
(In reply to comment #18) > Created attachment 545067 [details] > Local copy from July 8 2011 > > This is my local copy, but the bug shows up even in Firefox 3.6.18 with this > one. Yes, bug with HTML5 parser enabled and disabled. Also buggy in Opera 11.50, which worked fine on the reported site The Google copy shows no bug. So I leave this bug closed. (There is some -moz-inline-box styling around ...)
The attachment looks the same to me in Firefox, in Firefox with the iteration limits removed from the adoption agency algorithm, Firefox with the old parser and in Chrome. What difference am I supposed to see between Firefox and Chrome or between the old and the new parser?
> What difference am I supposed to see between http://alternatorsnstarters.co.uk was fixed (comment 15) and the problem is no longer traceable. There was much space around images.
Does that explain everything i comment 8, or did the actions in comment 15 just hide the symptoms? But since it's no longer traceable we'll maybe never know.