Disclaimer: I work for or provide services to the Wikimedia Foundation. However, the Foundation does not vet all my activity, so edits, statements, or other contributions made by this account may not reflect the views of the Foundation.
Wed, May 27
This is one of those areas where our really lax username options make it tricky, because we allow spaces and many other punctuation characters.
Tue, May 26
Okay, schema-change updated to not have anything new that's required.
@DLynch : I think this is the case but, again, to be super clear: to keep things backwards compatible the new properties should not be required, otherwise all events coming with the old schema version will fail validation . They should be optional.
Mon, May 25
We need to go over the events for the mode-switching and ensure that they're firing appropriately.
- How – if at all – would we currently distinguish between the wikilink and user link (@-mention) sequences? I'm assuming both of the below will produce link:window-open-from-trigger events. [ii]
Depends when you mean. The @-mention dropdown will use the mwUsernameCompletion feature (and window-open-from-sequence) rather than link -- once the link is actually created, we haven't done anything with T252083 yet, so that'd still be link.
Once the instrumentation is deployed, will this be handled automatically or are there any manual steps (by Analytics or other team) that will be required to make this happen ?
Fri, May 22
@DLynch: what do you think about switching to performance.now(), rather than including the check-and-omit logic?
Thu, May 14
I'd speculate it's to do with the changes from T240355.
Tue, May 12
Might need to ask @Jdforrester-WMF if they can remember the context.
Mon, May 11
Did you want the @ to be inside or outside the link?
Sat, May 9
Yeah, it is -- sorry, I made that comment without refreshing the page and you'd edited the description to include it as I did so.
Thu, May 7
Implementation detail (which is not yet implemented): as in the signature, the IP address @mentioned should link to the Special:Contributions page for the IP address, not the (probably non-existent) user page for it.
...and that got merged. So, adblockers may still be cutting off the beacon requests, but DoNotTrack should be applied to client-side and server-side equally now.
@mpopov here's a quick implementation of respecting the DNT header server-side, for discussion: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/EventLogging/+/595005
Hm, sorry, or maybe it is installed. The checkout has happened into extensions and running provision a few times seems to have eventually made the extension dependecy errors stop happening. So I'll go rebuild everything more thoroughly and see if that makes provision stop dying.
Links becoming out of sync with their labels is not a problem unique to user links:
Notably, we debated this general topic and behavior around it a lot while we were talking about the link-label field in the inspector in T55973.
@mpopov there's also the visualeditor-nondefault group in config, which mostly consists of the various wikitionaries / wikisources / wikiquotes and similar... but has a few mainline wikipedias on it -- ganwiki, iuwiki, kkwiki, kuwiki, srwiki, tenwiki, tgwiki, uzwiki, and (probably the biggest?) zhwiki.
I keep wondering if we could add a server-side EventLogging component to VE the way that WikiEditor has.
Perhaps we could work out some sort of baseline adblocker-but-JS rate by looking at what percentage of edits are made with VE and EventLogging and seeing how that compares to our anticipated rate based on our sampling-rate? Then apply that to the WikiEditor data to compensate?
- Visual and source modes have different inspector behavior, and lots of our fancy behaviors will only apply to visual mode. Source mode just inserts the link wikitext -- if you put your cursor in it and deliberately trigger the inspector via the shortcut you'll see it, but it's much less amenable to the whole "you backspaced into this" stuff.
- T250332 could result in what's inserted by the autocomplete not being a link. If it's a template, entirely different behavior applies.
Wed, May 6
Actually @DLynch was right, we don't notify IPs, so they should just be removed.
Client-side EventLogging respects browser do-not-track settings, and server-side doesn't. We could actually improve server-side in this regard, I think, by checking for the DNT HTTP header and treating it as equivalent to the client-side setting. That might help our tracking here.
Mon, May 4
If it's only happened once, I'm inclined to call it some sort of fluke.
I don't think that method can be relied upon, mostly because of caching.
It's worth considering that the current popup styling is the OOUI MenuSelectWidget styles, so anything which we think is an improvement to general list styling / focus stuff might be worth coordinating with @Volker_E and just getting upstream.
Thu, Apr 30
(This sounds horrible but is actually only mildly horrible. Find the start and end of the table body (these don't change so could be shown by a marker comment), tokenize for |, ||, |-, <ref>, </ref>, <!--, -->, and process the stream with a simple state machine (in the table / in a comment / in a reference). There are a number of other states in wikitext, like inside a template or another extenstion tag, but it's reasonable to assume those won't ever be used in these tables.)
Wed, Apr 29
@Pbsouthwood Right now it'll show the popup as you're typing the email address -- I've been meaning to have it not trigger if there's a non-whitespace character immediately before the @, but haven't done so yet. Fortunately, the popup triggering doesn't inherently do/insert anything, so you can just keep typing and ignore it and it'll go away.
Apr 21 2020
We talked about it in a meeting, and @Esanders supports the idea of making a generic hook (via mw.hook or a custom jQuery event or whatever) which VisualEditor/NWE can fire off to tell the page it's about to be taken over. This could then be registered by DiscussionTools (and other extensions like Thanks) so it can try to do a teardown there.
Apr 17 2020
We also haven't actually changed the event rate yet. Train was still going out until this afternoon, so we need to get a config-change patch out via a SWAT window now that's done.
Apr 16 2020
Here's my list-of-open-questions from T232601:
Apr 15 2020
Two options seem to exist:
- Display a warning pre-submit that changes have been made, in case they want to check what was said before posting their own.
- Display a notice post-submit that other edits were made.
Yes, section edit links are handled as well.
Note: usernames will appear in the username results list exactly as they appear on the page. Meaning, if someone has a custom signature such that the username that is appended to the comments they post on talk pages  is different from the username that appears in the link to their user page , their alias will show up in the username results list. Pings to aliases will work the same way they do for non-aliases.
Incorrect -- the only thing that appears in the completion list at the moment is the username that the signature links to. (I.e. the text of the link doesn't matter, just the URL it points to.)
Pings to aliases will work the same way they do for non-aliases.
Only in the sense that so long as they get translated down to a link to the real username (which we don't currently do), they'll get picked up as a ping by Echo. Attempting to write @alias isn't going to do what the user expects in the current implementation.
The display text for the link should be the same as what is shown in the username results list. Which, in this case, is their alias.
But not in the current implementation.
Apr 14 2020
This is slightly more complicated than just making WikiEditor detect whether it's being accessed by a mobile UA (server-side and client-side, because it's logging from both), because we'd probably still want to differentiate between MobileFrontend and WikiEditor. As-is, that desktop / phone split for platform is the only way to tell, I think.
Apr 13 2020
Apr 10 2020
@kaldari Yeah, you beat me to it -- API requests shouldn't do any of this logging, and (assuming that the apps are both doing their logging and tagging it correctly) we can filter it down to just on-page stuff with the filter you suggested.
Apr 8 2020
If nothing else, we should fix the preview.
Mar 25 2020
Mar 18 2020
I've verified that this is still happening, but I'm not actively looking at it.
Mar 17 2020
It's because of @matmarex's patch on T245794 to turn it on as a beta feature on the beta cluster -- because of how T245539 implemented the beta-feature stuff, if it's in beta-features it hides unless the specific enabled-for-beta preference is set.
Mar 11 2020
Current behaviors for reference:
Mar 10 2020
I can confirm that it no longer happens for me on https://nl.wikipedia.org/wiki/Overleg_gebruiker:RYasmeen_%28WMF%29/Kladblok?dtenable=1&debug=1 (after a moment of worry before I aggressively cleared some caches).
Mar 5 2020
For QA purposes: because of the restbase issues on beta (T246833) I don't know whether this issue could be reproduced there before this patch. So we might have to wait for it to get to production before we can know.
My understanding of the current state is: almost everything is as-expected.
I think we could squeeze it down to two (debug and everything else) if we don't mind loading both of the reply widget implementations and their dependencies at once despite only ever using one of them on a given wiki by config. That's definitely a performance trade-off, since one of them is the one which pulls in a large chunk of VisualEditor.
@Tkarcher alas, no -- that's about how dependencies bundled with the preview markup are applied. Which parser is used makes no difference.
Okay, it still fails on nlwiki now 1.35.0-wmf.22 has finished rolling out.
Mar 4 2020
@matmarex Yeah, I have a patch for that locally which I made speculatively -- I just got held up on trying to prove to myself that it was making any sort of difference. That said, it probably shouldn't do anything bad to run fixBase, so I'll put it up for review anyway...
So, it seems that in Safari findSignature always fails.
Error's changed since this task was filed, and is now: "Could not find the comment you're replying to on the page. It might have been deleted or moved to another page. Please reload the page and try again."
Feb 28 2020
And, given that times have changed since 2016 could the events possibly be attached to a more "modern" event from the page visibility API?
The existing instrumentation is from VisualEditor, mostly applies to desktop, and has been in place since ~2016.
I have some vague idea that this could be made better by using a promise instead..
Feb 27 2020
The not-logging issue should also currently be affecting VisualEditor, as I understand it.
Feb 26 2020
@iamjessklein do you mean that in the sense that the patch for the margin is a good idea and should be merged, or that the feature is good as-is without that?
There's a combination of missing and questionably-applicable involved here:
Feb 24 2020
Feb 21 2020
The vetags one is being passed along for a onRecentChangeSave hook. campaign is doing similarly, but not in the VE extension itself. (You'd presumably also see dttags if you were examining a DiscussionTools save.)
Feb 20 2020
Feb 19 2020
@matmarex from the way they phrased it, I get the impression it’s more “we agree that this is almost impossible to attack, but our analysis tools won’t shut up about it because they know nothing of the context things run in”. 😂
A patch for the defensive programming on the maintenance script: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/DiscussionTools/+/573051
There's a patch for the outdated packages which covers most of this: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/DiscussionTools/+/573048
Feb 17 2020
Feb 13 2020
There's questions regarding whether we should include any sort of "this comment was edited" notice on an edited comment. Meeting discussion leans towards "no", in part because there's no good way to link to the revision history showing the change without making a second edit to add that link in.
Feb 12 2020
@Mayakp.wiki I've made the very small required change to the schema here: https://meta.wikimedia.org/w/index.php?title=Schema:EditAttemptStep&type=revision&diff=19802113&oldid=19486181
Feb 11 2020
I did some research into hiding tags: it hides the tag entirely if the associated message is present-but-disabled. (If there's no message at all, it just shows whatever the tag name is.) Messages are disabled by setting them to literally the empty-string or to -.
My theory is that @Ryasmeen has NWE enabled, and so "edit source" isn't technically a navigation event (because it's just replacing the contents of the current page). We need to special case detecting and canceling this somehow.
Feb 10 2020
But Maya and I have spoken about it, and we know what needs to happen.
Feb 7 2020
@Esanders: I'm actually not sure what's going on there with 1. For me, locally, exact matches are working just fine. See:
Feb 6 2020
This is pretty tight, so we should some a top margin (0.5em?) as seen in Phab:
Mm, I do agree. I've updated the patch with a top margin 0.5ex, which looked better to me than 0.5em:
Feb 5 2020
Why is it that a reply made using DiscussionTools in visual mode would receive three tags instead of two?
My initial logic was just that it'd be simpler for search, rather than anyone interested in the data having to know up front what all the possible modes were. That said, I can certainly remove the pure discussiontools tag, and you can remember when searching what the options are.
Jan 24 2020
How – if at all – should the text input mode (e.g. source vs. rich text) be tracked?
Jan 23 2020
EditAttemptStep needs to be tweaked a little so it can apply to DiscussionTools being used to edit a page. I think what's needed is:
Jan 22 2020
I'm working on a patch for this which will apply placeholder tags for likely edit types. The bulk of the actual technical work is adjusting the VisualEditorEdit API to allow the tags to be customized, anyway.
Jan 21 2020
This is more work to audit than I have time to handle. The difficulty is mostly that any random wiki could have a gadget / extension which adds a message on arbitrary criteria... and even for just the core / extension code, there's enough different ways to trigger something like this that it's a real pain to search for it happening.