When we started loading damp.js using the BrowserLoader, the performance global in damp.js is no longer in sync with what ChromeUtils.addProfilerMarker uses to compute its duration. This lead to incorrect marker durations in profiles.

We should use Cu.now instead for now.

Florian: In devtools codebase we sometimes get performance globals which are coming a window global, and in that case, the start time we provide seems out of sync with whatever addProfilerMarker uses. Typically, I get around 1 second of extra duration on those markers.

The workaround is easy, we just have to use Cu.now() instead, but it's easy to miss.

I'm not sure what we could do about this? Some ideas:

• optionally allow the caller to pass the "current time", so that addProfilerMarker can compute the offset
• split the API in two, with a startMarker and endMarker or something similar?
• find a way to enforce passing valid (as in, "in sync with Cu.now") timestamps

Not expecting an action for this bug, just wanted to let you know about this small issue with the marker API.

Using performance.now will generate incorrect markers because the timestamps are not in sync with the ones used internally by the ChromeUtils.addProfilerMarker API.

(In reply to Julian Descottes [:jdescottes] from comment #1)

Florian: In devtools codebase we sometimes get performance globals which are coming a window global, and in that case, the start time we provide seems out of sync with whatever addProfilerMarker uses.

addProfilerMarker uses a reference for the startTime that depends on the global on which addProfilerMarker was used. When calling from a jsm, Cu.now is correct, when calling addProfilerMarker from a window or worker context, performance.now from the same window global is what should be used.
This is more complicated than I would like, but Cu.now isn't accessible in worker contexts. I was almost tempted to introduce a ChromeUtils.now that would be the same everywhere, but I was afraid introducing yet another 'now' method would cause even more confusion.

Thanks for the info!

Set release status flags based on info from the regressing bug 1678550

https://hg.mozilla.org/mozilla-central/rev/be98edd5e549

The patch landed in nightly and beta is affected.
:jdescottes, is this bug important enough to require an uplift?
If not please set status_beta to wontfix.

For more information, please visit auto_nag documentation.

Only useful for development, wontfix on beta.