Closed
Bug 523441
Opened 16 years ago
Closed 15 years ago
undo in textarea (ctrl+z) when there is no undo to execute results in mysterious invisible newline
Categories
(Firefox :: General, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: u349420, Unassigned)
Details
(Keywords: testcase, Whiteboard: [CLOSEME 2011-1-1])
Attachments
(1 file)
|
1016 bytes,
text/html
|
Details |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 (.NET CLR 3.5.30729)
Pressing ctrl+z once while in an empty textarea (when the context menu item for undo is disabled) results in no visible change in the UI. However, javascript now reports the textarea value as containing a single newline character. It is not possible to delete this "newline" from the textarea using backspace/delete keys - one must do "Select All" and then backspace/delete.
This breaks functionality for any code which reads a textarea's value - when the user believes the textarea is empty, the browser may be reporting a newline.
Here's the test html:
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html><head><title>firefox bug</title>
<script type="text/javascript">
window.onload = function () {
document.getElementById('data').onchange = function () {
alert(
'length: ' + this.value.length +
', charCode: ' + this.value.charCodeAt(0));
};
};
</script></head>
<body><form action="#"><div>
<textarea id="data" rows="5" cols="20"></textarea>
</div></form></body>
</html>
Reproducible: Always
Steps to Reproduce:
FOR EXAMPLE CODE PROVIDED:
1. Load page with the given html.
2. Give focus to textarea. Note that it is empty (no spaces/newlines).
3. Press ctrl+z only once to "undo" (shouldn't be possible, but do it anyway).
4. Take focus away from the textarea.
5. Be amazed as an onchange event executes even though you didn't visibly change the textarea value. The event alerts you with the value/length/charCode of the single character which has mysteriously appeared in a non-visible value.
FROM SCRATCH:
1. Place a textarea on the page, ensuring empty contents (no spaces, newlines).
2. Check the textarea value with javascript. As expected, the value is an empty, 0-character length string.
2. Give focus to the field to begin editing, but do not type any characters.
3. There is no physical undo that should be possible. Indeed, the "Undo" context menu item for the textarea is disabled.
4. Press ctrl+z only once.
5. Using javascript, check the value of the textarea. Surprise! The value is now a 1-character length string: a newline.
BUT:
6. Give focus back to the textarea. Use backspace and delete keys to try and delete the mysterious newline. You can't. There is no newline to delete in the textarea, yet firefox reports a newline to the javascript.
7. Do Select All, either via context menu or via ctrl+a. Note that there is nothing visibly selected. But now press backspace. Voila, javascript now reports the expected empty string.
Actual Results:
An alert() with the following text:
length: 1
charCodeAt(0): 10
value: |
|
Expected Results:
An alert() with the following text:
length: 0
charCodeAt(0): NaN
value: ||
|
||
Comment 1•16 years ago
|
||
I *confirm* this on mac osx
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; it; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3
|
|
||
Comment 2•16 years ago
|
||
I *confirm* this also in Minefield/3.7a1pre
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.3a1pre) Gecko/20091019 Minefield/3.7a1pre
As an additional note, the mystery newline isn't only a javascript visibility problem. With javascript disabled and the addition of a submit button, upon submission of the form, that single chr(10) / \n is submitted to the server as chr(10) + chr(13) / \r\n.
|
|
||
Comment 4•15 years ago
|
||
Reporter, are you still seeing this issue with Firefox 3.6.12 or later in safe mode? If not, please close. These links can help you in your testing.
http://support.mozilla.com/kb/Safe+Mode
http://support.mozilla.com/kb/Managing+profiles
Also, please consider using the most recent Firefox 4 beta build, your bug may be resolved there.
Whiteboard: [CLOSEME 2011-1-1]
|
|
||
Comment 5•15 years ago
|
||
No reply, INCOMPLETE. Please retest with Firefox 3.6.13 or later and a new profile (http://support.mozilla.com/kb/Managing+profiles). If you continue to see this issue with the newest firefox and a new profile, then please comment on this bug.
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → INCOMPLETE
|
|
||
Comment 6•15 years ago
|
||
@Tyler: confirmed in FF3.x 4.x and 5.x in safe mode and with new profile
It is extremely annoying. I'm having to jump thru hoops to get rid of this.
It applies to input field too not just textarea and it happens with Undo/Redo when there is nothing to Undo/Redo ... Annoying as hell.
|
||
Comment 8•14 years ago
|
||
|
|
||
Comment 9•14 years ago
|
||
Nate: thank you for the clear and minimal testcase and the detailed and clear steps to reproduce! It was an excellent report, which we missed :(
Unfortunately the good reports get lost in the haystack of bad ones... Next time you file such a report, feel free to ping people on irc.mozilla.org (#qa and #developers) or me personally so that it can get triaged appropriately.
I can reproduce this in Firefox 11 (on Windows XP and Mac), but not in the latest Nightly build <http://nightly.mozilla.org/>, so this must have been fixed independently (although I couldn't find the bug where the fix was landed).
Note that there's a similar bug 740784 still unfixed.
Keywords: testcase
Resolution: INCOMPLETE → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•