Other notes:

Here's my first stab at a proposal for how we'd provide a smooth migration experience:

Huh, for some reason I thought I tested this and confirmed that browsers didn't move this <a> tag, but you're right, they do:

In T257579#6841524, @egardner wrote:

(especially if we can drop the need to transpile code back to ES5)

To elaborate on this: I am currently working on T272104: Allow modules to opt-in to ES6 syntax support and T272882: Upgrade ResourceLoader JS minifier to support ES6, which will allow us to write ES6 code and ship it directly to the browser without using Babel. Modules using this feature would not be loaded in browsers that don't support ES6 (mostly, IE11), but we think that's fine since IE11's market share is low, and Vue 3 doesn't support IE11 anyway.

Some relevant tasks from previous times people brought up the idea of sending watchlist emails by default:

• T38316: Set "Add pages I edit to my watchlist" and "Add pages I create to my watchlist" to true by default on Wikimedia wikis (only for new users) was tried briefly in 2012, then rolled back. The plan was changed to only enabling it for new users, not existing ones.
• That led to T40796: Set "E-mail me when a page or file on my watchlist is changed" (enotifwatchlistpages) to true by default for new Wikimedia users, but it looks like that never went anywhere
• T47022: Make preference "Email me when a page or file on my watchlist is changed" true by default ended up only making the change for third-party MediaWiki installs, but keeping the status quo on WMF wikis

Digging into this further, @Krinkle and I found that, because MinifyJS uses regexes, it can't successfully tell whether / is a division operator or the start of a regex, even with reasonable (non-contrived) inputs. For example,

let num = (foo + bar) / baz, rx = /.global(ly)? unique(ness?)/;
// incorrectly minifies to
let num=(foo+bar)/ baz, rx = /.global(ly)?unique(ness?)/

Pull request now up: https://github.com/matthiasmullie/minify/pull/358

In T272882#6779352, @matthiasmullie wrote:

https://github.com/matthiasmullie/minify/commit/8538190f4ab21f77c938e51109547f0e943f7d44 would probably fix the slowness in that regex. Thanks for tracking that down!

For the OOUI input case, most of the slowness occurs on this line:

// multi-line comments
$this->registerPattern('/\n?\/\*(!|.*?@license|.*?@preserve).*?\*\/\n?/s', $callback);

Commenting it out speeds up minification of oojs-ui-core.js from 2372ms to 475ms.

Benchmark results:

My patch above implements what I outlined in T272104#6750238. A module can add "es6": true to its definition to mark itself as ES6-only, and loading such a module will throw an error on non-ES6 browsers. This error is handled similarly to other module loading errors, so it fails the promise when using mw.loader.using()but is suppressed when using mw.loader.load().

In T272104#6767669, @Jdforrester-WMF wrote:

Does that actually throw a catchable exception, rather than error as unparseable?

Yes, as long as it's wrapped in eval(). Attempting to eval() code that contains a syntax error throws a catchable exception.

ES6 compatibility isn't easy to test for, because there are so many aspects of ES6. I looked through kangax's compatibility tables and explored using native Promise support as a proxy for "good enough" ES6 support. That seems to work relatively well. If we ignore tail call optimization (which is not supported even by recent versions of Chrome), the only browsers that support Promise but don't support some ES6 features are:

• Android 4.4.3: supports Promise but almost nothing else
• Safari 12 - 13.1, iOS <14: doesn't support using certain Unicode characters in identifiers
• iOS <11: doesn't support scope shadowing resolution and shadowing parameters in for-in loop bindings
• Safari 12 ,12.1: doesn't do template string caching correctly (which leads to equality checks sometimes breaking)
• Edge 17, 18: Many RegExp-related features are missing, including Symbol.match, and some other ES6-y things (like proxies) don't work when RegExp objects are involved

In T178356#6632565, @Krinkle wrote:

And some additional numbers from opening that page in older browsers via BrowserStack:

