243920 - Text field not getting focus although caret is positioned on it

Status: RESOLVED WORKSFORME

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

Description

[KIRAN SHIVARAMA SUNDAR]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040514
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040514

In the testcase(buttontest.htm), clicking on one of the buttons("Show Alert")
shows an alert message and then attempts to position the focus onto a text field
following the alert.  The caret(flashing line showing where the cursor is) is
displayed in the correct field, however the button still has the focus and the
focus ring is still present on the button face. So it is highly misleading that
the caret is on the text box and the focus is on the 'Show Alert' button. So if
you attempt to type some text in the text field where the caret is present, no
characters appear in it. 

Reproducible: Always
Steps to Reproduce:
1. Load the html document(buttontest.html).
2. Click on the 'Show Alert' Button. An alert message pops up.
3. Click 'ok' button.

Actual Results:  
when we follow the Steps given above, it is positioning the caret in the text
field as desired, but it is  not shifting the focus on to the text field where
the caret is positioned. Focus still remains on the 'Show Alert' button. So when
we try to enter some text in the text field, it is not getting entered since the
focus has not shifted to the text field.

Expected Results:  
When we follow the Steps given above, it should shift the focus on the text
field where the caret is positioned. So when we try to enter some text it should
get entered into the text field.

The problem is happening on the latest mozilla release i.e. Mozilla 1.7 rc2.
Also, it is a cross-platform problem, since it is happening on Mozilla on OS/2,
Windows XP, Linux platforms also. Also, expected results are seen with Internet
Explorer 6.0 and Netscape Communicator 4.61 for OS/2, although in the latter, a
click on the window panel is required to bring the focus and the caret on to the
desired field.

Comment 1

[KIRAN SHIVARAMA SUNDAR]

Attachment: testcase for Bug 243920

Comment 2

[KIRAN SHIVARAMA SUNDAR]

(In reply to comment #0)
> User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7)
Gecko/20040514
> Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7)
Gecko/20040514
> 
> In the testcase(buttontest.htm), clicking on one of the buttons("Show Alert")
> shows an alert message and then attempts to position the focus onto a text field
> following the alert.  The caret(flashing line showing where the cursor is) is
> displayed in the correct field, however the button still has the focus and the
> focus ring is still present on the button face. So it is highly misleading that
> the caret is on the text box and the focus is on the 'Show Alert' button. So if
> you attempt to type some text in the text field where the caret is present, no
> characters appear in it. 
> 
> Reproducible: Always
> Steps to Reproduce:
> 1. Load the html document(buttontest.html).
> 2. Click on the 'Show Alert' Button. An alert message pops up.
> 3. Click 'ok' button.
> 
> Actual Results:  
> when we follow the Steps given above, it is positioning the caret in the text
> field as desired, but it is  not shifting the focus on to the text field where
> the caret is positioned. Focus still remains on the 'Show Alert' button. So when
> we try to enter some text in the text field, it is not getting entered since the
> focus has not shifted to the text field.
> 
> Expected Results:  
> When we follow the Steps given above, it should shift the focus on the text
> field where the caret is positioned. So when we try to enter some text it should
> get entered into the text field.
> 
> The problem is happening even on the latest mozilla release i.e. Mozilla 1.7 rc2.
> Also, it is a cross-platform problem, since it is happening on Mozilla on OS/2,
> Windows XP, Linux platforms also. Also, expected results are seen with Internet
> Explorer 6.0 and Netscape Communicator 4.61 for OS/2, although in the latter, a
> click on the window panel is required to bring the focus and the caret on to the
> desired field.

(In reply to comment #0)
> User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7)
Gecko/20040514
> Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7)
Gecko/20040514
> 
> In the testcase(buttontest.htm), clicking on one of the buttons("Show Alert")
> shows an alert message and then attempts to position the focus onto a text field
> following the alert.  The caret(flashing line showing where the cursor is) is
> displayed in the correct field, however the button still has the focus and the
> focus ring is still present on the button face. So it is highly misleading that
> the caret is on the text box and the focus is on the 'Show Alert' button. So if
> you attempt to type some text in the text field where the caret is present, no
> characters appear in it. 
> 
> Reproducible: Always
> Steps to Reproduce:
> 1. Load the html document(buttontest.html).
> 2. Click on the 'Show Alert' Button. An alert message pops up.
> 3. Click 'ok' button.
> 
> Actual Results:  
> when we follow the Steps given above, it is positioning the caret in the text
> field as desired, but it is  not shifting the focus on to the text field where
> the caret is positioned. Focus still remains on the 'Show Alert' button. So when
> we try to enter some text in the text field, it is not getting entered since the
> focus has not shifted to the text field.
> 
> Expected Results:  
> When we follow the Steps given above, it should shift the focus on the text
> field where the caret is positioned. So when we try to enter some text it should
> get entered into the text field.
> 
> The problem is happening on the latest mozilla release i.e. Mozilla 1.7 rc2.
> Also, it is a cross-platform problem, since it is happening on Mozilla on OS/2,
> Windows XP, Linux platforms also. Also, expected results are seen with Internet
> Explorer 6.0 and Netscape Communicator 4.61 for OS/2, although in the latter, a
> click on the window panel is required to bring the focus and the caret on to the
> desired field.

Comment 3

[OstGote!]

I guess ... related bugs are bug 241942 and bug 243782.

Comment 4

[KIRAN SHIVARAMA SUNDAR]

(In reply to comment #3)
> yes although bugids 241942 and bug 243782 describe the same, but the patch
made avaiable in bugid 241942 does not solve the problem. I am able to recreate
the same still

Comment 5

[KIRAN SHIVARAMA SUNDAR]

I am not able to see the problem on Mozilla release 1.2.1 dated 01/12/2002. but
the problem is seen with the next release that is mozilla 1.3 alpha dated
13/12/2002.

Comment 6

[rbs]

Nice testcase. Confirming.

The last focused element on the content window is not restored properly when the
alert goes away. It is as if the "true" last focused element was not stashed
away before firing the alert. Looks like some bits of the event code may be
missing the special care needed for these onblur="elsewhere.focus()" and
onfocus="elsewhere.focus()"

Comment 7

[Brian Ryner (not reading)]

A bit of analysis on this problem, from bug 241942:

243920 is a slightly different problem.  In that case, the focus controller is
suppressed but active at the time when we want to give the form control focus...
meaning that it gets a real focus event but the focus controller ignores it. 
Since we're in the middle of bringing up a dialog, we should not do a real focus
at that point, but just update the focus memory.  This may require us to
deactivate the focus controller in the parent window before dispatching the blur
event.

Comment 8

[KIRAN SHIVARAMA SUNDAR]

We have found out that the patch for bugzilla bug172691 is responsible for the
problem. The patch was from [e-mail]. 

Making the following two changes in the patch (attachment 106081 [details] [diff] [review] of bug172691)
fixes the problem.

+ var firstButton = null;
- var firstButton = document.documentElement.getButton("accept");
  switch (nButtons) {
     case 4:

We want this to be reviewed by someone and also want neil to check the code
change. We have also verified that the code change does not affect the given
fix. Kindly have someone review this fix above.

Comment 9

[[e-mail]]

(In reply to comment #8)
>var firstButton = null;
That's no good, it gets used twice later on the same function! Also, I see the
same issue with prompt() too, which doesn't use that variable. And I see an
###!!! ASSERTION: Attempt to decrement focus controller's suppression when no
suppression active!
: 'PR_FALSE', file c:/mozilla/dom/src/base/nsFocusController.cpp, line 478

Comment 10

[KIRAN SHIVARAMA SUNDAR]

Neil, I would like to know what problems could changing the code to "var
firstButton = null;" give rise to.

Comment 11

[Aaron Leventhal]

(In reply to comment #10)
> Neil, I would like to know what problems could changing the code to "var
> firstButton = null;" give rise to.

Kiran, Neil already said that firstButton is used twice in that function. If
firstButton is null and we call firstButton.foo() don't you see the problem?

Comment 12

[KIRAN SHIVARAMA SUNDAR]

Aaron,  Neil told me that first button is used in two places:

1: here:
      string = gCommonDialogParam.GetString(8);
      if (string)
        setLabelForNode(firstButton, string);
and 
2: here:
    if (gCommonDialogParam.GetInt(3) == 0) // If no text fields
    firstButton.focus(); // Don't focus checkbox, focus first button instead

So, according to Neil, changing the "var > firstButton = null;" could affect the
above two functions. 
Aaron, I am not able to see the problem by making the above changes to Neil's
patch on Mozilla on OS/2. Also, Neil has told me that his patch is not
responsible for the regression as he sees the problem on mozilla 1.2 on windows
where his fix has not been checked in. I am not able to see the problem with
Mozilla 1.2 on OS/2 wherein the fix of Neil has not been checked in, but I am
seeing the problem on Mozilla 1.3 alpha onwards on OS/2 wherein Neil's fix has
been checked in. I am but able to see the problem on Mozilla 1.2 on Linux  and
windows, wherein the fix has not been checked in.

Comment 13

[Robi Brunner]

Not sure if it's related, but similar thing occurs on Window XP (SP2) with Firefox 1.5b2 (I think any 1.5 build) with xmouse/autofocus turned on with typeaheadfind set to true and having the download manager notify you when downloads have completed.  Basically nothing will bring back focus to the browser window until you acknowledge that the download manager has completed by giving it focus and then returning to the window.

Recreate by:
1. turn on typeaheadfind
2. turn on xmouse/autofocus windows tweak (maybe not related)
3. open up a site with a text input box
4. download something (could be from a different tab in the same window), download manager pops up for the first time in the foreground.
5. bring browser window back into focus but leave download manager open underneath
6. download another file
7. focus goes to download window but it will stay underneath.  Focus is on browser main window.
8. Windows task bar flashes indicating event on download manager
9. go back to page with text box.
10. Click on text box and start typing.  typeaheadfind should get activated instead
11. Clicking on the page, switching tabs, nothing seems to bring back focus to the window in order to be able to type in the textbox, typeaheadfind is always activated.
12. bring download manager to foreground to give it focus (or if with xmouse, just mouse over to give it focus and can leave underneath)
13. return to window, click in textbox, should now be able to type normally into textbox w/o typeaheadfind being activated.

Comment 14

[Thomas Bertels]

I can't reproduce with the testcase under Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9a3pre) Gecko/20070228 Minefield/3.0a3pre

I suggest marking as WFM.

Comment 15

[Uri Bernstein]

WFM on trunk (and in 1.8.1.9).