Fenix: [Bug] on some URLs, tapping the URL to enter search screen does not highlight whole URL

[Cheap-Skate]

Will be handled in AC: mozilla-mobile/android-components#4328

Steps to reproduce

Navigate to www.theverge.com
Tap the URL to go to search
https://www.theverge.com/ is highlighted AND possibly spurious "2019/" appears at the end of the URL but is not highlighted

It causes confusion if I start to type, the 2019/ part hangs around

If I task swap to another app and come back to Fenix the 2019/ part has disappeared but the URL is not highlighted

The 2019/ part does not appear when I use Fennec on the same site

I have seen the same on www.bikeradar.com but not always, perhaps it depends on how the site is behaving?

Expected behavior

The extra URL part "2019/" should not appear in the search text box.

Device information

• Android device: Galaxy S7
• Fenix version: Today's

[darkwing]

I cannot reproduce with the provided STR. I further visited a link on the page which contained the year 2020 in the URL, but the entire URL was highlighted.

Could you provide more detail @Cheap-Skate ?

[Cheap-Skate]

@darkwing do the STR in #7934 work for you? I think it's the same bug. There is also #8236.

7934 still shows the incorrect behavior for me on today's Fenix Nightly.

[codrut-topliceanu]

This bug seems to be related to the keyboard you are using and its interaction with the URL suggestions. I have been unable to reproduce this exact issue, but I have reproduced the behaviour specified in #7934 and #8236 using SwiftKey custom keyboard. However, when using Pixel's build-in GBoard everything worked as it should.

Swiftkey:

GBoard:

@Cheap-Skate & @darkwing are you using your phone's build-in keyboard or a custom one?

I am investigating why this behaviour is different between the keyboards.

[Cheap-Skate]

You are correct, interesting!

