Closed
Bug 168788
Opened 22 years ago
Closed 15 years ago
Composer does not properly show and save filenames with non-ASCII characters
Categories
(SeaMonkey :: Composer, defect)
SeaMonkey
Composer
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.
Comment 1•22 years ago
|
||
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
Comment 2•22 years ago
|
||
Is this a regression?
This seems bad.
Charley--did you change any of this stuff recently?
Comment 3•22 years ago
|
||
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?
Comment 4•22 years ago
|
||
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
Comment 6•22 years ago
|
||
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
Updated•22 years ago
|
Updated•22 years ago
|
Whiteboard: editorbase-
Assignee | ||
Updated•22 years ago
|
Target Milestone: mozilla1.3alpha → mozilla1.4beta
Comment 10•20 years ago
|
||
It seems that this problem still exists in Mozilla 1.7.
Updated•20 years ago
|
Product: Browser → Seamonkey
Updated•16 years ago
|
QA Contact: sujay → composer
Target Milestone: mozilla1.4beta → ---
Comment 11•15 years ago
|
||
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
Comment 12•15 years ago
|
||
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
Comment 13•15 years ago
|
||
bug 168788 was fixed, so I believe that this bug was fixed.
Could you reproduce this on latest trunk of SeaMonkey?
Comment 14•15 years ago
|
||
Oops. this number is bug 161791.
Comment 15•15 years ago
|
||
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: 15 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•