Previously, if the browser didn't support the Beacon API, then
instrumentation/eventLogging#isEnabled would bucket the user with a
sampling rate of 0, which is equivalent to returning false. This change
simply does the latter.
Additional changes:
* Update the documented module names of the instrumentation/eventLogging
and statsv modules.
Bug: T168847
Change-Id: I7ae5c10da42ca614b5b1a6619f9555e5665344cf
Changes:
- removed ugly PopupsContext::getInstance
- removed ugly PopupsContextTestWrapper helper
- defined all services inside ServiceWirings
- fixed unit tests to test classes directly or use MediawikiServices
Change-Id: Ie27e28bb07aebe01014848c290369b1b1f098e9b
Per I28003c5898d64031e1efb212cb0bec58ff44b958 Popups require at least
MediaWiki version 1.30. Documentation should respect that
Change-Id: Ifc87ac5cdcf61ae54cefe3f6ccab7aac5c52e0a6
Changes:
- introduced new UserPreferencesChangeHandler class that listens to
PreferencesFormPreSave hook
- introduced wrapper for EventLogging extension plus NullLogger when
EventLogging extension is not availalbe
- when user changes PagePreview to disabled system will trigger
disabled event
Bug: T167365
Change-Id: I63faecb0495eb30a9fc2763e7ddf3944baf7f55a
We had instrumentation for over 4 weeks and duplicate events rate
was very low. We want to keep stats so we check the duplicate events
rate but there is no need to filter those.
Bug: T167365
Change-Id: I72585beb21e9db589e45eeace657ef25f432abc9
Changes:
- introduced new event 'disabled', sent from settings popup
- added unit tests for 'disabled' event handling
Bug: T167365
Change-Id: I048b38122b8843199c86fd1ed9ec2ff21767e114
This is the usual practice in MediaWiki extensions,
for consistency among wikis where pages are
not necessarily articles.
Change-Id: I25d8ccb9090c31e4672998c8a01ebdfcaf625e9f
In order to debug the EventLogging instrumentation in production
environments, we want to be able to bucket ourselves at will.
When the debug flag (?debug=true) is passed send all events
for given page view.
Bug: T168847
Change-Id: Id1b13b0ecaa791b4f26be4d1151bdbbe5270b64d
Changes:
- set margin-top and margin-bottom to 0 on following elements:
ul, ol, li, dl, dd and dd
Bug: T168941
Change-Id: I80478de046d7944fde3c0de3f96f5c9dc4623c36
Changes:
- when event doesn't have linkInteractionToken do not check for
duplicated tokens
- hygiene, move event duplication logic into separate functions
for better readability
Bug: T168449
Change-Id: I3ae197567ec9f67e104af109d4f1a1c1a6769d32
Following on from I4f653bba, since the schema and statsvInstrumentation
modules are similar, let's group/rename them:
schema -> instrumentation/eventLogging
statsvInstrumentation -> instrumentation/statsv
Change-Id: Ic59e0da7d4917f6733fd090f15d3c269af863f05
The following sniffs are failing and were disabled:
* MediaWiki.Commenting.FunctionComment.MissingParamComment
* MediaWiki.Commenting.FunctionComment.MissingParamTag
* MediaWiki.Commenting.FunctionComment.MissingReturn
* MediaWiki.Commenting.FunctionComment.ParamNameNoMatch
* MediaWiki.FunctionComment.Missing.Public
* MediaWiki.WhiteSpace.SpaceBeforeSingleLineComment.NewLineComment
Change-Id: Id9e98b7a4e87d00c63e7b509506c23f12cf0d380
Currently, the mw.eventLog.Schema class samples per pageview. However,
we expect that if a user is bucketed for a session, then all
EventLogging events logged during that session are in the sample.
Moreover, loading the class in the way that we did - asynchronously,
using mw.loader#using - introduced an issue where the eventLogging
change listener would subscribe in the next tick of the JavaScript VM's
event loop and miss the "pageLoaded" event being queued (see T167273).
Changes:
* Make the schema module follow the form of the statsvInstrumentation
module, i.e. make it expose the #isEnabled method, and add the
associated getEventLoggingTracker function.
* Update the eventLogging change listener accept the tracker returned by
getEventLoggingTracker.
* Update/fix related JSDoc documentation.
Bug: T167236
Bug: T167273
Change-Id: I4f653bbaf1bbc2c2f70327e338080e17cd3443d4