I think there are two issues (see #7934)
(a) when tapping some URLs (eg www.bbc.co.uk) to edit them, extra text is appended to the URL (eg "/news")
(b) after step (a), when I start typing the URL is not correctly erased, the typed text is appended to the URL.

On Swiftkey I see issues (a) and (b)

On Gboard and Samsung keyboard I only see issue (a)

I use Galaxy A40 so Samsung keyboard is build-in but I normally use Swiftkey.

Thanks

[codrut-topliceanu]

@Cheap-Skate

I have managed to fix the issue with Swiftkey (issue b). Swiftkey's own autocomplete would unselect the text, so you would be adding text to the URL instead of replacing it. I have not created a PR for it as I believe this fix would also be used by the task swap issue you mentioned.

As for issue "a" I haven't been able to reproduce it on a Samsung Galaxy S7 (Android 8.0) or Pixel 2 & 4 (Android 10) with GBoard.
Just so that I understand exactly what the problem is I would like to go over the expected behaviour, if that's ok.

Expected behaviour when touching the URL bar and moving to the SearchFragment is to display the current URL+Suggestion (autocomplete), if available, to the user. (e.g. you are on "https://www.theindependent.co.uk/" but have visited the "world" section recently, then the search bar would display "https://www.theindependent.co.uk/world/" with "world/" coloured differently than the rest of the URL.)

At this point if you:

• press backspace-> the suggestion should be deleted and the URL should be unselected so you can edit it.

• type in a character-> the whole URL + suggestion should be replaced by the character you have entered. If you enter an additional character you should start getting suggestions already.

• touch the URL-> the suggestion should disappear and only your current URL should remain in the search bar with the cursor located at the point you selected.

• touch the suggestion-> the suggestion should not disappear and stay attached to the URL allowing you to edit it.

• long press URL or suggestion-> URL+suggestion is selected & opens up "copy-paste-share" pop-up menu.

Please let me know if issue "a" is indeed abnormal behaviour.

If I task swap to another app and come back to Fenix the 2019/ part has disappeared but the URL is not highlighted

This is indeed another issue, but I'm still investigating it.

Thank you for your help in this matter.

[Cheap-Skate]

OK I didn't realise that adding a suggestion to the URL was normal behavior. I find it confusing, but I think for issue "a" Fenix is behaving correctly.

So I think there are only two issues:- the interaction with Swiftkey issue (b); and task swapping to another app and coming back to Fenix losing the +suggestion, call it issue (c) if you like.

I might raise a feature request for issue (a) because I find it confusing, but it is a feature not a bug!

Thanks

[codrut-topliceanu]

@csadilek
I could use some help with this issue. (issue "b" mentioned in the previous comments).

The problem stems from the fact that Swiftkey has its own autocomplete which would change our selection of the text from InlineAutocompleteEditText.kt. The only way I found to fix this without altering the behaviour of Swiftkey in other scenarios is to add:

public override fun onAttachedToWindow(){
...
  if(isSwiftKeyKeyboard)
              inputType = InputType.TYPE_TEXT_FLAG_NO_SUGGESTIONS
}

Of course, this removes the suggestions offered by Swiftkey which makes me think it's not that good of a fix.

I've tried intercepting the selection change from Swiftkey, saving the state, and restoring it after Swiftkey is done, but I couldn't get it to work and it would affect other scenarios anyway.

In regard to issue "c", namely selection+suggestion loss on sending the app to the background and bringing it back: I'm still looking into it, but the autocomplete suggestion is removed when the view loses focus (onFocusChanged), and the text selection seems to disappear when restoring the search fragment's viewState.

Any suggestions would be greatly appreciated.

[codrut-topliceanu]

I moved issue "c" mentioned previously (regarding app switching from search fragment) into its own separate issue in fenix #8568 .

[codrut-topliceanu]

I have come up with several fixes for this issue, but they either only work on Swiftkey, and not on the Samsung keyboards or they work on Samsung Keyboards and not on Swiftkey.
Switfkey changes the text's selection (unselecting the text) when composing. Samsung reselects text when composing (at least on some devices).

Cause:
All of these have to do with those keyboards' build-in autocomplete. We are competing in editing the composing text, url+autocomplete, with the keyboards' autocomplete.

Details:
When the user presses a key (be it a text input or a delete key) InlineAutocompleteEditText tries to take the entire text, edit its span flags in order to add the coloured autocomplete text at the end, then re-display the whole thing, but does this at the same time as the autocomplete system of any of the user's keyboards and not really checking to see if there are any ongoing edits of the composing text (I haven't found a way to check for this either. Though it does announce its intention to edit the text with beginBatchEdit, endBatchEdit) and not updating any changes to the selection. I have tried to implement these things without success.

Related issues that I believe are caused by InlineAutocompleteEditText:
https://github.com/mozilla-mobile/fenix/issues/8502
https://github.com/mozilla-mobile/fenix/issues/6077
https://github.com/mozilla-mobile/fenix/issues/8468
https://github.com/mozilla-mobile/fenix/issues/7934
possibly https://github.com/mozilla-mobile/fenix/issues/8495
https://github.com/mozilla-mobile/fenix/issues/5680
https://github.com/mozilla-mobile/fenix/issues/3475
very old https://github.com/mozilla-mobile/fenix/issues/526

Possible solutions:

• use InputType.TYPE_TEXT_FLAG_NO_SUGGESTIONS(Works, but I'm not sure users would appreciate us disabling their favorite keyboard's autocomplete)
• keep current workflow and implement a way of extending InputConnectionWrapper to check and wait for editBatches to be over (tried, but without any threading)
• move all the logic for autocomplete to the InlineAutocompleteEditText's TextWatcher (tried. doesn't work by itself)
• move the whole autocomplete "attached" text from InlineAutocompleteEditText's view to a separate child view so that the URL will be one EditText view and the suggestion would be a simple TextView attached to it. We could edit that TextView without any issues or concerns of competing edits from keyboards. (my recommendation)

@vesta0 @liuche @csadilek
I could really use some input on how to proceed.

[sblatz]

Throwing this into group triage so we can decide how to proceed.

[boek]

@sblatz @vesta0 and I agree since this is search related we should try to find a good solution

[dholbert]

I hit this today as well, FWIW, and I'm using the pixel's built-in GBoard as my keyboard (not switfkey or any other custom keyboard).

