Bug 13544 - REGRESSION (r21120): Member profile frame not erased at Yahoo! Answers
Summary: REGRESSION (r21120): Member profile frame not erased at Yahoo! Answers
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Layout and Rendering (show other bugs)
Version: 523.x (Safari 3)
Hardware: Macintosh OS X 10.4
: P1 Normal
Assignee: Nobody
URL: http://answers.yahoo.com/question/ind...
Keywords: HasReduction, Regression
Depends on:
Blocks:
 
Reported: 2007-04-29 15:16 PDT by mitz
Modified: 2007-04-29 22:58 PDT (History)
0 users

See Also:


Attachments
Reduction (576 bytes, text/html)
2007-04-29 16:14 PDT, mitz
no flags Details
Repaint layers becoming invisible even if they also need layout (10.41 KB, patch)
2007-04-29 16:39 PDT, mitz
hyatt: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description mitz 2007-04-29 15:16:58 PDT
Repaint regression, probably introduced in <http://trac.webkit.org/projects/webkit/changeset/21120>: open the URL and hover over a member's avatar and wait for the member info box to appear, then move the mouse away to make the box disappear. Three sides of the gray frame remain visible until you force a repaint.
Comment 1 mitz 2007-04-29 16:14:37 PDT
Created attachment 14271 [details]
Reduction

Layers need to repaint when turning invisible.
Comment 2 mitz 2007-04-29 16:39:42 PDT
Created attachment 14272 [details]
Repaint layers becoming invisible even if they also need layout

Includes change log and repaint test.
Comment 3 Dave Hyatt 2007-04-29 17:41:36 PDT
Random unrelated question, but why did your previous change remove a setNeedsLayout(false) call?  Was it redundant?
Comment 4 Dave Hyatt 2007-04-29 17:43:25 PDT
Comment on attachment 14272 [details]
Repaint layers becoming invisible even if they also need layout

r=me
Comment 5 Mark Rowe (bdash) 2007-04-29 20:49:35 PDT
Landed in r21186.
Comment 6 mitz 2007-04-29 22:42:53 PDT
(In reply to comment #3)
> Random unrelated question, but why did your previous change remove a
> setNeedsLayout(false) call?  Was it redundant?
> 

layoutBlockChildren uses the logic that "we don't need to repaint children if the parent needs layout, because in that case it will do a full repaint". But by resetting the bit in layoutBlockChildren it was invalidating this logic since by the time layoutBlock called repaintAfterLayoutIfNeeded, the latter couldn't tell that it needed to do a full repaint. I think I explained it in my ChangeLog ;-) and it's covered by one of the repaint tests IIRC.
Comment 7 Dave Hyatt 2007-04-29 22:58:01 PDT
Reading ChangeLogs is hard.