Bug 51127 - Web Inspector: timeline records should only operate WebCore time.
Summary: Web Inspector: timeline records should only operate WebCore time.
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Web Inspector (Deprecated) (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Pavel Feldman
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-12-15 12:17 PST by Pavel Feldman
Modified: 2010-12-16 15:39 PST (History)
15 users (show)

See Also:


Attachments
[PATCH] Proposed change (3.34 KB, patch)
2010-12-15 12:22 PST, Pavel Feldman
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Pavel Feldman 2010-12-15 12:17:40 PST
Network timing and such should belong to the data / aux properties. Primary timing info in timeline should be taken by means of currentTime in WebCore.
Comment 1 Pavel Feldman 2010-12-15 12:22:30 PST
Created attachment 76679 [details]
[PATCH] Proposed change
Comment 2 Yury Semikhatsky 2010-12-15 13:19:30 PST
Comment on attachment 76679 [details]
[PATCH] Proposed change

>     // Sometimes network stack can provide for us exact finish loading time. In the other case we will use currentTime.
The comment should be removed too. But at the first place what's wrong with using the time provided by the network stack?
Comment 3 jaimeyap 2010-12-15 13:53:54 PST
(In reply to comment #2)
> (From update of attachment 76679 [details])
> >     // Sometimes network stack can provide for us exact finish loading time. In the other case we will use currentTime.
> The comment should be removed too. But at the first place what's wrong with using the time provided by the network stack?

You can (and actually do in practice) end up with the time reported in the finish being well before the time reported by the response received event.

In general, the timeline agent has a contract that it records times in WebCore on the UI thread. It has strict ordering guarantees, and the timestamps should follow this.

Also, the network stack and resource loader will be out of process in chrome, so the webcore callbacks get invoked after some Async IPC action. So the common case will be this time wont make sense when combined with the responsetime taken in webcore on the UI thread.

Basically negative time deltas (end  - responseReceived) is incorrect for the timeline agent.
Comment 4 WebKit Commit Bot 2010-12-16 09:25:16 PST
Comment on attachment 76679 [details]
[PATCH] Proposed change

Rejecting attachment 76679 [details] from commit-queue.

Failed to run "['./WebKitTools/Scripts/webkit-patch', '--status-host=queues.webkit.org', '--bot-id=cr-jail-3', 'apply-attachment', '--non-interactive', 76679]" exit_code: 2
Last 500 characters of output:
ailed to merge in the changes.
Patch failed at 0001 2010-12-16  Yury Semikhatsky  <yurys@chromium.org>

When you have resolved this problem run "git rebase --continue".
If you would prefer to skip this patch, instead run "git rebase --skip".
To restore the original branch and stop rebasing run "git rebase --abort".

rebase refs/remotes/origin/master: command returned error: 1

Died at WebKitTools/Scripts/update-webkit line 132.

Failed to run "['WebKitTools/Scripts/update-webkit']" exit_code: 2

Full output: http://queues.webkit.org/results/7131071
Comment 5 Pavel Feldman 2010-12-16 10:01:40 PST
Comment on attachment 76679 [details]
[PATCH] Proposed change

Clearing flags on attachment: 76679

Committed r74198: <http://trac.webkit.org/changeset/74198>
Comment 6 Pavel Feldman 2010-12-16 10:01:51 PST
All reviewed patches have been landed.  Closing bug.
Comment 7 WebKit Review Bot 2010-12-16 15:39:26 PST
http://trac.webkit.org/changeset/74198 might have broken Leopard Intel Debug (Tests)
Comment 8 WebKit Review Bot 2010-12-16 15:39:32 PST
http://trac.webkit.org/changeset/74199 might have broken Leopard Intel Debug (Tests)