Bug 150982 - Web Inspector: Add View.prototype.contentElement, to protect the "private" part of the view's DOM
Summary: Web Inspector: Add View.prototype.contentElement, to protect the "private" pa...
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: Web Inspector (show other bugs)
Version: WebKit Nightly Build
Hardware: All All
: P2 Normal
Assignee: Matt Baker
URL:
Keywords: InRadar
Depends on:
Blocks: 151126
  Show dependency treegraph
 
Reported: 2015-11-06 16:00 PST by Matt Baker
Modified: 2016-12-13 15:35 PST (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Matt Baker 2015-11-06 16:00:17 PST
* SUMMARY
Add View.prototype.contentElement, to protect the "private" part of the view's DOM. There are two advantages to doing this:

1) Views with scrollbars and other chrome cannot be broken by a subclass naively calling this.element.removeChildren().
2) The view's root element, and the element to which subviews and other elements are added by subclasses and other clients are not always the same.

Proposal:

1) A new contentElement property will be added to View. It will be the logical container to which subviews and other DOM elements are added. View's implicit contract guarantees that DOM mutations can safely be done to contentElement without breaking other parts of the view.
2) View.prototype.element will remain the view's root DOM element. It is appended to the parent view's contentElement, and may be styled by subclasses and other clients (as is currently the case).
3) A view begins life with element === contentElement. It's the responsibility of each subclass to create a separate contentElement, if needed.
4) Each class in a view's hierarchy may have a different contentElement. This is an implementation detail used by addSubview and friends. To view clients there is a single contentElement, which is that of the most derived class.
Comment 1 Matt Baker 2015-12-14 13:49:52 PST
Building this functionality into class View might be overkill. For the following cases it's straightforward to just create a "contentView" with a public getter:

- TimelineOverivew: graphContainerElement (fixed in https://webkit.org/b/152235)
- SidebarPanel: contentElement -> contentView
- DetailsSection: contentElement -> contentView
- ScrollableView: will need a content view to hide scrollbars, etc, from derived classes and view clients.
- Popovers
Comment 2 Radar WebKit Bug Importer 2015-12-14 13:50:15 PST
<rdar://problem/23888254>