699465 - Tapping on the urlbar does not bring up keyboard; 2nd tap displays context menu

Status: VERIFIED FIXED

(Firefox for Android Graveyard :: General, defect, P2)

Description

[Matt Brubeck (:mbrubeck)]

Steps to reproduce:
1. Tap on the titlebar to focus the URL field.
2. Tap on the URL field again.

Expected results: After step 1, the URL field is selected and the on-screen keyboard appears. After step 2, the caret is positioned in the URL field.

Actual results: After step 1, the URL field is selected but the on-screen keyboard does not appear.  After step 2, the keyboard appears, the caret is not positioned, the text is still selected and the selection handles appear, and the textbox context menu also appears.

This bug is reproducible on my HTC T-Mobile G2 (stock Android 2.3.4), in both portrait and landscape, with both Swype and Android Keyboard.  It's not a new regression; I think it's happened since very early in Fennec Native development.

Comment 1

[Alex Pakhotin (:alexp)]

Matt, can you reproduce this with the nightly, and/or on another device?

Comment 2

[Matt Brubeck (:mbrubeck)]

I can reproduce this in birch nightlies, as well as in my local builds.  I'll test on some other devices tomorrow.

Comment 3

[Alex Pakhotin (:alexp)]

Both Nightly and my local build work fine for me on Nexus One, Android 2.3.6, with stock keyboard, Smart Keyboard Pro, Swiftkey X, Swype; and HTC Sensation, Android 2.3.4, with HTC Touch Input.

Comment 4

[Aaron Train [:aaronmt]]

Is this the exact same issue with the droid pro in bug 697773?

Comment 5

[Matt Brubeck (:mbrubeck)]

(In reply to Aaron Train [:aaronmt] from comment #4)
> Is this the exact same issue with the droid pro in bug 697773?

I'm seeing bug 697773 (can't type in urlbar with hardware keyboard) on this device too.  It seems likely that this issue (quirky behavior in urlbar with software keyboard) is related, but I don't know for sure.

Comment 6

[Alex Pakhotin (:alexp)]

I still cannot reproduce this bug on another device. Last attempt was with Motorola Droid 3, a slider phone with Android 2.3.4. Both the Multi-touch keyboard and Swype work as they should - the on-screen keyboard appears on the first tap on the title bar.
This works in a portrait mode only. In landscape we don't show the keyboard by design (bug 698419).

Comment 7

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

This occurs with me on swiftkey trial on the Nexus S which is 2.3.6 with the tinderbox build.  I can't repro this on the Galaxy S II

Comment 8

[Martijn Wargers (dead)]

I can reproduce this on the Motorola Droid 1, I filed bug 719857 for it, but I guess it can be duped against this bug, right?

Comment 9

[Martijn Wargers (dead)]

Sorry, ignore comment 8.

Comment 10

[Chris Peterson [:cpeterson]]

I think this bug should be a fennec-1.0 blocker because it can prevent the user from entering URLs.

Comment 12

[Benoit Girard (:BenWa)]

In bug 730869 I do see the keyboard appear in step 1 but do not get the caret in step 2. This is on Nexus S.

Comment 13

[Kevin Brosnan [Ex-Mozilla]]

Then the first part is a bug. The expected behavior is that tapping the awesome bar will bring up the awesome screen with no keyboard. tapping in the awesome screen will bring up the keyboard.

Comment 14

[Aaron Train [:aaronmt]]

Received a Sony Experia Play phone this morning, and ran into this too. Not limited to a single phone.

Comment 16

[Chris Peterson [:cpeterson]]

Like bug 730869, I see the keyboard appear in step 1 but get the "Edit Text" menu in step 2 on the Kindle Fire.

Comment 17

[Chris Peterson [:cpeterson]]

Attachment: bug-699465-part-1-select-on-focus.patch

Enable selectAllOnFocus for AwesomeBar to preempt Edit Text context menu. On some Gingerbread devices, focusing the AwesomeBar will pop up an "Edit Text" context menu. Setting the selectAllOnFocus=true layout attribute avoids the "Edit Text" menu by re-selecting the AwesomeBar's already selected URL text.

This patch ONLY addresses the context menu pop-up, NOT the keyboard problem (which, depending on UX feedback, may not be a bug).

This patch fixes the problem on my Kindle Fire. mbrubeck, who reported this bug, confirmed this patch fixes the problem on his HTC G2.

Comment 18

[Chris Peterson [:cpeterson]]

Attachment: bug-699465-select-on-focus.patch

Minor update to patch's commit message.

Comment 19

[Doug Turner (:dougt)]

Comment on attachment 602539 [details] [diff] [review]
bug-699465-select-on-focus.patch

Review of attachment 602539 [details] [diff] [review]:
-----------------------------------------------------------------

lgtm

Comment 20

[Sriram Ramasubramanian [:sriram]]

Comment on attachment 602539 [details] [diff] [review]
bug-699465-select-on-focus.patch

Review of attachment 602539 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good to me too.

Comment 21

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/9f12a459fc45

Comment 22

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/9f12a459fc45

Comment 23

[Martijn Wargers (dead)]

This didn't fix bug 719857 in any case, I can still reproduce that issue in today's trunk buil.

Comment 24

[Cristian Nicolae (:xti)]

(In reply to Martijn Wargers [:mw22] (QA - IRC nick: mw22) from comment #23)
> This didn't fix bug 719857 in any case, I can still reproduce that issue in
> today's trunk buil.

Please reopen bug 719857 if you will be able to reproduce it again. I will close this one as verified fixed since it's not reproducing anymore on the latest Nightly build (03/28).

--
Firefox 14.0a1 (2012-03-28)
Devices: Samsung Galaxy S (2.2), Samsung Nexus S (2.3.6)