Closed
Bug 916751
Opened 11 years ago
Closed 11 years ago
Many glitches in <textarea> and webpage
Categories
(Core :: Layout: Text and Fonts, defect)
Tracking
()
VERIFIED
FIXED
mozilla27
Tracking | Status | |
---|---|---|
firefox25 | --- | unaffected |
firefox26 | + | verified |
firefox27 | --- | verified |
People
(Reporter: Yoric, Assigned: dbaron)
References
()
Details
(Keywords: regression)
Attachments
(4 files, 2 obsolete files)
603.77 KB,
image/png
|
Details | |
2.89 KB,
text/plain
|
Details | |
99.23 KB,
image/png
|
Details | |
2.44 KB,
patch
|
dholbert
:
review+
lsblakk
:
approval-mozilla-aurora+
|
Details | Diff | Splinter Review |
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/
Reporter | ||
Comment 1•11 years ago
|
||
This seems pretty easy to reproduce by resizing the textarea.
Comment 2•11 years ago
|
||
Is this really on all OSes? What's the regression range on nightlies?
Flags: needinfo?(dteller)
Keywords: regressionwindow-wanted
Reporter | ||
Comment 3•11 years ago
|
||
Sorry, MacOS X. I started noticing this with the Nightly of September 14th, 2013, if my memory serves.
Flags: needinfo?(dteller)
OS: All → Mac OS X
Reporter | ||
Comment 4•11 years ago
|
||
Present already in http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2013-09-13-mozilla-central-debug/
Comment 5•11 years ago
|
||
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....
Reporter | ||
Comment 6•11 years ago
|
||
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
Reporter | ||
Comment 7•11 years ago
|
||
First bad seems to be http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2013-09-13-mozilla-central-debug/
Assignee | ||
Comment 8•11 years ago
|
||
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.
Comment 9•11 years ago
|
||
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
OS: Mac OS X → All
Comment 10•11 years ago
|
||
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
Blocks: 911786
tracking-firefox26:
--- → ?
tracking-firefox27:
--- → ?
Keywords: regressionwindow-wanted → regression
Updated•11 years ago
|
Version: unspecified → 26 Branch
Comment 11•11 years ago
|
||
Alice0775, thank you!
Comment 12•11 years ago
|
||
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)
Comment 13•11 years ago
|
||
I can repro (occasionally) by visiting... data:text/html,<textarea> ...and and performing Alice0775's STR there.
Comment 14•11 years ago
|
||
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
Updated•11 years ago
|
Component: Layout: Form Controls → Layout: Text
Comment 15•11 years ago
|
||
Updated•11 years ago
|
Attachment #805737 -
Attachment description: screen shot (it happens ion normal webpage) → screen shot (it happens on normal webpage)
Updated•11 years ago
|
Summary: Many glitches in <textarea> → Many glitches in <textarea> and webpage
Assignee | ||
Comment 16•11 years ago
|
||
Attachment #805745 -
Flags: review?(dholbert)
Assignee | ||
Updated•11 years ago
|
Assignee: nobody → dbaron
Status: NEW → ASSIGNED
Assignee | ||
Comment 17•11 years ago
|
||
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.
Attachment #805746 -
Flags: review?(dholbert)
Assignee | ||
Updated•11 years ago
|
Attachment #805745 -
Attachment is obsolete: true
Attachment #805745 -
Flags: review?(dholbert)
Assignee | ||
Comment 18•11 years ago
|
||
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.
Attachment #805750 -
Flags: review?(dholbert)
Assignee | ||
Updated•11 years ago
|
Attachment #805746 -
Attachment is obsolete: true
Attachment #805746 -
Flags: review?(dholbert)
Assignee | ||
Comment 19•11 years ago
|
||
https://tbpl.mozilla.org/?tree=Try&rev=c2448e8b0ae5
Comment 20•11 years ago
|
||
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.
Attachment #805750 -
Flags: review?(dholbert) → review+
Comment 21•11 years ago
|
||
sorry: s/can't fails/fails/. (originally said "can't land without this patch" & made edit typo)
Assignee | ||
Comment 22•11 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/8050ed3e50f5
Flags: in-testsuite?
Assignee | ||
Comment 23•11 years ago
|
||
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
Attachment #805750 -
Flags: approval-mozilla-aurora?
Comment 25•11 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/8050ed3e50f5
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla27
Assignee | ||
Comment 29•11 years ago
|
||
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
Comment 31•11 years ago
|
||
verified fixed in nightly 20130918030202 Mozilla/5.0 (Windows NT 6.1; rv:27.0) Gecko/20100101 Firefox/27.0
Keywords: verifyme
Updated•11 years ago
|
status-firefox25:
--- → unaffected
status-firefox26:
--- → affected
status-firefox27:
--- → fixed
tracking-firefox27:
? → ---
Updated•11 years ago
|
Attachment #805750 -
Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Assignee | ||
Comment 33•11 years ago
|
||
https://hg.mozilla.org/releases/mozilla-aurora/rev/916b70165ece
Updated•11 years ago
|
QA Contact: twalker
Whiteboard: [good first verify]
Comment 36•11 years ago
|
||
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…
Comment 37•11 years ago
|
||
Verified fixed in Nightly 27.0a1 buildid 20131007030203, Aurora 26.0a2 buildid 20131007004003.
Status: RESOLVED → VERIFIED
Keywords: verifyme
Updated•10 years ago
|
QA Contact: twalker
Whiteboard: [good first verify]
You need to log in
before you can comment on or make changes to this bug.
Description
•