[e10s] nsPrefetchNode fails with NS_NOINTERFACE (0x80004002), font prefetch fails

RESOLVED FIXED in Firefox 39

Status

()

Core
Networking: HTTP
RESOLVED FIXED
3 years ago
3 years ago

People

(Reporter: David Jones, Assigned: dragana)

Tracking

({reproducible, testcase})

36 Branch
mozilla39
reproducible, testcase
Points:
---

Firefox Tracking Flags

(e10s+, firefox39 fixed)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

3 years ago
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:34.0) Gecko/20100101 Firefox/34.0
Build ID: 20141127111021

Steps to reproduce:

I added a LINK element to the home page of a website to prefetch a web font so that it's quickly displayed on subsequent pages. (The font isn't used on the home page, only prefetched.) I set the LINK element's REL attribute to "prefetch" and I set the HREF attribute to the web font's URL (e.g., "http://localhost:3000/font.woff" when testing locally and "https://cdn.example.com/font.woff" on my employer's server).


Actual results:

When I test font prefetching locally, it works as expected in Firefox and Chrome. Both browsers' dev tools show that the font is downloaded on the home page and not downloaded on subsequent pages. Similarly, when I visit one of the non-home pages first and then visit the home page, the font is downloaded on the non-home page and not downloaded on the home page.

When I test font prefetching on my employer's server, it works as expected in Chrome, but not in Firefox. Firefox's dev tools show that the font is downloaded on the home page, but surprisingly, the dev tools show that the font is downloaded again on the next page. The font is not downloaded on other pages, only on the home page and the first page that's visited after the home page. When I visit one of the non-home pages first and then visit the home page, the font is downloaded on the non-home page and also downloaded on the home page, but it's not downloaded on any subsequent pages.


Expected results:

I expected that Firefox wouldn't download a font from a CDN twice.
(Reporter)

Comment 1

3 years ago
Additional details:

Only the font is downloaded twice
Summary: Font downloaded twice from CDN → Prefetched font is downloaded twice from CDN
(Reporter)

Comment 2

3 years ago
Additional details:

Only the font is downloaded twice, not any of the other prefetched files, which include images, stylesheets, and JavaScript files.

Setting the LINK elements's TYPE attribute to "application/font-woff" had no effect.

Below is the result of running "curl -I https://cdn.example.com/font.woff".

HTTP/1.1 200 OK 
Date: Mon, 15 Dec 2014 14:15:04 GMT
Content-Type: application/font-woff
Content-Length: 65452
Connection: keep-alive
Strict-Transport-Security: max-age=31536000
Last-Modified: Mon, 15 Dec 2014 14:02:11 GMT
Cache-Control: public, s-maxage=31557600, max-age=31557600
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET
Access-Control-Allow-Headers: x-requested-with
Access-Control-Max-Age: 3628800
Via: 1.1 vegur
Server: NetDNA-cache/2.2
X-Cache: HIT
(Reporter)

Updated

3 years ago
Version: 34 Branch → 36 Branch

Updated

3 years ago
Component: Untriaged → Networking: HTTP
Product: Firefox → Core

Comment 3

3 years ago
Is the CDN google? This looks like it's related to / a duplicate of bug 1060767.
Flags: needinfo?(davidjohnson)
(Reporter)

Comment 4

3 years ago
Hi, Gijs. The CDN that we use is MaxCDN. I've created a test site <http://111158.nfshost.com/> to demonstrate the issue. In addition to being the CDN that we use, MaxCDN also provides the public CDN for Font Awesome, so to keep things simple, I used MaxCDN's Font Awesome CDN for the demonstration.
Flags: needinfo?(davidjohnson)

Updated

3 years ago
Flags: needinfo?(gijskruitbosch+bugs)

Comment 5

3 years ago
Thanks for the testcase!

I can reproduce this on Windows, and I agree it doesn't seem to make a lot of sense. After the 'real' (not prefetch) request of the font, it seems like subsequent refreshes of the page just get a 304, which makes more sense - but it's not clear to me why the prefetch doesn't just do that anyway. Jonathan, can you enlighten us as to what is going on here and if there's a font or http issue, or something else?
Flags: needinfo?(gijskruitbosch+bugs) → needinfo?(jfkthame)
Keywords: reproducible, testcase
OS: Linux → All
Hardware: x86_64 → All
Sorry, I don't know much about network requests, etc.

AFAICS, the "real" GET request for the font when visiting the "Display font" page does not (on the first load) include any of the headers such as If-Modified-Since that would make it a conditional GET, so the server has no choice but to return a full copy of the font. Which seems to suggest that the "prefetch" link has not recorded the prefetched resource in such a way that the subsequent "real" font request recognizes it as being the same. Maybe because the Accept header is different? But that's just me guessing wildly.... I think you need someone who actually knows a bit about the HTTP cache, requests, prefetch links, and all that.
Flags: needinfo?(jfkthame)

Comment 7

3 years ago
(In reply to Jonathan Kew (:jfkthame) from comment #6)
> I think you need someone who actually knows a bit about the HTTP
> cache, requests, prefetch links, and all that.

Fair! Trying McManus next. :-)
Flags: needinfo?(mcmanus)
honza is the cache guru
Flags: needinfo?(mcmanus) → needinfo?(honzab.moz)
I think the prefetch is using an anonymous load (XHR) but the "real" load is non-anonymous (a.k.a. "normal").  Each uses a distinct storage.

If confirmed, please close as INVALID.
Flags: needinfo?(honzab.moz)
(In reply to Honza Bambas (:mayhemer) from comment #9)
> I think the prefetch is using an anonymous load (XHR) but the "real" load is
> non-anonymous (a.k.a. "normal").  Each uses a distinct storage.
> 
> If confirmed, please close as INVALID.

Does that mean this is not a supported use of prefetching? Is it documented somewhere which kinds of resources can usefully be prefetched, as specifying a prefetch link for a resource (and using bandwidth to download it) when it is not able to satisfy the "real" request is rather sad...

Should we be using an anonymous load in the userfont-loading code? (Is that what other resources do, given that they apparently work -- comment 2?)
Flags: needinfo?(honzab.moz)
I don't know what you are doing exactly, so it's hard to answer.  This bug just sounds like the prefetch is anonymous.

Please provide a simple proof of concept (a simple test case) so that I can reproduce to move forward here.

Thanks.
Flags: needinfo?(honzab.moz) → needinfo?(jfkthame)

Comment 12

3 years ago
(In reply to Honza Bambas (:mayhemer) from comment #11)
> I don't know what you are doing exactly, so it's hard to answer.  This bug
> just sounds like the prefetch is anonymous.
> 
> Please provide a simple proof of concept (a simple test case) so that I can
> reproduce to move forward here.
> 
> Thanks.

There's a link in comment #4 with a simple testcase.
Flags: needinfo?(honzab.moz)
See above for details including testcase (comment 4).
To reproduce, with the Network tab open to observe requests (and assuming you start with an empty cache):
* Load http://111158.nfshost.com/
* Click the "Prefetch assets" link. Note that it fetches the HTML page, a CSS file, and a font.
* Go back
* Click the "Display font" link. Note that it re-fetches the font that was just prefetched.
Flags: needinfo?(jfkthame)
>	xul.dll!nsPrefetchNode::OnStartRequest(0x04e9b450, 0x00000000) Line 251	C++
 	xul.dll!mozilla::net::HttpChannelChild::DoOnStartRequest(0x04e9b450, 0x00000000) Line 360	C++
 	xul.dll!mozilla::net::HttpChannelChild::OnStartRequest(NS_OK, {...}, true, {...}, false, true, 0x5692ad2b, {...}, {...}, {...}, {...}) Line 352	C++
 	xul.dll!mozilla::net::HttpChannelChild::RecvOnStartRequest(NS_OK, {...}, true, {...}, false, true, 0x5692ad2b, {...}, {...}, {...}, {...}, 0x0000) Line 296	C++


NS_IMETHODIMP
nsPrefetchNode::OnStartRequest(nsIRequest *aRequest,
                               nsISupports *aContext)
{
    nsresult rv;

    nsCOMPtr<nsICachingChannel> cachingChannel =
        do_QueryInterface(aRequest, &rv);
    if (NS_FAILED(rv)) return rv;


aRequest = [mozilla::net::HttpChannelChild]
rv = NS_NOINTERFACE (0x80004002)



nsPrefetchNode must go after nsICacheInfoChannel.  It's single/multiprocess compatible.

Jason, can you do it?  Feel free to bounce back.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(honzab.moz)
Summary: Prefetched font is downloaded twice from CDN → [e10s] nsPrefetchNode fails with NS_NOINTERFACE (0x80004002), font prefetch fails

Updated

3 years ago
tracking-e10s: --- → +
(Assignee)

Updated

3 years ago
Assignee: nobody → dd.mozilla
(Assignee)

Comment 15

3 years ago
David, can you put the test that you have made back on, so i can test the patch?
Just to check, have you been using e10s?
Flags: needinfo?(davidjohnson)
(Reporter)

Updated

3 years ago
Flags: needinfo?(davidjohnson)
(Reporter)

Comment 16

3 years ago
Dragana wrote:
> David, can you put the test that you have made back on, so i can test the patch?

Hi, Dragana. I needed to move the test to here: http://www.storylink.com/1111581/

> have you been using e10s?

No, I haven't. I enabled e10s in Firefox Developer Edition 37.0a2 just now, and it didn't seem to make a difference.
(Assignee)

Comment 17

3 years ago
Created attachment 8569124 [details] [diff] [review]
bug_1111581_v1.patch
Attachment #8569124 - Flags: review?(honzab.moz)
(Assignee)

Comment 18

3 years ago
https://treeherder.mozilla.org/#/jobs?repo=try&revision=94e0bfac59e4
Comment on attachment 8569124 [details] [diff] [review]
bug_1111581_v1.patch

Review of attachment 8569124 [details] [diff] [review]:
-----------------------------------------------------------------

thanks!
Attachment #8569124 - Flags: review?(honzab.moz) → review+
(Assignee)

Updated

3 years ago
Keywords: checkin-needed
https://hg.mozilla.org/integration/mozilla-inbound/rev/af0e56fc81b3
Keywords: checkin-needed
https://hg.mozilla.org/integration/mozilla-inbound/rev/138f4bb6fbde
Re-landed, sorry for the churn.
https://hg.mozilla.org/integration/mozilla-inbound/rev/27f56cce6182
https://hg.mozilla.org/mozilla-central/rev/27f56cce6182
Status: NEW → RESOLVED
Last Resolved: 3 years ago
status-firefox39: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla39
You need to log in before you can comment on or make changes to this bug.