Closed Bug 669184 Opened 13 years ago Closed 13 years ago

Cursor position is set before first character in bookmark edit dialog

Categories

(Firefox for Android Graveyard :: General, defect)

Firefox 6
ARM
Android
defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED
Firefox 9

People

(Reporter: xti, Assigned: martijn.martijn)

References

Details

(Keywords: regression, Whiteboard: [inbound])

Attachments

(2 files)

Build id : Mozilla/5.0 (Android;Linux armv7l;rv:6.0a2)Gecko/20110704 Firefox/6.0a2 Fennec/6.0a2 Device: Motorola Droid 2 OS: Android 2.2 Steps to reproduce: 1. Open Fennec app 2. Go to www.mozilla.com 3. Pan left for the right sidebar 4. Tap on the the white star 5. Tap on Edit button Expected result: After step 5, the Bookmark Editor dialog is displayed. The page name input field is in focus and the cursor is set at the end of its content (just after the last character). Actual result: After step 5, cursor position is set on the beginning of the page name input field.
Whiteboard: [regression]
Confirming that I see this on Mozilla/5.0 (Android; Linux armv7l; rv:7.0a1) Gecko/20110704 Firefox/7.0a1 Fennec/7.0a1 Device: HTC Nexus One, Samsung Nexus S OS: 2.3.4 Simply head to about:home, and edit the bookmark and see the cursor before the first character in 'Firefox Start'.
Summary: Cursor position is set on the beginning of an already filled input field → Cursor position is set before first character on edit fields with text
Whiteboard: [regression]
This issue doesn't occur on: Build id : Mozilla/5.0 (Android;Linux armv7l;rv:6.0a1)Gecko/20110512 Firefox/6.0a1 Fennec/6.0a1 but it occurs on: Build id : Mozilla/5.0 (Android;Linux armv7l;rv:6.0a1)Gecko/20110513 Firefox/6.0a1 Fennec/6.0a1 http://hg.mozilla.org/mozilla-central/rev/7fd948de62a6 Possible range: http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2011-05-12&enddate=2011-05-13+03%3A00
Looks like this was caused by the patch in bug 612129.
This issue is really silly, setting the tracking-fenec flag. Ehsan, any idea if this is indeed caused from bug 612129?
tracking-fennec: --- → ?
Attached patch patch (deleted) — Splinter Review
Something like this fixes it.
If putting the caret at the beginning of the selection is the new "right way", why should we move it to the end?
What do you mean with the new "right way". Bug 612129 was mainly about being compatible with IE. That doesn't mean it is something you would want to happen, necessarily.
This behavior change is intentional, and makes Gecko compatible with other browser engines. I'm not sure why Fennec should be an exception to this rule...
We should not. Closing for now.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WONTFIX
Can or should we compromise here and mimic the stock browser behaviour by creating a selection/highlight of a fields text content on tap allowing the user to decide where to place the cursor (akin to how we do it on url bar tap)? At least in this approach, one will have the option of where they wish to place the cursor. For deleting all text contents, it will be as easy as tapping delete, and it will not be necessary and required to move the cursor position to the end of the text contents prior. Opening bug 674006
(In reply to comment #10) > Opening bug 674006 dupe of bug 652168?
(In reply to comment #8) > This behavior change is intentional, and makes Gecko compatible with other > browser engines. I'm not sure why Fennec should be an exception to this > rule... Not at all, this behavior change makes Fennec behave differently than Stock Android browser, which selects the whole textbox and Opera Mobile, which sets the caret position at the end. On desktop, Firefox and IE select the whole textbox.
Martijn - Sounds like the "select the whole textbox" part needs to be addressed, in all textboxes, right?
Reopening this bug. Bug 612129 may have a good reason to change the *default* behavior of text fields, but that doesn't mean we can't override the default behavior for specific fields in the Fennec chrome. Re-titling this bug to focus on the specific case in comment 0; we can open other bugs if this impacts other chrome elements. Martijn's patch looks fine to me, but I actually think it would be simpler and better to just make autoSelect be the default (and only?) behavior for startEditing. (For comparison, the desktop Firefox bookmark edit popup auto-selects the tags field.) Assigning this bug to Martijn because he already has a patch here; feel free to request review, or provide a new patch based on my suggestion here, or un-assign yourself if you are not working on it anymore.
Assignee: nobody → martijn.martijn
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Summary: Cursor position is set before first character on edit fields with text → Cursor position is set before first character in bookmark edit dialog
Attached patch patch (deleted) — Splinter Review
startEditing doesn't do anything with the autoSelect argument anymore, it seems: http://mxr.mozilla.org/mozilla-central/search?find=%2Fmobile%2F&string=startediting This code was added in bug 481121. So I think the autoSelect thing can just be removed.
Attachment #557777 - Flags: review?(mbrubeck)
Attachment #557777 - Flags: review?(mbrubeck) → review+
Keywords: checkin-needed
Status: REOPENED → ASSIGNED
Keywords: checkin-needed
Whiteboard: [inbound]
Status: ASSIGNED → RESOLVED
Closed: 13 years ago13 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 9
Thank you for fixing this. Samsung Nexus S Mozilla/5.0 (Android, Linux armv7l; rv:9.0a1) Gecko/20110906 Firefox/9.0a1 Fennec/9.0a1
Status: RESOLVED → VERIFIED
tracking-fennec: ? → ---
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: