Closed Bug 1161288 Opened 8 years ago Closed 8 years ago

Support app:// origins on Fetch API

Categories

(Core :: DOM: Core & HTML, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla40
Tracking Status
firefox40 --- fixed

People

(Reporter: ferjm, Assigned: ferjm)

References

Details

(Whiteboard: [s1])

Attachments

(1 file, 3 obsolete files)

I get "TypeError: NetworkError when attempting to fetch resource" when trying to cache a resource via cache.addAll() within the install event handler. The same code works if I install the sw from an https:// origin.
Summary: Trying to cache a resource from a service worker installed from an app:// origin fails → Support app:// origins on Fetch API
Component: DOM: Workers → DOM
Blocks: 1158848
Assignee: nobody → ferjmoreno
Whiteboard: [s1]
Depends on: 1147214
Attached patch WIP (obsolete) — Splinter Review
Status: NEW → ASSIGNED
Attached patch WIP (obsolete) — Splinter Review
Attachment #8601456 - Attachment is obsolete: true
Blocks: 1161684
Attached patch v1 (obsolete) — Splinter Review
Attachment #8602112 - Attachment is obsolete: true
Attachment #8602185 - Flags: review?(nsm.nikhil)
Attachment #8602185 - Flags: review?(amarchesini)
Attached patch v1Splinter Review
Sorry for the spam. I forgot to add one file.
Attachment #8602185 - Attachment is obsolete: true
Attachment #8602185 - Flags: review?(nsm.nikhil)
Attachment #8602185 - Flags: review?(amarchesini)
Attachment #8602188 - Flags: review?(nsm.nikhil)
Attachment #8602188 - Flags: review?(amarchesini)
Comment on attachment 8602188 [details] [diff] [review]
v1

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

I didn't review the script security bit. Everything else looks good!

::: dom/fetch/FetchDriver.cpp
@@ +686,5 @@
>  
> +    // We simulate the http protocol for jar/app requests
> +    uint32_t responseStatus = 200;
> +    nsAutoCString statusText;
> +    statusText.AssignLiteral("OK");

Replace this...

@@ +691,2 @@
>  
> +    response = new InternalResponse(responseStatus, statusText);

... with NS_LITERAL_CSTRING("OK") here.
Attachment #8602188 - Flags: review?(nsm.nikhil) → review+
Comment on attachment 8602188 [details] [diff] [review]
v1

Thank you Nikhil.

Bobby, could you take a look at the nsScriptSecurityManager change, please? Thanks!
Attachment #8602188 - Flags: review?(bobbyholley)
Comment on attachment 8602188 [details] [diff] [review]
v1

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

::: dom/fetch/FetchDriver.cpp
@@ +14,5 @@
>  #include "nsIHttpHeaderVisitor.h"
>  #include "nsIScriptSecurityManager.h"
>  #include "nsIThreadRetargetableRequest.h"
>  #include "nsIUploadChannel2.h"
> +#include "nsIJARChannel.h"

alphabetic order.

@@ +294,5 @@
>      return FailWithNetworkError();
>    }
>  
>    if (scheme.LowerCaseEqualsLiteral("file")) {
>    } else if (scheme.LowerCaseEqualsLiteral("http") ||

can you remove this empty if(scheme.LowerCaseEqualsLiteral("file")) ?
Attachment #8602188 - Flags: review?(amarchesini) → review+
Comment on attachment 8602188 [details] [diff] [review]
v1

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

::: caps/nsScriptSecurityManager.cpp
@@ +756,5 @@
>                                   nsIProtocolHandler::URI_DANGEROUS_TO_LOAD);
> +
> +    // In order to be able to test packaged apps (app:// scheme) from
> +    // mochitests (http:// scheme) we need to ignore the scheme mismatch.
> +    if (!Preferences::GetBool("security.uri.allow_scheme_mismatch", false) &&

I'm not wild about this - this seems like an overly-broad hammer to apply here, and we're trying to make the URI loading permissions simpler rather than adding more special cases. Can you describe the use-case you're trying to solve in more detail?
Attachment #8602188 - Flags: review?(bobbyholley) → review-
Talked to Bobby on IRC and he suggested a change in the test that solved the issue and avoids making the change in the ScriptSecurityManager.
https://hg.mozilla.org/mozilla-central/rev/c997b5af752d
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla40
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.