Bug 269909 – Inert attribute should make text not findable by find-in-page

• Status: NEW
• Component: DOM

[Emilio Cobos Álvarez (:emilio)]

See https://html.spec.whatwg.org/multipage/interaction.html#inert-subtrees.

Firefox implements this now (https://bugzilla.mozilla.org/show_bug.cgi?id=1868316).

Chromium issue tracking this is https://issues.chromium.org/issues/325372936.

WPT is in https://wpt.fyi/results/inert/inert-and-find.html

[Alexey Proskuryakov]

I'm curious about the rationale. As a user, I'd expect all text that is visible to be findable, and I don't see any desirable exceptions to this rule.

[Emilio Cobos Álvarez (:emilio)]

Same rationale for inert not being in the a11y tree nor interactable... Or same reason for having aria-hidden or such. It is true that most visible text should be accessible / findable, but there are use cases for that not being the case.

See https://github.blog/2023-06-21-crafting-a-better-faster-code-view/#hiding-text-from-ctrlf in particular for such a valid use case, and some extra discussion in https://github.com/orgs/community/discussions/77953 / https://github.com/w3c/csswg-drafts/issues/9726 / https://github.com/w3c/csswg-drafts/issues/3460 about other proposed alternatives.

You can already achieve non-findable, visible text by using pseudo elements in WebKit and Blink. Having find and the a11y tree match for inert nodes makes sense to me.

[Alexey Proskuryakov]

Agreed with the use case of not finding the same result twice when there is an overlay with some highlight, however this solution seems like it can potentially create worse usability problems than what it solves.

I understand that this is not the right venue for debating standards, however excluding from find seems entirely orthogonal to other meanings of inert.

> You can already achieve non-findable, visible text by using pseudo elements in WebKit and Blink. 

For what it's worth, this seems like a bug to me.

> Having find and the a11y tree match for inert nodes makes sense to me.

I think that this principle would be more accurately applied as "inert elements should be all visibility:hidden", which is clearly not what inert does. But as long as they are visible, I don't see the consistency in having them excluded from find.

[Emilio Cobos Álvarez (:emilio)]

(In reply to Alexey Proskuryakov from comment #3)
> Agreed with the use case of not finding the same result twice when there is
> an overlay with some highlight, however this solution seems like it can
> potentially create worse usability problems than what it solves.
> 
> I understand that this is not the right venue for debating standards,
> however excluding from find seems entirely orthogonal to other meanings of
> inert.

Curious, can you elaborate why you think it's orthogonal? Seems pretty similar to other effects inert has.

> > You can already achieve non-findable, visible text by using pseudo elements in WebKit and Blink. 
> 
> For what it's worth, this seems like a bug to me.

Yeah, a bug without any alternative that big pages like GitHub use, causing perf issues in Firefox (which doesn't suffer from that bug)... :/

> I think that this principle would be more accurately applied as "inert
> elements should be all visibility:hidden", which is clearly not what inert
> does. But as long as they are visible, I don't see the consistency in having
> them excluded from find.

How so? The point of `inert` is having an easy way of making stuff visible but both hidden from a11y and similar means.

[sideshowbarker]

Pull request: https://github.com/WebKit/WebKit/pull/25161

[sideshowbarker]

I went ahead and put together a patch for this, but I wanted note that’s not in any way intended to preëmpt further discussion here. Of course it’s anyway not up to me to decide whether or not the patch gets merged — but it seems useful to have a concrete change for others to evaluate.

[sideshowbarker]

Emilio, I wonder if we should also have tests for the case of text nodes which have become inert due to being outside an open modal dialog https://html.spec.whatwg.org/multipage/interaction.html#modal-dialogs-and-inert-subtrees

[Emilio Cobos Álvarez (:emilio)]

Sure, expanding the test I added (or using a different file) to test that case would be great. Same for fullscreen.

[Alexey Proskuryakov]

> Curious, can you elaborate why you think it's orthogonal? Seems pretty similar to other effects inert has.

I'm thinking of find as purely a user operation which is not supposed to be controlled by webpage at all. If you see it, you can find it.

In an ideal world, accessibility would be like that too - if something works visibly, then it's also accessible. But in practice it's not, and accessibility requires additional design and testing to work properly. Adding the same kind of complexity to find seems very undesirable to me.

Thinking ahead of a website that breaks find accidentally or intentionally, respecting find-breaking inert behavior would be a user hostile action, so browser engine implementors will be put in a position of choosing between spec compliance and user friendliness, which is not a good position to be in.

> How so? The point of `inert` is having an easy way of making stuff visible but both hidden from a11y and similar means.

Right, but find is not similar in my view.

[Emilio Cobos Álvarez (:emilio)]

(In reply to Alexey Proskuryakov from comment #9)
> Adding the same kind of complexity to find seems very undesirable to me.

That's why it's nice that this is controlled by `inert` (which is a heavy hammer) and not by something more granular like it was proposed in https://github.com/w3c/csswg-drafts/issues/3460, for example.

I think this change will generally be a progression. I don't think find should find nodes outside what the user can interact with in any way. For example, consider this test-case:

```
<!doctype html>
<button onclick="this.requestFullscreen()">Go fullscreen</button>
<p>Can you find this text?</p>
```

Right now Safari allows you to find the <p>, while this change would prevent it from being findable.

You could argue that find could be smarter and take rendering more into account, but I don't think that's particularly trivial either, and even if you made the button and backdrop transparent with something like:

  button:fullscreen, ::backdrop { background: transparent; pointer-events: none; }

You wouldn't be able to interact with the text in any other way that //isn't// find-in-page.

> Right, but find is not similar in my view.

I disagree. Find and accessibility tools should have ideally access to the same content, IMO.

[Alexey Proskuryakov]

> That's why it's nice that this is controlled by `inert` (which is a heavy hammer)

Perhaps this points to why I'm more concerned about negative consequences. In my experience, some designers are very prone to making as many parts of the webpage as "inert" as possible (can't select, can't invoke macOS Dictionary, can't invoke translation features, can't save images, can't get to a context menu by right-clicking). 

Would the actual inert be used more widely over time for this purpose and breaking find? My guess is yes. And of course accessibility will be made to work in custom  ways anyway, so that won't be much of a deterrent.

I appreciate that using inert was partly chosen due to this concern, but I don't think that it resolves it well enough.

(by the way, should browser translation features also be inhibited by inert? should full-text history search in Safari also be inhibited?)

> Right now Safari allows you to find the <p>, while this change would prevent it from being findable.

I'd be annoyed if I couldn't find it in this example. So I don't think that one needs to be able to interact in other ways with text for it to be included in search results.

In fact, I'd even want text drawn to a canvas to be findable. As a user, I don't care about the technology that brought letters to my screen, or any invisible parameters that this technology was invoked with.

[Alexey Proskuryakov]

> should full-text history search in Safari also be inhibited

Thinking about this for a moment more, this is kind of crazily inconsistent.

E.g. I might remember that I viewed something about Lamborghinis a few weeks ago, I go to history, find that page, open it, try to find where it was on the page, but now the browser just refuses to help me with this last step.

But it also makes no sense for history search to exclude it.

[Alexey Proskuryakov]

I guess there's no end to questions about what else should be disabled by inert, the moment it's not just event dispatch any more. E.g. should WebDriver getElementText omit the text too?

[Radar WebKit Bug Importer]

<rdar://problem/123823231>

[Karl Dubost]

The view-it/find-it might not be the best analogy for understanding the issue. 
<img alt="" src="something"> is a case of sighted users can view it, but the image is entirely meant for decoration purposes, so the alt is empty to hide it from accessibility tools. 


In the linked spec, it says:
> User agents may allow the user to override the restrictions 
> on find-in-page and text selection, however.



On the opposite spectrum, there are all these pages which do lazy loading of content (for performance reasons), that you can't find-in-page until you scrolled the full content which is very annoying for usability.

[Adam S]

Hello all, I don't mean to necro an old thread, but I do believe that the inert changes would be a net good overall. I don't see why giving developers an option is inherently a bad thing - the spec already says that it should hide things from find, so it would be in line with documentation.

[sideshowbarker]

Alexey, can you summarize what steps are needed to get resolution on this?
Is there anything further I could do on my end to help get resolution on it?

[Alexey Proskuryakov]

I think that the spec needs to be changed to forbid this behavior.

[Tim Nguyen (:ntim)]

WebKit has logic to detect obscured / clipped content to exclude it from find-in-page. In the fullscreen testcase that Emilio brought up, WebKit should just make that logic better to detect that the paragraph is obscured by the fullscreen content.

I'm not convinced that making inert content not findable is desirable here. I see more trouble than good from this, I could see sites using `inert` as an easy way to prevent folks from finding content.