See bug 1172205 comment 39. We end up in CacheFileUtils::AppendKeyPrefix on those urls and then end up with different key prefixes for the anon and non-anon case. Which means we need a way to do anon prefetch. Most simply, could we just support @crossorigin on <link rel="prefetch">?
Drew, I kicked off some test builds with this patch. I'll post a link to them here once they complete. With those builds, I think your test from bug 1172205 comment 39 should work the way you want, if you use <link rel="prefetch" crossorigin"> to do the prefetching.
Builds: http://email@example.com/try-linux64/firefox-44.0a1.en-US.linux-x86_64.tar.bz2 http://firstname.lastname@example.org/try-macosx64/firefox-44.0a1.en-US.mac.dmg http://email@example.com/try-win32/firefox-44.0a1.en-US.win32.zip
Thank you, Boris. Attempting to open the linked Mac OS build, I get the error: "Nightly" is damaged and can't be opened.
Also, I added a page in bug 1172205 comment 41 that has the same prefetch tag but with the crossorigin="anonymous" attribute.
> I get the error: "Nightly" is damaged and can't be opened. Is that opening the dmg, or running the resulting binary? I just tried downloading it and copying to my desktop and running it and it seems to work fine....
The dmg opens fine. When attempting to launch the binary, Mac OS shows a security icon and a progress bar, and a message about verifying the file. That then ends in the error message.
Huh. Odd... I can run it fine from here (at least via the command line, by running Nightly.app/Contents/MacOS/firefox from Terminal).
Comment on attachment 8673853 [details] [diff] [review] So perhaps like this Review of attachment 8673853 [details] [diff] [review]: ----------------------------------------------------------------- The code itself looks reasonable to me. I haven't fully thought through the idea of enforcing CORS on prefetch, but it seems right (CORS would be enforced on the real fetch later on, anyway). So I think it's worth throwing at the internet and seeing if anything breaks :)
Attachment #8673853 - Flags: feedback?(hurley) → feedback+
(In reply to Drew Stamps from comment #7) > The dmg opens fine. When attempting to launch the binary, Mac OS shows a > security icon and a progress bar, and a message about verifying the file. > That then ends in the error message. Are you attempting to launch directly from the dmg? I seem to remember having that same problem if I don't copy the app to a writeable directory, but I could be wrong.
I guess there's no spec for this prefetching stuff so we can just unilaterally do it... OK, then.
Let's try for actual review, with a commit message and all
Attachment #8674000 - Flags: review?(hurley)
Assignee: nobody → bzbarsky
Status: NEW → ASSIGNED
Thanks, Boris. Nightly launches for me from the command line. And... the change seems to work for my sample pages. Excellent!
Not sure whether we have real docs for this anywhere...
(In reply to Boris Zbarsky [:bz] from comment #15) > Not sure whether we have real docs for this anywhere... We have; I've updated: https://developer.mozilla.org/en-US/docs/Web/HTML/Link_types and https://developer.mozilla.org/en-US/Firefox/Releases/44#HTML
You need to log in before you can comment on or make changes to this bug.