[Webkit-unassigned] [Bug 219472] document.hasFocus() is true while URL bar has focus

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=219472

Alexey Proskuryakov <ap at webkit.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jer.noble at apple.com,
                   |                            |thorton at apple.com,
                   |                            |wenson_hsieh at apple.com

--- Comment #5 from Alexey Proskuryakov <ap at webkit.org> ---
> Several specs have attempted to define similar "visible and focused" criteria for features that would be creepy to activate (or in some cases resume) from background tabs, minimized windows/apps, and maybe even from (partially) visible windows other than the one the user is currently engaging with

I see. That's a huge can of worms, so it may be best to have this bug only track consistency, i.e. whatever poorly behavior focus/blur has, should match hasFocus().

My personal view is that it's not possible to expose details of window state to webpages in a way that's complete, cross-platform and will be compatible with future platform innovations. 

So instead of the browser engine telling the webpage about what's happening around it, and the webpage deciding what to do, it should be the opposite - the webpage tells the engine what it needs at a high level, and the engine decides how to respond. I do not know much about media capture, but it strikes me as a case where it should be browser engine's job to avoid creepiness, even for ill-behaved webpages.

> Would you mind elaborating on what "visual focus" is? 

I was referring to visual cues help the user understand where the focus is, whether keyboard focus or just focus of attention in general.

As inactive windows look different (window chrome is subdued, focus rings may disappear, selection and controls may be subdued in some OSes), I thought that the motivation could be that page content wants to update appearance of custom controls and selections.

Similar but not identical effects occur when changing keyboard focus to the URL bar, or to a utility window.

Utility windows (like the Emoji & Symbols window on Mac) are a particularly thorny case, as they take keyboard focus, and may overlap the main window, but don't become main windows for most intents and purposes, and even focus rings or selections don't change.

Also, we generally cannot notify webpages about things like Exposé or tab view, both because that would be a weird user experience for page rendering to change when minimized, and because there is no time to run JS event handlers for performance reasons.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20201204/2dfa29a3/attachment.htm>