WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED WONTFIX
43348
Introduce more explicit types into the rendering tree
https://bugs.webkit.org/show_bug.cgi?id=43348
Summary
Introduce more explicit types into the rendering tree
Eric Seidel (no email)
Reported
2010-08-02 07:42:24 PDT
Introduce more explicit types into the rendering tree
Attachments
work in progress
(82.58 KB, patch)
2010-08-02 07:42 PDT
,
Eric Seidel (no email)
no flags
Details
Formatted Diff
Diff
wip renderer
(139.20 KB, patch)
2010-08-04 13:23 PDT
,
Eric Seidel (no email)
no flags
Details
Formatted Diff
Diff
Show Obsolete
(1)
View All
Add attachment
proposed patch, testcase, etc.
Eric Seidel (no email)
Comment 1
2010-08-02 07:42:46 PDT
Created
attachment 63216
[details]
work in progress
Eric Seidel (no email)
Comment 2
2010-08-02 07:46:56 PDT
I am very interested in Darin and Hyatt's comments on this approach. The goal was to start moving the code towards stronger typed pointers (RenderBoxModelObject* instead of RenderObject*) so we could move more code down into RenderBoxModelObject (and eventually RenderBox and RenderBlock) instead of it all being on RenderObject. I chose this approach to try and leverage the compiler as much as possible. Moving "is-a" functions onto RenderBoxModelObject makes the compiler point out to me places where we have a RenderObject but secretly know it's a RenderBoxModelObject. Moving the "is-a" functions first also prevents further creep of RenderObject pointers. I also learned from this exercise that our Accessibility code is poor shape, wrt the rest of WebKit. It's especially abusive of the Render tree and I expect we could find a bunch of bad static_cast-turn-security bug holes as a result.
Darin Adler
Comment 3
2010-08-02 15:28:15 PDT
(In reply to
comment #2
)
> The goal was to start moving the code towards stronger typed pointers (RenderBoxModelObject* instead of RenderObject*) so we could move more code down into RenderBoxModelObject (and eventually RenderBox and RenderBlock) instead of it all being on RenderObject.
Seems OK. But functions that walk the tree still end up returning RenderObject* since that's the type of parent and firstChild.
> I chose this approach to try and leverage the compiler as much as possible. Moving "is-a" functions onto RenderBoxModelObject makes the compiler point out to me places where we have a RenderObject but secretly know it's a RenderBoxModelObject.
I have often done this myself, but you don’t have to check in such changes for them to do their thing.
> Moving the "is-a" functions first also prevents further creep of RenderObject pointers.
As long as it doesn't make common operations awkward, more specific types are good.
Eric Seidel (no email)
Comment 4
2010-08-04 13:23:19 PDT
Created
attachment 63486
[details]
wip renderer
Eric Seidel (no email)
Comment 5
2010-08-04 13:24:01 PDT
The patch compiles now. I'm going to need to run the layout tests and then split it up into pieces.
Eric Seidel (no email)
Comment 6
2011-05-17 10:55:07 PDT
I should come back to this at some point. This effort helped me find a couple bad-casts in the AX code iirc.
Eric Seidel (no email)
Comment 7
2011-06-05 10:46:45 PDT
I actually didn't mean to close this bug, I meant to close another one... but this should probably be closed too. This patch is too old to be useful.
Levi Weintraub
Comment 8
2011-06-06 10:50:17 PDT
This is awesome, but just way too *big*! It'd be great if we could pair it down to something more manageable.
Eric Seidel (no email)
Comment 9
2011-06-06 10:54:41 PDT
Feel free to knock yourself out. :)
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