Bug 150982 – Web Inspector: Add View.prototype.contentElement, to protect the "private" part of the view's DOM

• Status: NEW
• Component: Web Inspector

[Matt Baker]

* 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.

[Matt Baker]

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

[Radar WebKit Bug Importer]

<rdar://problem/23888254>