229016 - -p command does not work when profile name contains international character(s)

Status: RESOLVED DUPLICATE of bug 208363

(Core Graveyard :: Cmd-line Features, defect)

Description

[andré]

User-Agent:       Mozilla/5.0 (Windows; U; Win98; fr-FR; rv:1.4) Gecko/20030624
Build Identifier: Mozilla/5.0 (Windows; U; Win98; fr-FR; rv:1.4) Gecko/20030624

-p "profileName" works as documented online if profileName contains no
international characters.  (i.e. upper or lower-case P, quotes optional if no
space in profileName.)
If profileName contains an international character (e.g. é as in André) one is
asked to select a profile

Reproducible: Always

Steps to Reproduce:
1. Have 2 profiles defined, one without any international characters, the other
with at least one international character (such as "é").
2. In testing, test all variations of -P "profileName" -- i.e.: upper or
lower-case P, followed by a space, profileName matching case exactly of defined
profile, quotes optional if no space in profileName.
Test by adding parameters to a shortcut link to Mozilla.
Could alternately enter the command directly under "run".
3. Test profileName not containing any international characters.
4. Test profileName containing at least one international character.
Actual Results:  
If profileName contains no international characters, profile is automatically
selected.
If profileName contains any international characters, one is asked to select a
profile.

Expected Results:  
Automatically select the profile, even if profileName contains an international
character.

Behavior not tested with only one profile defined. (Not useful in that case.)
This option worked correctly under Mozilla 1.3.1 (before recent upgrade).
Each profileName tested matched exactly (in case and accents) the profileName
defined under the profile manager.
Bug rated as normal rather than minor because in some cases one wishes to hide
the profile selection from an occational user of one's computer (privacy/security).

Comment 1

[Andrew Schultz]

==> cmd line

dupe of bug 208363?

Comment 2

[Asa Dotzler [:asa]]

*** This bug has been marked as a duplicate of 208363 ***

Comment 3

[andré]

This bug has been resolved under mozilla 1.6 (gecko/20040113)
(But bug 208363, to which it was assigned as duplicate is still classified as
unresolved!?)
(It does seem appropriate to have classified it as a UTF-8 error.)