it just feels really wrong to process elements that are not the parsed content

...by attempting to add...

...caused a spam block list hit on $page...

I think that sounds reasonable. I'm sure there are gadgets out there without this attribute but at least we can offer an easy fix.

Reposting my comment on the patch here:

This should probably be upstreamed but in a way that is configurable. While in this case it makes sense that "escape" goes back, that is because the edit-template-param page is conceptually nested within the main dialog, so escape should "pop the stack".

In more linear workflows, pressing escape should probably still close the dialog.

I would suggest having a method like "getEscapeAction" in OO.ui.Dialog that returns empty string by default, and then can be overridden here to return 'back'

@Mvolz I'm not sure how urlStatus would work given the value type is different per wiki:

• on en.wiki it is a one of various strings (dead/live/deviated/unfit...)
• on fr.wiki it is a boolean/datetime (brisé le broken since = 4 juin 2018 or oui).
• on es.wiki it is a boolean (urlmuerta = [sí|no])

In T373875#10138364, @gerritbot wrote:

Change #1072249 merged by jenkins-bot:

[mediawiki/skins/Vector@master] Use base font size for wikitext editors

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

Possibly some old data in my local device. It was failing consistently for a few weeks, but now is working fine 🤷

The problem appears to the be the nowikis in the caption, which are triggered by square brackets next to a link.

I would note that the space-indented list is easier to edit in VE, while the <pre> wrapped is slightly easier in wikitext mode. 🤷

Most likely the user pressed the "Allow text styling" button, which deliberately removes the <pre> tags in the wikitext, and instead indents the text with one space.

This only affects standalone 3rd party usage of VE (ve-mw pulls the libraries from MediaWiki), and it is only used to generate language autonyms. It's unlikely any real world use case will come across missing data because of this, but I'll do an update now anyway.

I don't think there are upstream changes needed here. The fix is to not apply font scaling to interface components in the content area. Unless you plan to start scaling interface components?

It fails for me in Android chrome.

This also affects the other non-dropdown items in the toolbar, shown here with exaggerated border-radii. The radius is visible on hover.

DT example (note how the [edit source] UI component doesn't change size):

Other apps that may be affected by this:

There's misalignment in the 2010 wiktiext editor toolbar too, possibly due to the embeeded OOUI buttons on the right:

Ending a comment with a signed list item is still possible in wikitext mode (and probably the intuitive way people sign a comment that ends in a list).

I don't think we do any verification that users are starting with the same document state. You could probably also get a bug if 2nd user joined a different revision of the same article.

The plugin we use for this only uses classes found in the current codebase:

Note also that with an agreed prefixMap it could be set upstream in jsdoc-wmf-theme so extension never had to re-define it.

Data shows clicks to permalink timestamps on both non-talk (or subject) pages and talk pages. Is this possible/expected?

We use mix-blend-mode: darken so the text stays black under the highlight. There isn't a blend mode that works well in dark and light mode, so you'll need to use lighten in dark mode. mix-blend-mode is used in a few place so perhaps you will want to make this a re-usable token.

Deleted

Since T345281 all non-inverting images are marked with mw-no-invert, or cdx-no-invert.

In T362939#9844095, @JScherer-WMF wrote:

In T362939#9840767, @Jack_who_built_the_house wrote:

Then, boxes should be evenly spaced from top and bottom (p:last-child { margin-bottom: 0.5em }):

Yes, boxes should have equal top and bottom margins like the message component in codex.

Looks like https://gerrit.wikimedia.org/r/c/mediawiki/skins/Vector/+/1036715 which introduces negative margins.

Possibly related to T362939

You can prepare the upgrade patches before we do the release by installing from gerrit (npm i --save-dev git+https://gerrit.wikimedia.org/r/jsdoc/wmf-theme#refs/changes/47/1041147/2)

(executeAction is called directly quite rarely, so I doubt we would have a problem with the above breaking change: https://codesearch.wmcloud.org/search/?q=executeAction%5C%28&files=&excludeFiles=&repos=#Extension:VisualEditor)

2. We could fix this at the OOUI level, checking if there are visible actions, and if those actions are disabled. It would technically be a breaking change, although I don't know how likely it is that someone has deliberately programmatically triggered an action that is disabled in the UI. One could add an override to allow it to go through, or have it skip the UI check by default.

but the functionality is known to other people

I did not open all rMW2af1c3c901a6117fe062e1fd88c0146cffa1481d but I could imagine that the same bug has been injected in many many codes.

Looking at the code I can't see where this might be going wrong either. In T368029, there was an issue with the first argument being undefined, but in this case the first argument is a literal object, and only the second argument can be undefined, which isn't a problem.

> Object.assign( {a: 1}, undefined )
< {a: 1}

When on source text editing something is marked and string overwriting is requested, undefined is additionally inserted into wikitext after selection end.

Users expect to be able to follow the links in the preview - to check on the source while editing. Link contexts work the same way. If you feel this functionality needs to change we should file a task explicitly for that and discuss the pros and cons there.

I've never really understood the hidden file standard (leading .) so happy to go without it. Other tools are inconsistent, so I don't think it matters too much which we pick:

• .eslintrc.json
• .stylelintrc.json
• .bananaconfig.json
• tsconf.json
• package.json
• bundlesize.config.json