Intent to refactor: removal of Widget class

16 views
Skip to first unread message

Walter

unread,
Aug 11, 2016, 7:34:14 PM8/11/16
to blink-dev, layou...@chromium.org, platform-architecture-dev
TL;DR = wkorman@/szager@ are working on removing the Widget class. We expect to modify the Frame tree to support everything that's currently done with the Widget tree.

This was partly prompted by desire to further centralize the geometry logic. See also http://crbug.com/634143.

Brief history and rationale notes:
- a longstanding goal among Blink developers
- considered no longer a useful abstraction. Has morphed into a grab bag of functionality.
- encompasses logic re: frameview, plugin, scrollbar.
- easy to find dead code on detailed tracing/investigation, two examples
- source of subtle bugs related to code that walks widget hierarchy when it should be walking the frame hierarchy, or vice versa

The end result should not produce any change in behavior, but may intersect with other efforts, so we wanted to let folks know that this work is underway.

Chris Harrelson

unread,
Aug 11, 2016, 8:36:35 PM8/11/16
to Walter, blink-dev, layou...@chromium.org, platform-architecture-dev
On Thu, Aug 11, 2016 at 4:34 PM, Walter <wko...@chromium.org> wrote:
TL;DR = wkorman@/szager@ are working on removing the Widget class. We expect to modify the Frame tree to support everything that's currently done with the Widget tree.

Frame and Layout trees, right? e.g. existing Widget geometry methods will delegate to the layout tree, as indicated in crbug.com/634143.
 

This was partly prompted by desire to further centralize the geometry logic. See also http://crbug.com/634143.

Brief history and rationale notes:
- a longstanding goal among Blink developers
- considered no longer a useful abstraction. Has morphed into a grab bag of functionality.
- encompasses logic re: frameview, plugin, scrollbar.
- easy to find dead code on detailed tracing/investigation, two examples
- source of subtle bugs related to code that walks widget hierarchy when it should be walking the frame hierarchy, or vice versa

The end result should not produce any change in behavior, but may intersect with other efforts, so we wanted to let folks know that this work is underway.

--
You received this message because you are subscribed to the Google Groups "layout-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to layout-dev+unsubscribe@chromium.org.
To post to this group, send email to layou...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/layout-dev/38e88603-a1b4-43cd-9022-2a042b6d0914%40chromium.org.

Walter

unread,
Aug 11, 2016, 8:49:46 PM8/11/16
to blink-dev, wko...@chromium.org, layou...@chromium.org, platform-arc...@chromium.org, chri...@chromium.org
On Thursday, August 11, 2016 at 5:36:39 PM UTC-7, Chris Harrelson wrote:


On Thu, Aug 11, 2016 at 4:34 PM, Walter <wko...@chromium.org> wrote:
TL;DR = wkorman@/szager@ are working on removing the Widget class. We expect to modify the Frame tree to support everything that's currently done with the Widget tree.

Frame and Layout trees, right? e.g. existing Widget geometry methods will delegate to the layout tree, as indicated in crbug.com/634143.

Yes, that's correct.

 
Reply all
Reply to author
Forward
0 new messages