• Safari 9: 53% spec compliant
• Safari 10.1: 98% spec compliant
• Mobile Safari iOS 9: 53% spec compliant
• Mobile Safari iOS 10.0: 98% spec compliant
• Android 4.4 (evergreen, Chrome 80): 98% spec compliant
• Android 4.3 ("Browser" like Chrome 68): 98% spec compliant

If you check the "show obsolete platforms" checkbox on kangax's es6 tables, you'll see that it claims that Android 4.4 is 5% compliant, and Android 4.4.3 is 7% compliant.

Alongside this, I think we should also formalize the notion of grade B (in between grade A and grade C) in ResourceLoader. Modules that are flagged as using ES6 should not be executed in browsers that don't support ES6 (most prominently including IE11). ResourceLoader currently does not have a concept of per-module executability, only a global one: the startup code feature-detects ES5 support, and either decides that no JavaScript is going to be executed or that everything can be. In browsers that support ES5 but not ES6 (like IE11), we'd presumably want to execute the ES5-compatible modules, but not the ES6 ones.

In T270137#6734931, @MMiller_WMF wrote:

@Catrope -- is the above your only/final feedback on the documentation?

In T256887#6734933, @Tgr wrote:

This confused me for a while, but I think I found an OK configuration. The stats are a bit strange though - for other wikis that I have seen precision and recall are more or less an "X" shape for the "bad" outcomes, while here especially for goodfaith precision is not even remotely monotonic, and it's just not possible to reach better precision than 0.6. Is that legit?

In T271124#6722315, @kostajh wrote:

Stepping back a bit, as mentioned in the task description, I think we should probably not use word boundaries and instead rely on other metadata from T267329 (ie instance occurence) to make the correct link.

We could use instance occurrence, if both mwaddlink and the frontend agree that that counter includes sub-word strings. For example, in A scary [[car]] careens, there would be three occurrences of "car", and the linked one would be the second one. Using context_before/context_after could potentially be more resilient, as long as mwparserfromhell and the Parsoid HTML agree on what counts as text and where block-level boundaries (e.g. paragraph boundaries) are.

I don't remember any examples offhand, but this has definitely happened before (cc @Jdforrester-WMF )

In T270137#6691297, @Tgr wrote:

• Identifying / backporting missing l10n. There is some script for this but I couldn't remember the details.

The way I recommend doing this is:

• Add the language code of the new target wiki to the requireCompleteTranslationLanguages array in Gruntfile.js
• Run grunt banana:translations (in master or in the currently-deployed wmf branch, depending on how soon you plan to deploy)

The output of this script is not ideal, but it's workable. Languages are listed multiple times, once for each i18n subdirectory, and they're not grouped together (the grouping is by subdir then language). It also complains about missing translations for messages that are optional and don't have to be translated, but there aren't very many of them.

In T271124#6720075, @Tgr wrote:

Oh wow that's sad. They could be expressed with Unicode property escapes (something like ([\p{L}\p{N}\p{M}][^\p{L}\p{N}\p{M}]|[^\p{L}\p{N}\p{M}][\p{L}\p{N}\p{M}]) I think?) but apparently IE doesn't support those.

Another alternative is to use unicodeJS.characterclass.patterns.word, which is a fully Unicode-compliant regex for word characters. From that we could try to concoct a regex that uses lookahead/lookbehind to implement word boundaries somehow (which we would also have to do if we use \p{L} and friends).

In T270146#6692799, @Jdlrobson wrote:

For the product owners wanting to prioritize this, can we update the description with how this impacts products? I'm also like us to add a test for this given the times this has broken, so that would be helpful for working out where this should go.

The impact is that all features involving programmatically scrolling something into view don't work in new Vector. In VisualEditor alone, this includes scrolling down the editor to display the highlighted text when doing find and replace, and scrolling such that the entire inspector is visible when clicking a link or reference near the bottom of the screen. I discovered this issue when working on T261398, where navigating to the next link recommendation may require scrolling down the editor to make it visible.

