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

RESOLVED FIXED in mozilla37

Status

()

defect
RESOLVED FIXED
5 years ago
5 months ago

People

(Reporter: alice0775, Assigned: enndeakin)

Tracking

(Depends on 1 bug, {regression, ux-control})

28 Branch
mozilla37
x86_64
Windows 7
Points:
---
Dependency tree / graph
Bug Flags:
firefox-backlog -

Firefox Tracking Flags

(firefox33 affected, firefox34 affected, firefox35 affected, firefox36 affected, firefox-esr31 affected)

Details

(Whiteboard: [parity-Chrome][parity-IE])

Attachments

(2 attachments, 3 obsolete attachments)

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)
Good:
http://hg.mozilla.org/integration/mozilla-inbound/rev/7e6cb031ed8f
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:28.0) Gecko/20100101 Firefox/28.0 ID:20131104081507
Bad:
http://hg.mozilla.org/integration/mozilla-inbound/rev/07ea7b11adef
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:28.0) Gecko/20100101 Firefox/28.0 ID:20131104082308
Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=7e6cb031ed8f&tochange=07ea7b11adef

Suspect:
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
Posted file datalist.html
Also, there is a similar problem in HTML5 datalist dropdown.
Keywords: ux-control
Whiteboard: [parity-Chrome][parity-IE]
Depends on: 990846
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.
Posted 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
Status: NEW → ASSIGNED
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+
https://hg.mozilla.org/mozilla-central/rev/203e26771e77
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla37
Iteration: 37.3 - 12 Jan → ---
Points: 3 → ---
QA Whiteboard: [good first verify]
Depends on: 1251569
Depends on: 1328045
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.