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.
We also very-recently added a highlight to the category box when in VE mode, to bring it in line with other editable block elements in VE.
That patch is very much a quick prototype that didn't consider any edge cases. A little thought would need to be put into e.g. "what if the user's launching VE for the first time and is going to get the Welcome dialog".
Wed, Sep 22
@egardner If we're just fixing the use of parse in MediaSearch, I think it'd be quicker to do that (and backport it) than to revert the DiscussionTools patch.
Message does contains setInterfaceMessageFlag whose documentation seems to suggest it exists entirely to restore the interface behavior after setting a language. We could probably add that to the call chain in ResourceLoaderContext? I'm unsure of whether that'd cause side-effects we care about...
I would suspect that these IPs wouldn't be producing many (any?) automated actions, as inherently any requests from them should be coming from inside a Safari browser.
I also agree about keeping it the same every time. (And avoiding extra storage.)
Specifically whatever metric we use shouldn't collide with anything that's set by the reply tool. E.g. "discussiontools-editmode preference is empty" would get us only people who had never used either the new discussion or reply tools.
I think that's a bunch of new-functionality requested for the core Special:Preferences page? (Linking to specific subsections, and adding some sort of first-run experience for said links.)
Tue, Sep 21
I was talking with @Urbanecm about this around mid-August, and they did some log-analysis. At that time, ~30% of beta users of iOS 15 visiting wikipedias were using Private Relay. That's perhaps a high-water mark, as I'd suspect that the sort of person who installs a beta OS is also relatively more-likely to be paying Apple for extra storage.
You should be able to test this on beta using the links in matmarex's earlier post. Given the patch that was written, it'd be good if we could test anything you can think of around the empty-state display, with and without discussiontools enabled -- if we got the logic wrong, it could manifest as either the "edit" page appearing like the regular article view, or as the empty-state version not being shown.
init_timing isn't particularly meaningful -- all the other timings are defined as "time since some other event", but init is the first event. We also try to log the init event basically-immediately after the click that triggers the session, so there's not much to record. (In DT it'd be bimodal -- either it'd be instant, or it'd take a few hundred milliseconds as we animate the closing of a different open reply widget.)
Mon, Sep 20
In this context, "not used" is being defined as people whose discussiontools-editmode preference is empty.
Yeah, looks like the onGetActionName hook should be a little smarter about this?
Thu, Sep 16
Wed, Sep 15
We could probably do some analysis on this after it's available -- see whether watchlisting of talk pages drops noticeably? If so that'd be a good sign that removing the watchlist item would be a good idea.
Tue, Sep 14
iOS 15 will be out on September 20th: https://www.apple.com/newsroom/2021/09/apple-unveils-iphone-13-pro-and-iphone-13-pro-max-more-pro-than-ever-before/ (tucked away in the pricing and availability section)
Incidentally, we should still be able to (mostly) compare this new data after this merges to historical data -- the timing added to saveSuccess/saveFailure should be about equal to the time between the saveIntent and saveSuccess/saveFailure events in a given session. (With any difference being very minor and down to transmission time, I'd think.) This would be a more complicated query for Megan to run, but...
Depends a bit on the use-case of the integration, I think.
@ppelberg I don't know of a specific place. Thus far everything we're logging is the same as for VisualEditor -- it's the same two editing-related schemas. (This will change as the new instrumentation is about to add a commenting-specific schema.)
Mon, Sep 13
Note that it won't be perfectly comparable, since we've made the http error more granular so we can distinguish subtypes. http in the earlier logs will be comparable to http-[various-numbers] + timeout + abort + parsererror.
This would appear to have completely stopped as of August 27th, which lines up nicely with the deployment.
This would appear to have completely stopped as of August 27th, which lines up nicely with the deployment.
Tue, Sep 7
My assumption was the same as @matmarex -- but I admit I didn't confirm it before implementing.
Mon, Sep 6
We saw some complaints of this again today on Slack, or at least a presumably very similar one where it's erroring with "Error contacting the Parsoid/RESTBase server: (curl error: 28) Timeout was reached". Couldn't reproduce it myself, though I was trying a few hours later, so it might have been some intermittent issue.
Thu, Sep 2
Wed, Sep 1
I've also looked through this, and can't see how this would be happening. It'd have to involve something like different user-preferences or cookies showing up to different anon requests. Caching issue, maybe?
Fri, Aug 27
Bartosz did some quick searching and didn’t turn anything up. However, worst case it’ll be the status quo for editing a talk page, I think — with “opening the new topic widget” standing in for “navigating to the source edit page”.
Thu, Aug 26
Patch won't affect the user-not-registered case, as that's not a warningbox. (It's solely targetable as .mw-userpage-userdoesnotexist error, but it could easily be added in to the same behavior.)
Ahh, okay. I misinterpreted it as "hide it on pages where the empty state is showing", sorry. That sounds like a reasonable approach to me -- splitting the difference.
The disadvantage to hiding the original notice seems to be that it conceals information that people who don't want to add a topic might still want to see, with no indication that it'll be present before you click the button.
The notice is recreate-moveddeleted-warn.
Any reason not to just add it to the list-o-suppressed-notices? (So the second one in the new-topic widget won't show up.)
Aug 26 2021
Can't speak for the spelling-out-that-it's-public part, but I know that the link in the article-talk's title was deliberately removed because I asked about it as well. The desc and desc-user messages starting with similar text seems reasonable to me, and they do split into being page/user specific after that opening blurb.
Aug 25 2021
Good news on the “lots of mobile readers being IP-blocked” front, though: private relay will be off by default initially, though it sounds like they plan to flip that later in the 15 cycle.
In Special:Preferences#mw-prefsection-betafeatures: the Discussion tools beta feature should contain a list item that reads: Receive notifications when new comments are added in sections you have subscribed to.
@MNeisler Thanks for checking -- let me go nudge this and see whether it's just logging being disabled, or if something else needs to happen to the schema...
Aug 24 2021
Whereas the appearance as of beta 6 lets you just toggle approximately the current iOS 14 location bar between the top/bottom:
By "floating-oval" are you referring to how the address bar currently behaves[i]?
Having checked, I don't see any validation errors showing up referencing the integration field. If @MNeisler could confirm we're actually seeing events getting logged with integration==contenttranslation, this'll be done.
Aug 23 2021
@MNeisler Sure! They're:
@MNeisler do you have access to querying the unfiltered user_properties? None of the properties here are in the filtered version.
As betas progress, the iOS Safari address bar has become less visually-radical, but now can be toggled to being either on the top or bottom. This seems easier to cope with than the floating-oval, but we should make sure that this doesn't cause any strange offset issues with e.g. mobile context items.
Aug 19 2021
Could we just change the default for existing users. It's a beta-feature and there's almost no users with subscriptions yet -- locking ourselves into creating preferences rows for all new users forevermore seems sub-optimal.
So, that patch changes the default for everyone. "Only affect new users" is a pain, because preferences.
Aug 18 2021
Context: the remaining patch can't be merged until Peter approves merging the entire enabled-on-mobile patch stack.
Aug 17 2021
This should probably be verified once the train has gone out -- just double-checking that (a) @MNeisler seeing if there are events which are being stored with the appropriate integration, and (b) me making sure that we don't get some spike in schema validation errors in logstash. (I normally wouldn't worry, but this is the first time I've had to update one of the new-style schemas, so there's at least a chance I've missed something.)
There's a little on-wiki discussion of the Private Relay feature and its blocking.
Aug 16 2021
Aug 12 2021
Ah, right, and that's not working here because an empty page will be too short to be scrollable. This makes sense.
Also, since the doc is restricted...
Consideration: "Wikipedians" is a difficult thing to have in the copy. After all, this extension is going to be running on non-Wikipedia projects; should we call someone on Wikitionary a "Wikipedian"? (It can also be run on entirely non-Wikimedia projects -- if someone installs it on the wiki for their knitting community, they're not a Wikipedian.)
Aug 11 2021
Copying Bartosz's comment from the original ticket:
Our interface and the notifications interface are not aware of each other, and our interface has no way to react to anything happening in the notifications interface. It is definitely possible to make that happen, but we'd need to make some changes to Echo, I'd prefer to handle this in a separate task.
There haven't been any of these errors since August 5th, so I think we've gotten it.
That patch is the most-naïve possible version to us providing our own comment structure. It's just dumping the flat comment list from CommentParser, resulting in something like:
Yeah, that one would be it.
@santhosh Yes, sorry, I missed that one.
Aug 10 2021
While what was implemented in T288314 is an improvement, I think there is more that could be done (see the task description's newly-created ===Behavior section).
Aug 6 2021
T274832 did have a list. I think I can approximate the correct result by checking for "discussion enabled" + $title->isTalkPage()
would it be accurate for me to think the time between someone pressing Add topic and said topic being posted to the page will be significantly faster on production?
You mean compared to what's shown in the video there? That was taken locally in a docker container on my laptop. I'd generally expect production to be a bit quicker, though it's complicated. (Much more powerful servers, but serving more traffic at once, and with more room for your internet connection between you and the server to be slow. 🤷🏻)
Fine, fine, fine, it's now updated to work without even that flicker of the widget changing: https://youtu.be/5r4B_D-VKa8
I've updated the patch to be the more-expansive "don't teardown, but do clean up the reply widget" variant. There's no flash of empty state, though there's a moment of the widget having emptied itself out.
Actually, I noticed one more objection, which is that it makes the "you replied" toast appear, disappear, then appear again. (Because it appears for however long it takes the reload to happen, disappears until the page is loaded enough to show it, then times out naturally.)
That seems to be consistent with the pre-deploy rate of errors, so I don't think this patch actually touched whatever's causing this.
Hmm, can we do this? It'd be a little inefficient, but it would look nicer.
I think the only objection would be that there's a chance the user would start interacting with the new contents and then lose that interaction as the page reloads.
This is the warning appearing when the focus is lost from the title, moving the cancel button out of the way before your click on it can happen. You don't actually have to click the cancel button twice, just click anywhere at all outside the title and then the cancel button.
It's appearing in any namespace where discussiontools would apply. You'll note that Wikipedia: pages get reply links, e.g. https://en.wikipedia.beta.wmflabs.org/wiki/Wikipedia:Village_pump911
This is probably the most-trivial approach: https://youtu.be/aUCPBHUUCfs
So, the reason for this is that when we post a topic that creates a page, we're refreshing the entire page. (Because there's a lot of things on the page that need to be updated to reflect that it's a real page now, and that's difficult to update.)
Aug 5 2021
Also, to adjust this going forwards, we could suppress (much) unknown reuse causing logging by just not having a default and making it abort logging if none is set. This wouldn't help with reusers who extend ve.init.mw.ArticleTarget, but the more-generic ve.init.mw.Target would cope.