[Webkit-unassigned] [Bug 146256] New: Web Inspector: Nested ContentBrowsers / ContentViewContainers cause too many ContentView updates

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=146256

            Bug ID: 146256
           Summary: Web Inspector: Nested ContentBrowsers /
                    ContentViewContainers cause too many ContentView
                    updates
    Classification: Unclassified
           Product: WebKit
           Version: 528+ (Nightly build)
          Hardware: All
                OS: All
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Web Inspector
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: joepeck at webkit.org
                CC: burg at cs.washington.edu, graouts at webkit.org,
                    joepeck at webkit.org, jonowells at apple.com,
                    mattbaker at apple.com, nvasilyev at apple.com,
                    timothy at apple.com, webkit-bug-importer at group.apple.com

* SUMMARY
Nested ContentBrowsers / ContentViewContainers cause too many ContentView updates.

For resources the View hierarchy looks something like this:

  - TabBrowser
    - ContentViewContainer
      - ResourcesTabContentView (1) (ContentBrowserTabContentView with a ContentBrowser)
        - ContentViewContainer
          - ResourceClusterContentView (2) (ClusterContentView)
            - ContentViewContainer
              - TextResourceContentView (3)
                - TextEditor

In the process of showing each of the 3 ContentViews, actions are taken on its sub-views that repeat over and over depending on the nested level. ContentViewContainer.showContentView triggers BackForwardEntry.prepareToShow, and BackForwardEntry.prepareToShow triggers multiple actions which may cascade:

    - _restoreFromCookie() may cascade actions to sub ContentViews
    - shown() may cascade actions to sub ContentViews
    - updateLayout() may cascade actions to sub ContentViews

This situation is not ideal! It would be much better to reduce duplication of work here.

* STEPS TO REPRODUCE
1. Load <http://apple.com>
2. Show page source (Web Inspector, Resources Tab, Main Resource selected)
3. Scroll down the text editor
4. Switch to the Elements tab
5. Switch back to the Resources tab
  => updateLayout was called 6+ times on the TextEditor

* NOTES
- Here are annotations of the different updateLayout calls I saw in this case:
    1. prepareToShow ResourceClusterContentView triggers restoreFromCookie/showContentView for the TextResourceContentView (call shown false) and updateLayout
    2. prepareToShow->shown ResourceClusterContentView triggers shown for the TextResourceContentView (call shown true) and updateLayout
    3. prepareToShow->shown ResourceClusterContentView triggers another showContentView for TextResourceContentView (call shown false) and updateLayout
    4. prepareToShow->updateLayout ResourceClusterContentView triggers another updateLayout for TextResourceContentView
    5. prepareToShow->updateLayout Tab ContentView triggers another updateLayout down the cascade to TextResourceContentView
    6. Left Sidebar opening (I came from Elements -> Resources) triggers another updateLayout
    7. Quick Console claims it resized (probably didn't) triggers another updateLayout

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20150623/ee30a5aa/attachment.html>