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)
Tracking
()
VERIFIED
WORKSFORME
M18
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
Comment 1•24 years ago
|
||
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?
Reporter | ||
Comment 2•24 years ago
|
||
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.
Comment 3•24 years ago
|
||
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
Reporter | ||
Comment 4•24 years ago
|
||
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.
Comment 5•24 years ago
|
||
Okay, I can reproduce this in a debug build of the tip from around 6PM.
Comment 6•24 years ago
|
||
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
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)
Comment 9•24 years ago
|
||
FYI, FTP authenticaion works just fine I'll take a look. Where does this XUL live?
Status: NEW → ASSIGNED
Comment 10•24 years ago
|
||
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.
Comment 11•24 years ago
|
||
*** Bug 28109 has been marked as a duplicate of this bug. ***
Comment 12•24 years ago
|
||
*** Bug 24370 has been marked as a duplicate of this bug. ***
Comment 13•24 years ago
|
||
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
Assignee | ||
Comment 14•24 years ago
|
||
Hmm. I'm not entirely sure where to go with this either. I'll need Linux debugging help.
Comment 15•24 years ago
|
||
looks like bug 24318-- see comments there as well. and decide which one is the dup...
Comment 16•24 years ago
|
||
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!).
Comment 17•24 years ago
|
||
One more data point, for what it's worth. The checkbox also doesn't work -- there is no way you can check it.
Comment 18•24 years ago
|
||
I just realized that the checkbox problem is already covered in bug 28100.
Comment 19•24 years ago
|
||
*** Bug 24318 has been marked as a duplicate of this bug. ***
Assignee | ||
Updated•24 years ago
|
Whiteboard: [PDT+] → [PDT+], fix date unknown. possible fix now risky. looking for workaround.
Comment 20•24 years ago
|
||
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
Comment 21•24 years ago
|
||
Added self to CC list, still getting this bug on the latest Linux build.
Comment 22•24 years ago
|
||
spam: added self to cc list as this would affect my area.
Comment 23•24 years ago
|
||
*** Bug 28566 has been marked as a duplicate of this bug. ***
Comment 24•24 years ago
|
||
per PDT, who else can help with this bug?
Comment 25•24 years ago
|
||
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?
Comment 26•24 years ago
|
||
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 :-(
Comment 27•24 years ago
|
||
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.
Comment 28•24 years ago
|
||
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.
Assignee | ||
Comment 29•24 years ago
|
||
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.
Comment 30•24 years ago
|
||
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.
Comment 31•24 years ago
|
||
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.
Comment 32•24 years ago
|
||
Linux only: pp keyword If not fixed for M14: release note
Comment 33•24 years ago
|
||
*** Bug 24329 has been marked as a duplicate of this bug. ***
Comment 34•24 years ago
|
||
joki: can we at least check in the work around to get this somehow working...? can you review/checkin that please. thx.
Comment 35•24 years ago
|
||
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 ;-)
Comment 36•24 years ago
|
||
*** Bug 29996 has been marked as a duplicate of this bug. ***
Comment 37•24 years ago
|
||
*** Bug 29964 has been marked as a duplicate of this bug. ***
Comment 38•24 years ago
|
||
*** Bug 30073 has been marked as a duplicate of this bug. ***
Comment 39•24 years ago
|
||
*** Bug 30073 has been marked as a duplicate of this bug. ***
Comment 40•24 years ago
|
||
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.
Comment 41•24 years ago
|
||
PDT-
Whiteboard: fix date unknown. possible fix now risky. looking for workaround. → [PDT-] fix date unknown. possible fix now risky. looking for workaround.
Comment 42•24 years ago
|
||
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.
Comment 43•24 years ago
|
||
*** Bug 30182 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 44•24 years ago
|
||
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
Comment 45•24 years ago
|
||
*** Bug 30383 has been marked as a duplicate of this bug. ***
Comment 46•24 years ago
|
||
*** Bug 30415 has been marked as a duplicate of this bug. ***
Comment 47•24 years ago
|
||
*** Bug 30392 has been marked as a duplicate of this bug. ***
Comment 48•24 years ago
|
||
*** Bug 31182 has been marked as a duplicate of this bug. ***
Comment 49•24 years ago
|
||
*** Bug 31092 has been marked as a duplicate of this bug. ***
Comment 50•24 years ago
|
||
*** Bug 32068 has been marked as a duplicate of this bug. ***
Comment 51•24 years ago
|
||
*** Bug 31429 has been marked as a duplicate of this bug. ***
Comment 52•24 years ago
|
||
*** Bug 32107 has been marked as a duplicate of this bug. ***
Comment 53•24 years ago
|
||
*** Bug 32179 has been marked as a duplicate of this bug. ***
Comment 54•24 years ago
|
||
removing the relnote keyword, since a workaround is in place
Keywords: relnote
Comment 55•24 years ago
|
||
*** Bug 33408 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 56•24 years ago
|
||
Mass-moving bugs out of M15 that I won't get to. Will refit individual milestones after moving them.
Target Milestone: M15 → M16
Comment 57•24 years ago
|
||
spam, open xptoolkit qa contact moving over to jrgm
QA Contact: paulmac → jrgm
Comment 58•24 years ago
|
||
*** Bug 35588 has been marked as a duplicate of this bug. ***
Comment 59•24 years ago
|
||
*** Bug 35728 has been marked as a duplicate of this bug. ***
Comment 60•24 years ago
|
||
*** Bug 32225 has been marked as a duplicate of this bug. ***
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
Comment 62•24 years ago
|
||
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-]
Comment 63•24 years ago
|
||
*** Bug 38379 has been marked as a duplicate of this bug. ***
Comment 64•24 years ago
|
||
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)
Comment 65•24 years ago
|
||
*** Bug 38650 has been marked as a duplicate of this bug. ***
Comment 66•24 years ago
|
||
[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)
Comment 67•24 years ago
|
||
*** Bug 34388 has been marked as a duplicate of this bug. ***
Comment 68•24 years ago
|
||
*** Bug 38045 has been marked as a duplicate of this bug. ***
Comment 69•24 years ago
|
||
*** Bug 39077 has been marked as a duplicate of this bug. ***
Comment 70•24 years ago
|
||
*** Bug 34120 has been marked as a duplicate of this bug. ***
Comment 71•24 years ago
|
||
Matthew Thomas - this URL now 404s. Can you replace it? Gerv
Comment 72•24 years ago
|
||
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/
Updated•24 years ago
|
Comment 74•24 years ago
|
||
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.
Comment 75•24 years ago
|
||
The textfields not showing their content until clicked on is a dup of bug 37650.
Comment 76•24 years ago
|
||
... 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.
Comment 77•24 years ago
|
||
*** Bug 40041 has been marked as a duplicate of this bug. ***
Comment 78•24 years ago
|
||
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.
Comment 79•24 years ago
|
||
*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
Comment 80•24 years ago
|
||
Matthew, the bug for the proxy port problem is bug 39779, which was recently marked verified fixed...
Comment 81•24 years ago
|
||
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.
Comment 82•24 years ago
|
||
*** Bug 40237 has been marked as a duplicate of this bug. ***
Comment 83•24 years ago
|
||
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
Comment 84•24 years ago
|
||
*** Bug 40788 has been marked as a duplicate of this bug. ***
Comment 85•24 years ago
|
||
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.)
Comment 86•24 years ago
|
||
*** Bug 41129 has been marked as a duplicate of this bug. ***
Comment 87•24 years ago
|
||
*** Bug 41196 has been marked as a duplicate of this bug. ***
Comment 88•24 years ago
|
||
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.
Comment 89•24 years ago
|
||
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.
Comment 90•24 years ago
|
||
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.
Comment 91•24 years ago
|
||
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 ago → 24 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?
Comment 93•24 years ago
|
||
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.
Comment 94•24 years ago
|
||
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+]
Comment 95•24 years ago
|
||
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?
Comment 96•24 years ago
|
||
Could the fix for bug #39806 also have helped?
Comment 97•24 years ago
|
||
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.
Comment 98•24 years ago
|
||
Comment 99•24 years ago
|
||
Comment 100•24 years ago
|
||
Comment 101•24 years ago
|
||
Comment 102•24 years ago
|
||
Per jrgm's comments, sounds like a [nsbeta2-]. Please send back in if disagree.
Whiteboard: [nsbeta2-]
Comment 103•24 years ago
|
||
M16 has been out for a while now, these bugs target milestones need to be updated.
Assignee | ||
Comment 104•24 years ago
|
||
This bug needs re-evaluation in the new world of Ender-lite text widgets.
Status: REOPENED → ASSIGNED
Comment 106•24 years ago
|
||
(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.
Comment 107•24 years ago
|
||
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 ago → 24 years ago
Resolution: --- → WORKSFORME
Comment 108•24 years ago
|
||
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
Comment 109•22 years ago
|
||
Mass removing self from CC list.
Comment 110•22 years ago
|
||
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.
Description
•