Odd in-page search behavior with recent Chromium and Chrome

[treeowl]

I don't know if this is a Chromium bug or a Haddock bug or some weird interaction, but since I updated Chrome and Chromium recently, I've been having a problem. Specifically, if I hit Ctrl-F to find a word in some module documentation, and the word appears some ways down the page, it ends up opening up the Synopsis tab and searching there before continuing with the main page. UGH. Note: I don't have this problem in Firefox.

[eltix]

I confirm I've been getting the same visualization bug in latest Chrome. Here is a screenshot exhibiting the bug:

Clicking on the search match in the yellow right panel has no effect

[stevehartdata]

This is a result of a recent change to the HTML spec that specifies that closed details elements should be searchable. See the relevant section in the HTML spec, which was changed in this pull request. The change was implemented in Chrome 97 and Firefox has an open bug to implement it.

[treeowl]

Thanks, @stevehartdata. That confirms the bug is in Haddock and not Chromium. Do you happen to know what we have to do to fix it? The search feature is currently nearly unusable.

[stevehartdata]

I think it depends on what the desired functionality is. It's not obvious to me that the new functionality is always undesirable, though I can see why it would be annoying for certain use cases.

If the goal is just to revert back to the old behavior so that the synopsis is not searchable when hidden, then we can toggle a CSS property like visibility or content-visibility to hidden whenever the synopsis is collapsed. (I would need to do some more research to see which property is most appropriate.) But I'm not sure that this is the right approach, since we'd be working around the default semantics for the details element. Perhaps we would want to also change the element type to something other than details.

I'm not a regular contributor to Haddock, so I don't know who would make the call on what the desired behavior is. Are you the one?

[treeowl]

No, I'm certainly not. Have you tried navigating Hackage with the new behavior? I can confidently say it's not what anyone is likely to want.

[treeowl]

Specifically: search will go into the sidebar, then clicking on the found thing won't actually take you there. It's just wretched.

[stevehartdata]

The links in the synopsis not taking you to the expected location is a different bug that is not related to the recent HTML change. I definitely agree that that behavior is not how it should be, and I've opened #1457 to track that issue separately.

[treeowl]

I personally really don't want searching to open the sidebar either.

[MaxGabriel]

For pages with wide type signatures, this issue makes searching almost unusable. In Eltix's screenshot of text, it's sort like, "oh this side bar popped up, that's annoying and weird", but for eg persistent it's more like "my entire screen was taken over by this popping up and I can't search"

[parsonsmatt]

I can't really say how I feel about this without being hyperbolic and rude, so I'll just say "please let's fix it"

[Lysxia]

This does seem like an easy fix. I'll make a PR.

The new default behavior of <details> makes sense as a default, but this certainly seems like a case where we want to override it. There's no reason to search the synopsis element, since all of its contents can already be found elsewhere in the main part of the page. It doesn't seem possible to unconditionally hide an element from search, so disabling visibility when it's already hidden by <details> seems the next best option. And it seems visibility: hidden is the right setting; content-visibility: hidden is too new, not supported on Firefox, even though it seems preferable in principle because we do not care about preserving its layout.

[MaxGabriel]

@Lysxia Thank you so much!