Closed Bug 1187766 Opened 6 years ago Closed 6 years ago

Test loading plugins scenarios with fetch interception

Categories

(Core :: DOM: Service Workers, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla43
Tracking Status
firefox42 --- affected
firefox43 --- fixed

People

(Reporter: dimi, Assigned: dimi)

References

Details

Attachments

(1 file, 1 obsolete file)

No description provided.
blocking v1, feel free to change it as needed. Thanks!
Assignee: nobody → dlee
Status: NEW → ASSIGNED
Hi Ben,
I write a web page with following:

<object data="./test.swf"></object>
<embed src="./test.swf"></embed>
<APPLET ALT="Applet" CODE="./test.class" CODEBASE="applets"></APPLET>

But SW won't intercept these resources when load this page, and I try finding if there is spec talking about what kind of resources SW should intercept but I cannot find it. So I am not sure if current behavior is correct.
Could you provide some suggestion ? Thanks for your help!
Flags: needinfo?(bkelly)
According to http://slightlyoff.github.io/ServiceWorker/spec/service_worker/index.html#on-fetch-request-algorithm we should not intercept "potential client requests" (https://fetch.spec.whatwg.org/#potential-client-request) so <object> and <embed> are behaving correctly (also see bug 1168676). I do not see any such special case for <applet>, however.
Flags: needinfo?(bkelly)
I'll ask Google what they do in chrome this week.  They did mention they do not intercept network requests for "plugins" at the meeting last week.  Not sure if that includes applets.
For now, can you write tests that verify object, embed, and applet are NOT intercepted?  I think its good to have those to protect against accidentally intercepting them in the future.

Thanks!
Attached patch Patch v1 (obsolete) — Splinter Review
I found <applet> doesn't go through the path[1] this bug trying to check unless i miss something. When loading <applet> it will create new channel through DTD case[2] but with the flow i don't understand very well.

So in this patch I only check <object> & <embed>.

[1]http://hg.mozilla.org/mozilla-central/file/0b901209064c/dom/base/nsObjectLoadingContent.cpp#l2482
[2]http://hg.mozilla.org/mozilla-central/file/0b901209064c/parser/htmlparser/nsExpatDriver.cpp#l806
Attachment #8640435 - Flags: review?(bkelly)
Comment on attachment 8640435 [details] [diff] [review]
Patch v1

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

Overall looks good, but I'm not sure about the test completion condition.  r=me with that fixed.  Thanks!

::: dom/workers/test/serviceworkers/fetch/plugin/plugins.html
@@ +25,5 @@
> +      ok(false, "<object> should not be intercepted");
> +    } else if (e.data.context === "embed") {
> +      ok(false, "<embed> should not be intercepted");
> +    } else if (e.data.context === "fetch") {
> +      navigator.serviceWorker.removeEventListener("message", onMessage);

Won't the plugins.html fetch event trigger this before the object and embed elements can be added?  Can you check the URL as well to make sure its completing on the foo.txt fetch?
Attachment #8640435 - Flags: review?(bkelly) → review+
After applying patch to latest code, request.context become undefined.
Will check the root cause.
(In reply to Dimi Lee[:dimi][:dlee] from comment #8)
> After applying patch to latest code, request.context become undefined.
> Will check the root cause.

Ah, I found this is because of Bug 1188062
Encounter try server error :
LoadObject called while not bound to an active document: 'Not Reached'
Attached patch Patch v2Splinter Review
Address Ben's comment, add check for test completion
Attachment #8640435 - Attachment is obsolete: true
Attachment #8650958 - Flags: review+
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/8693948df8f0
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla43
You need to log in before you can comment on or make changes to this bug.