Closed Bug 1156037 Opened 10 years ago Closed 10 years ago

SelectWord triggered by NS_MOUSE_MOZLONGTAP widget event doesn't move focus

Categories

(Core :: DOM: Selection, defect)

ARM
Android
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla40
Tracking Status
firefox40 --- fixed

People

(Reporter: capella, Assigned: capella)

Details

Attachments

(2 files)

Long-tapping into a contentEditable will select a word and move focus to the element. A subsequent NS_MOUSE_MOZLONGTAP generated by Android widget via long press into non-editable text content, will successfully select the word in the new element, but leave the focus on the contentEditable. This patch will correct that, removing focus from a previously focused contentEditable.
Attachment #8594425 - Flags: review?(tlin)
Adding kats (fyi)
Comment on attachment 8594425 [details] [diff] [review] bug0000000_contentEditableFocusBug.diff Review of attachment 8594425 [details] [diff] [review]: ----------------------------------------------------------------- This commit lacks a title. Do you have a test webpage to reproduce this issue? I would like to test this patch on B2G. Thanks. ::: layout/base/SelectionCarets.cpp @@ +20,5 @@ > #include "nsIDocument.h" > #include "nsIDocShell.h" > #include "nsIDOMDocument.h" > #include "nsIDOMNodeFilter.h" > +#include "nsGenericHTMLElement.h" Nit: Please keep the #includes sorted alphabetically. @@ +644,5 @@ > + } > + } else { > + // Clear focus if it was contentEditable. > + nsGenericHTMLElement* focusedGeneric = > + nsGenericHTMLElement::FromContent(focusedContent); Since both the if and else branch are to clear focus, how about moving the declaration of "focusedGeneric" below line 638 to avoid the duplication of line 650-653?
Attachment #8594425 - Flags: review?(tlin) → feedback+
Yah, no commit title because I wrote the patch before posting to a new bug :) I'll fix that and the other nits. I duplicated the code block to avoid grabbing a |nsGenericHTMLElement* focusedGeneric| value every time, as in the majority of cases it won't be required to be checked. With a tradeoff of speed or code size, I optimized for speed. But I'll be happy to change it as you suggest. It'll be more compact / readable. Here's the test page I forgot to post: [0] I long-tap onto the contenEditable field at the bottom containing text "TAP ME TAP ME TAP ME TAP ME", then I long-tap onto the content field containing text "LONGPRESS ME LONGPRESS ME LONGPRESS ME" above it. [0] https://www.dropbox.com/s/j5jcon30y8vda3u/test_bug988143.html?dl=0
Attached patch bug1156037.diff (deleted) — Splinter Review
Updated :-)
Attachment #8594626 - Flags: review?(tlin)
Comment on attachment 8594626 [details] [diff] [review] bug1156037.diff Review of attachment 8594626 [details] [diff] [review]: ----------------------------------------------------------------- I verify the test case provided in comment 3 on B2G. We surely need to clear the old focus on contenteditable element. Nice catch!
Attachment #8594626 - Flags: review?(tlin) → review+
Assignee: nobody → markcapella
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla40
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: