Closed Bug 534293 Opened 15 years ago Closed 14 years ago

<base> tag ignored by lookahead algorithm

Categories

(Core :: DOM: HTML Parser, defect)

Product:
Core
Component:
DOM: HTML Parser
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Tracking Flags:
Tracking Status
blocking2.0 --- betaN+

People

(Reporter: devin, Assigned: hsivonen)

References

(Blocks 1 open bug,
URL
)

Details

Attachments

(2 files, 1 obsolete file)

Add speculation-specific base URI management but prefer document-managed <base> when available
6.94 KB, patch
jst
: review+
Details | Diff | Splinter Review
Mochitest
6.85 KB, patch
jst
: review+
Details | Diff | Splinter Review 
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.
Depends on: 580571
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)
Attached patch Mochitest — — Splinter Review 

        Attachment #460223 -
        Flags: review?

    
  

        Attachment #460212 -
        Flags: review? → review?(jonas)

    
  

        Attachment #460223 -
        Flags: review? → review?(jonas)

    
    

    
  
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: 14 years ago
Resolution: --- → FIXED

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: