1021401 - [Rocketbar] Can't Edit Search Term in Rocket Bar

Status: VERIFIED FIXED

(Firefox OS Graveyard :: Gaia::Search, defect)

Description

[Aaron]

# Build Information

Device: Flame
Gaia      d2cfef555dabab415085e548ed44c48a99be5c32
Gecko     https://hg.mozilla.org/mozilla-central/rev/51b428be6213
BuildID   20140605040202
Version   32.0a1
ro.build.version.incremental=94
ro.build.date=Tue May 20 09:29:20 CST 2014

# Description
After typing a search term in the search bar, tapping back into it does not let me position a cursor in order to edit or add to the term(s).

Comment 1

[Johan Lorenzo [:jlorenzo]]

Need input from UX team to check if this is by design or a missing feature.

Comment 2

[Stephany Wilkes]

Pretty sure this is a bug but double checking with Rob or Francis. I ran into the same issue during the bug bash yesterday - very frustrating. :)

Comment 3

[Rob MacDonald [:robmac]]

The behaviour here should be the same as other input fields across the OS, which allow the user to tap to reposition the cursor.

Comment 4

[Jason Smith [:jsmith]]

The UX here is extremely confusing & it's a basic use case on the homescreen, so I think we have to get this fixed for 2.0.

Comment 5

[bhavana bajaj [:bajaj]]

NI : johan, can we get the old screenshot that we discussed offline with the old homescreen to be more clear on the ask here ?

Comment 6

[Stephany Wilkes]

FWIW, the ask should be pretty clear: the Rocketbar search should follow the established, OS-wide UX pattern for search, which includes being able to edit the search term.

Comment 7

[Johan Lorenzo [:jlorenzo]]

Attachment: Old e.me bar - Clear search button - screenshot

On the previous e.me bar, you were able to clear a research by hitting the X button on the right of the bar.

In today's rocketbar, there is a close button. This button does not clear the search when you go back into it, though.

Comment 8

[Jason Smith [:jsmith]]

bajaj & jlorenzo - this isn't what this bug talks about. This bug talks about editing an existing search term, not deleting a search term by clicking a X button.

Comment 9

[Etienne Segonzac (:etienne)]

It's driving me crazy, I removed all the css all the JS and the field still doesn't work properly.
And it's not a in-process issue since you can move the caret properly in a prompt() field.

Note that when the keyboard is hidden and you tap on the field it will move the carret to where your tap, but only this one time until you hide the keyboard again.

Hopefully Vivien will have an idea :)

Comment 10

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

Attachment: allow.mousedown.on.the.rocketbar.patch

Here a patch.

Comment 11

[Etienne Segonzac (:etienne)]

Comment on attachment 8438307 [details] [diff] [review]
allow.mousedown.on.the.rocketbar.patch

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

r=me with `!==` and a small test, this area is already covered so it should be pretty easy.
In utility_tray_test.js in the mousedown event on status bar section, asserting that event dispatched on rocketbar-input aren't stopped even when the keyboard is up.

::: apps/system/js/utility_tray.js
@@ +243,5 @@
>      }
>    },
>  
>    _pdIMESwitcherShow: function ut_pdIMESwitcherShow(evt) {
> +    if (evt.target.id !=== 'rocketbar-input') {

isn't `!===` a syntax error? :)

Comment 12

[Kevin Grandon :kgrandon]

Hey - any chance you guys would be able to land this today? If not, let me know. Maybe I can write a test this weekend. Thanks!

Comment 13

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

(In reply to Kevin Grandon :kgrandon from comment #12)
> Hey - any chance you guys would be able to land this today? If not, let me
> know. Maybe I can write a test this weekend. Thanks!

Will try to :)

Comment 14

[Kevin Grandon :kgrandon]

Hey Guys - I hope you don't mind, but I went ahead and landed the updated patch along with a follow-up for the test.

Let me know if you have any concerns/comments. I would've liked to wrap a dispatchEvent() for the test, but that would've been a much bigger change for dom setup and such. If you don't think this test is sufficient let me know - I would probably like to write an integration test for it as well.

Comment 15

[Kevin Grandon :kgrandon]

Attachment: Github pull request

Pull request with patch + test, carring R.

Comment 16

[Johan Lorenzo [:jlorenzo]]

Verified on master.

Comment 17

[Kevin Grandon :kgrandon]

Attachment was updated as the rev link, the patch is here: https://github.com/mozilla-b2g/gaia/commit/53544093b17dbc3b2dbe69a5c979c3d58a1c5032

Comment 18

[Ryan VanderMeulen [:RyanVM]]

v2.0: https://github.com/mozilla-b2g/gaia/commit/a111c619867d5b1b5a4fe07a25a589a4a2c70f97

Comment 19

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

Gaia      23e06c3624309db22ad9cb736d89700768b42b36
Gecko     https://hg.mozilla.org/releases/mozilla-aurora/rev/164b61458ca5
BuildID   20140619000200
Version   32.0a2
ro.build.version.incremental=108
ro.build.date=Tue Jun 10 19:40:40 CST 2014
Flame

Comment 20

[Elie]

Attachment: VIDEO0064_Compress.MP4

This issue has been successfully verified on Flame 2.1:
Gaia-Rev        1bdd49770e2cb7a7321e6202c9bf036ab5d8f200
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/db893274d9a6
Build-ID        20141125001201
Version         34.0
Device-Name     flame
FW-Release      4.4.2