Closed Bug 168788 Opened 22 years ago Closed 14 years ago

Composer does not properly show and save filenames with non-ASCII characters

Categories

(SeaMonkey :: Composer, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 161791

People

(Reporter: grigas, Assigned: jag+mozilla)

Details

(Whiteboard: [adt3])

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; lt-LT; rv:1.1) Gecko/20020826
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; lt-LT; rv:1.1) Gecko/20020826

Mozilla 1.1
Windows XP

If file with non-ASCII characters is opened in Composer, its name in the tittle
bar is shown with non-ASCII characters converted into %FF notations. When file
is saved by command "Save As" all its non-ASCII characters are changed to %FF
notation and now in the tittle bar character % is changad to %25. When process
is repeated each time file name gets longer and longer. E.g. if I open file
ä.html, then first time I get it changed to %E4, second time to %25E4, third
time to %2525E4, etc. 

Reproducible: Always

Steps to Reproduce:
1.
2.
3.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2a) Gecko/20020915

I can confirm on Mozilla 1.2a (Build 2002091508) running Windows XP Professional.

All non-ASCII characters are escaped in the title bar, as they would be in a
URI. This behavior should definately not occur for local pages on my hard drive.
Even when opening a page from a URI, however, the title bar should not escape
the characters (or should it? Disregard the last sentence if I'm wrong).
Summary: Composer does not properly show and save filenames with non-ASCII characters → Composer does not properly show and save filenames with non-ASCII characters
Is this a regression?
This seems bad.

Charley--did you change any of this stuff recently?
Assignee: syd → cmanske
Keywords: nsbeta1
Whiteboard: editorbase
Not a regression. This hasn't changed in awhile.
All "document locations" are handled as URLs, even if local files, so any
escaping is done by non-Composer code.
Are non-ASCII characters legal in a filename?
confirming this is a bug (and not a regression; Netscape 7 also has this issue)
This may be a duplicate bug.

This is what we need to do:
 * When we set the window title we should unescape the string
 * When we set the default file name in the file picker dialog, we should
unescape the string

I'm not sure if we need to escape the name we get back from the file picker or
not; that needs to be investigated.

Yes, non-ascii characters are legal in filenames, how else could you name your
files in Japan? ;-)
Status: UNCONFIRMED → NEW
Ever confirmed: true
UI Issue. EDITORBASE-
Whiteboard: editorbase → editorbase-
seek retriage for editorbase
Files with escaped names appear with escaping and that is confusing.  (I think
the following is a valid example for this particular bug but I'm not positive.)
For example, I often name a file with the percentage that I need to print it at
so I know what to set it at:  sheet_87%.html
 * When I open this file in Composer to make a modification, the window's title
contains %25 which is confusing:  sheet_87%25.html
 * When I open this file in Composer and choose Save As, the file picker dialog
is prefilled with the filename of "sheet_87%25.html" instead of sheet_87%.html.
 This problem then compounds since the file name now actually does contain '25'
which it shouldn't.

The above examples are intended to show that this is in an obvious and easy to
see location.  The reason this should be editorbase+ is because any user who has
a file with non-ascii characters or '%' will see this in the window title and
when choosing Save As... (Europe which uses accented and other variants, Japan,
etc).
Whiteboard: editorbase- → editorbase
Status: NEW → ASSIGNED
Keywords: nsbeta1nsbeta1+
Whiteboard: editorbase → editorbase-
Target Milestone: --- → mozilla1.3alpha
Whiteboard: editorbase-
-> me
Assignee: cmanske → jaggernaut
Status: ASSIGNED → NEW
I think this is all-platforms.
OS: Windows XP → All
Hardware: PC → All
Composer triage team: nsbeta1+/adt3
Whiteboard: [adt3]
Target Milestone: mozilla1.3alpha → mozilla1.4beta
It seems that this problem still exists in Mozilla 1.7.
Product: Browser → Seamonkey
QA Contact: sujay → composer
Target Milestone: mozilla1.4beta → ---
MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
Status: NEW → UNCONFIRMED
Just reproduced with SeaMonkey 2.0. Steps:

1) open Composer, press Ctrl+S, enter "š" as page title, then press Enter to save with hinted file name š.html.
2) choose File -> Save as, you'll now be hinted with %C5%A1.html, press Enter
3) choose File -> Save as, you'll now be hinted with %25C5%25A1.html, press Enter

etc.
Status: UNCONFIRMED → NEW
bug 168788 was fixed, so I believe that this bug was fixed.

Could you reproduce this on latest trunk of SeaMonkey?
Oops. this number is bug 161791.
Thanks Makoto-san. Just tested with a fresh nightly, and the bug seems to have been fixed. Marking as duplicate, but feel free to change it to simply FIXED if you feel that suits better.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.