[Webkit-unassigned] [Bug 200637] Web Inspector: REGRESSION: Inspector Timeline always starts at about 500ms mark on a reload
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Wed Sep 11 21:55:21 PDT 2019
https://bugs.webkit.org/show_bug.cgi?id=200637
--- Comment #6 from Devin Rousso <drousso at apple.com> ---
Comment on attachment 378616
--> https://bugs.webkit.org/attachment.cgi?id=378616
[PATCH] Proposed Fix
View in context: https://bugs.webkit.org/attachment.cgi?id=378616&action=review
>>> Source/WebInspectorUI/UserInterface/Models/TimelineRecord.js:108
>>> + get unadjustedStartTime()
>>
>> The name of this function doesn't seem accurate, or at the very least seems like a roundabout/circumstantial way of getting to the desired result. The `timestamp` itself isn't guaranteed to be unadjusted either (I know it is right now, but that may not be the case for other future timeline record subclasses).
>>
>> I think a better approach would be to check `if (record instanceof WI.CPUTimelineRecord || record instanceof WI.MemoryTimelineRecord)` in `_updateTimesIfNeeded` and use the `record.timestamp` in that case instead.
>
> I'm not sure I buy the argument.
>
> That would mean:
> • The next time we add a timestamp based record we'd have to update that location as well
> • Each update call now has to do a chain of instanceof checks
> • Each TimelineRecord subclass can override unadjusted*Time as needed. So if "timestamp" was adjusted in some future class they would be able to override it to return sane values.
>
> Would you rather I make CPUTimelineRecord / MemoryTimelineRecord provide their own unadjusted*Time (or a common TimestampTimelineRecord superclass) and just return timestamp?
Good point. I like your suggestion.
How about something like:
TimelineRecord.js
```
get unadjustedStartTime()
{
// Overridden by subclasses if needed.
return this.startTime;
}
```
CPUTimelineRecord.js
```
get unadjustedStartTime()
{
return this.timestamp;
}
```
--
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20190912/62007efc/attachment.html>
More information about the webkit-unassigned
mailing list