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)

x86
Windows 98
defect

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).
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.
Group: netscapeconfidential?
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.
Correcting status
Whiteboard: [need info] → [rtm need info]
Attached file Syntax Error
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
Reassign
Assignee: rods → cata
Status: ASSIGNED → NEW
Status: NEW → ASSIGNED
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 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?
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!!  :-)
Keywords: relnoteRTM
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
Closed: 24 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
Component: HTML: Form Submission → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: