Re: [mediacapture-screen-share] Conditional Focus (When Display-Capture Starts) (#190)

I am trying to **reformulate** my position more clearly. Hopefully this won't be mere repetition. If it is - my apologies.

It might be worth it **working backwards** here:

Issue 1, [WoO](https://en.wikipedia.org/wiki/Window_of_opportunity)-closing-mechanism.
* We have NOT set out to allow applications to change focus to a captured surface at an arbitrary time.
* We don't want to allow applications to change focus any later than a "reasonable" time after capturing starts.
* All mechanisms discussed thus far (task/microtask) can be gamed through busy-waiting.
* For that reason, **besides** any "happy-case" mechanism (task/microtask), **additional** enforcement by the UA is necessary in the form of a maximum time-period.
* This cannot be the only mechanism, because it would not be snappy in the _legacy_ happy-case (tasks/microtasks are fast but the app does not call the API).
* Because of CPU scheduling issues, even optimal applications will **sometimes** hit this limit. When that happens, it's non-actionable and requires no exception. (Also, an exception here is hard to implement, as the time-limit may be imposed in another process for security reasons - particularly in Chrome's implementation.)
* A good API will minimize the number of times this issue is encountered, by encouraging the application to do the minimal amount of work between the time the Promise is resolved and the time it calls the API.
* Limiting the "happy-case" mechanism on microtask boundary rather than task boundary pushes the application harder in this desirable direction.

Issue 2, future-facing APIs:
* Applications can have branching logic in between the Promise being resolved and the API being triggered.
* This means an application could find that the API sometimes works, sometimes doesn't - for example, if it relies on data that it might-or-might-not already have in its app-level cache. (E.g. they might have previously fetched some data from a remote source, and it might already have been downloaded or might not have.)
* It's important to fail loudly and clearly in these cases.
* An API that's valid to call in order to influence the future, cannot raise exceptions when it's called too late to influence the past.
* Therefore, the global-attribute-influencing-future API cannot be our solution.
* It may **complement** our solution, though, by setting a **default** for future calls.

-- 
GitHub Notification of comment by eladalon1983
Please view or discuss this issue at https://github.com/w3c/mediacapture-screen-share/issues/190#issuecomment-931388252 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 30 September 2021 14:43:55 UTC