Closed Bug 1021401 Opened 5 years ago Closed 5 years ago

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

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set

Tracking

(blocking-b2g:2.0+, b2g-v2.0 verified, b2g-v2.1 verified)

VERIFIED FIXED
2.0 S4 (20june)
blocking-b2g 2.0+
Tracking Status
b2g-v2.0 --- verified
b2g-v2.1 --- verified

People

(Reporter: athornburgh, Assigned: vingtetun)

References

Details

(Whiteboard: [2.0-FL-bug-bash][systemsfe])

Attachments

(3 files, 1 obsolete file)

# 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).
Component: Gaia → Gaia::Search
Need input from UX team to check if this is by design or a missing feature.
User Story: (updated)
Flags: needinfo?(firefoxos-ux-bugzilla)
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. :)
Flags: needinfo?(rmacdonald)
Flags: needinfo?(firefoxos-ux-bugzilla)
Flags: needinfo?(fdjabri)
The behaviour here should be the same as other input fields across the OS, which allow the user to tap to reposition the cursor.
Flags: needinfo?(rmacdonald)
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.
blocking-b2g: --- → 2.0?
Whiteboard: [2.0-FL-bug-bash] → [2.0-FL-bug-bash][systemsfe]
QA Whiteboard: [2.0-rocketbar-FL-blocking+]
NI : johan, can we get the old screenshot that we discussed offline with the old homescreen to be more clear on the ask here ?
Flags: needinfo?(jlorenzo)
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.
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.
Flags: needinfo?(jlorenzo)
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.
blocking-b2g: 2.0? → 2.0+
QA Whiteboard: [2.0-rocketbar-FL-blocking+] → [VH-FL-blocking+]
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 :)
Flags: needinfo?(21)
Here a patch.
Attachment #8438307 - Flags: review?(etienne)
Flags: needinfo?(21)
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? :)
Attachment #8438307 - Flags: review?(etienne) → review+
Target Milestone: --- → 2.0 S4 (20june)
Assignee: nobody → 21
Flags: needinfo?(fdjabri)
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!
Flags: needinfo?(etienne)
Flags: needinfo?(21)
(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 :)
Flags: needinfo?(21)
QA Whiteboard: [VH-FL-blocking+] → [VH-FL-blocking+][VH-FC-blocking+]
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.
Status: NEW → RESOLVED
Closed: 5 years ago
Flags: needinfo?(etienne)
Resolution: --- → FIXED
Attached file Github pull request
Pull request with patch + test, carring R.
Attachment #8438307 - Attachment is obsolete: true
Attachment #8440310 - Flags: review+
Verified on master.
Status: RESOLVED → VERIFIED
Summary: Can't Edit Search Term in Rocket Bar → [Rocketbar] Can't Edit Search Term in Rocket Bar
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
Attached video 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
You need to log in before you can comment on or make changes to this bug.