WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED CONFIGURATION CHANGED
13443
FIXME: computeAbsoluteRepaintRect() ignores control clip rects
https://bugs.webkit.org/show_bug.cgi?id=13443
Summary
FIXME: computeAbsoluteRepaintRect() ignores control clip rects
mitz
Reported
2007-04-21 22:50:06 PDT
[Following up on
bug 13391
]. RenderBox::computeAbsoluteRepaintRect() ignores the lightweight clip used by some form controls, the reason being that when it's called during layout, controlClipRect() returns a wrong result. In the context of a child of the control repainting during layout, you need the control's clip rect before layout. I have considered several ways to fix this: 1) Cache the clip rects in the controls themselves post layout(). This is a very fast and simple solution, but it increases the memory footprint of controls for information that's basically needed only during layout. 2) Cache the clip rects in a hash table kept in the RenderView. Controls can cache their current clip rect when entering layout() and delete it from the hash before returning from layout(). 3) Similar to 2) but use a stack, so each control pushes its clip rect onto the stack. Since controls are very rarely nested, computeAbsoluteRepaintRect() could simply walk the stack looking for |o| (no need to pass the current stack pointer when recurring). 4) Maintain a true clipping rect stack in RenderView, including the "current clip", and pushing both control clip and layer clip. This will fix
bug 11489
as well. The disadvantage of 2-4 is the complexity, which includes having to keep a "during layout" code path separate from the "after layout" code path. I'd go with 1) or 2), assuming
bug 11489
will be addressed by flexbox changes.
Attachments
Controls only clip children's foreground
(501 bytes, text/html)
2007-04-22 08:43 PDT
,
mitz
no flags
Details
All browser differs
(619.08 KB, image/png)
2022-06-20 16:50 PDT
,
Ahmad Saleem
no flags
Details
View All
Add attachment
proposed patch, testcase, etc.
mitz
Comment 1
2007-04-21 22:54:47 PDT
On second thought, I like 3) better than 2).
mitz
Comment 2
2007-04-22 08:43:41 PDT
Created
attachment 14136
[details]
Controls only clip children's foreground I had written a patch and when I wanted to test it I realized that control clip is applied only to the children's foreground. I think it's a bug, but if it isn't, then this bug is INVALID.
mitz
Comment 3
2007-04-23 04:18:13 PDT
(In reply to
comment #2
)
> I think it's a bug
Bug 13453
.
Ahmad Saleem
Comment 4
2022-06-20 16:50:30 PDT
Created
attachment 460357
[details]
All browser differs I am not able to determine expected result across all browsers since all browser slightly differ. Chrome and Firefox are matched mostly except font rendering or text is strange and fits differently from each other in the <div>. As for Safari 15.5, it is vastly different from other browsers as shown in the attached screenshots. Thanks!
Radar WebKit Bug Importer
Comment 5
2022-06-20 16:51:03 PDT
<
rdar://problem/95557957
>
Ryosuke Niwa
Comment 6
2022-06-20 22:18:43 PDT
Firefox & Chrome are basically matching so we're the only engine to fail this test case now.
Ahmad Saleem
Comment 7
2023-02-25 08:00:57 PST
Safari Technology Preview 164 is also matching somewhat (text related differences) with Chrome Canary 112 and Firefox Nightly 112 and don't clip overflowing stuff. Marking this as "RESOLVED CONFIGURATION CHANGED". Please reopen, if the text display is also part of this bug. Thanks!
mitz
Comment 8
2023-02-25 08:03:01 PST
Seems OK to me.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug