<base> tag ignored by lookahead algorithm

RESOLVED FIXED

Status

()

defect
RESOLVED FIXED
10 years ago
9 years ago

People

(Reporter: devin, Assigned: hsivonen)

Tracking

(Blocks 1 bug)

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(blocking2.0 betaN+)

Details

()

Attachments

(2 attachments, 1 obsolete attachment)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5

This site has the following two lines near the top of the <head> elements:
<base href="http://bankofthewest.mortgagewebcenter.com/">
<link href="Cobrander/BankoftheWestBeta/Styles/BankoftheWestBeta.css" rel="stylesheet">

If you examine the HTTP requests, you'll notice that Firefox loads this URL: URL=http://bankofthewest.mortgagewebcenter.com/CheckRates/Cobrander/BankoftheWestBeta/Styles/BankoftheWestBeta.css

It's essentially ignoring the <base> tag when it requests the CSS file.  However, several requests later, the correct URL (with the new <base> applied) is loaded.

This seems to be the exact same problem seen in a longtime IE bug that was fixed recently (http://blogs.msdn.com/ieinternals/archive/2009/10/13/Using-Meddler-to-Simulate-HTTP.aspx).

Reproducible: Always




I saw the bad HTTP request using Tamper Data, Fiddler, and Firebug.
http://hg.mozilla.org/mozilla-central/annotate/f1742529aaa7/parser/htmlparser/src/nsParser.cpp#l353
Component: General → HTML: Parser
Product: Firefox → Core
QA Contact: general → parser
Version: unspecified → Trunk
FWIW, the HTML5 parser intentionally preserves this bug for simplicity.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Just discovered this MDC page, too:
https://developer.mozilla.org/en/Optimizing_your_pages_for_speculative_parsing

Consider this bug report a feature request, I suppose.
Devin, could you come up with a minimal testcase where you see this? We should handle <base href=...><script src=a.js><script src=b.js> correctly.
Here is a minimal example that does not seem to work on OSX 10.6.2 and FF 3.5.5

##############################################################################
<html>
<head>
 <title>test</title>
 <base href="http://staging.fotozap.com/MEDIA/webStorage/affiliate/1/campaignThemes/pmcomics/owner_photopage/"/>
</head>
<body>
 <img src="images/blimp.gif" />
</body>
</html>
There shouldn't be any prefetching happening in that testcase...
[17/Dec/2009:09:38:14 +0000] "GET /~ccjpb/x.html HTTP/1.1" 200 219
[17/Dec/2009:09:38:14 +0000] "GET /MEDIA/webStorage/affiliate/1/campaignThemes/pmcomics/owner_photopage/images/blimp.gif HTTP/1.1" 200 3765
[17/Dec/2009:09:38:15 +0000] "GET /~ccjpb/images/blimp.gif HTTP/1.1" 404 6531

[with appropriate change to base]
John are you running OSX?

I have confirmed from multiple people running OSX that they are not able to see the image in this page:
http://info.picturemarketing.com/test.html

I am able to see the image fine in every other browser/os combination that I have at my disposal.

Shall I file a new bug report since this is not related to prefetching?

Thank you.
This can result in pages taking a long time to render if the URL prefetched without taking into account the base element takes a long time to respond.

For instance, try to load any pages on airbus.com, such as http://www.airbus.com/en/aircraftfamilies/a350/a350_xwb/

That page will first try to load http://www.airbus.com/en/aircraftfamilies/a350/a350_xwb/typo3temp/stylesheet_e4cb9909dc.css.
However the web server waits several seconds before sending the 404 error. The page is blank until the browser gets the 404 and can load the correct stylesheets and scripts.
Blocks: 580571
No longer depends on: 580571
I'll write a test case separately.
Assignee: nobody → hsivonen
Status: NEW → ASSIGNED
Attachment #459834 - Flags: review?(jonas)
OS: Windows XP → All
Hardware: x86 → All
Comment on attachment 459834 [details] [diff] [review]
Add speculation-specific base URI management

>diff --git a/parser/html/nsHtml5TreeBuilderCppSupplement.h b/parser/html/nsHtml5TreeBuilderCppSupplement.h
>--- a/parser/html/nsHtml5TreeBuilderCppSupplement.h
>+++ b/parser/html/nsHtml5TreeBuilderCppSupplement.h
>@@ -144,16 +144,24 @@ nsHtml5TreeBuilder::createElement(PRInt3
>           nsHtml5TreeOperation* treeOp = mOpQueue.AppendElement();
>           NS_ASSERTION(treeOp, "Tree op allocation failed.");
>           treeOp->Init(eTreeOpSetStyleLineNumber, content, tokenizer->getLineNumber());
>         } else if (nsHtml5Atoms::html == aName) {
>           nsString* url = aAttributes->getValue(nsHtml5AttributeName::ATTR_MANIFEST);
>           if (url) {
>             mSpeculativeLoadQueue.AppendElement()->InitManifest(*url);
>           }
>+        } else if (nsHtml5Atoms::base == aName &&
>+            (mode == NS_HTML5TREE_BUILDER_IN_HEAD ||
>+             mode == NS_HTML5TREE_BUILDER_AFTER_HEAD)) {

Why is the AFTER_HEAD part there? Is that mode for when we are after the </head> but before the <body>? Note that we no longer honor <base> elements that aren't direct children of the <head> element.
(In reply to comment #11)
> Why is the AFTER_HEAD part there?

<base> between </head> and <body> becomes a child of the head element.

> Is that mode for when we are after the
> </head> but before the <body>?

Yes.

This new patch changes how |base| is computed in nsHtml5TreeOpExecutor::ConvertIfNotPreloadedYet. If the document is already aware of a <base>, that <base> is now used instead of the speculative <base>.

The upside is that if <base> is created by DOM scripting or by document.write(), speculative loads thereafter are correct. The downside is that the point in time when speculations become correct in that case depends on how the main thread and the parser thread execute relative to each other, which will make bugs arising from speculations not becoming correct soon enough harder to reproduce and debug.
Attachment #459834 - Attachment is obsolete: true
Attachment #460212 - Flags: review?
Attachment #459834 - Flags: review?(jonas)
Attachment #460212 - Flags: review? → review?(jonas)
Attachment #460223 - Flags: review? → review?(jonas)
Duplicate of this bug: 582551
I think we need to fix this for Firefox 4. Marking blocking betaN+.
blocking2.0: --- → betaN+
Comment on attachment 460212 [details] [diff] [review]
Add speculation-specific base URI management but prefer document-managed <base> when available

Stealing review, r=jst
Attachment #460212 - Flags: review?(jonas) → review+
Attachment #460223 - Flags: review?(jonas) → review+
Thanks for the reviews. Pushed:
http://hg.mozilla.org/mozilla-central/rev/44f910ba5741
http://hg.mozilla.org/mozilla-central/rev/e278b19aa8ca
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.