Closed Bug 27784 Opened 24 years ago Closed 24 years ago

Can't enter authentication password (Objects set to display:none still steal events)

Categories

(Core :: XUL, defect, P2)

x86
Linux
defect

Tracking

()

VERIFIED WORKSFORME

People

(Reporter: tever, Assigned: joki)

References

()

Details

(Keywords: platform-parity, Whiteboard: [nsbeta2-])

Attachments

(4 files)

Overview Description:  Can not get to edit box to enter password either through 
mouse clicking or tabbing.  This is necessary for proxy authentication. 

Steps to Reproduce:
1.)  Go to site
2.)  When name / password dialog appears, try to enter password.

Actual Results:  Cannot get to password edit box

Expected Results:  Should be able to enter pw.

Build Date & Platform Bug Found: Linux 2000021416

Additional Builds and Platforms Tested On: 
Works fine on NT 2000021408
I don't get any authentication dialog going the tegu.mozilla.org, on Linux or
Windows.  I also don't see what this has to do with proxy authentication.  Whose
dialog is this that you're seeing, anyway?
sorry, my mistake.  I changed the test URL above.  

What this has to do with proxy authentication is that I need to log in with a 
user name and password to get access to the server.  If you go to the prefs | 
Advanced | proxies and enter a proxy server in you will get the same dialog.
The dialog is generated by mozilla.

I found bug 24148 where the tabbing problem is addressed but what I am saying is 
that I cannot get to the password entry field at all.  
Well, with the latest URL I do get an authentication dialog. The tabbing order
is incorrect, as you point out (and as covered by 24148), but I can get to the
password field, either by clicking once in it, or by tabbing a couple of extra
times. It seems to work fine once I get a caret. Resolving as wfm. If you're
still seeing this, please reopen with sufficient steps to reproduce.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
Peter, are you sure you are checking this on Linux?  I can reproduce this on a 
second Linux box with both yesterday's and today's build.  What you describe is 
what I am seeing with NT4.0.  
Status: RESOLVED → REOPENED
Keywords: beta1
Resolution: WORKSFORME → ---
Whiteboard: [PDT+]
Okay, I can reproduce this in a debug build of the tip from around 6PM.

Also happens in today's mozilla verification build. reassigning to saari as p2
for m14
Assignee: trudelle → saari
Status: REOPENED → NEW
Priority: P3 → P2
Target Milestone: M14
*** Bug 28026 has been marked as a duplicate of this bug. ***
Note that the password is neither being displayed nor conveyed to the caller of
PromptUsernameAndPassword. In past it used to not be displayed but was still
conveyed (so its a regression of the latter)
FYI, FTP authenticaion works just fine

I'll take a look. Where does this XUL live?
Status: NEW → ASSIGNED
The password field is getting focus just like it should, at least from the
code's standpoint, but I'm seeing the processor is pegged. This looks like it
might be the linux dialog pegging the cpu problem again.
*** Bug 28109 has been marked as a duplicate of this bug. ***
*** Bug 24370 has been marked as a duplicate of this bug. ***
Argh, someone nuked my comment...

Okay, one more time...

If you revese the order of the two password fields in commonDialog.xul, this 
works. This means focus is going to a non-visible field. This means I'm getting 
the wrong content node from GetContentForFrame. Or I'm getting the wrong frame. 
Anyway, I'm not really sure what to do with this bug, I don't think it falls in 
my court, so I'm reassigning to joki.

I don't know why this is linux specific either.

Sorry Tom...
Assignee: saari → joki
Status: ASSIGNED → NEW
Hmm.  I'm not entirely sure where to go with this either.  I'll need Linux 
debugging help.
looks like bug 24318-- see comments there as well. and decide which one is the 
dup...
I noticed that if in commonDialogs.js you comment out the part in which it
deactivates the unused fields (leaving all the 3 input fields) it works.
If I leave this part I can reach the login field but not the password.
I think this is related at setting style="display: none", becouse if you try to
exchange dialog order in commonDialogs.xul everithing works (in the
login/password case!).
One more data point, for what it's worth.  The checkbox also doesn't work -- 
there is no way you can check it.
I just realized that the checkbox problem is already covered in bug 28100.
*** Bug 24318 has been marked as a duplicate of this bug. ***
Whiteboard: [PDT+] → [PDT+], fix date unknown. possible fix now risky. looking for workaround.
Joki -- I would LOVE to help. How can I? :) My experience with C/C++ is limited,
and my experience with gdb is limited, but .. I offer my services, for what it
is worth. :)

