Closed
Bug 323291
Opened 19 years ago
Closed 19 years ago
Painting bug with absolute positioned testcase
Categories
(Core :: Web Painting, defect)
Core
Web Painting
Tracking
()
RESOLVED
FIXED
People
(Reporter: martijn.martijn, Assigned: roc)
References
Details
(Keywords: regression, testcase)
Attachments
(2 files)
642 bytes,
text/html
|
Details | |
4.46 KB,
patch
|
bzbarsky
:
review+
bzbarsky
:
superreview+
|
Details | Diff | Splinter Review |
See upcoming testcase, you should only see two 20px by 20px boxes, one red and one green. In current trunk builds though, the red one stays much larger. It is a regression, it doesn't happen in Mozilla1.7 builds (Ria, could you find the regression date?)
Reporter | ||
Comment 1•19 years ago
|
||
Comment 2•19 years ago
|
||
Between 20-May-2004:14 and 22-May-2004:09 http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=PhoenixTinderbox&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2004-05-20+13%3A00%3A00&maxdate=2004-05-22+09%3A00%3A00&cvsroot=%2Fcvsroot
Reporter | ||
Comment 3•19 years ago
|
||
In that case, I think this is a regression from bug 243882.
Blocks: 243882
Updated•19 years ago
|
OS: Windows XP → All
Hardware: PC → All
Comment 4•19 years ago
|
||
The big red box changes to 20x20px if you resize the window. Also, parts of the red box will dissappear if you drag another application above it.
Assignee | ||
Comment 5•19 years ago
|
||
The problem is that we were relying on resizing the view to invalidate the area covered by the frame size change (see the comment deleted in this patch), but that doesn't work when overflowing content means the view size doesn't change even though the frame size did. So this patch adds code to invalidate the difference between the old and new areas, currently conditional on the frame not moving, since if it moves the view system will invalidate everything. After the reflow branch lands, I really need to rethink the way we invalidate during reflow. We currently have an inconsistent mess, and I think it could be much simpler.
Attachment #208608 -
Flags: superreview?(bzbarsky)
Attachment #208608 -
Flags: review?(bzbarsky)
![]() |
||
Comment 6•19 years ago
|
||
Comment on attachment 208608 [details] [diff] [review] fix r+sr=bzbarsky; let's get that followup bug filed and marked [reflow-refactor] and mention this code in it, ok?
Attachment #208608 -
Flags: superreview?(bzbarsky)
Attachment #208608 -
Flags: superreview+
Attachment #208608 -
Flags: review?(bzbarsky)
Attachment #208608 -
Flags: review+
Assignee | ||
Comment 7•19 years ago
|
||
checked in. Filed bug 323574 about the general problems.
Assignee | ||
Comment 8•19 years ago
|
||
oops, this is actually fixed.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Comment 9•19 years ago
|
||
When loading the testcase the red box starts off at the (incorrect) huge size for a blink-of-an-eye before being redrawn at the correct size. Is this expected behaviour? (I just wonder in case bugs about flickering whilst webpages loading get filed due to this)
![]() |
||
Comment 10•19 years ago
|
||
Testcase says: window.onload=function(){ setTimeout(doe,10); } Onload fires after initial layout and paint.
Comment 11•19 years ago
|
||
(In reply to comment #9) > When loading the testcase the red box starts off at the (incorrect) huge size > for a blink-of-an-eye before being redrawn at the correct size. Is this > expected behaviour? (I just wonder in case bugs about flickering whilst > webpages loading get filed due to this) > In branch, the red one stays large while the green one stays small. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20060117 Firefox/1.5 ID:2006011703
Reporter | ||
Comment 12•19 years ago
|
||
(In reply to comment #11) > In branch, the red one stays large while the green one stays small. That's because it is fixed on trunk, not on branch.
Comment 13•18 years ago
|
||
(In reply to comment #12) > (In reply to comment #11) > > In branch, the red one stays large while the green one stays small. > That's because it is fixed on trunk, not on branch. > Which begs the question of whether it should be reopened for Version: ALL
![]() |
||
Comment 14•18 years ago
|
||
> Which begs the question of whether it should be reopened for Version: ALL
No, it doesn't. Please go read up on the difference between trunk and branch, ok?
Updated•6 years ago
|
Component: Layout: View Rendering → Layout: Web Painting
You need to log in
before you can comment on or make changes to this bug.
Description
•