Closed Bug 241942 Opened 20 years ago Closed 20 years ago

Parent window should also get focus when input textbox gets focus

Categories

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

Product:
Core
Component:
DOM: UI Events & Focus Handling
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: martijn.martijn, Assigned: bryner)

Details

(Keywords: fixed1.7, Whiteboard: fixed-aviary1.0)

Attachments

(3 files, 1 obsolete file)

Testcase for the bug
833 bytes, text/html
Details
patch
730 bytes, patch
jst
: review+
jst
: superreview+
asa
: approval1.7+
asa
: approval1.8a1+
Details | Diff | Splinter Review
reduced testcase of bugid 243920
233 bytes, text/html
Details 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7b) Gecko/20040323 Firefox/0.8.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7b) Gecko/20040323 Firefox/0.8.0+

When the parent window of a textbox is not focussed, and you focus the textbox
with javascript, you can't type anything in the textbox, but you can see the caret.
This gives problems at least on this site:
https://www.dresdner-privat.de/
Discussed previously here:
http://forums.mozillazine.org/viewtopic.php?t=72066&sid=8fbbab0d1d7686a14056aa8346352c11

I will attach a testcase which always shows the problem.

This testcase works in:
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030827
It doesn't work in:
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20030916
So it seems to have been regressed since 27/8/2003

The testcase consists of a frameset with two frames.
The first frame has this source:
<html><head></head><body onload="setTimeout('window.focus()',100)"></body></html>

The second frame has this source:
<html><head>
<script type="text/javascript">
function doe(){document.getElementById('test').focus();}
</script>
</head>
<body onload="setTimeout('doe()',200)">
<input type="text" id="test"><br>
You see the cursor blinking but typing is not possible
</body>
</html>

I think this problem also causes/is related to bug 236596.


Reproducible: Always
Steps to Reproduce:
1.See testcase
2.
3.

Actual Results:  
Not able to type anything in the textbox

Expected Results:  
You should be able to type anything in the textbox
Hmm, the first patch from bug 198153 seems to be the cause of this.
Removing the code from this patch (compiling from scratch by the way) makes the
testcase work (and also the first testcase from bug 236596):
http://bugzilla.mozilla.org/attachment.cgi?id=121244&action=diff

I have changed the component to event handling, since this seems like a bug in
nsEventStateManager.cpp.
Component: XP Toolkit/Widgets → Event Handling
Removing the the ESM patch from bug 198153, fixes bug 241942, bug 236596, and
quite possibly bug 218995 (not tested, but see comments there). 
Especially note http://bugzilla.mozilla.org/show_bug.cgi?id=218995#c2 where one
of the reviewers specificly asks for that patch to be removed.
Attachment #147614 - Flags: review?(bryner)
Flags: blocking1.7?
Comment on attachment 147614 [details] [diff] [review]
Patch which removes the ESM patch from bug 198153

I don't want to back out the patch entirely; I still think it's mostly correct.
   In this case, there's no reason for the focus controller to be inactive, so
my guess is that when this code is called, mDocument is null or the document's
focus controller isn't hooked up.  I'll post a new patch shortly.
Attachment #147614 - Flags: review?(bryner) → review-
Attached patch patch — — Splinter Review 
EnsureDocument() must be called before using mDocument.
Attachment #147614 - Attachment is obsolete: true
Attachment #148769 - Flags: superreview?(jst)
Attachment #148769 - Flags: review?(jst)
Brian, I hit upon a newly reported bug i.e bug 243920, which has a similar 
testcase like the one posted above. Although the patch u have posted solves the 
above testcase, it does not do any good to the one posted on bug 243920, for 
reasons unknown to me. Also, the earlier patch which removes the ESM patch from 
bug 198153 does not also do any good to the testcase. I am uploading a reduced 
testcase given in bug 243920.
In this testcase, the caret gets triggered even before we click ok on the
message box. Also the canvas focus ring is on the Alert button while the caret
is on the text field. In Internet explorer it seems to be working fine though.
Comment on attachment 148769 [details] [diff] [review]
patch

r+sr=jst
Attachment #148769 - Flags: superreview?(jst)
Attachment #148769 - Flags: superreview+
Attachment #148769 - Flags: review?(jst)
Attachment #148769 - Flags: review+
I have also tried that patch by Brian for the reduced testcase of bugid 243920.
It does not seem to fix the problem, though it fixes the first testcase.
Comment on attachment 148769 [details] [diff] [review]
patch

a=asa (on behalf of drivers) for checkin to 1.8a1
Attachment #148769 - Flags: approval1.8a1+
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.
Assignee: jag → bryner
Status: UNCONFIRMED → NEW
Ever confirmed: true
checked in (bug 243920 remains open)
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Indeed, the testcase seems to be working now in:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a1) Gecko/20040520
Firefox/0.8.0+
That's great, really! 

But the first testcase
(http://bugzilla.mozilla.org/attachment.cgi?id=143024&action=view) from bug
236596 is still not working. Removing the ESM patch entirely makes it work (just
an observation).

Of bug 218995, I'm not sure if that one is fixed by this bug. I will ask it there.
Comment on attachment 148769 [details] [diff] [review]
patch

a=asa (on behalf of drivers) for checkin to 1.7
Attachment #148769 - Flags: approval1.7+
checked into 1.7 branch and aviary 1.0 branch.
Keywords: fixed1.7
Flags: blocking1.7?
Whiteboard: fixed-aviary1.0
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: