components/webmessaging/public/interfaces/broadcast_channel.mojom - Issue 2004643002: Implement BroadcastChannel

Side by Side Diff

Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.

Keyboard Shortcuts

	File
u :	up to issue
j / k :	jump to file after / before current file
J / K :	jump to next file with a comment after / before current file
	Side-by-side diff
i :	toggle intra-line diffs
e :	expand all comments
c :	collapse all comments
s :	toggle showing all comments
n / p :	next / previous diff chunk or comment
N / P :	next / previous comment
<Up> / <Down> :	next / previous line

	Issue
u :	up to list of issues
j / k :	jump to patch after / before current patch
o / <Enter> :	open current patch in side-by-side view
i :	open current patch in unified diff view

	Issue List
j / k :	jump to issue after / before current issue
o / <Enter> :	open current issue

Side by Side Diff: components/webmessaging/public/interfaces/broadcast_channel.mojom

Issue 2004643002: Implement BroadcastChannel (Closed) Base URL: https://chromium.googlesource.com/chromium/src.git@master

Patch Set: try to fix ios gyp build Created 4 years, 5 months ago

Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.

Jump to:

View unified diff | Download patch

« no previous file with comments | « components/webmessaging/public/interfaces/OWNERS ('k') | content/browser/BUILD.gn » ('j') | content/browser/background_sync/background_sync_manager_unittest.cc » ('J')
Toggle Intra-line Diffs ('i') | Expand Comments ('e') | Collapse Comments ('c') | Hide Comments ('s')

OLD	NEW
(Empty)
	1 // Copyright 2016 The Chromium Authors. All rights reserved.

	2 // Use of this source code is governed by a BSD-style license that can be

	3 // found in the LICENSE file.

	4

	5 module webmessaging.mojom;

	6

	7 import "url/mojo/origin.mojom";

	8

	9 interface BroadcastChannelClient {
	dcheng 2016/06/30 08:23:11 Nit: can we add some sort of interface-level comme Nit: can we add some sort of interface-level comment, e.g. the purpose of this interface? Some sort of documentation about where the service is hosted would be nice too (since this interface is implemented in both the trusted browser process and the untrusted renderers) Marijn Kruisselbrink 2016/06/30 17:21:56 Added some explicit comments to this interface. Show quoted text On 2016/06/30 at 08:23:11, dcheng wrote: > Nit: can we add some sort of interface-level comment, e.g. the purpose of this interface? Some sort of documentation about where the service is hosted would be nice too (since this interface is implemented in both the trusted browser process and the untrusted renderers) Added some explicit comments to this interface.
	10 // Messages are passed as SerializedScriptValue.

	11 OnMessage(string message);

	12 };

	13

	14 interface BroadcastChannelProvider {
	dcheng 2016/06/30 08:23:12 Is there expected to be one of these in the browse Is there expected to be one of these in the browser per renderer? Or some other model? I guess it's exposed by StoragePartition, but I don't know how that concretely maps to the process model. Sorry if this is a dumb question =) Marijn Kruisselbrink 2016/06/30 17:21:56 A content::BrowserContext (chrome::Profile) consis Show quoted text On 2016/06/30 at 08:23:12, dcheng wrote: > Is there expected to be one of these in the browser per renderer? Or some other model? I guess it's exposed by StoragePartition, but I don't know how that concretely maps to the process model. Sorry if this is a dumb question =) A content::BrowserContext (chrome::Profile) consists of multiple StoragePartition, and each renderer process lives inside a particular storage partition (this is for example how chrome apps have separate cookie jars/storage from regular websites). So the way that's currently implemented is that there is one BroadcastChannelProvider instance in the browser process for each StoragePartition, and all connections from all renderers in that storage partition end up binding to the same Provider implementation. Added some more comments to explain this a bit more.
	15 // Connect to the channel identified by the \|origin\| and \|name\|. Messages can

	16 // be sent to the channel using \|sender\|, and messages to the channel will be

	17 // received by \|receiver\|.

	18 // All connections to channels made from the same event loop should be made

	19 // through the same BroadcastChannelProvider to ensure correct ordering of

	20 // messages.

	21 ConnectToChannel(url.mojom.Origin origin, string name,

	22 associated BroadcastChannelClient receiver,

	23 associated BroadcastChannelClient& sender);

	24 };

OLD	NEW