My STR:
(1) Have both https://www.reddit.com/r/firefox/ and https://www.reddit.com/r/firefox/comments/ in your autocomplete history (i.e. have visited both of those URLs before)
(2) Visit the first (shorter) URL.
(3) Tap the URL bar.
(4) (optional) Press "enter" on the keyboard.

EXPECTED RESULTS: After step 3, the (now-editable) URL/search textfield should initially show me the URL that I currently have open, which is https://www.reddit.com/r/firefox/ . Hitting enter in step 4 should simply load that URL again.
ACTUAL RESULTS: After step 3, the URL/search texfield is immediately autocompleted beyond the URL that I'm currently on, and it shows up as https://www.reddit.com/r/firefox/comments/ (with comments/ highlighted), even though that's not the page that I'm viewing. So after step 4, I end up viewing that other URL.

Screencast of me performing the STR (in landscape mode to ensure that the whole URL is visible in the URL bar): https://www.dropbox.com/s/45ebg99a1umg8aj/fenix-autocomplete4.mp4?dl=0

[codrut-topliceanu]

@dholbert Thanks for looking at this issue.
However the actual results you specified are expected behaviour AFAIK. As the comments/ highlighted part of the url is actually the fenix autocomplete suggestion. Just like if you were to write "goo" it would autocomplete to "google.com".

[dholbert]

However the actual results you specified are expected behaviour AFAIK

No, they aren't the expected behavior.

I do understand that comments/ is added as an autocomplete, but the point of this bug (I think) is that we should not directly autocomplete-extend the contents of the URLbar until the user types something. If the user simply taps the URLbar, they rightly expect us to show them an editable field which contains the current full URL (without any unexpected changes/additions to it). On the other hand, if they do actually type "goo" or whatever, then sure, autocompleting makes sense.

[codrut-topliceanu]

Tagged with needs:UX because I'm unsure how to proceed.

[willfs84]

Is it possible this can be increased in priority please? A lot of people use Swiftkey, especially Firefox users

[liuche]

@AmyYLee could you give some feedback as to what should be default-highlighted in the urlbar?
a) The whole url (including autocomplete suggestions)
b) just the url excluding autocomplete suggestions
c) whole url but do not show autocomplete until the user types something

or something else.

[AmyYLee]

@AmyYLee could you give some feedback as to what should be default-highlighted in the urlbar?
a) The whole url (including autocomplete suggestions)
b) just the url excluding autocomplete suggestions
c) whole url but do not show autocomplete until the user types something

or something else.

Hi @brampitoyo ,

Can you assist with this since you've been working on search bar. Thanks!

[ekager]

I believe these are all the same bug: filed in AC here https://github.com/mozilla-mobile/android-components/issues/4328

[brampitoyo]

@liuche @ekager @jonalmeida We should highlight the whole URL. Autocomplete shouldn’t show up until the user has typed something.

For instance, if the hotels.com main page is currently open, then the URL bar should show:

From here, I can take two paths that will trigger autocomplete.

1. Start typing immediately

The address bar is cleared. Fenix behaves as if autocomplete starts from scratch with just the character that users have typed.

If users type the letter h, this is what they will see:

2. Select a part of the URL, then start typing

The address bar isn’t cleared. Autocomplete starts only from the part of the URL that was selected.

If users select the end of the URL, then type the letter s, this is what they will see:

[codrut-topliceanu]

@brampitoyo Thank you for the detailed explanation. I know how to proceed now.
Apologies to @dholbert , I was mistaken.
I will start working on a fix for this.

[codrut-topliceanu]

Should be fixed by https://github.com/mozilla-mobile/android-components/issues/6751

[brampitoyo]

Thanks heaps, @codrut-topliceanu!

[sflorean]

I was able to reproduce the issue on Samsung Galaxy Note10 (Android 10) and I can confirm the fix, with the same device on the latest Nightly build from 04/27.
@Cheap-Skate can you please confirm that this issue is fixed also for you? Thanks

[Cheap-Skate]

Yes seems fixed in the last couple of days. Thanks a lot.