513299 - Switching windows causes all text in single-line textfield to be reselected

Status: RESOLVED FIXED

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

Description

[[e-mail]]

Steps to reproduce problem:
1. Start typing in a textfield; generally I find the Error Console to be the one whose buggy behaviour is most likely to annoy me
2. Switch to another window (in any application) e.g. to copy some text
3. Switch back so you can paste it in at the caret

Expected result: able to paste text in at caret

Actual results: caret position lost because all text is now selected

This doesn't happen on 1.9.1, so I'd like to blame focus refactoring.

Comment 1

[Neil Deakin]

Don't see this bug myself.

Comment 2

[[e-mail]]

It depends on how focus was originally moved to the textfield. When the window is activated it does not reset the last focus method so if that was by key (or by move focus) then the text field gets reselected.

Comment 3

[Neil Deakin]

So it looks like we need to distinguish between a focus caused by a window raise and otherwise. Alternatively, fm->GetLastFocusMethod could instead return some cached value that is always set. That would require an alternate way of retrieving the focus method per window though.

Comment 4

[Neil Deakin]

Attachment: add back nsFocusEvent with a flag to indicate that the window was raised

Comment 5

[Neil Deakin]

Comment on attachment 400113 [details] [diff] [review]
add back nsFocusEvent with a flag to indicate that the window was raised

Try server shows no issues with this patch

Comment 6

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 400113 [details] [diff] [review]
add back nsFocusEvent with a flag to indicate that the window was raised

You need to add nsFocusEvent to nsDOMEvent::DuplicatePrivateData 

>@@ -1776,21 +1776,24 @@ nsHTMLInputElement::PostHandleEvent(nsEv
>   }
> 
>   if (NS_SUCCEEDED(rv)) {
>     if (nsEventStatus_eIgnore == aVisitor.mEventStatus) {
>       switch (aVisitor.mEvent->message) {
> 
>         case NS_FOCUS_CONTENT:
>         {
>+          // see if we should select the contents of the textbox. This happens
>+          // for text and password fields when the field was focused by the
>+          // keyboard or a navigation, the platform allows it, and it wasn't
>+          // just because we raised a window.
>           nsIFocusManager* fm = nsFocusManager::GetFocusManager();
>           if (fm && (mType == NS_FORM_INPUT_TEXT || mType == NS_FORM_INPUT_PASSWORD) &&
>+              !(static_cast<nsFocusEvent *>(aVisitor.mEvent))->mFromRaise &&
>               SelectTextFieldOnFocus()) {
What if someone creates focus event using
var e = document.createEvent("Event");
e.initEvent("focus", false, false);
inputElement.dispatchEvent(e);

That event isn't nsFocusEvent, but nsEvent.
You probably need to change nsDOMEvent::SetEventType so that 
NS_FOCUS/BLUR_CONTENT is set only to nsFocusEvent.

Please test accessing focus event after event dispatch.

Comment 7

[Neil Deakin]

Attachment: updated patch

Comment 8

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 401062 [details] [diff] [review]
updated patch

Sorry about the delay!

Comment 9

[Neil Deakin]

http://hg.mozilla.org/mozilla-central/rev/d9267e3d8f8c