Closed Bug 1021401 Opened 10 years ago Closed 10 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
normal

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)
Attached patch allow.mousedown.on.the.rocketbar.patch (obsolete) (deleted) — Splinter Review
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: 10 years ago
Flags: needinfo?(etienne)
Resolution: --- → FIXED
Attached file Github pull request (deleted) —
Pull request with patch + test, carring R.
Attachment #8438307 - Attachment is obsolete: true
Attachment #8440310 - Flags: review+
Verified on master.
Status: RESOLVED → VERIFIED
Attachment was updated as the rev link, the patch is here: https://github.com/mozilla-b2g/gaia/commit/53544093b17dbc3b2dbe69a5c979c3d58a1c5032
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 (deleted) —
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.

Attachment

General

Created:
Updated:
Size: