Consider making it possible to use BroadcastChannel from (somehow privileged) child js to communicate with chrome js

NEW
Unassigned

Status

()

Core
DOM
P3
normal
a year ago
9 months ago

People

(Reporter: smaug, Unassigned)

Tracking

50 Branch
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

a year ago
Need to figure out how to do this. Some special origin?
(Reporter)

Comment 1

a year ago
(it is still unclear whether Activity Streams actually would need this, or indexedDB or something else, but something to consider. )
Tim for adding more people to explain current usage and their thinking about IDB.
Flags: needinfo?(tspurway)
(Reporter)

Comment 3

a year ago
yet another option is to send somehow MessagePort to another process and use that for communication.
I am going to widen the conversation on this bug.  Kate, Ed, Dan: what is our current thinking on relieving the main thread.  I assume this will be most important when we are dealing with querying and processing for highlights?
Flags: needinfo?(tspurway)
Flags: needinfo?(khudson)
Flags: needinfo?(edilee)
Flags: needinfo?(dmose)

Comment 5

a year ago
nanj, I can't seem to find a bug/issue related to your work on content process SQL access. Assuming we do have that, are there other needs to specially communicate between content/chrome?
Flags: needinfo?(edilee) → needinfo?(najiang)

Comment 6

a year ago
Mardak, I am currently working on https://bugzilla.mozilla.org/show_bug.cgi?id=1352502, which consists of a table schema change and the related getter/setter APIs. That patch will be pushed to try and reviewboard shortly. 

Note that like most of the async Places APIs, all the SQL queries will be executed on a database worker thread in the chrome process, without any involvement of the content process. There is also a plan of wrapping all the existing non-trivial topsites&highlights queries into a few async APIs running on the database worker thread.

So the main purpose of this work is about moving those expensive queries off the main thread, I'm not very sure about the needs of content processs SQL access, although that seems to be doable :). I've already confirmed with ursula of this, it appears to be fine to access Places in this way.

Let me know if I missed anything.
Flags: needinfo?(najiang)

Updated

11 months ago
Flags: needinfo?(khudson)

Updated

10 months ago
Flags: needinfo?(dmose)
mystor told me about some plans that were discussed with Ursula. Maybe they can comment about priority here?
Flags: needinfo?(usarracini)
Flags: needinfo?(michael)

Comment 8

10 months ago
(In reply to Andrew Overholt [:overholt] from comment #7)
> mystor told me about some plans that were discussed with Ursula. Maybe they
> can comment about priority here?

I haven't talked with ursula about this IIRC. Assuming you're talking about our recent discussion, we were talking about remoting the moz-thumbs protocol.

I don't know what this bug is related to.
Flags: needinfo?(michael)
If this has to do with indexedDB, Activity Stream could definitely use this functionality in the future to save some state in IDB and rehydrate the content process from there on startup. Other than that, Michael covered it, our recent discussions had to with allowing moz-page-thumb protocol to run in content so Activity Stream can use it for displaying screenshots. Not sure how this bug is related to that discussion
Flags: needinfo?(usarracini)
OK, thanks. It seems this isn't super urgent so I'll mark it as P3.
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.