Bug 94559 - Make shared workers respect third-party storage blocking setting
Summary: Make shared workers respect third-party storage blocking setting
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebCore Misc. (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Vicki Pfau
Keywords: InRadar
Depends on:
Reported: 2012-08-20 18:27 PDT by Vicki Pfau
Modified: 2012-08-28 12:26 PDT (History)
5 users (show)

See Also:

Patch (9.17 KB, patch)
2012-08-27 11:28 PDT, Vicki Pfau
no flags Details | Formatted Diff | Diff
Archive of layout-test-results from gce-cr-linux-06 (524.69 KB, application/zip)
2012-08-27 12:38 PDT, WebKit Review Bot
no flags Details
Patch (10.25 KB, patch)
2012-08-27 15:20 PDT, Vicki Pfau
abarth: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Vicki Pfau 2012-08-20 18:27:34 PDT
When the third-party storage blocking setting is enabled, shared workers should not be allowed to leak information across origins.
Comment 1 Vicki Pfau 2012-08-21 15:41:05 PDT
Comment 2 Vicki Pfau 2012-08-27 11:28:59 PDT
Created attachment 160756 [details]
Comment 3 Adam Barth 2012-08-27 12:06:59 PDT
Comment on attachment 160756 [details]

View in context: https://bugs.webkit.org/attachment.cgi?id=160756&action=review

> Source/WebCore/workers/SharedWorker.cpp:68
> +    // We don't currently support nested workers, so workers can only be created from documents.

Should we have an ASSERT here so we remember to look at this code when we do start supporting nested workers?

> Source/WebCore/workers/SharedWorker.cpp:71
> +        ec = SECURITY_ERR;

Is SECURITY_ERR the right error to through here?  Is this what we throw in other circumstances?
Comment 4 Adam Barth 2012-08-27 12:08:12 PDT
I wanted to mark this r+/cq-, but when I've done that in the past, you've ignored some of my comments.  It doesn't seem right to mark this r- since I'm just asking for ASSERTs and about the types of exceptions, so I'm going to leave it r?.  I'm happy to mark an updated patch r+ if you address my comments above.
Comment 5 Adam Barth 2012-08-27 12:22:12 PDT
Comment on attachment 160756 [details]

jpfau and I talked through our miscommunication on #webkit and joy was restored throughout the land.
Comment 6 WebKit Review Bot 2012-08-27 12:38:16 PDT
Comment on attachment 160756 [details]

Attachment 160756 [details] did not pass chromium-ews (chromium-xvfb):
Output: http://queues.webkit.org/results/13609478

New failing tests:
Comment 7 WebKit Review Bot 2012-08-27 12:38:19 PDT
Created attachment 160779 [details]
Archive of layout-test-results from gce-cr-linux-06

The attached test failures were seen while running run-webkit-tests on the chromium-ews.
Bot: gce-cr-linux-06  Port: <class 'webkitpy.common.config.ports.ChromiumXVFBPort'>  Platform: Linux-2.6.39-gcg-201203291735-x86_64-with-Ubuntu-10.04-lucid
Comment 8 Vicki Pfau 2012-08-27 15:20:26 PDT
Created attachment 160823 [details]
Comment 9 Adam Barth 2012-08-27 15:21:07 PDT
Comment on attachment 160823 [details]

Comment 10 Vicki Pfau 2012-08-28 12:26:26 PDT
Committed r126912: <http://trac.webkit.org/changeset/126912>