It looks like putting the surface in read-only mode works quite well for this. The only drawbacks I've found so far is that we have to toggle read-only mode when we want to change the acceptance status of a recommendation (but to avoid a flash in the UI, we can toggle only the DM surface), and that context items show a "View" button instead of an "Edit" button (but we can work around that for the link recommendation context item, and it's appropriate for the link context item).

In T267691#6625528, @kostajh wrote:

We could maybe also use BeforePageDisplay hook to export this data from the server-side. The data is not particularly heavy and should be fast to retrieve.

I think this is resolved, now that the patch is merged.

@Urbanecm noticed errors in the logs that looked like Pool key 'nowait:dpl-query:enwikinews' (DPL): Error reading from pool counter server 10.64.0.151., and asked me to revert

In T267705#6618687, @matmarex wrote:

Can this be fixed using ve.ce.Surface#selectAnnotation?

In T269804#6681051, @MMiller_WMF wrote:

@Tgr -- thank you! I think we would like to backport this tomorrow if possible. The community members are writing the copy now. A couple questions:

• Would this be immediately usable on any wiki?

Yes. Community members can also put the copy on the MediaWiki config page preemptively, before we deploy this feature tomorrow, and the banner text will appear immediately. In fact, that would be preferred, for ease of testing.

In T269477#6680840, @Volker_E wrote:

Even with above patches, we might need an additional OOUI release, given the number of interfaces that use TagItemWidget. Could need your help Growth team member devs tomorrow.

This patch adds the messages, but it doesn't add the robot icon. I'm also not sure if paragraph breaks are currently supported in those tooltips, I'll have to check.

If you have suggestions for how to fix the text alignment (item (g) in your comment above), I'm all ears. Both the text and the icon have vertical-align: middle, and neither has vertical padding or margin, so I don't know what else to do.

If we decide to purse T267706: Add a link in VE: consider using a permanent context instead of VE's built-in context, that might obviate these problems.

One thing that is clearly deficient about the current rules is that it doesn't handle about groups: in HTML like <span typeof="mw:Transclusion" about="#mwt1">...</span><div about="#mwt1">...</div> both nodes should be skipped, but the current implementation skips only the first one.

Another relevant piece of information is that some notification types supersede others. There is no systematic guarantee that the same event/edit/comment won't result in multiple notifications being sent to the same user, but we do try to make it that way through these supersedence rules:

Spreadsheet with the above notification types, when they're triggered, and what their text looks like in English: https://docs.google.com/spreadsheets/d/1MbLZKCc2Yy3q90Y78qSxUtBLLyGAzUm2oDHMeXVYq8g/edit

In T259572#6543237, @JTannerWMF wrote:

@Catrope does this spreadsheet accurately and exhaustively capture all of the notifications people could receive triggered by events on flow or wikitext talk pages?

I've edited the Hebrew message on TWN to work around this bug: https://translatewiki.net/w/i.php?title=MediaWiki:Wikibasemediainfo-special-mediasearch-empty-state/he&diff=prev&oldid=9688010

The cause of this issue is T249892: mw.message.parse() should not escape HTML returned from magic words (e.g. {{PLURAL}}). The Hebrew translation of the message looks something like Search more than {{PLURAL:$1|<span class="...">one</span> file that is|<span class="...">$1</span> files that are}} free to use. This syntax (putting HTML syntax inside of a PLURAL magic word) works in PHP, but breaks in JavaScript because of a bug.

Still not broken for me on testwiki, closing

Russian Wikipedia also encountered this issue, and we created a task about it at the time: T261714: Support posting new help desk questions at the top of the page.

It worked this time, the submodule update was created automatically without my intervention.

In T258017#6557815, @Catrope wrote:

In T258017#6557809, @gerritbot wrote:

Change 634755 had a related patch set uploaded (by Catrope; owner: Catrope):
[mediawiki/extensions/GrowthExperiments@master] StartEditingDialog: Make image in difficulty banner top aligned, fix padding

