clarify Clients.matchAll() focus order for nested frames

[wanderview]

Clients.matchAll() says to order Clients so most recently focused clients are first in the list. What does this mean for nested iframes? Consider:

1. A window with a nested iframe. The iframe is focused. In theory both the window and iframe Client.focused will be true. Will they also have the same focus time?
2. A window that is already focused with a nested iframe that is not focused. The iframe is focused. Are the focus times for both windows updated or just the iframe?

[wanderview]

Note, it may be difficult to write a WPT test to expose this behavior. At least in firefox we restrict what things like window.focus() based on a variety of heuristics. To write an effective test I'll like need to use a browser-specific test framework to get around these restrictions.

[wanderview]

There is some discussion in IRC here where Jake and I conclude it should probably follow what browsers do for document.hasFocus():

http://logs.glob.uno/?c=freenode%23whatwg&s=23+Feb+2017&e=23+Feb+2017&h=focus#c1021602

This means parent/child frames get the same focus time when the child frame is focused. Although perhaps creation order is not the best there since ideally the child would be returned first, but current rules require window to be returned first (same time, creation order fallback).

[wanderview]

Talking with @smaug----, it also seems a bit weird that the matchAll() steps link to this for the focus order:

https://html.spec.whatwg.org/multipage/interaction.html#focusing-steps

But those steps largely deal with browsing contexts. In contrast, Client objects represent environment or environment settings.

It seems we need something that tracks "last focus time" on the environment. This is basically what I am implementing, but it would be nice if the spec was clear about it.

[wanderview]

Note, it may be difficult to write a WPT test to expose this behavior. At least in firefox we restrict what things like window.focus() based on a variety of heuristics. To write an effective test I'll like need to use a browser-specific test framework to get around these restrictions.

Ignore this. I just wrote the WPT test using iframes:

https://hg.mozilla.org/integration/mozilla-inbound/rev/b53d88cb7099

The test codifies my best interpretation of the spec in its current state.

[smaug----]

(environment is basically Window, but the same Window can be reused for different Documents. Though, not sure if SW can be used with initial about:blanks )

[jakearchibald]

F2F: Outside window appears first. Inner windows afterwards.

We think we can change this in future without too much breakage if we have to.

[xzhan96]

Hi @jakearchibald, this is related with Chromium issue 701233

Sorry, I didn't clear about the conclusion in chromium.

1. A window with a nested iframe. The iframe is focused. In theory both the window and iframe Client.focused will be true. Will they also have the same focus time?
2. A window that is already focused with a nested iframe that is not focused. The iframe is focused. Are the focus times for both windows updated or just the iframe?

[jungkees]

Not sure if we are clear about this issue now. I haven't changed the behavior but tried to clean up the steps: https://github.com/w3c/ServiceWorker/pull/1259/files#diff-27b79860afe28f01aed4f1f6228367faR1232.

I think both Blink and Gecko implemented this introducing some "last focus time" info that's updated when focusing step runs on a frame in the document hierarchy. I think that conforms to what spec suggests, right?

But those steps largely deal with browsing contexts. In contrast, Client objects represent environment or environment settings.

I addressed this by defining and referencing the client's associated browsing contexts.