Should the focused area of the control group change when losing focus?

[avallee]

I'm writing a test to help me clarify my understanding of which element should be the activeElement in a document. web-platform-tests/wpt#7907

Now the focus update steps only mention updating the focused area of a control group for those control groups that are in the new chain after removing the common elements with old chain. There is no mention of this for the elements of the old chain. This would lead me to think that since the value is not explicitly changed, we can assert that it does not change as a result.

However, current implementations fail this test and seem to reset to the body element.

Is my interpretation wrong? Is the spec underspecified? Are the implementations wrong?

[RByers]

@domenic @smaug---- thoughts?

[smaug----]

I don't quite understand what is being asked here. Could you link to the relevant part of the spec and the part of the testcase you're wondering?

[avallee]

In https://html.spec.whatwg.org/multipage/interaction.html#focus-update-steps in step 2, while processing the old chain, there is no mention to designate any new focused area of the control group. Only step 4.2 and (https://html.spec.whatwg.org/multipage/interaction.html#focusing-steps) mention designating a new focused area of the control group.

This confused me as this is against what I observe in the wild where the implementations all seem to reset it (the return value of document.activeElement is document.body where it was something else before focusing another element).

[domenic]

I'm sorry for the delay here. As you've discovered, the control group stuff is pretty confusing, and #2171 doesn't help by creating a level of indirection. Let's see what we can do.

I think what you might be missing is

When the currently focused area of a top-level browsing context is somehow unfocused without another element being explicitly focused in its stead, the user agent must immediately run the unfocusing steps for that object.

The unfocusing steps 5 + 6 reset the activeElement to the viewport (i.e. the body).

The "somehow" here is pretty unhelpful, and it could help to insert an example similar to your test, I think.

I guess it's also unclear whether "another element" includes other elements in other browsing contexts. I'm interpreting it as not including those, so that your test triggers this condition.

Does this seem right? If so we can definitely make the spec more clear here.

[avallee]

This doesn't sound exactly right, at least not for my specific case.

The unfocusing steps 5 + 6 reset the activeElement to the viewport (i.e. the body).

My reading of the spec indicate to me that the user agent would run the unfocusing steps either:

When the currently focused area of a top-level browsing context is somehow unfocused without another element being explicitly focused in its stead, the user agent must immediately run the unfocusing steps for that object.

or

The blur() method, when invoked, should run the unfocusing steps for the element on which the method was called. User agents may selectively or uniformly ignore calls to this method for usability reasons.

The problem seems to be that in the case i am interested in, these steps are not invoked.I am explicitly focusing another element. From my reading of the spec only the focus update steps are being run then. Am I wrong in understanding that only focus update should run?

[domenic]

Right, as I said, I think the following clause triggered:

When the currently focused area of a top-level browsing context is somehow unfocused without another element being explicitly focused in its stead

When you focus something in another frame, I think it unfocuses the focused area of the top-level browsing context.

As I said above, this isn't explicitly clear, and we can make it clearer. But I think that's what's going on.

[avallee]

If it is intended that the unfocusing steps should be run when updating, it should be called out explicitly somewhere in the focusing steps or focus update steps.