Search.js in doxygen documentation module not working on mobile

[smistad]

Tested this on Android with both chrome and firefox.
The autocomplete inserts text while typing, making it impossible to search.

It seems to me that the code that marks the autocompleted text to be replaced when the next key is typed, is not working.

I can contribute to a fix, if anyone can point to where in the code the issue might be.

[crisluengo]

Search works fine on iOS with both Safari and Firefox. This is likely an Android bug.

[crisluengo]

I just tried this on a Samsung phone (Android, Chrome) and it works just fine as well.

Autocomplete inserts text, but it is selected, meaning that as you type the selection (inserted text) gets replaced. It works the same way on all platforms and browsers I've tried so far, and is very convenient. Disabling this behavior would be a reduction in usability.

[smistad]

Hm, strange, on my phone the added text is selected, but when I continue to type, the text is inserted before the added text instead of replacing it. I agree that finding a fix is better than removing the functionality.

[mosra]

(Sorry for embarrassingly late replies, finally got a chance to get back to this project.)

Hmm, seems like I can reproduce this, although maybe a bit differently(?):

• go to https://doc.magnum.graphics/
• type magnu, m will be autocompleted and highlighted in blue
• press backspace (or the equivalent on a phone keyboard) -- on desktop browsers it'll erase the m but on mobile the m will stay there, unhighlighted, with cursor before (and thus new text inserted before)
• if you don't press backspace but continue typing, it'll work as expected (adding m will replace the autocompletion, adding s instead will show no results)

So I suppose there's something weird in how I implement the autocompletion highlight, causing mobile browsers to not highlight in certain circumstances, which then results in the autocompleted text not being overwritten when typing?

[smistad]

I tried doing the same as you @mosra
On my mobile, if I try to type m after m was autocompleted, I get two m's, so magnumm.
If I try backspace I get the same issue as you.

So yeah, definitively something weird going on here, which is why I disabled this on mobile for my own documentation page

[mosra]

Eh, stupid Chrome, of course it's the WONTIFX bug that's linked from the comment in the code (https://bugs.chromium.org/p/chromium/issues/detail?id=118639) or maybe some variant of it:

m.css/documentation/search.js

Lines 734 to 752 in fb5fd85

	/* Looks like the user is inserting some text (and not cutting,
	copying or whatever), allow autocompletion for the new
	character. The oninput event resets this back to false, so this
	basically whitelists only keyboard input, including Shift-key
	and special chars using right Alt (or equivalent on Mac), but
	excluding Ctrl-key, which is usually not for text input. In the
	worst case the autocompletion won't be allowed ever, which is
	much more acceptable behavior than having no ability to disable
	it and annoying the users. See also this WONTFIX Android bug:
	https://bugs.chromium.org/p/chromium/issues/detail?id=118639 */
	} else if(event.key != 'Backspace' && event.key != 'Delete' && !event.metaKey && (!event.ctrlKey || event.altKey)) {
	Search.autocompleteNextInputEvent = true;
	/* Otherwise reset the flag, because when the user would press e.g.
	the 'a' key and then e.g. ArrowRight (which doesn't trigger
	oninput), a Backspace after would still result in
	autocompleteNextInputEvent, because nothing reset it back. */
	} else {
	Search.autocompleteNextInputEvent = false;
	}

All event.keys from the virtual keyboard reporting as Unidentified, meaning I can't check if backspace was pressed or not. What's extremely funny is that if I use remote Chrome Developer Tools, the keys entered from a physical keyboard have the correct event.key (the last entry in the console log):

Trying to find another solution for this.

[mosra]

On my mobile, if I try to type m after m was autocompleted, I get two m's, so magnumm.

Huh, but that's different from what I see here. I get magnum (the blue m becomes white), not magnumm...

[smistad]

I get double m's on both firefox and chrome on my mobile

[mosra]

I suspect it's maybe also related to the virtual keyboard you use. Which one do you have? I'm on the vanilla gboard I think.

[smistad]

I use gboard as well..

[mosra]

This patch should disable autocompletion completely on the buggy Android virtual keyboard, do you have an easy way to try it out?

diff --git a/documentation/search.js b/documentation/search.js
index 5346fa63..ce7a7dea 100644
--- a/documentation/search.js
+++ b/documentation/search.js
@@ -739,15 +748,25 @@ if(typeof document !== 'undefined') {
                excluding Ctrl-key, which is usually not for text input. In the
                worst case the autocompletion won't be allowed ever, which is
                much more acceptable behavior than having no ability to disable
-               it and annoying the users. See also this WONTFIX Android bug:
-               https://bugs.chromium.org/p/chromium/issues/detail?id=118639 */
-            } else if(event.key != 'Backspace' && event.key != 'Delete' && !event.metaKey && (!event.ctrlKey || event.altKey)) {
+               it and annoying the users. */
+            } else if(event.key != 'Backspace' && event.key != 'Delete' && !event.metaKey && (!event.ctrlKey || event.altKey)
+                /* Don't ever attempt autocompletion with Android virtual
+                   keyboards, as those report all `event.key`s as
+                   `Unidentified` with `event.code` 229 and thus we have no way
+                   to tell if a text is entered or deleted. See this WONTFIX
+                   bug for details:
+                    https://bugs.chromium.org/p/chromium/issues/detail?id=118639
+                   Another option would be to use inputEvent there and catch
+                   deletion. */
+                && event.key != 'Unidentified'
+            ) {
                 Search.autocompleteNextInputEvent = true;
             /* Otherwise reset the flag, because when the user would press e.g.
                the 'a' key and then e.g. ArrowRight (which doesn't trigger

Meanwhile I'm trying to find a better solution that doesn't just kill the feature altogether.

[mosra]

Okay, I think I have it -- for Chrome at least, if I delay-call setSelectionRange() in a timeout instead of directly, it gets rid of the nasty bugs where the selection was rendered but didn't actually work.

I temporarily uploaded the patched script to https://doc.magnum.graphics/ to make it easier to test -- can you try there with magnu again? It should behave properly now, although you may need to open it in a private tab or something to bypass the cache. EDIT: stable link: https://tmp.magnum.graphics/search-android-fix/ -- type an, should autocomplete to another and work as desired.

Thanks in advance for a confirmation! :)

[smistad]

I tried your tmp url. Now I don't get the duplication issue on chrome, but backspace is still broken. On firefox both errors are still there

[mosra]

Ah well :/ So I guess I'll have to disable this altogether.

This URL has the above patch, disabling autocompletion completely when (buggy) Chrome is detected: https://tmp.magnum.graphics/search-android-nocompletion/ -- typing an should not autocomplete at all. Does that work for you and does that disable autocompletion on Firefox as well?

I finally managed to reproduce both of your issues in Firefox. Will report if I get anywhere, thanks for the help so far 👍