Closed
Bug 1099208
Opened 10 years ago
Closed 3 years ago
Textbox loses selection and caret when stopping propagation on focus event in capturing event handler on document/window/documentElement
Categories
(Core :: DOM: Editor, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: info, Unassigned)
References
Details
(Keywords: testcase)
Attachments
(1 file, 1 obsolete file)
15.32 KB,
patch
|
Details | Diff | Splinter Review |
User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:35.0) Gecko/20100101 Firefox/35.0 Build ID: 20141113004001 Steps to reproduce: I focused a text box in ff x dev edition. http://jsfiddle.net/bhkqnv0w/ Actual results: Nothing. Expected results: The caret should be visible and selections in should be be in selected style.
Reporter | ||
Comment 1•10 years ago
|
||
Wrong link above, sorry! And same goes for document and document body document: http://jsfiddle.net/bhkqnv0w/1/ window: http://jsfiddle.net/bhkqnv0w/2/ document.body: http://jsfiddle.net/bhkqnv0w/1/
Comment 2•10 years ago
|
||
I'm confused. Your testcase calls stopPropagation(), and the handler is attached as a capturing handler. So the focus never arrives in the textbox. Why is this surprising or wrong?
Reporter | ||
Comment 3•10 years ago
|
||
I'm confused too :-). FF behaves different than all other browsers... I tested on Windows: - Chrome 38.0.2125.111 m - IE 11.0.9600.17416 - Opera 25.0.1614.71 Showing the caret has nothing to do with the focus event. Seems like FF uses the event to set cursor/caret/selection/range.
Flags: needinfo?(info)
Comment 4•10 years ago
|
||
Olli, can you help? :-)
Component: Untriaged → DOM: Events
Flags: needinfo?(bugs)
Summary: Textbox loses selection and caret when focus event on window object is subscribed → Textbox loses selection and caret when stopping propagation on focus event in capturing event handler on document/window/documentElement
Comment 5•10 years ago
|
||
Interesting. Sounds like an editor issue to me
Component: DOM: Events → Editor
Flags: needinfo?(bugs)
Comment 6•10 years ago
|
||
Yes, I blame nsEditorEventListener::InstallToEditor().
Comment 7•10 years ago
|
||
(In reply to Olli Pettay [:smaug] from comment #6) > Yes, I blame nsEditorEventListener::InstallToEditor(). Should the focus and blur events, at least, "just" use system event listeners, and then check getDefaultPrevented?
Comment 8•10 years ago
|
||
Looks like a "recent" regression from bug 283897. A patch coming.
Comment 9•10 years ago
|
||
https://tbpl.mozilla.org/?tree=Try&rev=28b689b31946 This may break quite some tests. Another option is to not use system group, but current window's parent target and default group's capture phase.
Updated•10 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 10•10 years ago
|
||
Actually, might not break anything. But let's wait for the test results.
Updated•10 years ago
|
Flags: needinfo?(bugs)
Comment 11•10 years ago
|
||
(In reply to Olli Pettay [:smaug] from comment #10) > Actually, might not break anything. But let's wait for the test results. Hmm, if a focus event handler of web apps sets selection range in <input> or <textarea> wouldn't it break the range at handling focus event in system group? I guess that nsFocusManager or something needs to notify editor of setting focus *before* dispatching DOM focus event.
Comment 12•10 years ago
|
||
(In reply to Masayuki Nakano (:masayuki) (Mozilla Japan) from comment #11) > Hmm, if a focus event handler of web apps sets selection range in <input> or > <textarea> wouldn't it break the range at handling focus event in system > group? I don't see what you mean with this. > I guess that nsFocusManager or something needs to notify editor of > setting focus *before* dispatching DOM focus event. This is why I was thinking the other approach to handle these events during capture phase of default group, but add event listener to nsPIDOMWindow::GetParentTarget
Flags: needinfo?(bugs)
Updated•10 years ago
|
Flags: needinfo?(bugs)
Comment 13•9 years ago
|
||
https://tbpl.mozilla.org/?tree=Try&rev=b62cb31dabce
Attachment #8524905 -
Attachment is obsolete: true
Comment 14•9 years ago
|
||
https://tbpl.mozilla.org/php/getParsedLog.php?id=56978024&tree=Try&full=1#error0 Masayuki, that show rather ugly bug in IME handling currently. We dispatch a composition event from focus event listener. We should do it either before or after the focus event.
Flags: needinfo?(masayuki)
Comment 15•9 years ago
|
||
Hmm, will that be fixed if we call IMEStateManager::OnFocusInEditor() from ESM::PostHandleEvent() when it receives focus event? If so, I guess it works.
Flags: needinfo?(masayuki)
Comment 16•9 years ago
|
||
Or, just keep calling it from (new) "focus" event handler but you make new it listen in the system group.
Comment 17•3 years ago
|
||
The testcase seems to be working now. Please reopen if needed.
Status: NEW → RESOLVED
Closed: 3 years ago
Flags: needinfo?(bugs)
Resolution: --- → WORKSFORME
Comment 18•3 years ago
|
||
Perhaps, dup of bug 1450055, but just marking this as depending on it.
Depends on: 1450055
You need to log in
before you can comment on or make changes to this bug.
Description
•