Closed Bug 854272 Opened 13 years ago Closed 5 months ago

Undo breaks in a textarea when overflow property is changed.

Categories

(Core :: DOM: Editor, defect, P5)

Product:
Core
Component:
DOM: Editor
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
149 Branch
Tracking Flags:
Tracking Status
firefox149 --- fixed

People

(Reporter: adel.smee, Unassigned)

References

Details

(Keywords: testcase)

Attachments

(1 file)

Reporter's Testcase
445 bytes, text/html
Details
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_5) AppleWebKit/537.22 (KHTML, like Gecko) Chrome/25.0.1364.172 Safari/537.22 Steps to reproduce: I wrote this code to resize a textarea when the user types lots of stuff into it: <html> <head> <script type="text/javascript"> function breakundo() { var myElement = document.getElementById("mine"); myElement.style.overflow = "scroll"; myElement.style.height = myElement.scrollHeight; myElement.style.overflow = "hidden"; } </script> </head> <body> <form> <textarea id="mine" oninput="breakundo()" style="overflow: hidden">Placeholder</textarea> </form> </body> </html> While your suggested method of resizing a textarea works (https://developer.mozilla.org/en-US/docs/DOM/HTMLTextAreaElement#Example_.231.3A_Autogrowing_textarea) it does a little hiccup every time the user types a new line, so I'd much prefer to get this way working as it is nice and smooth. Actual results: The problem is my users can no longer Undo any text typing they've done into the textarea. Expected results: Undo should work. If I get rid of this line: myElement.style.overflow = "scroll"; ... and just set the height to some number then Undo still works as I would expect.
This is a similar bug to: https://bugzilla.mozilla.org/show_bug.cgi?id=448784 but I don't require a focus or blur event to cause Undo to stop working.
Confirmed with Mozilla/5.0 (Windows NT 6.1; WOW64; rv:22.0) Gecko/20130325 Firefox/22.0 ID:20130325093524 CSet: 4d3250f3afea (FWIW, this never worked). WFM in Chrome 27 and MSIE 10.
Status: UNCONFIRMED → NEW
Component: Untriaged → Layout: Form Controls
Ever confirmed: true
Keywords: testcase
OS: Mac OS X → All
Product: Firefox → Core
Hardware: x86 → All
Version: 19 Branch → Trunk
Component: Layout: Form Controls → Editor

Bulk-downgrade of unassigned, untouched DOM/Storage bug's priority.

If you have reason to believe, this is wrong, please write a comment and ni :jstutte.

Severity: normal → S4
Priority: -- → P5

I can still reproduce this on Firefox 85...

I can't reproduce anymore.

My STR:
(1) Load https://bug854272.bmoattachments.org/attachment.cgi?id=729227
(2) Click to focus the textarea
(3) Ctrl+A to select all of its content
(4) Type "test"
(5) Ctrl+Z (several times if necessary)

EXPECTED RESULTS:
You should see the word "Placeholder" restored.

ACTUAL RESULTS (in older builds):
Ctrl+Z either has no effect or changes "test" to "t" and then won't undo beyond that point.

Fix range: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=e835d0f9fea4b05436e5f3be55c9c4e31a82f377&tochange=a810895a0020d2d6be3ccf63452b8808a0d020a4

--> Fixed by bug 2016280.

Masayuki, do you think we can close this, or is there another use-case in this bug that's not covered by my STR / not fixed by bug 2016280? (I saw you added a dependency on bug 2017201 but I'm not clear how bug 2017201 relates to the testcase on this bug here.)

Flags: needinfo?(masayuki)

Sounds like we can close this bug without adding the reported testcase since this is not easy to regress. (Although I don't understand why only the patch for bug 2016280 fixed this bug since TextControlState still depends on the nsTextControlFrame and it may be reframed by the style change.)

Status: NEW → RESOLVED
Closed: 5 months ago
status-firefox149: --- → fixed
No longer depends on: 2017201
Flags: needinfo?(masayuki)
Resolution: --- → FIXED
Target Milestone: --- → 149 Branch
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: