Closed Bug 1089005 Opened 7 years ago Closed 7 years ago

Caret position is not changed by mouse click in input field when form-history autoComplete doropdown has been shown


(Core :: DOM: UI Events & Focus Handling, defect)

28 Branch
Windows 7
Not set



Tracking Status
firefox33 --- affected
firefox34 --- affected
firefox35 --- affected
firefox36 --- affected
firefox-esr31 --- affected


(Reporter: alice0775, Assigned: enndeakin)


(Depends on 1 open bug)


(Keywords: regression, ux-control, Whiteboard: [parity-Chrome][parity-IE])


(2 files, 3 obsolete files)

This is annoying bug. 

Steps To Reproduce:
1. Focus input fields (which is enabled form-history autocomplete)
2. Type text so that form-history autocomplete suggestion pops up
3. Attempt change the caret position by clicking on the input field

Actual Results:
The caret position is not changed. You need click once more.

Expected Results:
The caret position should be changed where you clicked.

Regression window(m-i)
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:28.0) Gecko/20100101 Firefox/28.0 ID:20131104081507
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:28.0) Gecko/20100101 Firefox/28.0 ID:20131104082308

07ea7b11adef	Neil Deakin — Bug 596723, Don't consume clicks outside of arrow panels by default, always consume the clicks on anchors of all popups, r=dao,neil
Flags: needinfo?(enndeakin)
Component: Layout: Form Controls → Event Handling
Attached file datalist.html
Also, there is a similar problem in HTML5 datalist dropdown.
Keywords: ux-control
Whiteboard: [parity-Chrome][parity-IE]
Flags: firefox-backlog?
Not taking this into the Firefox Desktop backlog because we probably need to fix the widget itself or its event handling here.
Flags: firefox-backlog? → firefox-backlog-
I think it may require a change in the popup code to handle autocomplete popups which would be in scope for someone like Neil.
Hmmm ok, let's leave that to Neil then. I think he is a good person to decide whether we should put it in the backlog.
Attached patch Patch (obsolete) — Splinter Review
This patch changes the consume flag to have three states, 'don't consume', 'always consume' and 'consume on parent only'.
Assignee: nobody → enndeakin
Flags: needinfo?(enndeakin)
Attachment #8531724 - Attachment is obsolete: true
Attachment #8535698 - Flags: review?(neil)
This version is the same except also removes the manual manipulation of consumeoutsideclicks from autocomplete.xml which I don't think is needed any more. This fixes some issues with things working only some of the time.
Attachment #8535698 - Attachment is obsolete: true
Attachment #8535698 - Flags: review?(neil)
Iteration: --- → 37.3 - 12 Jan
Points: --- → 3
Blocks: 1116865
This fixes a bug in the searchbar as it has its own content.
Attachment #8543980 - Attachment is obsolete: true
Comment on attachment 8544000 [details] [diff] [review]
Allow consume to be one of three states, v2.1

Maybe Dao can review this.
Attachment #8544000 - Flags: review?(dao)
Comment on attachment 8544000 [details] [diff] [review]
Allow consume to be one of three states, v2.1

>-    consume = item->Frame()->ConsumeOutsideClicks();
>+    ConsumeOutsideClicksResult consumeResult = item->Frame()->ConsumeOutsideClicks();
>+    consume = (consumeResult == ConsumeOutsideClicks_True);
>     // If the click was over the anchor, always consume the click. This way,
>     // clicking on a menu doesn't reopen the menu.
>-    if (!consume && pos) {
>+    if (consumeResult == ConsumeOutsideClicks_ParentOnly && pos) {
>       nsCOMPtr<nsIContent> anchor = item->Frame()->GetAnchor();

That comment doesn't seem quite accurate anymore
Attachment #8544000 - Flags: review?(dao) → review+
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla37
Iteration: 37.3 - 12 Jan → ---
Points: 3 → ---
QA Whiteboard: [good first verify]
Depends on: 1148716
Depends on: 1251569
Depends on: 1328045
Duplicate of this bug: 990846
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.