185406 - Can't save image whose name contains special chars

Status: RESOLVED FIXED

(Core Graveyard :: File Handling, defect)

Description

[Olivier]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130

1. create an image file named "é.jpg", at root
2. Create page.html at root, containing:
...
<object data='%C3%A9.jpg' type='image/jpg'></object>
<object data='é.jpg' type='image/jpg'></object>
<object data='http://host_root/%C3%A9.jpg' type='image/jpg'></object>
<object data='http://host_root/é.jpg' type='image/jpg'></object>
<object data='file://c:/root/%C3%A9.jpg' type='image/jpg'></object>
<object data='file://c:/root/é.jpg' type='image/jpg'></object>
...
3. display your file in Mozilla: http://host_root/page.html

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Actual Results:  
Only objects 1, 3 and 6 displays image.
Only objects 1 to 4 would "save image", or "show image", and they would do it
right. Cases 5 and 6 returns "The link could not be saved. Web page might have
been removed"

Expected Results:  
I can't understand:
- if the correct syntax is "%C3%A9" for the caracter "é", why it doesn't worked
for 5 and 6?
- if the image is not displayed, why can I View and save it (for 2 and 4)?
- if the image is displayed, why can't I view and save it (case 6)?

Thanks.

On pages containing a lot of these "broken" uri to images, if you try to save
the page, Mozilla just close (crash), with no result.
I don't have test case for this, and am not sure can reproduce.

If you try to open file://c:/root/page.html, the behaviour change:
You now see 2, and not 1.
You can't save or view 1 or 2.

Comment 1

[Christian :Biesinger (don't email me, ping me on IRC)]

file://c:/root/%C3%A9.jpg

this is wrong... you need three slashes, not two, I'm pretty sure.


Does it work if you use img instead of object?

Comment 2

[Ian Neal]

The being able to save the image part of this sounds like a possible dupe but I
can't find that bug at the moment.
Reporter: What is the locale set to in your OS and what's your Languages and
character encoding set to?

Comment 3

[Olivier]

Three slashes instead of two doesn't help, and doesn't change anything.
Win 2000 Pro set to french.
Apache web server and Mozilla set to Western ISO-8859-1... So it might be ok...
... hum, I'm not an expert of such things.
But there must be a problem.
Another thing not yet mentionned:
When you ask the properties of case 3 and 4, you got respectively "%C3%A9.jpg"
and "é.jpg".
But when you save them, they both default save to "é.jpg"...

Thanks.

Comment 4

[Christian :Biesinger (don't email me, ping me on IRC)]

Have you tried <img> instead of <object>?

Comment 5

[Olivier]

<img> instead of <object> provides strictly the same results.
Except one point, not yet mentionned:
Whatever the case, you are always allowed to "send" the image (create an
attachment).
With <object>, the name of the file attached is always (invalid) nasty caracters.
With <img>, the name is the same nasty thing only when it was specified "%C3%A9.jpg"
When it was é.jpg, it remains "é.jpg" in the attachment.

I don't know more... it's really confusing.
Maybe it's a problem of charset setting on my side, and this is much trouble
even inside of Win2k wich I experienced not being very rational on that point.

But it's too much irrationality here... There problably is a Mozilla problem.

Thanks.

Comment 6

[Christian :Biesinger (don't email me, ping me on IRC)]

OK so there are several issues here.

1. The HTTP links are entirely a server-side issue, so it depends on the HTTP
Server as which charset the characters are interpreted

2. %C3%A9 is the UTF-8 way for specifing é in URLs. Mozilla, however, seems to
use the normal windows charset for file: URLs; therefore, %E9 would be the
sequence to use for é. This is probably no bug; but if you believe it is one,
please file it seperately in the Networking:File component and leave the
discussion on this out of this bug.

3. The "Save Image As" behaviour does seem wrong, especially that the images
that can be displayed can not be saved. Interestingly, Save Image As does not
work for me for any of the 4 file: urls presented here (it does work if %E9 is
used as mentioned above).
This does seems like a bug to me, therefore changing the component
appropriately. This was tested with Build 2002122108 on Windows 98.

4. The Send Image behaviour is wholly unrelated to this bug, I would file it as
a separate bug in the Mailnews product. The strange characters come from
interpreting the %C3%A9 sequence as latin1.


Changing summary to match my point 3.

Comment 7

[Rob Stow]

If any one wants an URL on the web where they can see this bug in action, try
loading
http://equis.ya.com/kippys/Q22/SharperV_SW_N004_Sou%EF_Mangas.jpg.html
and then saving the image on that page.   

Be warned that it is a large image and that site seems quite slow lately.

Comment 8

[Jungshik Shin]

I also put up a test page at http://jshin.net/moztest/dl1.html
(the test page in comment #7 is not accessible). My local
filesystem uses UTF-8 so that "%E9.jpg" requested by Mozilla
fails. (both web servers and clients  may do a bit more
in this case.). Olivier, on what platform does your web server
run? What web server are you using?

I'll begin with #3 because that's what this bug is about.
With Mozilla 1.2.1 under Win 2k(ko), Mozilla's behavior is
very erratic. Sometimes I can save images while othertimes I can't. 
With my debug built from the source updated about 12 hours ago,
I can't reproduce the problem with saving for two cases
where images are rendered correctly. 

As for #1 in comment #5, I agree with Christian mostly, but
Mozilla may *optionally* can do a bit more (try UTF-8 first
and originCharset if it fails). (optionally because trying
this for every failed request may lead to a serious performance
hit.)  The same can be said of
http servers, which is, needless to say, not at Mozilla's
disposal. Anyway, the issue should be filed as a separate
bug. PErhaps, this has already been filed. 

As for #4, has anybody filed it? That's definitely a bug. 
If none has, I'll do. 

Comment 9

[Olivier]

"Olivier, on what platform does your web server
run? What web server are you using?"

I used only Apache web server, in some flavours: 1.3.27, 2.0.4x up to the last
2.0.44.
I'm using it only on a "local" level, developping php apps.
I used W2k with SP2, then switched to service pack 3.
As I said, I experienced pretty much *charset* trouble with W2k wich are
obviously windows fault, and pretty much a shame.
By my experience, it seems that Apache behave correctly with *special* chars, as
the generated html (from php-scripts) contains them as they were in the script
or from the filesystem. Am'I missing something?

It would be cool that mozilla should handle the problems I described (even if
it's W2k fault...), but I can't help you more, as my limited knowledge stops here...
As far as I'm concern, I solved my problems (in my php apps) by creating a
"cache" (with *valid* filenames) containing server side resized copy of the
images (that speeds-up drastically the loading in Mozilla) and parse objects
from that "special cache" instead of the originals.

Thx for Mozilla, the best browser.
Please continue the good job.

Paris, France.
Olivier.

Comment 10

[Olivier]

Anyway, if it's of some uses, I'll do tests under WinXP.

Best regards.

Comment 11

[OstGote!]

With Mozilla 1.8b on WinNT4 I can view/save all 6 images from the testpage (see
comment 8).

Comment 12

[Jungshik Shin]

I totally forgot about this bug, but I landed a few patches related with this
bug that should have fixed it. Btw, 'raw Latin1' and 'url-escaped Latin1'
couldn't work for you unless you changed 'network.standard-url.encode-utf8' to
false in 1.8a6( or nightly) because my server (apache 1.3.x) doesn't understand
IRIs. That's not a mozilla bug, though. It's my server that's to blame. IRI is
now an official standard (RFC 39??)