Bug 149682 – Web Inspector: Thousands of timers fire after switching to JavaScript and Events timeline

• Status: RESOLVED
• Resolution: FIXED
• Component: Web Inspector

[Joseph Pecoraro]

* SUMMARY
Thousands of timers fire after switching to JavaScript and Events timeline.

The UI is slow and frequently unresponsive while interacting with the timeline while these timers fire. For instance scroll synchronization (which uses timers) doesn't get synchronized until all of the previously queued timers are exhausted. That can take 30+ seconds for a large profile.

* STEPS TO REPRODUCE
1. Inspect apple.com
2. Timeline tab
3. Reload
4. Click "JavaScript & Events"
  => try to scroll the data grid after it shows up

* NOTES
- Many many TreeElement onchange events spawned by the "status" of the GeneralTreeElement changing. Seems we don't even need to trigger a treeOutline.onchange for that.

[Radar WebKit Bug Importer]

<rdar://problem/22924064>

[Joseph Pecoraro]

Created attachment 262200 [details]
[PATCH] Proposed Fix

[Timothy Hatcher]

Comment on attachment 262200 [details]
[PATCH] Proposed Fix

Do the close status elements still work? I think I added these to make those close elements work.

[Joseph Pecoraro]

(In reply to comment #3)
> Comment on attachment 262200 [details]
> [PATCH] Proposed Fix
> 
> Do the close status elements still work? I think I added these to make those
> close elements work.

Yes, I tested this a bunch but never encountered an issue. Wherever there is a goto arrow, loading a content view produces a close button to go back. I tested in the overview timeline, network timeline and tab, and JS & Events timeline.

[WebKit Commit Bot]

Comment on attachment 262200 [details]
[PATCH] Proposed Fix

Clearing flags on attachment: 262200

Committed r190377: <http://trac.webkit.org/changeset/190377>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.