RESOLVED FIXED 195317
Web Inspector: recordsInTimeRange sometimes does not get the expected record when includeRecordBeforeStart
https://bugs.webkit.org/show_bug.cgi?id=195317
Summary Web Inspector: recordsInTimeRange sometimes does not get the expected record ...
Joseph Pecoraro
Reported 2019-03-05 00:58:35 PST
recordsInTimeRange sometimes does not get the expected record when includeRecordBeforeStart For example, when the before record is a composite of a bunch of paints: - Composite: - Paint: ... - Paint: ... - Paint: ... - Paint: ... Currently we get the inner Paint, but that isn't as useful as the Composite, which may be much longer in duration. Steps to Reproduce: 1. Record CPU Timeline on maps.google.com zooming in/out 2. Select part of the large composite and view the CPU Timeline graph => Main Thread indicator doesn't see paints when it should
Attachments
[PATCH] Proposed Fix (1.87 KB, patch)
2019-03-05 00:59 PST, Joseph Pecoraro
no flags
Archive of layout-test-results from ews124 for ios-simulator-wk2 (3.13 MB, application/zip)
2019-03-05 03:09 PST, EWS Watchlist
no flags
Joseph Pecoraro
Comment 1 2019-03-05 00:59:09 PST
Created attachment 363616 [details] [PATCH] Proposed Fix
Devin Rousso
Comment 2 2019-03-05 02:13:37 PST
Comment on attachment 363616 [details] [PATCH] Proposed Fix View in context: https://bugs.webkit.org/attachment.cgi?id=363616&action=review r=me > Source/WebInspectorUI/UserInterface/Models/Timeline.js:116 > + lowerIndex--; You could make this into a do-while :) > Source/WebInspectorUI/UserInterface/Models/Timeline.js:117 > + while (this._records[lowerIndex] !== recordBefore.parent) Is it guaranteed that we'd eventually reach the parent record, or should we also add `&& this._records[lowerIndex].type === recordBefore.parent.type` so it's a bit more restrictive?
EWS Watchlist
Comment 3 2019-03-05 03:09:07 PST
Comment on attachment 363616 [details] [PATCH] Proposed Fix Attachment 363616 [details] did not pass ios-sim-ews (ios-simulator-wk2): Output: https://webkit-queues.webkit.org/results/11375599 New failing tests: fast/scrolling/ios/hit-testing-iframe-002.html fast/images/imagemap-polygon-focus-ring.html fast/scrolling/ios/hit-testing-iframe-003.html editing/selection/thai-word-at-document-end.html fast/scrolling/ios/mixing-user-and-programmatic-scroll-006.html
EWS Watchlist
Comment 4 2019-03-05 03:09:09 PST
Created attachment 363629 [details] Archive of layout-test-results from ews124 for ios-simulator-wk2 The attached test failures were seen while running run-webkit-tests on the ios-sim-ews. Bot: ews124 Port: ios-simulator-wk2 Platform: Mac OS X 10.13.6
Joseph Pecoraro
Comment 5 2019-03-05 16:14:39 PST
Comment on attachment 363616 [details] [PATCH] Proposed Fix View in context: https://bugs.webkit.org/attachment.cgi?id=363616&action=review >> Source/WebInspectorUI/UserInterface/Models/Timeline.js:116 >> + lowerIndex--; > > You could make this into a do-while :) True, I thought this was clearer. >> Source/WebInspectorUI/UserInterface/Models/Timeline.js:117 >> + while (this._records[lowerIndex] !== recordBefore.parent) > > Is it guaranteed that we'd eventually reach the parent record, or should we also add `&& this._records[lowerIndex].type === recordBefore.parent.type` so it's a bit more restrictive? We already did this check up above: `recordBefore.parent && recordBefore.parent.type === recordBefore.type`. Once they are the same type, then yes it should be guaranteed that the parent is in the list (it should have started earlier then the child).
WebKit Commit Bot
Comment 6 2019-03-05 16:40:50 PST
Comment on attachment 363616 [details] [PATCH] Proposed Fix Clearing flags on attachment: 363616 Committed r242520: <https://trac.webkit.org/changeset/242520>
WebKit Commit Bot
Comment 7 2019-03-05 16:40:52 PST
All reviewed patches have been landed. Closing bug.
Radar WebKit Bug Importer
Comment 8 2019-03-05 16:41:24 PST
Note You need to log in before you can comment on or make changes to this bug.