328056 - Pressing Ctrl+Y in an empty input field invisibly adds \r\n to the end

Status: RESOLVED FIXED

(Core :: DOM: Editor, defect)

Description

[Chris Moore]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060209 Debian/1.5.dfsg+1.5.0.1-2 Firefox/1.5.0.1
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060210 Ubuntu/dapper Firefox/1.5.0.1

I was using a form like this:

<form action="http://localhost/cgi-bin/foo.cgi" method="post" enctype="multipart/form-data">
<input name="a" type="file" />
<input type="submit" />
</form>

The "file" input expects a filename.  I copied a full path into my clipboard using Emacs and wanted to paste it into the "file" input field.  I typed control-y, the Emacs way of pasting.  Nothing appeared to happen.  Realising my mistake I typed control-v instead and the value was pasted.  Then I hit submit to send the file for upload, the upload failed.

What got sent to the web server was the following:

-----------------------------11692444882074929047948775071
Content-Disposition: form-data; name="a"; filename="/path/to/file
"
Content-Type: application/octet-stream


-----------------------------11692444882074929047948775071--

Notice the newline at the end of the filename, before the closing quote.  The application on the web server interpreted the closing quote and Content-Type header as the contents of the file, and uploaded that.

Using 'get' instead of 'post' causes a similar effect, visiting:

  http://localhost/cgi-bin/foo.cgi?a=file%0D%0A

(note the %0D%0A at the end of the URL).

The same effect happens for regular 'text' input fields, but with less obvious results.

Typing control-y when the field isn't empty doesn't cause this problem.

Typing control-y when the field is empty and then using the 'browse' button to select a file doesn't cause the problem.

Reproducible: Always

Steps to Reproduce:
1. find a web page which lets you upload a file using an <input type="file">
2. empty the "file" input box if it's not already empty (control-a backspace will do that)
3. type a valid path to a file into the box (don't use the browse button)
4. click 'submit' to upload the file.  the file won't be sent to the webserver as it should



This bug is reported on the ubuntu bug tracker, here:

  https://launchpad.net/products/firefox/+bug/32301

Comment 1

[Philip Withnall (unavailable)]

Attachment: Testcase

Comment 2

[Philip Withnall (unavailable)]

Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9a1) Gecko/20060221 Firefox/1.6a1 ID:0000000000
Confirmed.
This might be something to do with Ctrl+Y being bound to redo; it might be trying to redo something which happened when initialising the input, but this is pure conjecture.

Comment 3

[Chris Moore]

*** Bug 328094 has been marked as a duplicate of this bug. ***

Comment 4

[Andrew Schultz]

also occurs with linux seamonkey trunk
same effect with Ctrl-Z
hmm, not widget... keyboard nav?

Comment 5

[Andrew Schultz]

also occurs with linux seamonkey trunk
same effect with Ctrl-Z
hmm, not widget... keyboard nav?

Comment 6

[:Gavin Sharp [email: [e-mail]]]

Attachment: patch?

This fixes it in my testing, but it's a stab in the dark. I made this code match the code at http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/editor/libeditor/html/nsHTMLEditRules.cpp&rev=1.324#1502  and http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/editor/libeditor/text/nsTextEditRules.cpp&rev=1.203#397.

I don't really understand what mBogusNode is. I'm also unsure as to who would know... this code is pretty old, and most of it's original authors are no longer active.

Comment 7

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

Comment on attachment 223576 [details] [diff] [review]
patch?

r=[e-mail]

Yeah, the couple WillRedo/DidRedo should not act differently from other insertion methods like WillInsert/DidInsert on the bugus node...

Please note that the 'else' part of the test you patches seems to me quite problematic, to say the least... It considers the lone br child of an empty single div in a document as a bogus node ; but why only a div ? Why not an h1 or a p or any block-level element ?

Comment 8

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 223576 [details] [diff] [review]
patch?

Neil found several issues with this patch, like it breaking multiple undo/redo. I don't remember the exact details, unfortunately, other than it isn't suitable to land.

Comment 9

[Graeme McCutcheon [:graememcc]]

Also affects Ctrl-Z as well. This is a similar problem to bug 471319, and I think my patch in that bug would be the right fix for this.

Comment 10

[Graeme McCutcheon [:graememcc]]

> Please note that the 'else' part of the test you patches seems to me quite
> problematic, to say the least... It considers the lone br child of an empty
> single div in a document as a bogus node ; but why only a div ? Why not an h1
> or a p or any block-level element ?

That was probably bug 471722