Great ! Thanks a lot :)
Went trying it on my Kobo before looking at the code :)

A few usability remarks, dunno how feasible or nice this can be:

• it would be nice if, once a search is made, long-press on the Find button would do "Find next" (instead of having to hit it again, see the inputdialog and hit Find next there). (Unless I missed some shortcut for find next ?)
• when finding stuff, and manually scrolling down, "Find next" can scroll you up to the occurence after the first one found: it would be nice if it started from the current scroll position (so, when you know your stuff is near the bottom, you can manually scroll to near the bottom, and launch Find from there.
• also, Find next often scroll to get the occurence into the view, but on the last line of the view ("Found, screen line 28"). May be it could be better if it was scrolled to have the occurence in the middle of screen, so you can see more of its context. I'm not really sure if this would be better when you have multiple occurence on a single screen, to have it scrolled continously a little, and possibly get lost. May be it should depend on the amount of scrolling ?

• long-press on the Find button would do "Find next"

You've asked to hide the "Show css" buttons on long-press.

You've asked to hide the "Show css" buttons on long-press.

Yes, I know :) But I'm willing to sacrifice it on the Find button (only) to get faster find next.
We could still hide with long-press on Close or Switch to debug view - or even also Find as long as one hasn't started using it.
(I feel it might be complicated to implement, just mentionning it.)

textviewer: "Find next" on long-press on Find works fine for me, thanks :)

Try to show the found string in the middle of the screen, do not scroll if the distance is 5 or less lines.

Try to show the found string in the middle of the screen, do not scroll if the distance is 5 or less lines.

Nice idea, works perfectly for me.

Any thought about my 3rd remark ?:

when finding stuff, and manually scrolling down, "Find next" can scroll you up to the occurence after the first one found: it would be nice if it started from the current scroll position (so, when you know your stuff is near the bottom, you can manually scroll to near the bottom, and launch Find from there.

Also, about the long-press on Find for finding next, it became a bit frustrating, having to long-press, and often missing pressing long enough and getting the dialog :/ Dunno if it would be better to swap them: once a search is launched, tap on Find would find next, and one would have to long press on it to get the dialog (and may be cancel the behaviour once we have reached "Not found", after having it shown once). Dunno how confusing this might be, even if practical.

So, given there is no cursor and current self.charpos, there are three options to find forward:
(1) start from the beginning (current "Find first", charpos = 1)
(2) start from the previously found entry (current "Find next", charpos is a search result or 1)
(3) start from the visible top line first char (maybe "Find forward", charpos to be calculated)

It is hard to distinguish a user's intention to get (2) or (3) automatically.
If I have scrolled 1-2-3 lines, where to start a new search?
I think there should be 3 separate buttons for (1), (2), (3) (or an additional checkbox) in the search dialog.

It is hard to distinguish a user's intention to get (2) or (3) automatically.
If I have scrolled 1-2-3 lines, where to start a new search?

If you have not scrolled, it should be (2).
If you have scrolled, assume the user wants to find next from the current view. If he doesn't want that, the user can scroll back to arond the previous position.
If you have scrolled 1 to 3 lines, that's small enough that it shouldn't really matter if (2) or (3).

I'd say:

• if current search result is still in the view (or in the 5 "middle" lines of screen) : find next from it
• otherwise, start from top of view (if the user has scrolled up, it may find the previous search result, and I guess that is fine)

Update
(1) Find button: after successful search short-press calls "Find next", long-press calls Find dialog.
After "Not found" the button is restored to the initial state.
(2) Scroll after successful search: if scrolled farther than <find_centered_lines_count> (currently 5) lines, "Find next" will start from the visible top line first char. Otherwise "Find next" starts from the previous serach result.

Switch the "Find" button label when in the "Find next" state (and back).

Oups, just got this after testing on the emulator (searching for "font-" in the hacked stylesheet of a Wikipedia EPUB, on my 3rd hit on Find next - and on the first Find next hit in a regular Wikipedia epub stylesheet, which should get no result):

./luajit: frontend/ui/widget/textboxwidget.lua:519: attempt to index local 'line' (a nil value)
stack traceback:
 frontend/ui/widget/textboxwidget.lua:519: in function '_shapeLine'
 frontend/ui/widget/textboxwidget.lua:820: in function '_renderText'
 frontend/ui/widget/textboxwidget.lua:880: in function '_updateLayout'
 frontend/ui/widget/textboxwidget.lua:1731: in function 'moveCursorToCharPosKeepingViewCentered'
 frontend/ui/widget/scrolltextwidget.lua:201: in function 'moveCursorToCharPos'
 frontend/ui/widget/textviewer.lua:345: in function 'findCallback'
 frontend/ui/widget/textviewer.lua:141: in function 'callback'

Cannot reproduce on Kindle (saved wiki article as epub and searched in the stylesheet.css).
Can it be the absence of math.floor in line 1719 in TextBoxWidget?

Yes, adding the math.floor solves the issue for me ! :)

