Closed Bug 15463 Opened 24 years ago Closed 24 years ago

[DOGFOOD] [PP] linux only Password dialog displays characters !, -, # when typing in password that includes these characters

Categories

(Core :: DOM: Editor, defect, P1)

Product:
Core
Component:
DOM: Editor
Platform:
x86
Linux
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: esther, Assigned: akkzilla)

References

Details

(Whiteboard: [PDT-]Have patch, looking for testers/reviewers)

Attachments

(2 files)

Patch: enables XIM, adds keycodes for shifted keys and some others
1.49 KB, patch
Details | Diff | Splinter Review
New patch, adds a few new characters
1.66 KB, patch
Details | Diff | Splinter Review 
Using 19991001 build on linux on my system and Fenella's, the password dialog
for a Mail test account "Ne!sc-pe", displays the ! and - when typing in the
password and then doesn't accept the password.  Can't get my mail for any
account that includes these two characters, haven't checked the other
characters.

1. Launch Messenger (with a test profile that includes the password "Ne!sc-pe")
2. Select Get Msg to bring up the password dialog (don't have remember password
on)
3. Type in the password Ne!sc-pe

Result:  The ! and - show up when it should show a *  to hide the password
Expected: "*" for each character in the password and the password to be
accepted.
Esther - does this happen if you go to:  ftp://username@raquelita where you also
get a password dlg?
is this ender?
OS: other → Linux
Hardware: HP → PC
This should be on M10 list.
Priority: P3 → P1
I can't even get the password dialog when I type in ftp://esther@raquelita.  I
was able to get it with 4.6 on that same linux system during this time.
Changing to P1
paulmac is going to try out some other dialogs which require name/password to
see if the problem is there also.
Target Milestone: M10
Putting on M10 list.
Is this linux only? As far as typing that is all ender nothing I can do about
it. I don't know if ftp auth. is in the product so I have no idea if you should
be getting a dialog or not.
Yes, this is Linux only.  Win32 and Mac M10 builds are fine.  David - if you
want to see this problem, can you check with Esther?
this occurs when setting your single-signon password also, those keys are
displayed and also ignored
Product: MailNews → Browser
Assignee: davidm → buster
Component: Security → Editor
reassign to editor since it seems to be a problem in the editor when used in
password editfields. I wouldn't worry about not getting the ftp dialog but you
can file a bug against necko if you want.
Esther - is this in the M10 builds only?  Does this occur in the M11 trunk
builds?
adding akkana@netscape.com to cc list
I just tried this using the tip from 10/4 am, and it worked (only stars were
echoed, and the password went through correctly).  So apparently whatever was
wrong has been fixed since the tree reopened.

Key events were badly screwed up around the end of M10, and there were a bunch
of fixes to XUL and the various key handlers which went in about that time; I
was under the impression that the fixes went into M10 (since that was the whole
point of doing them), but if that didn't happen, that could be the problem.
Adding saari to cc list hoping he knows what went into M10.
Per Akkana:
"The last checkin to nsGtkEventHandler.cpp was on 9/28 at 17:34.
That was tracking some changes saari made to key events, which had gotten broken
a week earlier.
I was under the impression that was going in to M10, but if it didn't make it,
that could be it."
My understanding is that those checkins made it into M10, so my best guess is
that the problem is elsewhere and got introduced after (or just before) the
branch was cut.
All of my changes made it into M10 as far as I know. You may want to check the
Gfx text widget as that has been getting worked on as well
Target Milestone: M10 → M11
there is no easy way to get this into m10.  we will have to release note.
Blocks: 15693
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
since this is fixed on the tip, as akkana indicates, I'm going to mark it fixed.
sujay, lisa, can you verify?
Ok, we'll verify.
Status: RESOLVED → VERIFIED
Peter told me he tried it on M11 yesterday 10/05 and this was OK and on M11
today 10/06, also OK.  This will be verified for M11 only.  M10 will go out with
this bug.
I verified this on 10-14-09-M11 build on Linux 6.0.
It's working fine. too - all the password display * sign.
Status: VERIFIED → REOPENED
I used 10-15-08-M11 build/Linux6.0 and re-migrate again:

I got the same problem again, I don't know whether this is migration problem or
not (the previous message:I didn't re-migration at that time...)

Problem is a following:
Password dialog for a Mail test account "Ne!sc-pe", displays the ! and - when
typing in the password and then doesn't accept the password.  Can't get my mail
for any account that includes these two characters.

So, I reopen this bug now.
Status: REOPENED → ASSIGNED
sorry, I don't know what "re-migration" means.  So at some point you loaded M11
daily build and the problem was gone, then you loaded the next day's build and
it reappeared?
Assignee: buster → akkana
Status: ASSIGNED → NEW
seems related to other key/password field problems.  assigning to akkana, cc'ing
pav.
Status: NEW → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: FIXED → DUPLICATE
the XIM doesn't work.  I have disabled it.  marking this bug as a duplicate of
the XIM code doesn't work bug.

*** This bug has been marked as a duplicate of 16670 ***
Status: RESOLVED → VERIFIED
Marking as duplicate.  I've made notes and added myself to the cc: list of the
other bug.
In nsGtkEventHandler.cpp's XIM code, I made an assumption that keycode value of
a keyevent
remains 0(zero) when the keyevent came through XIM, but it seems that it is not
always
true. Actually, nsPlatformToDOMKeyCode() returns 0 for a '!', and due to this,
my XIM code
processes the event as XIM event, and commit '!'. To solve the problem, I'm
seeking for
correct way to know which is the event from XIM, and which is not. However, I
also like to
know whether the current nsPlatformToDOMKeyCode()'s behaviour is right or not
with the
'!' event.
Status: VERIFIED → REOPENED
Resolution: DUPLICATE → ---
Reopening this one too. Seems related to 16645, possibly a dup. Leaving this
to Akkana to decide.
Severity: blocker → critical
lowering severity since there is a workaround checked in already.
Summary: [PP] linux only Password dialog displays characters ! and - when typing in password that includes these characters → [PP] linux only Password dialog displays characters !, -, # when typing in password that includes these characters
*** Bug 16645 has been marked as a duplicate of this bug. ***
*** Bug 16670 has been marked as a duplicate of this bug. ***
Netscape doesn't have virtual key codes (defined in widget/public/nsGUIEvent.h)
for any of these characters.

Who owns the list of NS_VK key codes?  Do we have authorization to add whatever
new codes we need?  Does it matter which key codes are contiguous (i.e. where in
the list a new key code is added)?
akkana and I talked about her questions above; I think she knows how to proceed
now (or at least where to pursue).  In short, the "!" isn't a virtual key since
it's not a physical key (on my keyboard it's shared with "1" which is definied).
Status: REOPENED → ASSIGNED
Here's the story as of now:
gdk has key syms of GDK_colon, GDK_exclam, GDK_numbersign, and GDK_minus; it
doesn't tell us what the unshifted key was.
Netscape doesn't have key codes for any of these, we're (presumably) supposed to
use the keycode for the unshifted key.

I have a patch to map the keys to what my personal keyboard has as their
unshifted equivalents.  But for people with different keyboard layouts, don't we
need a different solution?

I will attach the patch, which turns XIM back on and adds the keycodes for those
keys.  People on the cc list for this bug should pull the patch, build, test and
review.  I want a review from Pavlov and from someone involved with XIM before I
check anything in.  If you notice any other missing key syms (I'm sure there are
some), please let me know or add a comment here.  If other missing symbols turn
up after we've re-enabled XIM, this type of solution should enable us to fix
this sort of problem quickly without having to disable XIM.

Incidentally, nobody has marked this bug as dogfood to get it approved by the
PDT team; someone should probably do that since we're only supposed to be
working on PDT approved bugs.

At least this solution will get XIM running again on standard layouts.
Summary: [PP] linux only Password dialog displays characters !, -, # when typing in password that includes these characters → [DOGFOOD] [PP] linux only Password dialog displays characters !, -, # when typing in password that includes these characters
I didn't mark this dogfood before because it was resolved as a dup.  I'll mark
it dogfood now.
Whiteboard: Have patch, looking for testers/reviewers
I've found a couple more characters that need defining (some of which, like
apostrophe, don't have NS keycodes, and I've filed bug 17008 on that as a
reminder).  Attaching a new patch.  (These may keep coming as I find more keys
that don't work with XIM, but they're functionally similar; if you're testing an
early patch, don't feel like you have to pick up a later one for the testing to
be valid, just keep testing!)
This is working fine for today's build 10-21-08-M11 Linux 6.0
The Passwords displayed "*" now.
It's working in the release builds because XIM has been disabled.  The goal is
to get XIM turned back on and still have it work.  Sorry, I know that makes it
harder to test since you won't have seen the failure mode ...
Whiteboard: Have patch, looking for testers/reviewers → [PDT-]Have patch, looking for testers/reviewers
This is really beta, not PDT quality... but if you have the patch... lets land
it.
Thanks.
this is PDT+.  the chars don't actually get submitted with your password.
Yes, pavlov is right.  With this bug, you cannot login to mail on Linux if your
password contains any of the characters mentioned in this bug.  I'll send this
to pdt@netscape.com to review.
As I said on behalf of PDT, since you have the patch, go ahead and check it in.
I can understand your argument for a PDT+, but since you have the fix, this
should be a non-issue.  IF your fix is not complete, and you want it elevated,
then just delete the PDT- and I'll get it approved at the review meeting (and in
the mean time, you should just treat it as +).
Thanks,
Jim
I haven't heard yet from anyone saying that they've reviewed the code or tested
it.  I'm not comfortable checking this in until several people besides myself
have tested it.
Akkana, sorry I wasn't even on the Cc list so I didn't know that you wanted a
code review and some testing. Is it OK if I just test the XIM aspects, assuming
that you and others have tested the regular ASCII chars like '!' in password
fields?
You don't have to test password fields (though I hope someone will!) but do test
those characters when you're testing basic typing.  They were broken in IM in
the editor and normal text fields as well as password fields.

Shouldn't someone at Sun be cc'ed here too?  I'm a little puzzled by how
everyone thinks this is a critical bug yet it's so hard to get people to look at
the changes.  Adding ftang since I know he ought to be on the list -- Frank,
could you also look at this and review it?
I tested with Akkana's patch, and characters like '!' could be typed in
password fields, the URL field and the editor. Also, XIM (X input method) was
switched on. I also tried typing other chars. So I think the fix is good.

I reviewed the code too, and although it may seem strange to map e.g. NS_VK_1
to GDK_exclam, that is the current spec according to Tague. The current key
code spec meshes well with Windows and Mac, but not so well with X. Tague is
currently looking into this. We should track this issue, but for now, Akkana's
patch should be checked in.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
Fix checked in.  I'm not happy about hardcoding the mapping of shifted
characters to unshifted equivalents, though; I hope someone in I18n is thinking
about this issue!
akkana - so the XIM code is turned back on, right?  If so and with your patch,
we'll verify this in the next build or so for the mail case we specified in this
bug report.
Lisa: yes, as of tomorrow's build the XIM code should be turned back on and you
can verify the case in the bug report (and any other typing tests you normally
do, to make sure that this didn't break anything else).
Blocks: 17432
Status: RESOLVED → VERIFIED
Using 19991028 build on linux this is fixed for the mail password.  Verified
No longer blocks: 17432
You need to log in before you can comment on or make changes to this bug.