https://gerrit.wikimedia.org/r/634755

This patch does the 24/16 thing for item (c).

In T258019#6573343, @gerritbot wrote:

Change 635904 had a related patch set uploaded (by Catrope; owner: Catrope):
[mediawiki/extensions/GrowthExperiments@master] StartEditingDialog: Use smaller padding for mobile in various places

https://gerrit.wikimedia.org/r/635904

In T258016#6573344, @gerritbot wrote:

Change 635904 had a related patch set uploaded (by Catrope; owner: Catrope):
[mediawiki/extensions/GrowthExperiments@master] StartEditingDialog: Use smaller padding for mobile in various places

https://gerrit.wikimedia.org/r/635904

In T266033#6569882, @gerritbot wrote:

Change 635639 had a related patch set uploaded (by Catrope; owner: Catrope):
[mediawiki/extensions/GrowthExperiments@master] StartEditingDialog: Work around CSSJanus flipping bug

https://gerrit.wikimedia.org/r/635639

I'm being a bit silly here: I just removed variant A, so it doesn't make sense for me to complain that something doesn't look good in it. I've also added the 16px bottom padding so it looks better:

I was able to reproduce this by making my window short enough that the bottom of the suggested edits onboarding was out of view. I tracked down the issue by running $(window).on( 'scroll', function () { debugger; } ); during load and inspecting the call stack. It turns out that OO.ui.Window.prototype.ready calls this.$content.trigger( 'focus' ), which causes Chrome (but not Firefox) to scroll down so that it's centered.

This is live now! I apologize for the delays and the postponement. Other deployments were postponed/canceled and we had to wait for those.

Stage 1 is done, the patch for stage 2 has passed code review, so now we just need to wait for Oct 26 and deploy stage 2 then.

In T258017#6557809, @gerritbot wrote:

Change 634755 had a related patch set uploaded (by Catrope; owner: Catrope):
[mediawiki/extensions/GrowthExperiments@master] StartEditingDialog: Make image in difficulty banner top aligned, fix padding

https://gerrit.wikimedia.org/r/634755

While working on the big 24px->16px change mentioned in T258019#6557184, I noticed that the text in the difficulty banner in the variant C onboarding dialog was vertically centered on desktop, but should instead be top-aligned according to the mocks. The attached patch fixes that in both variant A and variant C.

Desktop issues:

Left and right padding in the desktop module intro topic area should only be 16px (not 24px)

Kosta's patch fixed this

Looking at var C only per this task, some items still to be fixed (or were maybe reverted at some point?):

All these screenshots are from variant A though (as you can tell by the presence of the start module in the background, and the topic filters below the intro section.

In T258017#6510357, @RHo wrote:

a. Similar to comment on T258019#6510238 - please make the Desktop left and right padding 16px for the module

This is fixed now, with Kosta's patch for that issue.

In T264636#6545662, @RHo wrote:

(ii) This also means updating the total card width according, done by adjusting the class .suggested-edits-task-card-wrapper to have a width:332px.

Done, on desktop. But what should happen on mobile? Currently mobile uses 260x128 for the image dimensions, should that change to something else?

No, we are keeping mobile as is (since we haven't made the same layout changes to mobile where there is just the SE module).

Great, that makes it easy.

In T264636#6545061, @gerritbot wrote:

Change 634138 had a related patch set uploaded (by Catrope; owner: Catrope):
[mediawiki/extensions/GrowthExperiments@master] SuggestedEdits: Change image size, styling tweaks

https://gerrit.wikimedia.org/r/634138

In T264636#6544942, @gerritbot wrote:

Change 634127 had a related patch set uploaded (by Catrope; owner: Catrope):
[mediawiki/extensions/GrowthExperiments@master] SuggestedEdits: Fix header icon size and padding

https://gerrit.wikimedia.org/r/634127