Handle NULL load_event_start.

Handle NULL load_event_start.

BUG=112006
Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=120087

[dominich, 2012-01-31 16:01:19]

Handling NULL load_event_start as in the legacy case, and adding a TODO to look
into it further once the load time metrics are consolidated.

[jar (doing other things), 2012-01-31 17:54:24]

Please see comments.....

but this CL LGTM already.

http://codereview.chromium.org/9301043/diff/1/chrome/renderer/page_load_histo...
File chrome/renderer/page_load_histograms.cc (right):

http://codereview.chromium.org/9301043/diff/1/chrome/renderer/page_load_histo...
chrome/renderer/page_load_histograms.cc:67: DCHECK(!load_event_end.is_null());
If you look at the PLT.AbandonType (see code to generate it in this file),
you'll also see that at times load_event_end is null.  Perhaps you need similar
conditional treatment for items derived from that metric??

In any case, I *think* the DCHECK is wrong.... or else it might be that this
code is only called when the load_event_end has been recorded, and the other
code is more general.

[dominich, 2012-01-31 18:07:31]

The legacy code handles even more NULL events and I am surprised from the
PerformanceTiming spec that any of these events in the PT_ code can be NULL. 
I think there's a deeper bug in the implementation of PerformanceTiming as they
are allowed to return 0 values but shouldn't be NULL.

Adding load_event_end NULL checks speculatively even though it hasn't been
reported missing.

[commit-bot: I haz the power, 2012-02-01 17:28:10]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/dominich@chromium.org/9301043/6001

[commit-bot: I haz the power, 2012-02-01 20:03:05]

Change committed as 120087