Closed
Bug 75739
Opened 24 years ago
Closed 21 years ago
InnerFrame paints BG incorrectly
Categories
(Core :: Layout: Images, Video, and HTML Frames, defect)
Tracking
()
RESOLVED
WORKSFORME
Future
People
(Reporter: rods, Assigned: john)
References
Details
(Keywords: perf)
Outerframe makes two calls that causes the InnerFrame to be painted twice. The
InnerFrame's paint paints the rect at mRect coords.
The first time it paints this is the correct location, the second time it paints
via OuterFrames call to nsHTMLContainerFrame::Paint it paint incorrectly,
meaning it really ought to be painting at 0,0,mRect.width,mRect.height.
See the code below, but it is confusing as to why it does the paint of the first
child and then call the paint for the container. My feeling is that the first
call should be removed in OuterFrame paint and the InnerFrame should paint at
0,0,mRect.width,mRect.height
(NOTE: I have filed bug 75737 on this same issue (but for printing only) and
will use that bug to put in a temporary fix until you can figure this out and
get it checked in. Please remove the temporary fix when you check this fix in.
NS_IMETHODIMP
nsHTMLFrameOuterFrame::Paint(nsIPresContext* aPresContext,
nsIRenderingContext& aRenderingContext,
const nsRect& aDirtyRect,
nsFramePaintLayer aWhichLayer)
{
//printf("outer paint %X (%d,%d,%d,%d) \n", this, aDirtyRect.x, aDirtyRect.y,
aDirtyRect.width, aDirtyRect.height);
nsIFrame* firstChild = mFrames.FirstChild();
if (nsnull != firstChild) {
firstChild->Paint(aPresContext, aRenderingContext, aDirtyRect,
aWhichLayer);
}
if (IsInline()) {
return nsHTMLContainerFrame::Paint(aPresContext, aRenderingContext,
aDirtyRect, aWhichLayer);
} else {
return NS_OK;
}
}
Comment 1•24 years ago
|
||
Reassigning to pollman and changing component from layout to html frames.
Assignee: karnaze → pollmann
Component: Layout → HTMLFrames
Updated•24 years ago
|
Target Milestone: --- → mozilla0.9.2
Updated•24 years ago
|
Target Milestone: mozilla0.9.2 → mozilla0.9.3
Comment 2•24 years ago
|
||
Doesn't look like this is getting fixed before the freeze tonight.
Pushing out a milestone. Please correct if I'm mistaken.
Target Milestone: mozilla0.9.3 → mozilla0.9.4
Updated•24 years ago
|
Target Milestone: mozilla0.9.4 → mozilla0.9.6
Comment 3•24 years ago
|
||
Bulk reassignin HTML FRAME/IFRAME bugs to Eric.
Assignee: pollmann → evaughan
Updated•24 years ago
|
Status: NEW → ASSIGNED
Target Milestone: mozilla0.9.6 → mozilla0.9.7
Comment 4•24 years ago
|
||
Bulk re-assigning all of Eric's HTMLFrame bugs to John.
Assignee: eric → jkeiser
Status: ASSIGNED → NEW
Updated•24 years ago
|
Severity: major → normal
Target Milestone: mozilla0.9.8 → mozilla1.0.1
![]() |
||
Comment 6•22 years ago
|
||
roc, I assume your innerframe removal makes this bug all better?
Depends on: 212366
Yeah, although I'm not completely sure without a testcase.
![]() |
||
Comment 8•21 years ago
|
||
No testcase, the code involved is gone... marking worksforme.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → WORKSFORME
Updated•7 years ago
|
Product: Core → Core Graveyard
Updated•7 years ago
|
Component: Layout: HTML Frames → Layout: Images
Product: Core Graveyard → Core
You need to log in
before you can comment on or make changes to this bug.
Description
•