Steps to reproduce:
1. Open the Web Console.
2. Type something that has no autocompletion, e.g. ` or whatisthisidonteven.
3. Input field context menu -> "Select All". (On Mac, you can press Cmd+A. On Windows and Linux, Ctrl+A for Select All may still be broken due to bug 634403.)
4. Press the right arrow key to move the caret to the end of input.
5. Type a character.
The character is inserted immediately following the last character.
A new line has been inserted, and the character inserted is the first character on the second line.
*** This bug has been marked as a duplicate of bug 623749 ***
How is this a duplicate of bug 623749 ?
(In reply to comment #2)
> How is this a duplicate of bug 623749 ?
oops. My dupe keybindings bug instincts are way to hair-triggered:)
I get lots of these assertions when I type the final character after the right arrow:
###!!! ASSERTION: We should have one text node and one mozBR at most: 'length <= 2', file /Users/past/src/devtools/layout/forms/nsTextControlFrame.cpp, line 1021
The value in the input field is always correct AFAICT, it seems that the resizing process here somehow gets confused:
CCing Ehsan, since the only lead I found via Google for this assertion is bug 240933 (Plaintext editor should stop using <br> all over). Ehsan, do you happen to know why this assertion would get triggered in this case?
I observed the same behavior in the Scratchpad window, too. I couldn't find any other multi-line input fields to test this, but it does smell like a platform bug.
sonofagun. It appears you are correct, sir!
make that ::editor.
So this is curious. From the editor's point of view, this is just an HTML <textarea> tag; that's what's sitting in the DOM. I can't reproduce the problem with a normal textarea in an HTML document, though.
So what is being done differently in this case? In particular, what's different about the behavior of cmd_SelectAll here?
Oh, and the height styling from comment 4 is _very_ unlikely to matter here.
Is http://mxr.mozilla.org/mozilla-central/source/toolkit/components/console/hudservice/HUDService.jsm#4962 interfering here? (custom Ctrl/Cmd+A behavior). Comment 0 mentions the context menu "Select All", which wouldn't be affected by this, but maybe that specific result was tainted by having previously used the shortcut?
(In reply to comment #10)
> hudservice/HUDService.jsm#4962 interfering here? (custom Ctrl/Cmd+A
> behavior). Comment 0 mentions the context menu "Select All", which wouldn't
> be affected by this, but maybe that specific result was tainted by having
> previously used the shortcut?
No, because I managed to reproduce this without Cmd+A.
1. Open Scratchpad (F4)
2. Select the textbox, type Ctrl/Cmd-A to Select All
3. Type "something" (clearing the text)
4. Type Cmd-A again followed by a right arrow (still on the single line)
5. type a letter
Letter should appear immediately after "something"
Letter appears on following line.
apparently this works (able to reproduce the failure) with the down arrow instead of the right arrow too.
OK, this is totally a regression from bug 240933, and also happens in a normal textarea element.
we definitely want a unittest for this.
I can probably write one for the scratchpad pretty easily.
then again, it's also trivial to add one for data:text/html,<textarea/> too.
Created attachment 534881 [details] [diff] [review]
Comment on attachment 534881 [details] [diff] [review]
Review of attachment 534881 [details] [diff] [review]:
(In reply to comment #15)
> we definitely want a unittest for this.
> I can probably write one for the scratchpad pretty easily.
I don't think that would be necessary, but I won't stop you if you want to write that test. ;-)
(In reply to comment #20)
> (In reply to comment #15)
> > we definitely want a unittest for this.
> > I can probably write one for the scratchpad pretty easily.
> I don't think that would be necessary, but I won't stop you if you want to
> write that test. ;-)
I think the moment's passed.
But this bug is fixed in today's nightly! huzzah! "20110526030623"