Last Comment Bug 328056 - Pressing Ctrl+Y in an empty input field invisibly adds \r\n to the end
: Pressing Ctrl+Y in an empty input field invisibly adds \r\n to the end
Status: RESOLVED FIXED
[fixed by bug 471319]
: testcase
Product: Core
Classification: Components
Component: Editor (show other bugs)
: Trunk
: x86 Linux
: -- normal (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
: Makoto Kato [:m_kato]
Mentors:
: 328094 (view as bug list)
Depends on: 471319
Blocks:
  Show dependency treegraph
 
Reported: 2006-02-21 08:19 PST by Chris Moore
Modified: 2012-01-09 16:19 PST (History)
7 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Testcase (527 bytes, text/html)
2006-02-21 12:25 PST, Philip Withnall (unavailable)
no flags Details
patch? (985 bytes, patch)
2006-05-27 19:41 PDT, :Gavin Sharp [email: gavin@gavinsharp.com]
daniel: review+
Details | Diff | Splinter Review

Description Chris Moore 2006-02-21 08:19:40 PST
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) 2006-02-21 12:25:31 PST
Created attachment 212625 [details]
Testcase
Comment 2 Philip Withnall (unavailable) 2006-02-21 12:30:08 PST
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 2006-02-21 13:07:52 PST
*** Bug 328094 has been marked as a duplicate of this bug. ***
Comment 4 Andrew Schultz 2006-02-21 18:16:33 PST
also occurs with linux seamonkey trunk
same effect with Ctrl-Z
hmm, not widget... keyboard nav?
Comment 5 Andrew Schultz 2006-02-21 18:16:51 PST
also occurs with linux seamonkey trunk
same effect with Ctrl-Z
hmm, not widget... keyboard nav?
Comment 6 :Gavin Sharp [email: gavin@gavinsharp.com] 2006-05-27 19:41:00 PDT
Created attachment 223576 [details] [diff] [review]
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) 2006-08-21 02:24:56 PDT
Comment on attachment 223576 [details] [diff] [review]
patch?

r=daniel@glazman.org

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: gavin@gavinsharp.com] 2006-09-20 16:07:30 PDT
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] 2009-03-18 08:49:04 PDT
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] 2009-03-18 09:03:31 PDT
> 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

Note You need to log in before you can comment on or make changes to this bug.