191896 - No focus on username/password possible when launching mozilla from a shortcut and page rquires authentication

Status: RESOLVED WORKSFORME

(Core :: Networking: HTTP, defect)

Description

[Allan Wilkins]

User-Agent:       Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130

No focus on username/password possible when launching mozilla from a shortcut 
and page rquires authentication.

Reproducible: Always

Steps to Reproduce:
1. Create desktop shortcut to page requiring authentication
2. Ensure mozilla not running
3. Double click shortcut
4. Notice that it is not possible to enter username and password textboxes.


Actual Results:  
Couldn't enter username/password. Clicking cancel and reload pops up the dialog 
again and allows entry of the username and password.

Expected Results:  
Allow the username textbox to accept focus

Comment 1

[Ere Maijala (slow)]

WFM, trunk build 2003013008 WinXP.

Comment 2

[Matthew van Eerde]

I'm seeing this too.

I'm using 1.3 final 20030312 Windows 2000

Also, starting from the command line gives this same issue, either with
start http://intranet/
or
mozilla.exe http://intranet/

A workaround is to give another application focus and then click back on
Mozilla, but the bug is definitely there.

Comment 3

[Matthew van Eerde]

Attachment: Screenshot of unresponsive authentication dialog

Note there is no cursor in the "Username" field.  Clicking on the username
field should allow typing in it, but does not.

Comment 4

[timeless]

darin owns the blame for the caller in nsHttpChannel.cpp, someone will probably
have to investigate this in a debugger, i agree with bz this is probably a danm
bug. but that ere didn't see the problem isn't promising.

Comment 5

[Ere Maijala (slow)]

Could you guys try it with a recent nightly build? Just in case it's related to
the focus stuff redone after 1.3.

Comment 6

[Matthew van Eerde]

Attachment: screenshot of entire application at freeze point

Comment 7

[Matthew van Eerde]

Reproduced on 20030324 build

Note: this problem has always been intermittent for me.

Comment 8

[Matthew van Eerde]

Attachment: screenshot of 20020324 nightly build in freeze

Comment 9

[Ere Maijala (slow)]

I was finally able to reproduce and will take a look. It seems that, contrary to
the report, I need to have Mozilla running before starting it again with an address.

Comment 10

[benc]

It sounds like the two of you do agree this is a problem...

Comment 11

[Ere Maijala (slow)]

Sure, I wouldn't spend my time on it otherwise :)

Comment 12

[Ere Maijala (slow)]

Oh crap. The same problem as with bug 163372. A dialog gets the focus only if
its owner had it (I believe). Now when a new browser window is created, it
doesn't get focus until idle timers fire (navigator.js 587, 589). Idle timers
won't fire before the dialog is displayed. Therefore, it doesn't get the focus.
Verified by removing the setTimeout() from navigator.js. Going to ask around a bit.

Comment 13

[Ere Maijala (slow)]

And the real question I make is: why is setTimeout() used to set the focus? It's
causing a lot of trouble because it's not predictable. Bryner? Jag? I've tried
to get a picture of the deal from related bugs, but it's a mess :/

Comment 14

[Brian Ryner (not reading)]

Unfortunately, setTimeout() is often used when setting focus to work around
problems with xbl bindings not being fully loaded (and perhaps other problems
with setting the focus during document load).

Comment 15

[Ere Maijala (slow)]

Oh crap, this all leads back to bug 90337.

Comment 16

[[e-mail]]

Attachment: timeout patch

Ere, can you see if this fixes the timeout issue without regressing anything?

Comment 17

[Ere Maijala (slow)]

Unfortunately Neil's patch didn't help, which means my thought was incorrect.
I've now done some more research. The real problem seems to be that for some
reason I've yet find out the dialog window doesn't receive SetFocus(true) which
means that NS_ACTIVATE isn't dispatched either. Now the window doesn't seem to
be active and dialog's commandDispatcher fails to move the focus.

Comment 18

[Ere Maijala (slow)]

Here's the deal: normally the dialog gets the focus when its parent is disabled
in the beginning of ShowModal(). The problem here is that chrome for the dialog
hasn't been loaded yet, which means the window is still invisible. This causes
WM_SETFOCUS to be missed. When the window is finally shown, it will only receive
WM_ACTIVATE, which is not dispatched as NS_ACTIVATE before WM_SETFOCUS is
received and dispatched as NS_GOTFOCUS. Therefore chrome and all never find out
that the window actually became active. 

Comment 19

[Ere Maijala (slow)]

Synchronously loading the local chrome (as in bug 90337) would fix this. I'm
looking into getting opinions on it.

Comment 20

[Ere Maijala (slow)]

I checked in a fix for bug 90337, but it seems it alone doesn't always make this
work :( I'll investigate.

Comment 21

[Ere Maijala (slow)]

Looks like I had a selfmade bug in my tree. Let's wait for the nightlies to
verify if this now works.

Comment 22

[Ere Maijala (slow)]

WFM, latest trunk build (2003041808) :)