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 email@example.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).
Nominating for RTM and dogfood. Is anyone else having this problem??? Currently have to enter bug reports in 4.x.
Keywords: dogfood, rtm
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?
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]
Asking around some.
I asked people who reported possibly similar incidents to comment here. Unfortunately the current Netscape Confidential setting prevents them from doing so.
Can I ask WHY this is marked netscape confidential?
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.
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.
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?
Over to Form Submission.
Assignee: asa → rods
Component: Browser-General → Form Submission
QA Contact: doronr → vladimire
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.
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.
Whiteboard: [need info] → [rtm need info]
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.
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.
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.
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?
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.
Rod is on vacation so if one of you in i18n land wants to investigate, please feel free to reassign this over there! :)
I'm reassigning this to myself, as I am more familiar with this code.
Status: NEW → ASSIGNED
Assignee: rods → cata
Status: ASSIGNED → NEW
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?
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 firstname.lastname@example.org 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?
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.)
Summary: Recieve "invalid user name" error when committing bugs → Receive "invalid user name" error when committing bugs
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)?
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...)
Exit w/ctrl-Q and File | Exit both leave me at Armenian when I come back.
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.
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.
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.
Testing commit w/armscii-8 prefs deleted...
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!! :-)
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...
Should this be rtm- now?
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
Last Resolved: 18 years ago
Resolution: --- → WORKSFORME
Whiteboard: [rtm need info] → [rtm-]
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.
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.
Jaime, In the profile that does not work, did you check your intl.charset.default? Has this occurred with a new profile?
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.
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).
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.
Note: user_pref("intl.charset.default", "armscii-8");
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...
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?
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.
The View menu make a temporary change and does not change the ***default***. You must go to the preferences panel to change the default.
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."
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-...
verifying works for me on build 2001-01-12-04-MTrunk
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.