-    local new_virtual_line_num = self.virtual_line_num + screen_line_num - self.lines_per_page / 2
+    local new_virtual_line_num = self.virtual_line_num + screen_line_num - math.floor(self.lines_per_page / 2)

I guess one needs to have an odd number of lines (23 on my emulator) to get the crash.

I've been a bit bothered by the position of the added Find button:

Most of the time, I don't need Find: I'm just looking, and want to Close - and the new Close button is a bit hard to reach on the left when holding one-handed, having to extend my finger there, while before it was easy with the fullwidth Close button.
But OK, we have a "rule" that most destructive/expensive stuff on the left, and safer stuff on the right - for right handed people.

But I just realized we have Close on the right in QuickDictLookup, and in the Wikipedia result

So, I wonder: should we put Close on the right (even if Find is not as expensive as Wikipedia full) ?

I’d put it on the right due to habits (PC UI has it most of the times on top-right) and the natural for LTR reading sequence (so “close” is the last word to read and the last action one would do to a window if none other buttons are interesting)

Minor user experience issue:
When you have done a Find, and get the Find next button at the bottom of TextViewer, you can long-press on this Find next to get the input dialog to enter a new search term. But this long-press (long-press release actually) is propagated to the keyboard, and get the keyboard unwillingly switched to symbol/numbers layout.

This solves it (as we already have something to prevent that, InputDialog:onShowKeyboard(ignore_first_hold_release))

--- a/frontend/ui/widget/textviewer.lua
+++ b/frontend/ui/widget/textviewer.lua
@@ -372,7 +372,7 @@ function TextViewer:findDialog()
     input_dialog:addWidget(self.check_button_case)

     UIManager:show(input_dialog)
-    input_dialog:onShowKeyboard()
+    input_dialog:onShowKeyboard(true)
 end

 function TextViewer:findCallback(input_dialog)

Not thoroughly tested, and I'm also surprised we don't have to use it anywhere in upper level widgets (only used by the Terminal plugin), so I don't know if it's the right thing to do.

I'm also surprised we don't have to use it anywhere in upper level widgets (only used by the Terminal plugin)

We do use it when the button to be long-pressed is in the bootom of the screen (where the keyboard is).
Multi-page Menu widget, long-press on the "Page 1 of #" button.

Oh, right, this makes sense only when that long-press button/thing is at the position that the keyboard would cover.
So, feels like the right thing to do?

So, feels like the right thing to do?

I believe yes.

I noticed another issue related to long-press and the hold-release being handled by something else:

Select multiple words, Highlight Dialog, hit Dictionary.
Long-press on Close button or top right Close x (which should close multiple DictQuickLookup widgets, but will happily just close one) : the DictQuickLookup is closed by the Hold, but the HoldRelease (which would be explicitely consumed by the Button if it was still there) is propagated to the HighlightDialog, and processed by its MovableContainer, which will move this ButtonDialog to where you had pressed the Close button.......
MovableContainer has indeed remember a Touch event from before - and seeing a HoldRelease make it think its touch > hold-release which might really be a pan - when it's from the same finger session :)
It's a hard (impossible?) to notice from MovableContainer itself that it's a different finger session, and stuff has happened since the touch... So I could only come up with this:

--- a/frontend/apps/reader/modules/readerhighlight.lua
+++ b/frontend/apps/reader/modules/readerhighlight.lua
@@ -109,2 +109,5 @@ function ReaderHighlight:init()
                 callback = function()
