Closed
Bug 478699
Opened 15 years ago
Closed 15 years ago
Firefox is randomly trying to fetch incorrect JavaScript file
Categories
(Core :: DOM: HTML Parser, defect, P2)
Tracking
()
RESOLVED
FIXED
People
(Reporter: kondzior.p, Assigned: mrbkap)
References
()
Details
(Keywords: fixed1.9.1)
Attachments
(6 files)
55.14 KB,
image/png
|
Details | |
125.79 KB,
image/png
|
Details | |
137.21 KB,
image/png
|
Details | |
74.23 KB,
image/png
|
Details | |
405 bytes,
text/plain
|
Details | |
745 bytes,
patch
|
jst
:
review+
jst
:
superreview+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090210 Shiretoko/3.1b3pre Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090210 Shiretoko/3.1b3pre Firefox 3.1 is trying to fetch wrong url to javascript, like on the screenshot. It's totally random (url), and totally random appears. Reproducible: Always Steps to Reproduce: 1. Go to http://www.warhammer-online.pl/testcase.html 2. Open Firebug Net tab 3. Press few times shift+cmd+r to re-fetch site 4. Firefox will try to fetch randomly number of weird urls like on attached screenshots Expected Results: All urls should be fetched without 404 Not found error All 404 not found errors on my daily work application are sent to my mailbox with full stack of application, i figured out that Fx 3.1 is producing all 404 Not Found errors with weird urls that are part of real urls from file that user is trying to view in browser. It seems that Fx 3.1 is randomly cutting random count of <script> urls. It depends probably on cache system.
Reporter | ||
Comment 1•15 years ago
|
||
Reporter | ||
Comment 2•15 years ago
|
||
Another sample that show Fx 3.1 trying to download ttp://www.warhammer-online.pl /js/very_long_name_for_javascript_file_to_show_that_gecko_fails_31 which is wrong.
Reporter | ||
Comment 3•15 years ago
|
||
Reproducable in Fx 3.1 beta 2
Reporter | ||
Updated•15 years ago
|
Flags: blocking-firefox3.1?
Reporter | ||
Comment 4•15 years ago
|
||
Another example that shows this appears to be totally random.
Comment 5•15 years ago
|
||
Hey Pawel: can you find a regression range? See https://wiki.mozilla.org/Calendar:QA_Home#Finding_a_Regression_Range_on_a_Bug and http://db48x.net/regression-search/ for details. --> Core::Networking:Cache, moving flag to blocking1.9.1?
Component: General → Networking: Cache
Flags: blocking-firefox3.1?
Keywords: regressionwindow-wanted
Product: Firefox → Core
QA Contact: general → networking.cache
Updated•15 years ago
|
Flags: blocking1.9.1?
Reporter | ||
Comment 6•15 years ago
|
||
Well i'm on that from 1 hour. I've testes Shiretoko alpha 1 - no regression Shiretoko alpha 2 - no regression Firefox 3.1 b1 - no regression Firefox 3.1 b2 - regression appears I recognized that between Fx 3.1 b1 and b2 Fx have new model of fetching files for pages, it's damn fast, so there is probably race somewhere
Reporter | ||
Comment 7•15 years ago
|
||
mac builds from http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2008/09/2008-09-29-02-mozilla-central/ are without regression mac builds from http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2008/09/2008-09-30-02-mozilla-central/ are with regression I thnik this is all related to speculative load of referenced files https://bugzilla.mozilla.org/show_bug.cgi?id=364315
Reporter | ||
Comment 8•15 years ago
|
||
build from 09-29 http://hg.mozilla.org/mozilla-central/rev/15cb5d25db05 build from 09-30 http://hg.mozilla.org/mozilla-central/rev/86b982e8b73e
Reporter | ||
Comment 9•15 years ago
|
||
Fx 3.1 b1 don't have regression because it was turned of 1 day before release http://hg.mozilla.org/releases/mozilla-1.9.1/log/04218932d5b7/parser/htmlparser/src/nsParser.cpp I think i can't do more to help here, I hope it will be fixed before 3.1 release. Cheers!
Updated•15 years ago
|
Blocks: 364315
Component: Networking: Cache → HTML: Parser
Keywords: regressionwindow-wanted
QA Contact: networking.cache → parser
Version: unspecified → Trunk
Updated•15 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 10•15 years ago
|
||
As per triage meeting, this blocks - needs someone to look into it. Blake?
Assignee: nobody → mrbkap
Flags: blocking1.9.1? → blocking1.9.1+
Priority: -- → P2
Whiteboard: [needs investigation mrbkap]
Assignee | ||
Comment 11•15 years ago
|
||
Paweł, thanks for helping to track this down. It's an easy fix. The bug doesn't affect the actual rendering of the page, but it does send spurious requests that clutter up logs & the like (and waste cycles on mobile devices).
Status: NEW → ASSIGNED
Whiteboard: [needs investigation mrbkap]
Assignee | ||
Comment 12•15 years ago
|
||
I used this to test the fix. 'test.cgi' is a script that sleeps for 5 seconds before returning a valid JavaScript program. Before the patch that I'm about to attach, I see [Tue Feb 17 14:05:49 2009] [error] [client 127.0.0.1] File does not exist: /home/mrbkap/public_html/SHOW_UP_IN_MY_LOGS, referer: http://localhost/~mrbkap/foo.cgi in my error logs, and only one of: [Tue Feb 17 14:23:15 2009] [error] [client 127.0.0.1] File does not exist: /home/mrbkap/public_html/SHOW_UP_IN_MY_LOGS_PASS, referer: http://localhost/~mrbkap/foo.cgi with it.
Assignee | ||
Comment 13•15 years ago
|
||
Without this line, the tokenizer would think that we're at the end of the document and return partial tokens to us.
Attachment #362783 -
Flags: superreview?(jst)
Attachment #362783 -
Flags: review?(jst)
Comment 14•15 years ago
|
||
Comment on attachment 362783 [details] [diff] [review] Fix Love it. r+sr=jst
Attachment #362783 -
Flags: superreview?(jst)
Attachment #362783 -
Flags: superreview+
Attachment #362783 -
Flags: review?(jst)
Attachment #362783 -
Flags: review+
Assignee | ||
Comment 15•15 years ago
|
||
http://hg.mozilla.org/mozilla-central/rev/79ef13e126a5 and http://hg.mozilla.org/releases/mozilla-1.9.1/rev/40818c0d61d3
You need to log in
before you can comment on or make changes to this bug.
Description
•