Gerritbot should've marked this as resolved when rEGADb340532c526a was merged.

In T171180#4459955, @TheDJ wrote:

I've been looking into this a bit, and the reason to me that this is a problem seems to be that there simply is no such thing as target=desktop. The only use of setTarget that I could find is by MobileFrontend and that sets 'mobile'. In all other situations, the target == NULL. (PS. what does this mean for PageOutput::filterModules ? )

@mmodell Commits from the 9th (rMWe0fab761f34c7c10ba33f0ead4969fe981ce9aa4) to the 12th (rMW67ba3f31ed5ed30c0c08bb5a75bb098e3ffbe824) seem to still be stuck on importing.

The issue is the mix-blend-mode property used in the animation, which causes browsers to use the faster, but ugly, text rendering. The pulsing animation needs to be implemented without using mix-blend-mode (should be easily done with z-index) or removed. It's very low importance to have the animation, and is certainly not worth making the page unusable due to the headache inducing blurry text.

The main issue I have with the way the widget works currently is for anything you type to actually have an effect, the user must press enter, which is totally counter-intuitive in a text input. Every other form has already conditioned the user to never press enter in text inputs until they are completely done and want to submit the form, and to instead press tab or click on the next field when they are done with the current one.

It's a simple fix, but it was stalled waiting review. If the issue is still relevant a year and half later and someone wants to review I'm happy to rebase. The main thing I personally wasn't sure of was if my test was any good or made any sense.

So what about everyone on 1.29 who are going to have their scripts broken, and then broken again when they update to 1.30 when the ID is reverted back?

It's caused by running the HTML through [[ http://php.net/manual/en/class.domdocument.php | DOMDocument ]] and getting it back out with [[ http://php.net/manual/en/domdocument.savexml.php | saveXML ]], rather than [[ http://php.net/manual/en/domdocument.savehtml.php | saveHTML ]].

My main concern is this inconsistency is a pitfall that is easy to fall into for extension developers. Either the API should normalize line endings like the edit form does, or the edit form shouldn't normalize line endings, and leave it entirely up to the content model to handle.

In T127147#2073423, @Krinkle wrote:

For example, you may want to use the skins filter instead (e.g. skins=minerva).

The problem is that cite does allow block elements in references, and then breaks the output by wrapping them in a span.

It's caused by the icon in the title. Removing it or changing its styling to inline fixes it.

.phui-font-fa {
	display: inline;
}

I don't think a new project cloning Vector should've been made for this (especially as this task as currently stated is invalid), not only are all Vector commit links without a project specified now broken (8a09ba2014e6 used to link to rSVEC8a09ba2014e6) due to the duplicate commit IDs, but this is exactly what branches exist for: to work on a set of changes separately from the main branch, to be merged in later.
Frankly, I don't know if it even needs a separate branch. You can work on implementing features from Winter (a nice concept, I agree) individually, it doesn't all need to be done in one go. Separate tasks blocking this one should be created suggesting the individual features to be implemented.

is-on seems like a far too generic classname to me. Should be something like mw-ui-button-active.

Gerritbot on holiday? https://gerrit.wikimedia.org/r/#/c/273436/

As far as complaints go, I'm talking about power users. They're the sort of people that will use arrow keys for navigating suggestions, so they don't have to move their hand to the mouse, and will already use the up arrow to loop back around to the bottom of the list.

I can foresee a lot of complaints about having to press an extra button to get to the suggestions with that approach.

I've submitted a patch which does this, though we might want to discuss if showing it immediately is actually desired (technically, there is still a 120 ms delay; although this could be removed if desired).

I already submitted a patch for this when I claimed it, but the bot obviously ignored it for some reason...

Rebased and updated patch to add release notes and get parser options in a better way.

Backporting because not being able to use mw.notify to reliably notify users until 1.27 isn't great.

Since that page didn't say anything special for security patches, the patch itself doesn't demonstrate or give any hints as to how to exploit the bug, and it's been like this for over two years and requires an old version of Scribunto or an old version of Widgets, it didn't seem like it'd matter much.

https://gerrit.wikimedia.org/r/#/c/189449/