Skip to content
This repository has been archived by the owner on Feb 29, 2020. It is now read-only.

Topsites telemetry fixes (#3105) #3108

Merged
merged 6 commits into from
Aug 9, 2017

Conversation

dmose
Copy link
Member

@dmose dmose commented Aug 7, 2017

This does two things:

The part that is easily testable is the extra marks:

  1. start up the browser
  2. start the profiler
  3. open a new tab
  4. capture the profile
  5. In the profile, switch to the Markers view
  6. Enter "User Timing" in the filter textbox
  7. Go through the main and all content processes
  8. There should be one, or at most two, topsites_first_painted_ts

There should be exactly two topsites_first_painted_ts.

r? Mardak

@coveralls
Copy link

Coverage Status

Coverage remained the same at 86.407% when pulling 1817be9 on dmose:topsites-telemetry-fixes into 54a5392 on mozilla:master.

@dmose dmose requested a review from Mardak August 7, 2017 22:18
@Mardak Mardak changed the title Topsites telemetry fixes (#3501) - WIP Topsites telemetry fixes (#3105) Aug 8, 2017
mockRaf.step({count: 1});
assert.calledOnce(callback);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was a little confusing to figure out as there's no explicit check that the callback was called except that if it wasn't called, the test would have timed out.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I'll fix this.

// have to do it here, so that other calls to this method
// while waiting for the next frame won't also try to handle
// handle it.
this._timestampHandled = true;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: this narrow comment block was bothering me more than it probably should ;)

    // And if we haven't, we're doing so now, so remember that.  Even if
    // something goes wrong in the callback, we can't try again, as we'd be
    // sending back the wrong data, and we have to do it here, so that other
    // calls to this method while waiting for the next frame won't also try to
    // handle handle it.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I dunno how it ended up that narrow. As we all know, 80 columns is the One True Width. :-D

* (not the upcoming one) paints.
* Call the given callback after the upcoming frame paints. We're using
* a Promise rather than a setTimeout or double rFA, as Promise resolution
* is faster, as of this writing (Firefox 57 Nightly) - see #3105 for
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

probably note that it's also consistent not just faster in particular when in a not visible browser

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll update the stuff referring to Promises to talk about setTimeout (and maybe postMessage).

@coveralls
Copy link

Coverage Status

Coverage remained the same at 86.407% when pulling cac31b3 on dmose:topsites-telemetry-fixes into 54a5392 on mozilla:master.

@dmose dmose assigned Mardak and unassigned dmose and Mardak Aug 9, 2017
@dmose
Copy link
Member Author

dmose commented Aug 9, 2017

@Mardak, can you have another quick look, since I've swapped out the promise for setTimeout...

@coveralls
Copy link

Coverage Status

Coverage remained the same at 86.407% when pulling c74dff8 on dmose:topsites-telemetry-fixes into 54a5392 on mozilla:master.

@Mardak Mardak merged commit 6864331 into mozilla:master Aug 9, 2017
@as-pine-proxy
Copy link
Collaborator

@coveralls
Copy link

Coverage Status

Coverage remained the same at 86.407% when pulling fcf61e3 on dmose:topsites-telemetry-fixes into 54a5392 on mozilla:master.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

hero element timestamp sent too many times
4 participants