Closed Bug 916751 Opened 11 years ago Closed 11 years ago

Many glitches in <textarea> and webpage

Categories

(Core :: Layout: Text and Fonts, defect)

26 Branch
defect
Not set
normal

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)

Attached image Screenshot
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?
Flags: needinfo?(dteller)
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
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
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
OS: Mac OS X → All
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
Version: unspecified → 26 Branch
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.
Attached file text1.txt
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
Component: Layout: Form Controls → Layout: Text
Attachment #805737 - Attachment description: screen shot (it happens ion normal webpage) → screen shot (it happens on normal webpage)
Summary: Many glitches in <textarea> → Many glitches in <textarea> and webpage
Assignee: nobody → dbaron
Status: NEW → ASSIGNED
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)
Attachment #805745 - Attachment is obsolete: true
Attachment #805745 - Flags: review?(dholbert)
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)
Attachment #805746 - Attachment is obsolete: true
Attachment #805746 - Flags: review?(dholbert)
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+
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
Attachment #805750 - Flags: approval-mozilla-aurora?
https://hg.mozilla.org/mozilla-central/rev/8050ed3e50f5
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla27
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
Keywords: verifyme
Attachment #805750 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
QA Contact: twalker
Whiteboard: [good first verify]
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.
Status: RESOLVED → VERIFIED
Keywords: verifyme
QA Contact: twalker
Whiteboard: [good first verify]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: