[Flock][Feature] - Ctrl+F support, finding text on a page (even when scrolled off screen)

[rensPols]

Flutter Issue Ticket Link:
Insert a link to the existing Flutter issue ticket. You should only file a feature request with Flock if you've already tried to get the Flutter team to implement it, first.

Why didn't Flutter implement this?
They put it in the triage multiple times now, but this issue is open since sep 9, 2020 now and it is still not addressed.

Why does this belong in Flock?
CTRL+F is essential for the browser since users expect this feature to be present and work properly.

[matthew-carroll]

Why didn't Flutter implement this?

I've noticed a couple tickets that you've filed where this question wasn't really answered. This is a very critical question.

For example, the reason that CTRL + F doesn't work is tied to deep browser API issues where the browser depends upon standard DOM nodes to locate the content to search through. But Flutter renders with a canvas, so there aren't any such nodes to search through.

The best that could probably be done is to create a partial shadow DOM that repeats all the text from the Flutter widget tree. But that's very complicated, probably has numerous edge cases, and might kill performance.

The optimal answer for this problem is for browsers to expose an actual search API, which could then be leveraged by Flutter and app developers. But Flutter has no control over browser standards.

[jezell]

Is there a specific change being provided @rensPols?

You can definitely implement a Google docs style CTRL+F to search with the APIs available today. Just like Google docs though, this would need to be implemented by the app, as the content is not available via widgets and wouldn't make sense to be available to widgets for perf reasons. We've done this type of thing with window paste events. It is true that just relying on listeners can make it difficult to catch all events, but with the web package you can add top level handlers to the window, trap the event, and invoke whatever UI you need today without any changes to the engine or Flutter.

Are you looking for guidance on how to accomplish that trap of the key?

[matthew-carroll]

@jezell could we do an opt-in adjustment to Text widgets or even RenderParagraph that adds the content to a global index?

[jezell]

Semantics nodes probably already serve that opt in purpose to some degree since they integrate with things like Text widgets already, but they face a few problems:

• As long as you depend on Widgets to provide this information, it only works for on screen things because Flutter doesn't put the whole app into a DOM.
• It's useful in the browser because it also scrolls to offscreen content automatically. Flutter scroll to item isn't something that's supported out of the box. You can scroll to offsets, but offsets would again require everything offscreen to be computed ahead of time, which Flutter doesn't do intentionally.
• It's useful in the browser because the browser itself supports rendering the ranges of selected text for find matches, which is similar to the text actually being selected but not the same thing. Using SelectableRegion for example would actually select things, which is not what the browser does.

I think it's telling that apps like google docs which use a similar rendering architecture just reimplement the entire feature inside the app instead of relying on the browser search box. In google docs for example, you wouldn't want the ctrl+f to find text in menus, just content inside the document. Ultimately the only reasonable solution is probably for apps to implement this themselves, or to opt into a specialized framework that is designed for rendering documents and implements this itself.

While I'm not sure there is a clear path toward making a universal solution that works with all the material widgets or all the widgets on pub.dev, providing a set of specialized document widgets that implement this functionality is definitely something that could be reasonably done. Nothing in the framework or engine prevents someone from building such a package on top of something like attributed_text or TextSpans and having it hook into the web package to intercept ctrl+f / cmd+f by default, show a UI, and allow people to jump between the matches.

If there was a case for something in the box, maybe building a SearchableRegion that works in a similar fashion and then integrating it like SelectableRegions are integrated with the stock widgets like Selectables are could be a path. In the same way that Selectables don't magically support everything in the box, Searchables could provide a path to get there that is not too hard for people to use.