Say there's a single lag event, a GC or a busy loop, during which the user
types several characters.
Is this one (lag) event? Several (input) events?
We have INPUT_EVENT_RESPONSE_MS which will accumulate several lagged events in
this case. However, that is more of an indication of how users use Firefox than
how good we've been at eliminating sources of lag.
INPUT_EVENT_RESPONSE_COALESCED_MS records the coalesced time spend waiting for
responses to input events. So in this case it will record one value for the
entire duration of the lag.
MozReview-Commit-ID: H5rYnhwF0q3
TimeStamp::ProcessCreations()'s aIsInconsistent outparam is ignored by the
majority of its caller. This patch makes it optional. Notably, this makes
ProcessCreation() easier to use in a constructor's initializer list.
FX_SESSION_RESTORE_COLLECT_DATA_LONGEST_OP_MS can go because that's exactly the same as FX_SESSION_RESTORE_COLLECT_DATA_MS now.
We can remove FX_SESSION_RESTORE_COLLECT_COOKIES_MS because that's just a flat line since bug 912717 landed.
Opening pages in a new tab might suffer an extra delay from e10s-multi because
the new process has to start up and then run all the process / frame scripts
before it can react on the request from the parent to load the first page.
There are two code paths. Either we start the tab with a remote browser and
then the RemoteWebNavigation will send the request. Or we start with a non-remote
browser and have to change the remoteness flag on it, and then the SessionStore
will send the request.
In each cases we start the timer on the parent side, send it with the message,
and when the child receives it it stops the timer and reports the measured delay.
Other browsers do not support any of these (IIRC), telemetry reports
essentially zero usage, and supporting them is contrary to the DOM spec.
Notes on specific events:
CommandEvent and SimpleGestureEvent: These are not supposed to be
web-exposed APIs, so I hid the interfaces from web content too
(necessary to avoid test_all_synthetic_events.html failures).
DataContainerEvent: This was a non-standard substitute for CustomEvent
that seemed to have only one user, so I removed it entirely and switched
the user (MozillaFileLogger.js) to CustomEvent.
ScrollAreaEvent: This is entirely non-standard, but we apparently expose
it deliberately to web content, so I didn't see any reason to remove it
from createEvent.
SimpleGestureEvent and XULCommandEvent: Can still be created from
createEvent(), but not by content.
TimeEvent: This is still in because it has no constructor, so there's no
other way to create it. Ideally we'd update the SMIL spec to add a
constructor. I did remove TimeEvents.
MozReview-Commit-ID: 7Yi2oCl9SM2
In bug 1353123 it was decided to not extend this telemetry, so it will
expire in this release. Given that, and the fact that bug 1329336 has
disabled the feature already, it's time to remove the probe.
We only need metric from top level content document, but we dont have
any information about it in nsDOMNavigationTiming, so I add a weak
reference which points to nsDocShell.
MozReview-Commit-ID: GiJigRLYHNV
This rolls browser.tabs.animate, browser.fullscreen.animate, and
alerts.disableSlidingEffect into a single pref; if any of these are disabled,
we'll disable the new pref too (toolkit.cosmeticAnimations.enabled). Most
future animations will also be subject to this pref.
MozReview-Commit-ID: 77pLMtERDna
Added test_main_ping_addon_install_tab_window_scalars.py. This test opens and closes tabs and checks
that the scalars for max number of concurrent tabs, tab open events, and number of windows open are correct.
It uses the addon install method to generate the ping.
Testrail test case: https://testrail.stage.mozaws.net/index.php?/cases/view/4963
MozReview-Commit-ID: IC1Ad2HSrUQ
addonHistograms isn't being used and has started getting in the way.
So it goes.
Leave the "Addon Histograms" section in about:telemetry for 60 days.
Remove it in bug 1355882
MozReview-Commit-ID: 4lm7ONirofl
