For the past few days, I have encountered many glitches in <textarea> in Nightly. Text is garbled (several lines displayed on top of each other) and/or blinking. I have seen this with Wordpress and with http://benjamin.smedbergs.us/weekly-updates.fcgi/

This seems pretty easy to reproduce by resizing the textarea.

Is this really on all OSes? What's the regression range on nightlies?

Sorry, MacOS X. I started noticing this with the Nightly of September 14th, 2013, if my memory serves.

Present already in http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2013-09-13-mozilla-central-debug/

OK. Can you try some nightlies in that range to verify exactly when this appeared? Or provide clearer steps to reproduce? I just tried to reproduce on Mac in today's nightly on the smedbergs.us page like so: 1) Type "This is\na test" (with a newline) in the "Done" textarea. 2) Resize that textarea in various ways. and I can't reproduce so far....

Works in http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2013-09-10-03-02-54-mozilla-central/ I might not have much more time to finish bisecting today. STR: * write lots of text in the smedbergs.us page (section Done); * start copying and pasting inside that textarea

First bad seems to be http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2013-09-13-mozilla-central-debug/

I've seen this on Linux, and it smells to me like a Block reflow bug, maybe related to Corey's changes for bug 911786.

I can reproduce the problem on Windows7 with/without HWA. http://hg.mozilla.org/mozilla-central/rev/9366ee039645 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:26.0) Gecko/20100101 Firefox/26.0 ID:20130915030208

Regression window(m-i) Good: http://hg.mozilla.org/integration/mozilla-inbound/rev/5a4bb2092618 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:26.0) Gecko/20100101 Firefox/26.0 ID:20130911231838 Bad: http://hg.mozilla.org/integration/mozilla-inbound/rev/bf930e7d61d3 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:26.0) Gecko/20100101 Firefox/26.0 ID:20130911233738 Pushlog: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=5a4bb2092618&tochange=bf930e7d61d3 Regressed by Bug 911786

Alice0775, thank you!

STR 1. Open this page 2. Paste the following text to "Additional Comments:" textarea -------- Cut ------------------ OK. Can you try some nighties in that range to verify exactly when this appeared? Or provide clearer steps to reproduce? I just tried to reproduce on Mac in today's nightly on the s med bergs.us page like so: 1) Type "This is \ test" (with a newline) in the "Done" text area. 2) Re size that text area in various ways. and I can't reproduce so far...reproduce . ---------- Cut ------------------ 3. Resize the textarea(narrow and expand width slowly)

I can repro (occasionally) by visiting... data:text/html,<textarea> ...and and performing Alice0775's STR there.

This problem happens in not only textarea but also the web page(text/plain, text/html etc) STR 1. Open attached or URL 2. Narrow / expand browser width slowly

Since bug 916751 is hard (for me) to test, I haven't confirmed for sure that this fixes the bug. However, it fixes the assertions that bug 911786 part 3 triggers in layout/base/crashtests/317934-1.html through this codepath.

Since bug 916751 is hard (for me) to test, I haven't confirmed for sure that this fixes the bug. However, it fixes the assertions that bug 911786 part 3 triggers in layout/base/crashtests/317934-1.html through this codepath.

Comment on attachment 805750 [details] [diff] [review] Do not use nsIFrame::MovePositionBy from nsLineLayout. >diff --git a/layout/generic/nsIFrame.h b/layout/generic/nsIFrame.h > /** > * Move the frame, accounting for relative positioning. Use this when > * adjusting the frame's position by a known amount, to properly update its > * saved normal position (see GetNormalPosition below). >+ * >+ * This must be used only when moving a frame *after* >+ * nsHTMLReflowState::ApplyRelativePositioning is called. When moving >+ * a frame during the reflow process prior to calling >+ * nsHTMLReflowState::ApplyRelativePositioning, the position should >+ * simply be adjusted directly. perhaps add "... using SetPosition()" at the end there. Aside: Maybe it'd make sense to move your assertion-patch from bug 911786 over into this bug (maybe merging it into this patch), since it can't fails without this patch? r=me, anyway.

sorry: s/can't fails/fails/. (originally said "can't land without this patch" & made edit typo)

Comment on attachment 805750 [details] [diff] [review] Do not use nsIFrame::MovePositionBy from nsLineLayout. [Approval Request Comment] Bug caused by (feature/regressing bug #): bug 911786 (part of position:sticky) User impact if declined: text misplaced, most commonly in textareas Testing completed (on m-c, etc.): landed on mozilla-inbound, confirmed to fix assertion triggered by part 3 of bug 911786 Risk to taking this patch (and alternatives if risky): low; it backs out a piece of bug 911786 (though changes it from using nsRect -> nsPoint) String or IDL/UUID changes made by this patch: none

Also, I'd appreciate if somebody who could reproduce the bug reliably could confirm that it's fixed.

I can reproduce pretty trivially, but there's been no nightly since this was fixed unfortunately

verified fixed in nightly 20130918030202 Mozilla/5.0 (Windows NT 6.1; rv:27.0) Gecko/20100101 Firefox/27.0

I was regularly seeing the issue described in Bug 916665. Since using the Nightly in which this fix landed, I haven't seen an issue. Tentative VERIFIED…

Verified fixed in Nightly 27.0a1 buildid 20131007030203, Aurora 26.0a2 buildid 20131007004003.