Thanks
Added self to CC list, still getting this bug on the latest Linux build.
spam: added self to cc list as this would affect my area.
*** Bug 28566 has been marked as a duplicate of this bug. ***
per PDT, who else can help with this bug?
one of the big issues relating to this bug is of the way the CPU gets pegged 
when the dialog appears. I suspect that this is becuz of an overkill of the 
proxy events to throw the dialog box from the same thread as the HTTP. A clean 
way to break out of that could be if webshell implements nsIHTTPEventSink (see 
bug 27048) then we could just use the sink to ask for the auth which in turn 
would let the webshell throw the dialog box thereby avoiding the proxy events. 
But this might just be a separate issue... 

Do we have a test case of just throwing up PromptUserNameAndPassword dialog 
boxes (without really the HTTP asking for it)? Joki could you elaborate on the 
problem (and your potential fix) here?
Why don't we fork commondialog.js or something, and apply the base workaround to
the one that mozilla normally calls (commenting out everything that hides
fields), and then keep working to create the correct fix for commondialog in
another file. I applied the raw fix to my version of commonDialog.js because
otherwise, I couldn't log in to anything :-(
In response to Gagan's question about other cases that use this dialog other 
than http, the answer is yes.  It is done in mailnews.  
Another place where a similar dialog is used is in ftp authentication.  It's not 
the same dialog (PromptUsernameAndPassword) but rather a one-text-field version 
of that dialog (PromptPassword).

Interestingly enough, this problem does not occur in the ftp authentication 
dialog.
gagan, not sure on the network event implications here.  We're strictly looking 
at this from a mouse event targetting standpoint.  The basic problem is that 
the event targetting system isn't set up well to handle hidden content in a 
number of cases.  dbaron has been working on a fix to this which we have but 
its really too scary and untested for M14.

What we're looking at now is workarounds inside commonDialog.js.  Similar to 
the fix proposed below of forking commonDialog.js but we think we might be able 
to rewrite the js to look the same but function correctly.
When I edit commonDialog.js to comment out the three lines after
dump("hiding password1EditField")
I get a password dialog with three boxes:
User Name, Password, Password
After entering the user name, it is 5 tabs to the second password box.
 I enter the the password, click on OK, and I'm accepted!

http://www.dmoz.org/editors/

First time I've been able to get past the password in more than a week.
Blocks: 24329
Just to clarify, the tabbing problem in this dialog is bug 18411. This bug 
(27784) is the problem of not being able to get into the password field *at all*, 
on Linux.

If you just want a workaround for M14, then why not use smalllinux's one.
Hard-code CSS into the second password field to make it gray, and to give it tiny 
height and width. While you were at it, you could hard-code a message into the 
dialog (to cover bug 18411): `For now, please use the mouse to activate the 
password field. This problem will be fixed soon.' It would be a bit cheesy, but 
it would work.
Linux only: pp keyword
If not fixed for M14: release note
Keywords: pp, relnote
*** Bug 24329 has been marked as a duplicate of this bug. ***
joki: can we at least check in the work around to get this somehow working...? 
can you review/checkin that please. thx.
I've seen a number of work-around hack-fixes described in the bug.  Can we pick
one, and get this off the PDT+ beta1 radar?  We are really trying to get beta1
shut down RSN.
Thanks ;-)

*** Bug 29996 has been marked as a duplicate of this bug. ***
*** Bug 29964 has been marked as a duplicate of this bug. ***
*** Bug 30073 has been marked as a duplicate of this bug. ***
*** Bug 30073 has been marked as a duplicate of this bug. ***
Checked in hack-around of setting visibility: collapse instead of display: none

Fixes the PDT+ness of this bug.
Whiteboard: [PDT+], fix date unknown. possible fix now risky. looking for workaround. → fix date unknown. possible fix now risky. looking for workaround.
PDT-
Whiteboard: fix date unknown. possible fix now risky. looking for workaround. → [PDT-] fix date unknown. possible fix now risky. looking for workaround.
I'm not saying that your hack-around was the wrong thing to do under the 
circumstances, but I'd like to point out a downside to it.  With your change, 
all dialogs are now comingup noticeably bigger.  Compare the cookie nag box for 
example with and without your change.  It was much cleaner before.

It's unfortunate that the only platform affected by this bug was linux, but the 
fix has made the dialogs objectionably bigger on all platforms.  Is there a way 
that you could localize your fix to unix-only?  I realize that there's no 
"#ifdef unix" in javascript, but with an appropriate callback from javascript to 
c-code, you could get the platform indication from a c module passed back to 
javascript.
No longer blocks: 24329
*** Bug 30182 has been marked as a duplicate of this bug. ***
Changing status from 'Can not enter password into basic authentication dialog'.  
We need to work more on the base issues here which I see as
1. Why did this only not work on Linux even though it should be xp code?
2. Why didn't the event system work around this?

Reminder to myself to fix commonDialog.js code when other issues resolved.
Status: NEW → ASSIGNED
Summary: Can not enter password into basic authentication dialog → Objects set to display:none still steal events
Whiteboard: [PDT-] fix date unknown. possible fix now risky. looking for workaround. → [PDT-]
Target Milestone: M14 → M15
*** Bug 30383 has been marked as a duplicate of this bug. ***
*** Bug 30415 has been marked as a duplicate of this bug. ***
*** Bug 30392 has been marked as a duplicate of this bug. ***
*** Bug 31182 has been marked as a duplicate of this bug. ***
*** Bug 31092 has been marked as a duplicate of this bug. ***
*** Bug 32068 has been marked as a duplicate of this bug. ***
*** Bug 31429 has been marked as a duplicate of this bug. ***
*** Bug 32107 has been marked as a duplicate of this bug. ***
*** Bug 32179 has been marked as a duplicate of this bug. ***
removing the relnote keyword, since a workaround is in place
Keywords: relnote
*** Bug 33408 has been marked as a duplicate of this bug. ***
Mass-moving bugs out of M15 that I won't get to.  Will refit individual 
milestones after moving them.
Target Milestone: M15 → M16
spam, open xptoolkit qa contact moving over to jrgm
QA Contact: paulmac → jrgm
*** Bug 35588 has been marked as a duplicate of this bug. ***
*** Bug 35728 has been marked as a duplicate of this bug. ***
*** Bug 32225 has been marked as a duplicate of this bug. ***
Keywords: beta2
Keywords: nsbeta2
When I undo the workaround to this bug, I see a bunch of GDK assertions paired
with NS assertions when I try to click in the password dialog:

Gdk-CRITICAL **: file gdkwindow.c: line 1707 (gdk_window_get_parent): assertion
`window != NULL' failed.
###!!! ASSERTION: GetShellWidget() fails: 'mIMEShellWidget', file nsWidget.cpp,
line 3273
###!!! Break: at file nsWidget.cpp, line 3273

Do these elements (inputs) have their own widgets?  Typically elements with
display: none shouldn't be represented in the frame tree, etc.  Could the
widgets not be destroyed when 'display: none' is set?  Or could there be an
expectation that there is a widget when there really isn't, since display is
none?    cc:ing pavlov
Keywords: beta2
Removing PDT- designation so this can get further consideration.  Symptom of 
this bug is serious (cannot enter password in browser-generated form on linux) 
although the summary line has been rewritten and no longer indicates this.
Whiteboard: [PDT-]
*** Bug 38379 has been marked as a duplicate of this bug. ***
Adding back "(password,auth)" to Summary, just to make it easier for people
to locate this oft-reported bug.
Summary: Objects set to display:none still steal events → Objects set to display:none still steal events (password,auth)
*** Bug 38650 has been marked as a duplicate of this bug. ***
[Updating URL to one which actually gives you a basic auth dialog. Removing beta1 
keyword, since beta1 is long gone. And having another go at resummarizing, to try 
and stem the tide of duplicates.]
Keywords: beta1
Summary: Objects set to display:none still steal events (password,auth) → Can't enter authentication password (Objects set to display:none still steal events)
*** Bug 34388 has been marked as a duplicate of this bug. ***
*** Bug 38045 has been marked as a duplicate of this bug. ***
*** Bug 39077 has been marked as a duplicate of this bug. ***
*** Bug 34120 has been marked as a duplicate of this bug. ***
Matthew Thomas - this URL now 404s. Can you replace it?

