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.
Fri, Apr 19
Thu, Apr 18
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.
Wed, Apr 17
@Ryasmeen When this makes its way to bn.wikipedia we'll know how much it has helped your specific case. :D
Fri, Apr 12
Thu, Apr 11
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.
Wed, Apr 10
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.
Tue, Apr 9
@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.
Mon, Apr 8
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.
Thu, Apr 4
@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.
Wed, Apr 3
Tue, Apr 2
@matmarex: see debug.js in the EventLogging extension for more details, but basically, do this in your console:
Mon, Apr 1
Thu, Mar 28
Wed, Mar 27
Ugh, reading things before responding to them. Terrible.
MobileFrontend.hooks.php has onOutputPageBeforeHTML which does a relatively simple set of things to the content.
It's making a patch for the mediawiki-config repo, and scheduling it on Deployments -- at which point one of us will need to be there during the deploy window to verify it worked after the ops team +2 it and push it out.
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.
Feb 15 2019
Elsewhere Neil said that this is useful for how the data is actually being analyzed currently, as he was just aggregating the various cite- values together.
Feb 5 2019
Jan 24 2019
Having checked: mobile VE's only source of abort events was (incorrectly) when switching. It has never emitted them for anything else. I'll improve that, so at least canceling out of it will emit them.
Jan 23 2019
We expected a drop because the patch for T211156 stopped abort (and ready) from being logged when switching from wikitext to visual, which I suspect was a common source (you could look for ones with the abort_type logged as switchnochange).
I cannot reproduce this with Safari, at least.
Jan 22 2019
Is the -1ms timing and the console warning expected/acceptable?
Jan 19 2019
I'm not sure if we can without changing the meanings of them, though. At least the timings will change, and no longer really be measuring the same thing as the VE timings for the same events. E.g. init will suddenly become the same thing as ready/loaded. There's also not a great place to do saveSuccess client-side, since it'd be on the redirect to a regular article page...
Jan 17 2019
Assuming it passes the QA phase, certainly.
Yes, that wound up being there.
@dchan: In this case it'd need to be model selections -- the annotation inspectors deal entirely with changes to the model. There's a reason I went for the somewhat-hackier route of just tweaking the DOM selection after the normal annotation path had been taken. :D
Jan 16 2019
Jan 15 2019
@dchan: I was thinking that the alternative route was to write greater awareness of nails into selections, such that when setting a selection you could declare whether it should bias inside or outside. That'd avoid this whole post-selection-change fixup routine... but would also complicate the core selection-handling code for the comparatively-unusual case. (That said, I don't have a comprehensive set of cases in my head for model-equivalent-but-practically-different selections. It's possible it'd be applicable to enough cases that it'd make sense to move further into the core...)
Jan 8 2019
Dec 18 2018
Almost the only QA possible for this one (besides it not actually breaking things) would be Neil saying whether the data being collected is correct, I think?
Dec 13 2018
Second patch for the MobileFrontend side of the logging code, which had the same use of mw.log.
There's also some intellectual verification -- turn on trackdebug, and verify that the timing keys in the logged events after a switch don't have any null / NaN values.
Dec 12 2018
Related is probably: T204387
Quick testing with trackdebug confirms that on mobile switching back and forth between visual and source modes causes a flurry of events which we probably don't want:
Kibana suggests upon following the provided link: "Unable to completely restore the URL, be sure to use the share functionality". I'm sufficiently unfamiliar with using it that the rest of this reply is going to be based just on what was said in the ticket description.
It should be pretty simple to do -- I've had it on my list of tasks to knock out when I have 15 minutes free.
We called it out in the planning document for T211255 as a related change that should be made. David or I could probably fit it in, depending on which of us finishes up our prototyping / research first.