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
timeStamp was used in two places, but we only had back-compat
code in one, so the other ended up using NaN.
Bonus: make jshint happy with the indentation of the $.extend() call.
Change-Id: I69000d11822658f2a227f9756093bc278f5fbaf5
* Use the event's timeStamp rather than the current time in the event
subscriber.
* Instead of using ve.trackSubscribeAll() and then branching on the topic
prefix, just use ve.trackSubscribe( prefix, ... ) to bind prefix-specific
handlers.
* Round timing measurements after performing arithmetic, and use Math#round
rather than Math#floor.
* Rename 'getDefaultTiming' to 'computeDuration'.
Change-Id: I27ff1622ecea9b82d414f871441f127fc2dbd2cc
This API doesn't have the ability to track any other data
in addition to a name and a duration in milliseconds, so
we add the target name ('mwTarget' or 'mobile') to the
event name and discard all other data.
Change-Id: I25ae0243f8983142d7755b65b05c18d5df36a253
