139781 - Composer adds %20 to blank spaces in new web page names

Status: VERIFIED DUPLICATE of bug 141819

(SeaMonkey :: Composer, defect)

Description

[Susie Wyshak]

If I create and save a file in Composer such as "susie home" and then go to edit
the file, Composer displays it as "susie%20home.html" when publishing. When I
look at my files it is saved with a blank space as intended. 

This is confusing. 

If Composer needs to add characters to connect the words it should add an
underscore like susie_home.html -- so that when I'm looking at my files the name
is the same as when I'm publishing. And so that the user does not think that
they will have to distribute URLs that contain %20.

Comment 1

[sujay]

--> brade/cmanske

Comment 2

[michael wendell]

I am able to reproduce this problem on the 04-24 trunk build.

But it seems to me this is related to (if not a dupe of) bug 76799.  

Comment 3

[Kathleen :Brade]

actually I don't think this is a duplicate.  The report is that the file is
saved with a space (unlike 76799 where it is saved with %20) but it is displayed
with %20.

-->cmanske since it's the UI that is showing the escaped version of the filename

(cmanske: you should be able to use NS_UnescapeURL for any url fragments you are
displaying)

Susie--I disagree that it should replace the space with an underscore for
display purposes.  There shouldn't be any need to do that; we should be able to
display it as a space.

Comment 4

[Susie Wyshak]

I agree :-) I assumed there had to be a character in the middle but better to
save it as the user wants it.

Comment 5

[Charles Manske]

Attachment: patch v1

Very conservative fix: Unescape filename when setting input file value,
but depend on nsIURI and network code to do appropriate "escape" before 
using name to publish.

Comment 6

[andreww]

Comment on attachment 81766 [details] [diff] [review]
patch v1

r=andreww

Comment 7

[kinmoz]

Comment on attachment 81766 [details] [diff] [review]
patch v1

sr=[e-mail]

Comment 8

[Charles Manske]

This fix is no longer a good idea, in my opinion.
I think this issue is subsumed by bug 141819.
We need to do appropriate "unescaping" for all parts of the documenent's URL.


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

Comment 9

[sujay]

verified.