This is needed to reconstruct population estimates from a sample.
Depends-On: Ie5cf24e84a2ed041bf7c4f0b891387c45667467b
Bug: T273454
Change-Id: I3a40e74f8ccb80aa6ed7d3313a5394aa31baf572
If someone is enrolled the DT a/b test, we want to know about their
editing here as well.
Bug: T273096
Change-Id: I235f4ccbcbfbf95c6aa0df327a9a5a7d5ddb1038
In the new-page case, wgRevisionId will be 0 so it'll try looking for
parentRevId and the cast-to-int on an undefined will get us NaN. That
fails validation, so we should give one last fallback to 0.
It's _possible_ that we could instead make this an explicit check for
using wgRevisionId if it's anything not-undefined, but I'm not certain
about whether there are cases that wouldn't cover.
Bug: T237063
Change-Id: I8a38c0f3b8f8b2b596f5d0933e1a9e7f1326d7be
EditAttemptStep requires an integer, and just getting the value of an
input is always a string.
Bug: T261664
Change-Id: I57e76857086474365124b5b016902211b0e63166
When opening the old wikitext editor, 'wgRevisionId' is always set to
0, and remains that way even if we switch to visual editor.
Elsewhere in the code, we handle this case by reading the revision ID
from the old wikitext edit form, so do that here as well. (This still
works after switching to visual editor.)
Bug: T230133
Change-Id: I9d3a23beb6b1393633b94ac3c9c6c667d7560308
Similar to WikiEditor, allow the editing_session_id value to be
overriden through the editingStatsId query parameter. Also allow
server-side code to override the session ID by setting
wgWMESchemaEditAttemptStepSessionId in mw.config.
Only apply the override to the first session. Once a second init event
happens, discard the overridden editing_session_id and generate a fresh
one.
Bug: T238249
Change-Id: I4ede70f310a35c95b6eb9cc34cfcf2baa77e69ee
Depends lightly on a patch to WikiEditor, which will hook up the logging there
for the case where the switch is happening from WikiEditor to VisualEditor on
the same pageload.
Bug: T221191
Change-Id: Ibafec77b2eabd3b3b3767472b7b5a40e3312bf18
The EventLogging extension no longer uses these internal modules.
They were phased out as part of last year's "lightweight EventLogging"
project (detailed at T187207). Migration notes at T205744.
VisualEditor has migrated already, mostly. It still depended
on the existence of these module names for some condition guards.
* The subscriber for 'mwTimingHandler' was guarded by 'schema.EditAttemptStep',
but did not emit events of that schema. What 'mwTimingHandler' really
needs is the '*SamplingRate' variable for its call to 'inSample()'.
This previously worked because the variable and the schema are both
provided by the WikimediaEvents extension.
* The subscriber for 'activityHandler' had a separate schema guard. This
might suggest an intent for the code to silently degrade if WikimediaEvents
were to be changed to no longer supply the second schema, or for the code
to work for third-parties without WikimediaEvents if they register only
the schema. However, this subscriber too calls 'inSample()' and needs those
variables.
I've assumed for now that it is okay for these to all be guarded together.
Even if the schemas were to be removed and we were to forget updating this
code, the new EventLogging client degrades gracefully from this (no errors).
Bug: T221281
Change-Id: I260c25752c3becfe6e499813197fbf7a3dba88c3
The EditAttemptStep schema doesn't have some of the fields we attempt to
submit, because we're generalizing and it only wants specific ones. Be more
selective about what we submit, so validation messages in the console will be
quiet.
Bug: T218163
Change-Id: Iaf9f47b61c138bb0106b2dfc4be2caec02a10d1d
The timing variable is a private closure variable containing an object
that tracks the timestamps of different events in the current cycle. The
duration variable is the result of using that information to compute the
difference between the current timestamp and the relevant anchor
timestamp. For the '_timing' property in the EventLogging data, duration
is the correct value, not timing.
(This is confusing and we should probably rename the timing variable.)
Change-Id: Iff78eb0ab83c84b73ad5c8f3eb85b1c7f120ebef
Follows-Up: Ifc2135d99f4bec917dac60992098958b72c37fc6
The schema itself is being renamed, many of the field names are
different, and two new fields were added (page_token and session_token).
Bug: T207803
Depends-On: I2949c9782669b75cf17978698c8cef21fdee6dea
Change-Id: I3ec11d74d71207acac130689bac93d5bf0c70715
Respect the config var exported by WikimediaEvents that, if set to true,
forces oversampling. When oversampling, all events are logged even if
they would have been sampled out. The isOversample property is set to
true if the event was oversampled and would not otherwise have been
logged.
Bug: T206543
Depends-On: I5fdf5fdd2dc0d99a0a0d7eb7ab2e3dce4798009b
Change-Id: I314da47d7d250672f1a9b34edeeeb720850f8fac
Instead of hard-coding the 6.25% sampling rate, allow it to be
controlled by the config variable in the WikimediaEvents extension
(which also defines the RL module for the Edit schema).
Also use sampling code from EventLogging so we can configure the
sampling rate as a number, rather than using a hex-digit based strategy.
Bug: T206543
Depends-On: I00383cec62f6c2a0137b329565b0ca84bfbb223f
Change-Id: Ia3e9a0f93d5d3001f222a64f31e82a63db36d7ab
Rather than computing all the data then throwing it away 93.75% of the
time. Also use .charAt() for consistency with WikiEditor.
Change-Id: I6360b5c636e94db3483f542791d158f240c542f8
This won't really do anything until the patches to ve-core for the activity
events, and WikimediaEvents for the schema land.
Bug: T202148
Change-Id: Ie462a24f66240a1accfd0185c46273e60effbd64
ve.track tries to guess the platform, but it needs a loaded Target to do so,
and init happens before that.
Also, log a warning when this happens, in case it comes up again.
Bug: T203618
Change-Id: I35fa58a42cd247e01f3717c9ab3a10d8ea93a484
In Schema:Edit, all action timing durations (ready, loaded, saveAttempt etc.)
are defined as "time since the editor was initialised", which is internally
stored as the timestamp for the "init" action.
The 'init' action itself does not have a timing duratation, but the Edit schema
has a special case for it, definining it as "time since the page was loaded".
In actually, it isn't actually implemented as "time since the page loaded",
and I suspect that as such, this value is probably not used by EventLogging
consumers of the Edit schema. Or, it might be used, but doesn't represent
what the consumers think it does.
Presently, it uses the init time now() - mediaWikiLoadStart, which basically
means the time between the random point at which MediaWiki core JavaScript
finished executing which is quite variable in practice due to the race between
<script async> and browssing parsing/rendering of HTML. That is by design,
and is also why mediaWikiLoadStart is undocumented and internal, and actually
in the process of being removed.
After many iterations on this patch to try and approximate an alternative to
this undocumented variable, I came up with an alternative approach with DLynch
at the Hackathon, which is to simply not record this one timing value, but
preserve the behaviour of all the other timing values exactly as-is.
That is, keep the behaviour of storing `now()` as "init" when the editor
activates, and keep the behaviour of substracting "init" from all other action
times, but only don't report "init" itself to EventLogging (given its value
would be 0, which isn't useful).
Bug: T160315
Change-Id: I778234efe40dde8ff30333339335be1c3910a4e0
* Remove page.length
* Add action.abort.type = switchnochange
Needs to be deployed at the same time as Ib99700ac
Bug: T111420
Change-Id: I7ee245157d4de6c220d7cdf54cd1dd69ff836f15
If70ff601 didn't really fix anything. The only reason you'd want this data is
to distinguish between mobile and desktop data, but it just set the value to
the desktop version always...
Bug: T95432
Change-Id: I76722e3ad8b7dbe644374b24093bec696f27f48c
We're currently rewriting "mwtiming.performance.system.domLoad" to
"timing.ve.undefined.performance.system.domLoad". The "undefined" comes from
the missing targetName property on the event. I'm not sure why it is missing,
but having it default to 'mwTarget' will Do the Right Thing™.
Task: T93156
Change-Id: If70ff601b6c54ec8f95171cbc43c82c87a177508
Still misses some preinit aborts because we need to figure out
a way to attach the unload handler early enough to catch these.
Change-Id: I0ce721e24e69c31318064c6b443c1bfe01077546
