Closed
Bug 57946
Opened 24 years ago
Closed 24 years ago
Receive "invalid user name" error when committing bugs
Categories
(Core :: DOM: Core & HTML, defect, P3)
Tracking
()
VERIFIED
WORKSFORME
People
(Reporter: jaimejr, Assigned: cata)
Details
(Whiteboard: [rtm-])
Attachments
(2 files)
Build ID: Gecko/20001023 Netscape6/6.0 Reproducible: Always 1. Launch N6 2. Enter Bugzilla into URL bar 3. Choose to Enter A New Bug 4. Complete the bug report and commit Results: "The name jaimejr@netscape.com is not a valid username. Either you misspelled it, or the person has not registered for a Bugzilla account." Submitting the exact same report in 4.x works with no erorr. The username is correct in both instances, and is added by default. I noticed the same behavior, when trying to add comments to bug (i.e. Valid usernames that were already part of the report, were being kicked back as invalid).
Reporter | ||
Comment 1•24 years ago
|
||
Nominating for RTM and dogfood. Is anyone else having this problem??? Currently have to enter bug reports in 4.x.
Comment 2•24 years ago
|
||
Jaime Rodriguez, Jr. I had no problems filing new bugs in Bugzilla with 102504 Mozilla trunk win32 build on NT4. I'm assuming that you're using a branch commercial build?
Comment 3•24 years ago
|
||
Asa, can you tell if this is a real problem that might be widespread? It would be really terrible if this were to affect people's ability to do online purchasing...
Whiteboard: [need info]
Comment 4•24 years ago
|
||
Asking around some.
Comment 5•24 years ago
|
||
I asked people who reported possibly similar incidents to comment here. Unfortunately the current Netscape Confidential setting prevents them from doing so.
Comment 6•24 years ago
|
||
Can I ask WHY this is marked netscape confidential?
Comment 7•24 years ago
|
||
I don't particularly care why. Without an explanation when the bug was marked confidential I don't feel particularly obliged to leave it as such. opening.
Group: netscapeconfidential?
Reporter | ||
Comment 8•24 years ago
|
||
Selmer- "Asa, can you tell if this is a real problem that might be widespread? It would be really terrible if this were to affect people's ability to do online purchasing..." huh??? This is a bug summary states "Recieve "invalid user name" error when committing bugs". I don't see how this refers to online purchasing??? I'm confused. ASA - Yes, I was using the branch build.
Comment 9•24 years ago
|
||
Jaime - selmer was probably asking if this was not only in bugzilla, but also on other sites. win8 newest trunk, I get no such error. Could be a bugzilla issue. cc: lchiang: have you had any reports about this?
Comment 10•24 years ago
|
||
Over to Form Submission.
Assignee: asa → rods
Component: Browser-General → Form Submission
QA Contact: doronr → vladimire
Comment 11•24 years ago
|
||
I've seen no other reports of this. We did have one form submission bug, but I think it was fixed. valdimire - pls confirm. jaime - can you try again with the latest build.
Reporter | ||
Comment 12•24 years ago
|
||
Yes, I can try again with the latest build. It may take me a while because I am working from LA on a landline today.
Reporter | ||
Comment 14•24 years ago
|
||
Reporter | ||
Comment 15•24 years ago
|
||
Lisa - Tested this on today's build (20001027 Netscape6/6.0), and got yet another error (see attachment). Note: I personally have had to use 4.x to edit all bugs in both Bugscape and Bugzilla.
Comment 16•24 years ago
|
||
Jaime, do you have any funny characters in your bugzilla password (non alphanumerics)? (Don't post your password, but if you have just one or two it might be worth nothing which ones). Also, can you check View->Character Coding to make sure that Western (iso-8859-1) is selected? This might be related to another bug we saw where characters like . ( and ) were encoded differently for other charsets and confusing server-sides scripts. If this is the problem, I'd say it was pretty rare.
Comment 17•24 years ago
|
||
Hm, it doesn't seem to matter if your password has funny characters or not, just make sure that the Character Coding is set to Western. I was able to reproduce this bug trying to add comments to this bug report with my character coding set to Armenian. Guessing this is a dup of bug 57720.
Reporter | ||
Comment 18•24 years ago
|
||
That's it! Excellent job Pollmann!!! My browser was set to Armenian. Now, here's the funny thing??? I didn't change this setting, and I'm on a US OS. Adding ftang and erik to cc: list. FTang - Any ideas on how this occurred?
Comment 19•24 years ago
|
||
Cata, this bug has been nominated for RTM. Somehow, some people end up having their charset set to Armenian. One theory is that it is due to "armscii" being near the beginning of the alphabetical list. Please also see the related bug 57720. How could this happen? It would be bad if this happened to any of our end users.
Comment 20•24 years ago
|
||
Rod is on vacation so if one of you in i18n land wants to investigate, please feel free to reassign this over there! :)
Assignee | ||
Comment 21•24 years ago
|
||
I'm reassigning this to myself, as I am more familiar with this code.
Status: NEW → ASSIGNED
Comment 23•24 years ago
|
||
Adding Steve to the CC of this bug because I think he just got hit by it too (based on an email). Jamie, Steve - do either of you remember doing anything unusual immediately prior to the change in behaviour? Did you just upgrade to one of the latest nightlies and use an existing profile? It seems to require quite a bit of effort to change the charset to Armenian when I tried it - several levels deep in the View menu, or scrolling up quite a bit in the Preferences->Navigator->Languages panel. Did either of you change an specific pref immediately before this started happening?
Comment 24•24 years ago
|
||
Yes, I hit this. I didn't intentionally change my charset, but I was using the prefs to do actions related to other bugs. I change my personal toolbar settings to have the home and my netscape buttons. I changed my home page to be a local file (and then put it back.) I was using an existing profile and the 10/26 16 MN6 build. I've never seen this with any previous update and I do them a few times a week on this machine. I had another problem where czhang@netscape.com got an error for being czhang@netscape<copyright symbol>com when I made absolutely no change to it. Since this is a prefilled textfield in the form, maybe a textfield change is responsible for all of this?
Comment 25•24 years ago
|
||
Using the affected profile, I see that the prefs | appearance | fonts is set to Western. However, every time I try to commit, the dot in netscape.com for the QA contact field gets changed to the copyright symbol. (This profile seems not to be affected by either problem.)
Updated•24 years ago
|
Summary: Recieve "invalid user name" error when committing bugs → Receive "invalid user name" error when committing bugs
Comment 26•24 years ago
|
||
Steve, please make a copy of the affected profile (the directory and all of its files) before you do anything else so that we can examine it. You mentioned the Prefs | Fonts dialog, but that is probably unrelated. After you have copied your profile, would you please take a look at View | Character Coding? It might be set to Armenian. (It was for Jaime.) Was that profile created by migrating from an old profile (e.g. Nav4)?
Comment 27•24 years ago
|
||
Ok, view | character coding does show armenian for me. I'm almost certain this is a migrated profile. Not sure how migration comes into this, seems like it would have always been broken rather than suddenly start failing in that build. Why does it only affect the QA Contact field? (Attempting to change to Western didn't seem to take the first time. When I exited and came back, it was Armenian again...)
Comment 28•24 years ago
|
||
Exit w/ctrl-Q and File | Exit both leave me at Armenian when I come back.
Comment 29•24 years ago
|
||
If your preference, intl.charset.default is set to Armenian, quitting and restarting won't change anything. Check this by opening Edit|Preferences|Navigator|Languages, and see if the lower panel has the pref set to Armenian (ARMSCII-8). Prefs moved to the chrome area a while ago, could you have gotten caught in the midst of the migration of this specific pref from the old location to the new? See bug 39790 [L12y] Move all localizable prefs into chrome:// What would have happened if intl.charset.default did not exist (because it had not been migrated to chrome:// yet) at the time a profile was created? cc'ing Tao who was involved in moving this pref.
Assignee | ||
Comment 30•24 years ago
|
||
Guys, can you please take a look, as Bob suggested, at your prefs file and see if you have ARMSCII-8 set anywhere? Make a search on disk. It would help a lot if I could take a look at the affected profile. Can you attach one to the bug? Or if you are on campus I can come by and check it out. I am unable to reproduce this and simply looking at code hasn't revealed anything yet.
Comment 31•24 years ago
|
||
My prefs file has intl.charset.default set to armscii-8 and intl.charsetmenu.browser.cache set to "armscii-8, Big5, ISO-8859-2, UTF-8, windows-1252" I'll delete those and see what happens.
Comment 32•24 years ago
|
||
Testing commit w/armscii-8 prefs deleted...
Comment 33•24 years ago
|
||
Yeah! Deleting the prefs from the prefs.js is a workaround for this problem. How exactly did these prefs get into my prefs.js file? If they were supposed to move to rdf, which builds implemented that? If this has restrictive requirements like having to run a certain build etc, then this isn't really an RTM stopper. Thanks for the workaround though!! :-)
Keywords: relnoteRTM
Assignee | ||
Comment 34•24 years ago
|
||
Ok, so this pref *was* causing the issue. One would normally edit it by going to Edit|Preferences|Navigator|Languages how the ... did it changed in your case?! LXR sez it is accessed in these places: /editor/ui/composer/content/editor.js, line 1607 -- prefCharsetString = gPrefs.getLocalizedUnicharPref("intl.charset.default"); /modules/libpref/src/init/all.js, line 366 -- pref("intl.charset.default", "chrome://navigator/locale/navigator.properties"); /layout/base/src/nsDocumentViewer.cpp, line 1853 -- prefs->GetLocalizedUnicharPref("intl.charset.default", &gDefCharset); /xpfe/browser/resources/locale/en-US/navigator.properties, line 55 -- intl.charset.default=ISO-8859-1 /xpfe/components/prefwindow/resources/content/pref-languages.xul, line 83 -- pref="true" preftype="string" prefstring="intl.charset.default" /xpfe/components/prefwindow/resources/content/nsPrefWindow.js, line 154 -- (aPrefString == "intl.charset.default") || Mostly read-only, one write in prefs. But you are didn't edit that pref. Digging deeper...
Comment 35•24 years ago
|
||
Should this be rtm- now?
Comment 36•24 years ago
|
||
Haven't been able to reproduce this. Looking at the current code, Cata cannot see how this will occur. The theory (yet to be validated) is that selmer created a profile and modified prefs in a build in which the pref migration and new pref code was not in sync. We looked at installed Win PR2 and PR3, and both had the intl.charset.default set correctly in defaults\pref\all.js and navigator.properties. Asa commented that other had experienced this, but have not heard from anyone. Marking WORKSFORME. Please reopen if anyone has new data.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
Whiteboard: [rtm need info] → [rtm-]
Assignee | ||
Comment 37•24 years ago
|
||
Hey Bob, we collided. :) Here are my comments. Ok, I tried more stuff: remove prefs, replace them, test with PR2 build etc and I could't reproduce it. I belive this was a one-time occurence caused by the usage of the same profile while the code changed. So, closing this bug, marking it "worksforme" and RTM- it.
Reporter | ||
Comment 38•24 years ago
|
||
Doesn't work for me. Got this error again today. Try switching between profiles in JA and EN to see if it sets Character coding to Armenian.
Comment 39•24 years ago
|
||
Jaime, In the profile that does not work, did you check your intl.charset.default? Has this occurred with a new profile?
Reporter | ||
Comment 40•24 years ago
|
||
Bob - Q1) In the profile that does not work, did you check your intl.charset.default? A1) Not sure what you mena, but nope . . . I didn't touch a thing, it just happened. The only thing I was doing is going from a JA_demo_on profile to my Jaime Rodriguez, Jr. profile. Q1) Has this occurred with a new profile? A1) I will need to test a new profile. For now, it is just happening with my original one.
Comment 41•24 years ago
|
||
Jaime> Q1) In the profile that does not work, did you check your Jaime> intl.charset.default? Jaime> A1) Not sure what you mena, ... Check this by opening Edit|Preferences|Navigator|Languages, and see if the lower panel has the pref set to Armenian (ARMSCII-8). For the more adventurous, check (w/Notepage) if intl.charset.default exists in ...\Windows\Mozilla\Users50\<profile>\prefs.js and see if the value is set to Armenian. If so, change this back to Western, and everything should be fine. The creation date of the profile folder and ther prefs.js file would be useful to try to track down when you created the profile and when you last changed your prefs (but you could have changed other things too).
Reporter | ||
Comment 42•24 years ago
|
||
Bob - Check this by opening Edit|Preferences|Navigator|Languages, and see if the lower panel has the pref set to Armenian (ARMSCII-8) - YUP . . . PREF IS SET TO ARMENIAN. Attaching my prefs.js. Dates on the Jaime Rodriguez, Jr. profile folder is 11.09.00 and pref file date is 11.02.00.
Reporter | ||
Comment 43•24 years ago
|
||
Note: user_pref("intl.charset.default", "armscii-8");
Reporter | ||
Comment 44•24 years ago
|
||
Assignee | ||
Comment 45•24 years ago
|
||
Jaime, we have this workaround for this bug: change the "intl.charset.default" pref back to ISO-8859-1 by either editing the JS file or going to Edit|Preferences|Navigator|Languages and changing the default character set there. Now the $64k question is: did you do that, and then, after a while, you noticed the problem again? 'Cause if you did, that means the code changed the default charset by itself, which would be very, very bad... But if you didn't apply the "workaround" and you just have the problem still happening, well, that would be expected, considering that this bug is caused by the pref to be set to armenian. The problem stays there until you reset it. Please help us clarify this...
Reporter | ||
Comment 46•24 years ago
|
||
To be clear, why would I ever change my pref to Armenian. This just happened! The only thing that I can figure, is that I've been switching between profiles. One for Japanese, and the other for English. Just tested this, but did not notice a shift in character coding in the Enligh profile. What is the work-around for people using Armenian encoding?
Reporter | ||
Comment 47•24 years ago
|
||
Note: I had changed my Character Coding from Armenian to Western (ISO-8859-1) under the View Menu, but not in my preferences. In this case my Western selection was changed to Armenian, and I saw this bug, after I thought I had applied a woraround.
Comment 48•24 years ago
|
||
The View menu make a temporary change and does not change the ***default***. You must go to the preferences panel to change the default.
Reporter | ||
Comment 49•24 years ago
|
||
Cata - Please see selmer's comments. He seemed to getting the same stuff as me without an intended action to change pref. "Exit w/ctrl-Q and File | Exit both leave me at Armenian when I come back."
Comment 50•24 years ago
|
||
Sure, my initial entry into this was not due to any action I'm aware of taking other than installing current builds from time to time. I applied the workaround and have not noticed a problem since then. Jaime, close all instances of NS6, go to your prefs.js file and delete that line. When next you launch, all will be well again. I continue to believe this was a glitch that will only bite people who have been following our daily builds and updating frequently. I don't see any evidence this will be widespread among new users. If that analysis is wrong, then we made a big mistake marking this rtm-...
Comment 51•24 years ago
|
||
verifying works for me on build 2001-01-12-04-MTrunk
Status: RESOLVED → VERIFIED
Updated•5 years ago
|
Component: HTML: Form Submission → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•