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, Jun 22
All looks fine to me. VisualEditorFeatureUse is very freeform; so long as you're avoiding collisions on the feature field and at least halfheartedly trying to match your action up with other semantically-equivalent ones, it's all good.
There's a ticket for problems with platform already (T249944) which might be worth reviewing. (Basically: on web it currently just means "is MobileFrontend being used?" which is not necessarily what people would expect, and there's discussion of whether/how that should get changed.)
Poor DavidL suffers for my sins.
Fri, Jun 17
I think it's mostly working as intended but is a fairly bad user experience and may have glitches.
Thu, Jun 16
Wed, Jun 15
Can you confirm
Fri, Jun 10
I'm not sure why lots don't have any mechanism recorded
It's because EditAttemptStep has a somewhat painful structure. The rows without an init_mechanism aren't inits, they're other types of event.
The enwiki one might be confusing because the first few sections don't contain any signed comments and so don't read as discussion sections to the parser.
Thu, Jun 9
Also worth considering that (in general) we'd like it if, when a link to an edit page is sent, the person following that link sees their own preferred editor rather than whichever editor was being used by the person who sent the link. Making more links which are editor-specific and don't respect the viewer's preferences seems like it'll decrease people getting their preferences respected.
This should hopefully be a rare case
Copying over @Esanders' comment on the ticket that got this reverted:
Note that the VE surface approximately uses Parsoid HTML, which this change appears not to be compatible with. The selector seems scarily generic (.mw-parser-output img) so it should be tested against a wide range of content (e.g. galleries and other rich media extensions in both parsers) before merging it again.
That patch will synchronize the sampling rate in the UIActions schemas, EditAttemptStep, and VisualEditorFeature use all at 20% on the 9 partner wikis. I picked 20% because that's the rate the desktop-improvements wikis are set to, and there's no current separate config to have a different rate between desktop and mobile for EditAttemptStep so lining everything up with the highest one was easiest. It does mean that EditAttemptStep will be sampling at higher than its normal 1/16 rate, and the MobileUIActions will be sampling at double their normal 10% rate on those wikis.
@ppelberg Yes. None of those require a change to the sampling method, as they don't involve VE/WikiEditor. Those can all be logged via EditAttemptStep or the UIActions schemas.
Wed, Jun 8
As well as the mode-switching, it also currently blocks the ability to quickly access the talk page or edit history (you'd have to leave edit mode in a fairly undiscoverable way, before you could reach any of those), both of which are useful during edits.
@Jdlrobson Yeah, applying such a parameter generically to all edit links would be usable for this. So long as there's something indicating the source, it'll be sufficient. It doesn't matter for this ticket whether the links are unique to the type of editor or not, though.
I wonder if this'd be better addressed as some sort of mediawiki-wide fix? Anything with e.g. <span class="mw-relative-time" data-ts="123443432"> would get updated by some site-wide JS, extensions and pages wouldn't need to independently implement it, and users wouldn't have to remember which pages have this behavior and which don't...
Tue, Jun 7
@Jdlrobson No, because it wouldn't distinguish between links from the sticky header and the tabs -- it's still the same editor, just a different route taken to reach it.
Fri, Jun 3
I'll note that it's not going to be possible to catch all edits that will send DiscussionTools notifications, because they're generated from Echo's post-save deferredupdate by parsing new revisions for comments. Thus it also sends notifications when people edit via WikiEditor and so don't use the new tools at all.
Wed, Jun 1
1 On the task description, it mentions after logging into Beta Cluster, "Verify you have been assigned to the test or control group.
Thu, May 26
I'm pretty sure none of this should be going into that schema. Adding the data-event-name attribute should, as I understand what Jon said, make this all get logged into the MobileWebUIActions schema.
May 23 2022
I had the impression that the normal flow of calling Title->getFullURL (as DiscussionTools is doing) is supposed to escape the fragment. Presumably there's some chain of circumstances which is bypassing that...
May 20 2022
This is server-side warning-logging, so QA can't really check it easily.
I'm not sure how a time duration value should be stored. Perhaps there's an existing system for this sort of thing, or perhaps we can extract this info from other existing logs (e.g. the parse API? although of course that'd include other usages).
May 19 2022
May 18 2022
To clarify, do we anticipate this synchronization to cause any changes to the UIActions schema's current sampling rates?
May 17 2022
Sounds like we might want to fix whatever parsing is happening inside the code running on maps.wikimedia.org -- it should probably treat an empty properties object the same as an entirely absent one.
It looks like for T304030, we want to include every logged-in user in the test, so we might be able to just remove the preference stuff entirely, and compute the bucket from the user ID every time.
May 13 2022
May 12 2022
A more-sensible behavior than we have now would probably be to hide the shortcuts on phone screens (which have limited space), but show them on tablets (which have more space, and are more likely to have a keyboard available).
Hm, fair point. We should probably be consistent. Given that apparently some actual mobile on-screen keyboards are gaining modifier keys, the argument for being consistent in the other direction isn't a bad one now, though -- stronger than it was back in 2018, anyway.
Their "issues affecting wikipedia" ticket, is a way to keep an eye on progress here, we'd hope: https://bugs.chromium.org/p/chromium/issues/detail?id=463348
Chrome has had some issues with spellchecking in contenteditable elements in recent versions -- they merged one fix back in v97, but it's either not completely fixed or has reemerged since then. We're working on seeing what they can do about it.
Could you check whether turning off "check spelling while typing" fixes this? (In the browser's Edit > Spelling and Grammar menu.)
Rebasing required: T306648 just made its own changes to the UIActions schemas, so I'm going to have to put everything back on top of that.
I clicked in to say what Tacsipacsi did. If you're on a mobile device with a keyboard you can use them. Fairly common example would be an iPad with a keyboard-cover, but you can pair a bluetooth keyboard with basically-anything.
I think the trash button going away was one of the WMDE changes that just went out via config.
May 11 2022
Breakdown 1 is a lot more accurate. In breakdown 2, viewing the namespace part as a "label" feels like it carries incorrect implications to me -- the namespace is an important part of the page name not a separate thing. Particularly when you're dealing with namespaced pages that aren't in a talk namespace -- every talk/user_talk/project_talk/etc_talk page is implicitly paired with a non-talk page, and "Wikipedia:Something" isn't necessarily related in any way to "Something".
May 10 2022
My understanding is that the outcome of various discussions is that we've committed to providing the contents of sections that don't contain any comments.
Seems challenging, because we're at a fairly industry-standard functionality for the tool. (i.e. it works about how, say, twitter's or phabricator's equivalents do.) The autocomplete also works about the same way as those -- pressing space moves on, pressing tab completes.
Uncollapsing only one might just make it so that's the only section they think exist. I continue my staunch support for having everything uncollapsed by default!
Same icon's used on desktop as well -- this seems like it'd need to be a far-reaching change?
For what it's worth, focus is contained to the dialog when it's open -- tabbing past the end of the elements in the dialog will send you back to the first element in the dialog, and vice versa. (I'll grant that I don't know to what extent accessibility tools could be used to bypass this. But regular keyboard navigation can't escape.)
This is a OOUI TabSelectWidget question, more than something VE-specific. As it works currently, you focus the widget, and then you can navigate between tabs with arrow keys (i.e. this is keyboard-reachable, with the right mental model). I'm sure this behavior is changeable, but we should watch out for side effects in various places that're using TabSelectWidget.
@mewoph the remaining two patches will immediately enable the new behavior. There's not any config for it, it just changes how things behave.
May 9 2022
May 8 2022
Interesting, I think this could maybe be something to do with the recent translate annotations changes, insofar as this is the element that it's erroring on:
May 6 2022
It's possible to correlate a page view logged in DesktopWebUIActions or MobileWebUIactions with any corresponding edit events (both page and discussiontool related events) that occur on the same page load logged in EditAttemptStep.
May 5 2022
Isn't integration=app-android already a perfectly-distinguishing method of filtering for Android app edits? I don't understand why you'd need to do anything else.
Actually, it's more likely that DiscussionTools is enabled but those pages aren't empty (as-in "not yet created, redlinks").
Those patches add a new field to both UIActions schemas called pageToken. It contains the same value from mw.user.getPageviewToken() that's logged in EditAttemptStep as page_token.
@ppelberg Yes, that sounds correct.
May 4 2022
This can be easily tracked for anything but WikiEditor -- it's logged server-side and wouldn't be distinguishable there from coming via existing methods, unless we add some otherwise-superfluous tracking parameters to the URLs.
An argument for the blob-of-HTML method is that it lets DiscussionTools adding metadata to the ToC work without the client-side code needing to know about that.
To be clear, "People who have used [i] Topic Subscriptions prior to the A/B test beginning." in the requirements just means also-including them, not only-including them?
@Jdlrobson I think it'd be a step towards it, at least from a display perspective -- it wouldn't help with the referenced translation concerns at all. It'd let the communities override the display via CSS, certainly, either to hide it entirely or to relocate it a bit. Though, that would make it easier to realize @Quiddity's concern about breaking the copy-paste workflows, but at least it'd be a community-chosen thing that we wouldn't have inherently pushed upon people (and e.g. in DiscussionTools we're making it *look* like there's a space, but it'll still copy just fine).
May 2 2022
The smaller buttons aren't the empty-state. Those are ones where the discussion tool isn't enabled.
Assuming you mean the classic WikiEditor previews, yeah, that's a whole different editor than this task is talking about, which would presumably require a very different solution.
as far as I can tell this issue occurs when I'm editing in VE, or in the source editor shown below:
Yeah, that's the 2017 wikitext editor, which is based on VE.
Apr 30 2022
Further clarification: I (naïvely) think that this should be happening in the editing modes based on VisualEditor (VE itself, and the 2017 wikitext editor), but not on classic WikiEditor. This is because the VE-based modes do an inline replacement of the article contents, while anything using the classic EditPage-based methods does a full page reload.
Apr 29 2022
This is specifically referring to the new Vector floating TOC, right? Or are you also seeing this on the traditional inline TOC?
Apr 27 2022
For editing, I guess we'd want to settle on a definition of "edit attempt" for this. If we're okay with "viewed an edit page while blocked", it's probably doable. If we want it to be comparable to other logging of edit attempts, we'd probably want to do all the logs from the client-side.
This has been deployed.
Agreed that it's not obvious what clicking the button will do (or that it's a clickable-button), and since it's a fairly disruptive action (triggering a reload/refresh and viewport movement), it might be good to hint to users somehow what would occur. The real time preview project has a similar use case for a manual-refresh button in their preview UI, so it might be an opportunity to share some design cues?
Apr 26 2022
I'll schedule this for a backport this week.
Apr 25 2022
To spell out the solution: that patch added mw-mf as a class on the body element, which will only be present if the site is in MobileFrontend mode (regardless of skins, etc). Anything that wants a binary "is MF active" can check for that, and TemplateStyles can hang themselves from it.
Apr 21 2022
Button width = is it possible to have the button width match the text width?
You mean the text around it, not the text inside it, right? It could be made to do so.
Patch is updated, it'll look like this:
Is the 502 Error something to worry about?
Apr 18 2022
With that change, should we also change the "meta" requirements in the description? My impression of the outcome of that discussion was that we were, essentially, going to be putting the "add topic" button into the sticky header in New Vector regardless of any DT involvement (i.e. whenever it would appear in the page tabs, it'd also be in the header), but the current description still has it gated behind the visual enhancements preference and only on certain namespaces.
Is there a page_token within talk_page_edit or can this be easily added?
Apr 15 2022
For completeness sake, here's your own user talk page:
Patch has been updated from Jess' comments. Button's correct now, and the image has been adjusted to be smaller and below said button:
Apr 14 2022
My comment about the desktop also entirely applies to here: T304036#7856122
Quick definition: I'm going to use "editing schemas" to refer to EditAttemptStep, VisualEditorFeatureUse, and talk_page_edit, and "UIActions schemas" to refer to DesktopWebUIActions and MobileWebUIActions.
My comment in T303654#7856027 applies to this as well. Summary: if we set the sample rates the same in config, this should work.
Conveniently: everything about whether or not to log in both desktop and mobile DiscussionTools (assuming nothing triggering oversampling is present), and also the UIActions schemas, goes through mw.eventLog.inSample. Because of how this works, using a global "pageload token" as the sampling ID, any events with the same sampling rate on the same pageload are going to be sampled the same.
@EAkinloose that screenshot cuts off halfway through the event before where I'd expect saveSuccess to be -- is that because nothing followed it?
Your codesearch is missing things -- it's used in MobileFrontend in schemaEditAttemptStep.js and schemaVisualEditorFeatureUse.js, and also in DiscussionTools.