1136219 - Hide the URL bar carets upon entering the Awesomescreen

Status: RESOLVED DUPLICATE of bug 1166116

(Firefox for iOS :: Browser, defect)

Description

[Brian Nicholson (:bnicholson)]

When we do the initial URL text selection upon entering the AwesomeScreen, carets show up on either side of the selection, which is ugly. If we don't want to show them, one option would be to use NSAttributedString to create the same highlighting effect (which Stefan used in his patch for bug 1109656).

Comment 1

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

Attachment: PR: https://github.com/mozilla/firefox-ios/pull/354

This patch introduces a AutocompleteTextField.selectAll() method and calls that when you enter the Awesome Screen. This results in the initial text being selected as in Safari: with the text highlighted but without the carrots. You can immediately start typing over the text.

Comment 2

[Richard Newman [:rnewman]]

lolautocorrect

Comment 3

[Brian Nicholson (:bnicholson)]

Comment on attachment 8594874 [details] [review]
PR: https://github.com/mozilla/firefox-ios/pull/354

Looks pretty good, but I found that the autocomplete highlight can get "stuck" on the text. STR:

1) Click the URL bar.
2) Click Cancel without typing any text.
3) Click the URL bar again.
4) Type some text.

Comment 4

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

Brian, I've looked at this, but there is a lot of confusing state in the code. If you know a quick solution, feel free. Otherwise I am not going to spend time on this right now because we have higher priority items.

Comment 5

[Brian Nicholson (:bnicholson)]

Comment on attachment 8594874 [details] [review]
PR: https://github.com/mozilla/firefox-ios/pull/354

(In reply to Stefan Arentz [:st3fan] from comment #4)
> Brian, I've looked at this, but there is a lot of confusing state in the
> code. If you know a quick solution, feel free. Otherwise I am not going to
> spend time on this right now because we have higher priority items.

Hm, might be an iOS bug. I added logging to verify that the most recent attributedText being set does *not* have a background color, yet the background color still persists. We can explicitly set a clear background color to force it to be removed -- work for you? Works for me if so!

Comment 6

[Brian Nicholson (:bnicholson)]

I meant to mention that I added this change to the PR (https://github.com/mozilla/firefox-ios/commit/2143242b261e994e2c1249e3da55dfc51449afb7) if you want to take a look/test it out.

Comment 7

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

Oh interesting that you think this is an iOS bug. That would explain why I was so confused about the highlight staying there. The patch/workaround looks good to me.

Comment 8

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

I can still reproduce the behaviour you mentioned in comment #3 - Will take a peek again later.

Comment 9

[Brian Nicholson (:bnicholson)]

Fixed by bug 1166116.