Gerv
As submitted in email by Kurt Huwig <kurt@iku-netz.de> (although appending 
directly to the bug report), another URL that requires basic auth is 
http://www.huwig.de/docs/
Putting on [nsbeta2+] radar for beta2 fix. 
Whiteboard: [nsbeta2+]
I tried 20000520 on Linux and cannot get past our proxy at all :-( Mozilla asks
for a password, but gets a "access denied" from Squid.

Also, all textfields don't show their content until you click into them.
The textfields not showing their content until clicked on is a dup of bug 37650.
... And not being able to get past the proxy is because the preferences aren't 
remembering the port number of your proxy server. (Anyone know if there's a bug 
on that?) As a workaround, enter `proxyname:portnumber' in the hostname field in 
prefs, instead of entering the port number in its own field.
*** Bug 40041 has been marked as a duplicate of this bug. ***
I've found I'm able to enter a password under Linux if I first disable gfx
scrollbars in the debug pref panel. That causes a crash once you attempt any
subsequent menu access. I'm using Build 2000052109.

I wish I could provide a fix, but it's beyond my programming skills. Hope it
will at least help in tracking it down.
*SPAM* - adding mostfreq keyword to bugs with loads of dupes. Please aid this 
effort by adding this keyword to any bugs with more than 15 DUPEs.
Keywords: mostfreq
Matthew, the bug for the proxy port problem is bug 39779, which was recently
marked verified fixed...
Go to the URL: http://slack.yak.net/member/cgi-bin/main
using the 20000522 build on Linux. You will be unable to tab or click in the
password field on the "Password" dialog. When you click in the Password field on
the Password dialog, the following is output several times in the terminal
window where mozilla was started from:

Gdk-CRITICAL **: file gdkwindow.c: line 1707 (gdk_window_get_parent): assertion
`window != NULL' failed.
*** Bug 40237 has been marked as a duplicate of this bug. ***
I am also seeing the same thing as Matt when clicking in the password field:

Gdk-CRITICAL **: file gdkwindow.c: line 1707 (gdk_window_get_parent): assertion
`window != NULL' failed.

linux-i686 redhat6.2 with build 2000052220
*** Bug 40788 has been marked as a duplicate of this bug. ***
Assertion:
-- gdkwindow.c
GdkWindow* gdk_window_get_parent (GdkWindow *window)
{
g_return_val_if_fail (window != NULL, NULL);
return ((GdkWindowPrivate*) window)->parent;
}
-- gdkwindow.c

This assertion failure indicates that NULL was passed as a window to
gdk_window_parent.  (This might appear to be obvious).  If someone has a
debugging version of gdk++ libs, and can put a gdb break in
gdk_window_get_parent and then trace back the stack, that would be of immense help!

My assertion would be that passing a NULL to the gdk libs has a different effect
(hopefully not a side-effect - I can't solve that!) in the Mozilla middle-layer
libs than passing NULL to the other libraries (Windows, Mac, etc).
Unfortunately, without a stack trace (and I am resource restricted at home for
the next month from doing this) it is very difficult for me to figure out where
the issue arises.  If someone else could email me with one or post it here, I
would be exceptionally grateful, as this bug is a real show-stopper for, well,
all the people with dups here. :-)

(note, the only stack trace that is relevent to this is when opening the
password-box and (GdkWindow*) window is null; you can tell gdb and/or ddd to
check for this for you, since there are multiple calls where the assertion fails.)
*** Bug 41129 has been marked as a duplicate of this bug. ***
*** Bug 41196 has been marked as a duplicate of this bug. ***
ust for note, if you're looking through the code, you'll notice that the
problem is in ./widget/src/gtk ; the relevent function is as follows:
(nsWidget.cpp)
3267: void
3268: nsWidget::IMESetFocusWidget()
3269: {
3270:  if (!mIMEShellWidget) {
3271:    mIMEShellWidget = GetShellWidget((GdkWindow*)
3272:           GetNativeData(NS_NATIVE_WINDOW));
3273:    NS_ASSERTION(mIMEShellWidget, "GetShellWidget() fails");
3274:    if (!mIMEShellWidget) return;
3274:  }
...
3300: }

Now, NS_ASSERTION fails, in this context, only when attempting to focus on
the password window.  This is only an issue in Linux.  Conclusively, since
IMESetFocusWidget is what is being called, and since line 3373, which is
in IMESetFocusWidget is where the assertion is blowing up, I'm thinking
this is a good place as any to start. :-)

Now debugging *may* be tricky.  For one, this thing may be called hundreds
of times, and I hope not, but it is possible.  There are some nice
workarounds that we can go through if that is the case (ie. selective
debugging criteria, or just start debugging at a time relevent to the
particular problem.)

The obvious (and probably even correct) assertion herein is that the issue
lies in the
static nsWidget* nsWidget::GetShellWidget(GdkWindow*)
void * nsWidget::GetNativeData(PRUint32 )
function calls on lines 3271-2, if I interpret that correctly (ie. the
class:: is correct; it may be that GetShellWidget is nsBaseWidget, I
haven't checked that yet).

I cannot tell what is being returned from these functions, as of right
now, and am unsure exactly what they should be returning.  Therein lies
the necessity to debug.

Note: There is a GetShellWidget2 in nsWidget.h but never declared in
nsWidget.cpp.  It is possible someone had this in mind before and didn't
get around to fixing/implementing it.  I can't tell.

Did someone check in a fix?  I tried this a few days ago and the bug was still
there, but on the 2000060308 build i can enter a password and then it would
segfault.  On a cvs build from 2000060323 i can enter a password and login fine.
 Hopefully this is fixed.  Would some of you try this also on the latest nightly.
I am running 2000060320 on Linux.  This bug appears to have been fixed.  I'm
going to keep this as an open bug so we can get more testing and confirmations. 
Marking WORKSFORME on redhat linux 6.2 i686 build 2000060409.  Several others in
#mozillazine have confirmed that this is working also.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago24 years ago
Resolution: --- → WORKSFORME
Is this fixed because of a workaround or a real fix?  (See last comments from
2000-03-02.)  If a workaround, should it be reopened?
I dont' think it was a workaround.  I tried this like 3 days ago and the bug was
still there.  But it seems that somehow it is working again.  There are some
other bugs appearing now (see 41517) that weren't seen because this wasn't working.
Actually, Ben unintentionally worked around this bug with a checkin for 
commonDialog.(xul|js) at ~6pm Jun 02 Pacific. 

I'm (sigh) reopening this bug because there is still a lurking event problem
that needs to be addressed. 

However, since this the current code works well on linux (in my tests and 
other's comments), then I'm removing the [nsbeta2+] from this bug for PDT
reconsideration. Unless there is another known bit of functionality that is 
hit by this bug, then this can wait until after PR2.

(Side note: the fact that there is now a crash when cancelling out of a 
basic auth dialog, or when logging in, is entirely orthogonal to the fact 
that you can now type into the dialog -- see bug 41404, bug 41467 -- just a 
quirk of fate that that code landed at about the same time as Ben's).
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Whiteboard: [nsbeta2+]
Oops, wasn't aware that this was a workaround.  I'm sorry.  Thanks for
enlightening us John.

Should the subject of this bug be rephrased to something more meaningful now
that we are able to enter a password?
Could the fix for bug #39806 also have helped?
I can't say that that checkin didn't help, but if I restore
commonDialog.xul and commonDialog.js from prior to Ben's checkin with
today's build, then this bug is fully back in place.

At any rate, I have a simplified .xul file, with embedded js, that
shows the problem, and can be loaded directly into the browser
(cutting any dependency on necko and dialog machinery). I'll attach
that file, as well as copies of commonDialog.(xul|js) that also show
the original problem.
Per jrgm's comments, sounds like a [nsbeta2-].  Please send back in if disagree.
Whiteboard: [nsbeta2-]
M16 has been out for a while now, these bugs target milestones need to be 
updated.
This bug needs re-evaluation in the new world of Ender-lite text widgets.
Status: REOPENED → ASSIGNED
Updating Milestone to M18.
Target Milestone: M16 → M18
(Hmm, first: looking at my attachment (attach_id=9650), I have no clue what 
that is supposed to be; ignore it).

Okay, I tried attach_id=9647 with today's build, and also put the old 
commonDialog.(xul|js) back into the chrome. Testing on mac/linux/win32, I 
can set the focus in the second visible textfield (the password) in either
the original problematic basic auth dialog, or in my simple testcase. 

Looks like this one is worksforme (or fixed by ender-lite changes), unless 
joki or someone knows something else about this bug that needs to be chased 
down.
Thanks for qa'ing this, John!  Tom also felt that this problem is resolved
before he left for sabbatical in the bug meeting that Chris Saari and I had with
him.  Marking worksforme.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago24 years ago
Resolution: --- → WORKSFORME
worksforme. I can enter a username password and move between using either tab or
mouse. Tested on linux 2000-09-26-09-MN6 mozilla build
Status: RESOLVED → VERIFIED
Mass removing self from CC list.
Now I feel sumb because I have to add back. Sorry for the spam.
You need to log in before you can comment on or make changes to this bug.