+                    if self.highlight_dialog then -- see below
+                        self.highlight_dialog.movable:resetEventState()
+                    end
                     UIManager:scheduleIn(0.1, function()
@@ -122,2 +125,10 @@ function ReaderHighlight:init()
                 callback = function()
+                    if self.highlight_dialog then
+                        -- DictQuickLookup handles Hold on its close button
+                        -- to close itself (and all instances): Button won't
+                        -- be able to handlt the HoldRelease event, which may
+                        -- then reach this ButtonDialog's MovableContainer,
+                        -- and cause a move: be sure to reset its state
+                        self.highlight_dialog.movable:resetEventState()
+                    end
                     this:onHighlightDictLookup()
--- a/frontend/ui/widget/container/movablecontainer.lua
+++ b/frontend/ui/widget/container/movablecontainer.lua
@@ -344,2 +344,9 @@ end

+function MovableContainer:resetEventState()
+    -- Cancel some internal moving-or-about-to-move state
+    -- Can be called explicitely to prevent bad widget interactions (see readerhighlight.lua)
+    self._touch_pre_pan_was_inside = false
+    self._moving = false
+end
+
 return MovableContainer

@hius07 : do you know/remember if we have other UI stuff that would behave as the DictQuickLookup close, that is: disappearing/closing itself on long-press, with possibly some MovableContainer underneath ?

Again these hidden long-pressings! (I didn't know about it)
It's hard to find more unexpected action than holding the Close button.
Maybe add Exit button instead of long-pressing?

It's "hidden" just because it's a shortcut.
Having multiple stacked DictQuickLookup is rare. You can always close them one by one with Tap on Close or x. I have done that for years, and still do. And sometimes I remember this long-press, and try it - and notice the above issue :) Note that it's just fine with a normal Dict lookup (not invoked from the highlight dialog).
It's just a shortcut, people can live without that "long-press on them close all the stacked DictQuickLookup".
Not worth adding another button just for that (no room, and not worth making room).

I vaguely remember making sure I didn't break that when you mentioned it back when I refactored GestureDetector (I... think it was that time?), and I don't recall any other widget doing that (I kinda have to agree with @hius07 there, it's... extremely sneaky ;p).

I checked with older versions:
v2022.07 : same behaviour as today, so, you didn't break it (at that time, it was only available on the title bar cross, you later made it work the same on the Close button in a62f076 - so the extreme sneakyness was good enough to be duplicated :)
v2021.09 : no issue, but that was because the closing happened on hold_release. I think I may have changed that to happen on hold, because having to wait for hold_release felt odd/inconsistent. Or may be not for that reason, but just because the move to TitleBar make it happen on hold: 48ca7e8. I still think it's better having it happen on hold than on hold_release.

A more generic way maybe:

--- a/frontend/ui/widget/buttontable.lua
+++ b/frontend/ui/widget/buttontable.lua
@@ -55,7 +55,12 @@ function ButtonTable:init()
                 icon_height = btn_entry.icon_height,
                 align = btn_entry.align,
                 enabled = btn_entry.enabled,
-                callback = btn_entry.callback,
+                callback = function()
+                    if self.show_parent and self.show_parent.movable then
+                        self.show_parent.movable:resetEventState()
+                    end
+                    btn_entry.callback()
+                end,
                 hold_callback = btn_entry.hold_callback,
                 allow_hold_when_disabled = btn_entry.allow_hold_when_disabled,
                 vsync = btn_entry.vsync,

you later made it work the same on the Close button in a62f076 - so the extreme sneakyness was good enough to be duplicated :)

Hahaha, I think that was me being puzzled because that's the first thing I tried it on after you described it (I rarely ever use the title's cross button ;)).

@NiLuJe : any preference among the 2 snippets above - or any alternative idea ?
First one just tweak the 2 current specific buttons that may get to something where a hold may close and the hold_release reach an upper MovableContainer and cause the issue.
Second one tweaks generically all buttons in a ButtonTable to make sure of that - but to the expense of an added anonymous function for each callback.
(The real proper fix would be more expensive and to broadcast for any touch event handled by anything, an other event that all MovableContainers in the stack would catch and reset their state - but not worth the expense :)

The second one sounds good (it's not like ButtonTable were performance-critical anyway ;p).