851469 - Bad File content when saving a Blob URL

Status: RESOLVED INVALID

(Core :: DOM: HTML Parser, defect)

Description

[Lcf.vs]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20100101 Firefox/19.0
Build ID: 20130307023931

Steps to reproduce:

I tried to save various types of files (PHP, JS, HTML, TXT, etc.).


Actual results:

Tests showed me that only certain types of files doesn't keep tabs and/or carriage return, such as TXT.

http://jsfiddle.net/w3JNG/


Expected results:

So there is a data integrity problem... 

It would seem natural to have an exact copy of what is sent, regardless of the file extension.

Comment 1

[Manuela Muntean [Away]]

Works for me with both latest Nightly (build ID: 20130314030914) and Firefox 19. The content of the file matches the output of the link provided in the description, which is:  
    line0
    line1
    line2

The only difference I get between Nightly and Firefox 19 is that in Firefox 19 the file is saved with the extension ".part" and in the latest Nightly without ".part".

Comment 2

[Lcf.vs]

Save it in ".txt" to see the bug... ;)-

Comment 3

[Manuela Muntean [Away]]

(In reply to Lcf.vs from comment #2)
> Save it in ".txt" to see the bug... ;)-

Indeed, after I open the saved file with Notepad, I get this output:  line0  line1 line2
Reporter, do you experience the same behavior?

Comment 4

[Lcf.vs]

Yeah...

Comment 5

[Lcf.vs]

It's the same for carriage returns & vertical tabs (ascii code 11)

Comment 6

[Manuela Muntean [Away]]

Reproducible on the latest Nightly - build ID: 20130314030914
Reproducible on the latest Aurora - build ID: 20130314042011
Reproducible on the latest Beta - build ID: 20130313170052

The same output as described in comment 3, on a Windows 7 64-bit machine.

Note:
I get the same behavior with Chrome.

Comment 7

[Lcf.vs]

Thanks for your confirmation. :)

Comment 8

[Loic]

The issue is present still blob constructor has been added in March 2012, in bug 721569, I guess.

http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=5ec9524de1af&tochange=1ca7a94573f2

Comment 9

[Masatoshi Kimura [:emk]]

It has nothing to do with Blob constructor.
http://jsfiddle.net/rPFhy/
The HTML parser will normalize the line ending to LF which is required by the spec.

Comment 10

[Lcf.vs]

(In reply to Loic from comment #8)
> The issue is present still blob constructor has been added in March 2012, in
> bug 721569, I guess.
> 
> http://hg.mozilla.org/mozilla-central/
> pushloghtml?fromchange=5ec9524de1af&tochange=1ca7a94573f2

Why DOM Component, please?

I don't know the inner workings of Firefox but it isn't about how the value of the textarea is interpreted but about how Firefox saves the file...

Evidence, save the file in ".html", ".php", ".js" and this bug doesn't appear...

Comment 11

[Masatoshi Kimura [:emk]]

I always saw LF line endings regardless of the extension.
(How did you save the file with an arbitrary extension? Right click > [Save Link As]?)

Comment 12

[Lcf.vs]

(In reply to Masatoshi Kimura [:emk] from comment #11)
> I always saw LF line endings regardless of the extension.
> (How did you save the file with an arbitrary extension? Right click > [Save
> Link As]?)

Yeah, I try to write a JS file editor.

I don't understand why this difference in behavior, according to the extension of the saved file...

It's, for me, a non-sense...

Comment 13

[Lcf.vs]

@Masatoshi Kimura :

For the future, I hope to see the download attribute value support, for it...

(already reported at : https://bugzilla.mozilla.org/show_bug.cgi?id=850378)

Comment 14

[Lcf.vs]

Hum, sorry... I just find that indeed, the carriage returns are well respected, my impression was related to Notepad rendering...

Really sorry for this disturb.