Bug 219472 – document.hasFocus() is true while URL bar has focus

• Status: NEW
• Component: DOM

From https://github.com/whatwg/html/pull/6172#discussion_r532608881

STRs:
 1. Open https://jan-ivar.github.io/dummy/focus.html
 2. Click on URL bar
 3. Click on page

Expected results (works in Chrome, Firefox, Edge):

  true
  true
  BLUR
  false
  false
  FOCUS
  true
  true

Actual results (Safari):

  true
  true
  BLUR
  true
  true
  FOCUS
  true
  true

The spec is being clarified in https://github.com/whatwg/html/pull/6172

[Alexey Proskuryakov]

The proposed patch speaks of "system focus", but what is that? I think that it's something between ill defined and undefined.

Is knowing about where keyboard events are going to be dispatched the intention here, or perhaps something else?

Hi Alexey, it's the existing focus concept [1] extended to the top-level document's viewport, to describe current behavior in all browsers of firing the "blur" event when it loses focus (e.g. from a user leaving the browser window or app, or clicking the URL bar or another tab), and firing the "focus" event when it returns.

In the context of Safari, it's whatever triggers the "blur" event when e.g. the user clicks on Safari's URL bar today, and triggers the "focus" event when the user clicks back on the page afterwards.

The spec fails to capture this, even though it behaves consistently in all the browsers, including Safari, so we're documenting it. If you have concerns about how to specify this, please comment in https://github.com/whatwg/html/pull/6172


In the context of this bug, we found an anomaly in Safari compared to the other browsers wrt document.hasFocus().

Here's the STR code:

  window.onfocus = () => console.log("FOCUS");
  window.onblur = () => console.log("BLUR");
  setInterval(() => console.log(), 1000);

It seems reasonable that a document that receives "blur" no longer hasFocus(), since blur is the opposite of focus, and if for no other reason web compat with other browsers. 

[1] https://html.spec.whatwg.org/multipage/interaction.html#focus

[Alexey Proskuryakov]

So there is no practical application in mind, just consistency between blur/focus/hasFocus()? Nothing bad about consistency, but I'm trying to understand if there is more behind this.

There are lots of edge cases around focus (utility windows taking keyboard focus but not visual focus; Exposé, menus, tab view on iOS etc. which aren't supposed to trigger any activity in content and thus should not be detectable).

> The spec fails to capture this, even though it behaves consistently in all the browsers, including Safari, so we're documenting it. If you have concerns about how to specify this, please comment in https://github.com/whatwg/html/pull/6172

This appears to be about keyboard focus, which I don't see how it can ever be relevant to a webpage.

Actually yes, there is a practical application. 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:

 - https://github.com/w3c/mediacapture-main/issues/752 (what motivated me)
 - https://github.com/immersive-web/webxr/issues/747
 - https://github.com/w3c/sensors/issues/222

They've all crafted language that relies in some part on HTML's concept of focus, and they're all broken right now.

Would you mind elaborating on what "visual focus" is? Because that sounds interesting, as I'm realizing it may in fact not be desirable to delay camera turning on just because the user has focused the URL bar...

If Safari's behavior ends up making more sense here, it might be good to try to capture it in the spec somehow. Open to ideas.

[Alexey Proskuryakov]

> 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.

Yes, it's the browser engine's job to avoid creepiness wrt to camera. My fault for being unclear: the engine won't rely on the behavior of document.hasFocus(), we were merely planning to reference the same underlying algorithm https://html.spec.whatwg.org/multipage/interaction.html#has-focus-steps — But on reflection, it may not even be right given how other browsers behave wrt the url bar. Sorry for the side-track.

I'm not aware of any practical application of the document.hasFocus() API vis-à-vis the URL bar other than consistency.

I notice the same problem happens in iframes as well: https://jan-ivar.github.io/dummy/iframe_focus.html — which violates the existing spec even without my patch.

Not informing a web page about every little focus loss caused by browser-chrome widgets seems reasonable to me, but I don't see what the discrepancy between the blur/focus events and the hasFocus() function accomplishes, since the page is still told about the unfocusing, at least in the URL bar case I observed.

[Alexey Proskuryakov]

> I don't see what the discrepancy between the blur/focus events and the hasFocus() function accomplishes

I agree. As always, it might be that some pages rely on quirky behavior, but I don't think that it's intentional.

[Radar WebKit Bug Importer]

<rdar://problem/72057577>