![]() So ideally, that focus involves both the page and app being in focus (but not privileged chrome) should be explicit in the spec.Microsoft has also denied a detailed technical post about the breach by cloud security firm Wiz, despite having been involved in verifying the post. That prevents the sensor from being deactivated in such cases, which has security consequences. ![]() I'm also not sure that all browsers consistently unfocus pages when the user focuses on browser chrome and/or browser extensions. That is, on some browsers the web page is considered to no longer have focus, while on other browsers this is not the case and the page continues to be considered as focused despite the browser having moved to the background. It's worth noting that there's currently no consistency in how browsers report pages loosing focus to other applications. when relying on the user agent's password manager or a third party password manager), or other applications altogether. when using an embedded third party to carry out payment), other tabs or windows (again when using third party payment solutions), browser chrome or browser extensions (e.g. In practice, this means nested iframes (e.g. See for example this 2011 article on this topic. Again, this is because sensors like gyroscopes can be used relatively effectively to steal data entered elsewhere (e.g. As mentioned, we want to be able to stop the sensor from reporting data as soon as the user is entering data on anything else than the web page of the active sensor. Giving a bit more context around our generic-sensor use case. Although I'm wondering if maybe we shouldn't overload the word "focus" and instead use some new word like "choice" or "foreground" or something. We'll need a good name for that hook that ties into the above concept naming.īTW I'm currently thinking of this as a new section underneath, probably at the bottom, defining and describing this new concept of "Top-level browsing context focus". So we'd need to create steps like "When the user agent changes its choice of currently-focused top-level browsing context, run the following steps." where those steps loop over all documents (browsing contexts? Windows? Which is more useful for your use cases?) that got un-focused and all documents that got newly-focused and runs some hook. That's the kind of hook we're talking about here. You'd need to find the point at which something becomes true or false, and then invoke a function. Think about how you'd write this in software. Second, we can't just use magic like "monitor whether something is true". I think we instead want to say something about how user agents can define the concept of the currently-focused top-level browsing context, and then give some explanation about how this ties into tabbed interfaces, window managers, popup windows, etc. ![]() my Firefox window currently has focus from the OS's window manager, despite only one of 20 tabs being actually focused). Also, it implies that background tabs are focused (since e.g. ![]() Is it just the sentence "the active document of a browsing context which is (or has an ancestor browsing context which is) in focus by a window which is in focus by the operating system's window manager."? That seems not great, given how it relies on undefined concepts like window manager. It's a lot of text, and I don't see a real algorithm in there. A couple issues with what you've got so far:įirst, it would help if you outlined what part of what you linked to you were thinking of including. Thanks for putting in the effort, I think I can start to help from this. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |