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.
Tue, Jun 18
Testing this patch beyond the superficial "it doesn't break the existing behavior" requires that you set the $wgMFDefaultEditor config variable, to one of source, visual, preference, or abtest. The first two are obvious, preference means it should obey your user's desktop preference, and abtest should do a 50/50 split which is persistent for a given user (including anonymous users, until cookies are cleared). Super-deep validation includes making sure that abtest causes eventlogging to include the anonymous_user_token and bucket fields with appropriate values.
@marcella: I don't think there's a reason to do it and save it -- it's meaningless from a data standpoint, which is why doing this edit in other ways already shows an error; this is just a way to reach that state without the error being shown.
A really simple enhancement along the lines Ed suggests there would be to allow the link to Wikipedia:Citation_needed to have a hover preview like article links do. It seems plausible that the preview summary that appears then would provide enough information for the user to proceed with.
Thu, Jun 13
@ppelberg I think your questions are tangentially relevant to this specific ticket -- this one applies to once you're within the editor, and your questions largely apply to users who're still pre-editor and reading the article.
One problem: if we store it in user_id, we will have to start purging that field after 90 days, whereas we currently do not. We should instead add an anonymous_user_token field or similar to EditAttemptStep.
How's the purge configured? I don't know anything about the mechanism for it -- is it raw "empty this field after X time", or are there more conditions possible?
@JMinor sorry, I was caught up in the Editing offsite when that comment came in and I missed having the time to work on it.
Wed, Jun 5
Outcome of call: generating a persistent-ish anon userid (cookie, expiring 90 days) and storing it as a negative integer in the user_id schema field would be acceptable for analytics.
Tue, Jun 4
Bot didn't add the patch: https://gerrit.wikimedia.org/r/c/VisualEditor/VisualEditor/+/514369
Alas, it doesn't. That said... possibly it's a useful bit of cleanup.
Mon, Jun 3
May 23 2019
May 22 2019
May 21 2019
During the planning meeting @matmarex said that we only store the preference after a switch has happened, rather than when the editor is opened.
May 15 2019
@Ryasmeen Yeah, the constraints on that space are such that the table-icon gets to take up the smallest amount of space of any of the table-adjacent options. It could become inconsistent with the others -- larger and floating over the other content a bit more, say -- or something like expanding the highlight could happen (so that there's that blue highlight joining the arrows to the table-icon and drawing eyes to it).
May 14 2019
@Ryasmeen -- Hard to discover that clicking the box will do something, you mean? Or hard to work out what the options within will do?
May 9 2019
May 8 2019
I can't reproduce it not scrolling while the find panel is open, but the jump to the top when the find panel closes is definitely there.
May 2 2019
I recall poking around for this in the past, and we've been fairly good at avoiding the model knowing about its views. Which is sensible design, but inconvenient at times like this.
Apr 24 2019
Apr 23 2019
Heh. Amusingly (?) I remember explicitly testing that post-link stuff, and completely missing that the context behavior had changed because I was entirely focused on the select-inside aspect..
@Ryasmeen Shouldn't be yet, I don't think. I believe it merged after the deploys started last week, and this week's the RelEng offsite so there's no train... so next week, I guess?
Yeah, I filed it here because it seemed to affect MobileFrontend generally, and just happened to be coming up in response to a redirect section-editing triggered.
Apr 19 2019
Apr 18 2019
I said it on the other ticket as well, but I suspect that pages which start with a / are probably far less common than subpages, so it'd be a strange case to optimize for...
I think the suggested behavior here is far less likely to be what people intended than the subpage behavior. Pages whose names start with a / are unusual, and I suspect people are more likely to be trying to link to a subpage.
Apr 17 2019
@Ryasmeen When this makes its way to bn.wikipedia we'll know how much it has helped your specific case. :D
Apr 12 2019
Apr 11 2019
I'm using a current checkout of it, so I suppose I have a few months of miscellaneous changes since the 0.10.0 release.
I can't reproduce the bad link generation, though I agree the not-actually-a-redlink is still happening.
In part we speak here of pull request #2990.
Apr 10 2019
I think this is partially Toggler.prototype.reveal passing the urlencoded selector into jquery, which predictably throws, because $( '#%E0%A6%B6%E0%A6%BF%E0%A6%B0%E0%A7%8B%E0%A6%A8%E0%A6%BEma' ) is quite invalid.
Apr 9 2019
@Esanders: ...actually, as well as pasting from externally, I was copying external links within that instance on test2, and they were getting stripped. So we might have a separate issue?
@mingle: It doesn't seem to? I just checked on test2, and cannot paste external links.
Okay, that's a completely separate issue. Seems to be with MobileFrontend not handling non-latin fragments at all well for the initial pageload. I'll make a different ticket.
Apr 8 2019
Until T208826 is done, this would have some side-effects, as removing the selection from within the text would immediately close the context popup. Once that ticket is done and the patches merged, it'd probably be doable.
Apr 4 2019
@Ryasmeen -- honestly, the weird part there is that it worked on en.wiki. We have a train stall at the moment, so en.wiki should still be on 1.33.0-wmf.23 which doesn't have the latest patch.
Apr 3 2019
Apr 2 2019
@matmarex: see debug.js in the EventLogging extension for more details, but basically, do this in your console:
Apr 1 2019
Mar 28 2019
Mar 27 2019
Ugh, reading things before responding to them. Terrible.
MobileFrontend.hooks.php has onOutputPageBeforeHTML which does a relatively simple set of things to the content.
Sorry, I missed seeing this question.
Looking at it... I think we've just always been pouring all of these in, and letting the schema accept the ones it knows about. I believe that it just discards the unknown properties, rather than the entire event in those cases, right?
A provision does seem to mostly work now... or didn't abort early, at least. Eventgate did throw out a bunch of errors when trying to build its node-rdkafka dependency, which can be seen in P8291 if you're curious.
Mar 19 2019
Okay, yeah. Patch made it so that we do var fragment = this.getSectionFragmentFromPage(); but that just interrogates the current markup of the page pre-edit. This explains changing the section-name breaking things, since after the page-reload it'll be a different id to look for.
Mar 18 2019
Yup, I have it.
I note that @Ryasmeen changed the title of the section. Perhaps we're generating an outdated section-hash as a result rather than one based on the new hash for the new title? The video didn't show the URL, so I can't be sure.
Mar 15 2019
I'll confirm that some forced-updating seems to have fixed this. Thanks!
Mar 14 2019
Let's see... doing exactly-what-the-error-message-says and adding the npm::node_version: 10 to hieradata/common.yaml gets through with no errors after only a few runs of provision.
The visualeditor role requires the restbase role which requires eventbus.
Mar 13 2019
Okay, I did a full re-initialization of vagrant, and this error didn't come up until I did role enable visualeditor. So one of the dependencies there is, I guess, not configured correctly?
A side-effect of some sort from rMWVAbb776a65b3e6dcd7a077add48fd3f1870dba333e, I assume.
Mar 12 2019
Isn't the 24ms just it being a really quick load because ResourceLoader has already loaded everything that comes from the mw.loader.using( 'ext.visualEditor.targetLoader' ) call, so it's just legitimately much faster than the 2565ms the first time?
@elukey No, nothing to fix it. Though it had, looking at it just now, switched into wildly spamming this into the log instead:
Mar 7 2019
That patch handles this ticket's case. We should probably go through all the changes in that patch and make sure that switching them to deep-extend won't cause any issues.
Seems to be the result of a8be7d15e94a8e by @Niedzielski, which changed how constructors initialize events. It passes event handlers into constructors, and does a non-deep merge of existing options with util.extend. This breaks if the existing options have any event handlers already.
Specifically the timing.ve.mobile.performance bits?
Mar 6 2019
Specifically: there's no autosave in wikitext mode, because that's not in the VE codebase -- there's no NWE on mobile currently. As far as I know we should have autosave working in visual mode, so it should recover from this case. It's possible that there's some disconnect in the recovery process, though, I haven't tested it.
I don't think this is section-editing specific? This is just the page getting kicked out of memory, and us not having autosave working on mobile (I think).
Mar 4 2019
This is because we don't actually try to preserve the value of the attribute, just its meaning. More potentially-confusing is that we discard the attribute entirely if it's the same as the wiki's default, so if the default changes lots of edits will suddenly be dirtied... and then toggle away from it if the default switches back again.
Feb 28 2019
Feb 27 2019
From a call today: Neil would prefer mobile-only oversampling. I'll work up a patch for that.
Feb 26 2019
Only mobile? I've taken a look at this, and @Catrope had hooked up mobile-and-desktop both to mw.config.get( 'wgWMESchemaEditAttemptStepOversample' ). If we want to only oversample mobile events, I think we'll need to tweak that.
Feb 21 2019
The other side effect of this bug was that removing all non-hidden categories from the page would leave an empty categories box, when it should have been hidden.