Try resizing the first textarea here: https://bug82711.bugzilla.mozilla.org/attachment.cgi?id=36296 If I were a mean person, I would blame DLBI patches landed yesterday!
Not obviously something that my patches would have caused, and flipping the disable pref for the biggest change doesn't fix it. Worth getting a regression window for this.
CCing Alice who knows all of the bisection magic!
I can reproduce in Aurora16.a2 and Nightly17.0a1 with/without HWA. #1 Initial-Regression window(m-i) Good: http://hg.mozilla.org/integration/mozilla-inbound/rev/daf9c42be518 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/16.0 Firefox/16.0 ID:20120623010444 Bad: http://hg.mozilla.org/integration/mozilla-inbound/rev/ad006bd70b37 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/16.0 Firefox/16.0 ID:20120623060947 Pushlog: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=daf9c42be518&tochange=ad006bd70b37 #2 Progression window(m-i) Bad: http://hg.mozilla.org/integration/mozilla-inbound/rev/0d9f7fb55226 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/16.0 Firefox/16.0 ID:20120629192951 Working again http://hg.mozilla.org/integration/mozilla-inbound/rev/cd6d52bdf2d8 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/16.0 Firefox/16.0 ID:20120629200651 Pushlog: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=0d9f7fb55226&tochange=cd6d52bdf2d8 #3 Re-Regression window(m-i) Good: http://hg.mozilla.org/integration/mozilla-inbound/rev/de483b66eb94 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/16.0 Firefox/16.0 ID:20120703174600 Broken again http://hg.mozilla.org/integration/mozilla-inbound/rev/0a009343d59d Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/16.0 Firefox/16.0 ID:20120703175500 Pushlog: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=de483b66eb94&tochange=0a009343d59d
Awesome, thanks Alice! Looks like a regression from bug 716875 which was temporarily fixed by DLBI (until it got backed out again). CC'ing relevant people.
>#1 Initial-Regression window(m-i) Gray vertical border remains when I extend the width of the textarea, However, before #1 regression,there is rendering bug where white dots are left in the top border when I extend the width of the textarea since Fireox4.
Hmm so I don't really know what could caused that. I'm ok to work on that but I think I'll need a hand to really understand. I guess that's caused by something wrong in the reflow....
We're probably using the visual overflow rect to invalidate, and it's not big enough to cover all the pixel that get painted. I'd start by checking what's different with the calculation of that.
Hmm that's clearer for me I'll have a look too tomorrow
Created attachment 655552 [details] test case This is just the test case that was given with a bigger border. It seems that the border is not included in the visual-overflow rect... So I would think it comes from nsControlFrame::reflow maybe we lose the border when we UnionWith in ReflowTextControlChild? I'm honestly a bit lost on that if somebody could help me.
I just stepped through nsTextControlFrame::Reflow, and at the end the overflow areas sure seem to match the actual frame size....
The problem is that there's no CheckInvalidateSizeChange in nsTextControlFrame::Reflow. Which is why DLBI fixes this, of course.
Created attachment 655616 [details] [diff] [review] Resizing a text control frame with borders should invalidate the borders as needed. Not sure how to write a test for this....
5 years ago
Comment on attachment 655616 [details] [diff] [review] Resizing a text control frame with borders should invalidate the borders as needed. [Approval Request Comment] Bug caused by (feature/regressing bug #): Bug 716875 User impact if declined: Turds when textareas are resized Testing completed (on m-c, etc.): Passes manual tests. Risk to taking this patch (and alternatives if risky): Risk is low; the worst case would be an overinvalidation leading to performance issues, but that should be pretty unlikely: we use CheckInvalidateSizeChange pretty extensively already. String or UUID changes made by this patch: I know better by now. None. ;)
Backout from Beta: http://hg.mozilla.org/releases/mozilla-beta/rev/6f7d29816c57
You meant "unaffected": the bug that caused this one was backed out too. But maybe it should have stayed "fixed". Who knows. In any case, "affected" is wrong.
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Firefox/17.0 Verified that there are no rendering glitches on Firefox 17 beta 3 when resizing a textarea with rows and cols attributes (used the test cases attached in the Description and in Comment 9).
WFM with ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/18.0b1-candidates/build1/linux-x86_64/ru/ , compared to 2012-08-27-03-05-49-mozilla-central-firefox-17.0a1.ru.linux-x86_64
mass remove verifyme requests greater than 4 months old