User Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:184.108.40.206) Gecko/20110902 Firefox/3.6.22 ( .NET CLR 3.5.30729; .NET4.0E) Build ID: 20110902133716 Steps to reproduce: I was coding in php and made use of the session at my website. I've created a variable with a random integer value which was needed to be entered into a form (like a CAPTCHA), just primitive. Actual results: When I was testing the script it worked well on FireFox 3.6 and Internet Explorer, Safari etc. Then I tested my site on FireFox 6.02. All time I entered the integer value in the form the system told me about an invalid input (the value was not the same with the v alue in the session). So I started debugging by hand and looked into all the vars and function calls.. and after some time I found out that the problem was that the site was loaded two times (when pressing F5 only once). So I kept on with debugging and found out that the template of my site was causing the issue. An empty source of an image (<img src="" width="" height="" />), which was somehow left in the code. This was he reason why FireFox 6.02 loaded my site twice. All other browsers (the old FireFox 3.6 too) worked fine. A bit in detail: When I submitted the form (via a POST request), then the page was loaded two times (because of that image tag as I found out). In the POST data the random number was submitted, which had to be assigned with the session number (and had to be the same, like a CAPTCHA). But because of the reload the number in the session was overwritten and so the submitted number in the post data was "out of date" -> so the funny thing is, the POST data was kept after these two requests, but the session variable was overwritten by a new number (and in this case I got the invalid numbers error). Expected results: Well, the site shouldn't be loaded two times (because of that the random integer value in the session variable was overwritten). It took me a lot of time to find out that it was an empty image tag, "interrupting" my session variable. It might be a problem for systems like CMS (ContentManagementSystem), as it can happen that empty image sources are left in code (well, but at least this wont happen often..), and specific session based things may not work anymore then. It's okay if this wont be fixed, I just don't think that this is thought to be like this.
This got fixed a long time ago with bug 444931. I would be surprised if this regressed with the html5 parser. Can you please test this again in the Firefox safemode http://support.mozilla.com/en-US/kb/Safe+Mode ?
Somehow I didn't get the safe mode running (I even tried running via cmd) -> well I will look to test it again right after this comment ;-) But what I can say for now is: Tested on 3 different computers (each another operating system, Windows XP x86, Windows 7 x64, Linux Ubuntu x64). But as things are easier if you can see them, I made a small script showing the issue. Hope it is clear and helps: http://www.webpictor.com/firefoxtest.php (in the source is an empty src="" image tag, and the input never matches with the session value.. you could also add a session variable which extens by a 'x' each time the site gets requested, and you will see the site is loaded two times). I'll upload it as attachement if you prefer that.
Oddinary. I can't find the safe mody on my computers (on all 3 of them), not in the Mozilla folder, not in the startup folder.. and not via cmd (entering the -safe-mode command). Anyway, another friend just tried it (he is using Windows 7 x64 FireFox 6.02) and had the same issue. I don't really have many plugins or addons installed, but I will try the following now: Disabling FireBug and FlagFox, as this is installed on all 4 computers.
Ok... had the page open in FF 3.6.x and tried to look for it on my laptop with FF 6.02.. the text was mentioned with FF 3.6.x.. So.. same result in the safe mode. Page is loaded two times. But as you said, the problem was solved in the past (FireFox 3.6.x does it well, no problems there). Only the newer versions of Firefox (5, 6) are having this issue.
confirming with Mozilla/5.0 (Windows NT 6.1; rv:9.0a1) Gecko/20110908 Firefox/9.0a1 SeaMonkey/2.6a1 with the testcase and also with a html file on my own server with only an empty img src= and changed caching headers. Is this a regression from the html5 parser ?
Status: UNCONFIRMED → NEW
Component: General → HTML: Parser
Ever confirmed: true
Product: Firefox → Core
QA Contact: general → parser
Version: 6 Branch → Trunk
We probably need the same check for empty src in the preload code as in the actual image loading code.... Henri, is the right place for that in nsHtml5TreeOpExecutor::PreloadImage or in nsHtml5TreeOpExecutor::ConvertIfNotPreloadedYet? That is do we want to apply it to more than just images?
(In reply to Boris Zbarsky (:bz) from comment #6) > Henri, is the right place for that in nsHtml5TreeOpExecutor::PreloadImage or > in nsHtml5TreeOpExecutor::ConvertIfNotPreloadedYet? That is do we want to > apply it to more than just images? We need this more than just images, so ConvertIfNotPreloadedYet is the place.
You patch I review, or vice versa? ;)
Thanks for your quick work & reply guys! So, this issue will be solved in one of the next updates? :)
(In reply to Boris Zbarsky (:bz) from comment #8) > You patch I review, or vice versa? ;) I can patch this next week when I have a working build system again.
Assignee: nobody → hsivonen
Status: NEW → ASSIGNED
Created attachment 560885 [details] [diff] [review] Check preload URLs for emptyness Any ideas how to write a test case for this without making the test case slow down the test suite and without making it racy?
Attachment #560885 - Flags: review?(bzbarsky)
Comment on attachment 560885 [details] [diff] [review] Check preload URLs for emptyness Without slowing down the test suite, no. :(
Attachment #560885 - Flags: review?(bzbarsky) → review+
Thanks for the r+. Landed without a test, because my recollection is that it's no longer ok to land tests that slow down the test suite. https://hg.mozilla.org/integration/mozilla-inbound/rev/19518187d2e8
Version: Trunk → 9 Branch
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.