Re: [mediacapture-handle] Don't reinvent postMessage (#11)

> If we're worried about opening new channels of communication, "actions" is worrisome because it goes in the other direction.

[sendCaptureAction]( is rate-limited because it requires [transient activation]( and [consumes user activation](

> A drive-by suggestion: Maybe rate-limiting the calls to setCaptureHandleConfig() can reduce the risk

@yoavweiss Thanks, I think that's a good idea worth considering as a minimum.

But I think the fact that (short of screen-scraping) no other cross-storage message channel exists in the platform today, merits concern. It's even superior to the [messaging channel it's supposedly bootstrapping](, which I guess would be:
1. the capturer making RESTFUL calls to the capturee's server, and
2. the capturee making RESTFUL calls to the capturer's server?

I don't see who'd bother setting up the 2. if they can send _local_ cross-storage instructions munged into `setCaptureHandleConfig()`.

I'd prefer single-use to start. We can always loosen it later, which is easier on web compat than tightening up mistakes.

> It's common for the top-level to be reloaded when users log in/out, but is it necessary?

That's a good question. I've not been impressed by other use cases mentioned offline, which included getting info to the capturer in time for the proposed "conditional focus" API. That's a legitimate problem, but seems deserving of a proper solution, not a hack like this. Maybe a shared `controller` object like in could bring these things together? 

GitHub Notification of comment by jan-ivar
Please view or discuss this issue at using your GitHub account

Sent via github-notify-ml as configured in

Received on Friday, 11 March 2022 22:34:43 UTC