We recently landed a patch in bug 590779 to not put the URL textbox into edit-mode when initially tapped. On devices with hard keyboard, we should try to go into edit-mode when a key is pressed, instead of requiring a second tap.
Created attachment 469758 [details] [diff] [review] patch I don't think this messes up any logic in BrowserUI._editURI, but I haven't tested many situations. The basic tests I did seem to work well.
Assignee: nobody → mark.finkle
Attachment #469758 - Flags: review?(21)
Works on N900 hard keyboard as well as desktop
tracking-fennec: --- → 2.0b1+
Comment on attachment 469758 [details] [diff] [review] patch I will replace + const nsIDOMKeyEvent = Components.interfaces.nsIDOMKeyEvent; + if (event.keyCode == nsIDOMKeyEvent.DOM_VK_RETURN) by + if (event.keyCode == aEvent.DOM_VK_RETURN) while checkin
Attachment #469758 - Flags: review?(21) → review+
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
So, I'm a bit confused. Is the intended behavior to not allow users to type in the url bar until they tap on it again in the awesomebar?
verified FIXED on builds: Mozilla/5.0 (X11; U; Linux armv71; Nokia N900; en-US; rv:2.0b5pre) Gecko/20100830 Namoroka/4.0b5pre Fennec/2.0a1pre and Mozilla/5.0 (Android; Linux armv71; Nokia N900; en-US; rv:2.0b5pre) Gecko/20100830 Namoroka/4.0b5pre Fennec/2.0a1pre
Status: RESOLVED → VERIFIED
litmus testcases updated to regression test this bug: https://litmus.mozilla.org/show_test.cgi?id=12323 https://litmus.mozilla.org/show_test.cgi?id=12317 https://litmus.mozilla.org/show_test.cgi?id=12330 https://litmus.mozilla.org/show_test.cgi?id=12313 https://litmus.mozilla.org/show_test.cgi?id=12335
Flags: in-litmus? → in-litmus+
You need to log in before you can comment on or make changes to this bug.