New core special page? If it's always global, it relies on an external database. It can't be in core.

If per-user-per-page blocking is on your roadmap, then you probably want to build a new extension for it. If it's not, then the functionality is best left inside Echo. So I'd go with...

1. Put the mute list in the echo extension and move it out later if necessary (based on the roadmap, within this quarter)

Block: User cannot perform certain actions.

In T171624#3534343, @dbarratt wrote:

Regardless, since we know that the "list" will be used for both muting and blocking, it doesn't make sense for this to be in the Echo extension.

In T173411#3534087, @kaldari wrote:

Also reported for Special:Notifications.

Hi @Volker_E. It's annoying because it's unlike what I see on other websites and it makes everything space out more instead of the compact version of things I'd like. I looked at the new design and still think it's a tad bit too big. The normal sized text looks weird against those huge checkboxes.

@Pastakhov Are you still working on this?

@Legoktm, thoughts on this? I recall you said at one point that the extension was more of a proof of a concept. What are the more fragile/hacky parts of it that need some rewriting?

This is still happening.

In T171624#3531218, @TBolliger wrote:

Perhaps. But I don't see any strong value in an option to not make this cross-wiki, which is what I believe T16950 will do.

Drive-by feedback: The checkboxes/radio buttons being larger than the text is very annoying and I'd much rather they were the same size or a teeny bit larger, not the way they are currently.

Hi, we're hoping to get this extension out this week/early next week. Can we get this reviewed soon? Ping @dpatrick

In T161054#3529652, @kaldari wrote:

@Niharika: But then what happens when the user scrolls? If the CodeMirror div only covers the part of the NWE that is in the viewport, it won't work very well when the user scrolls down.

Found another teeny bug while testing this - NWE shows the 'Syntax Highlighting' tab in the dropdown and lets you enable it even if the user has not explicitly enabled the Beta feature. I'm not sure if this is intentional.

In T170001#3522332, @Esanders wrote:

As VE doesn't use CodeMirror for input (and does use native browser cursoring in its own CE) this won't be a problem for the new wikitext editor :)

In T2424#3526844, @Johan wrote:

I think we should mention this new feature in next Tech News

This will go into production later this week? Or next week?

I added some of the open questions we discussed in the session to the task. Feel free to add more if I missed anything.

Two open source options I really like the UI of:

• http://demo.mamute.org
• http://paizaqa.herokuapp.com

In T161054#3494090, @kaldari wrote:

@Niharika: Yeah, I think that part would be easy, but I imagine converting NWE to fixed height would involve some complicated hackery to NWE. @Esanders: Thoughts?

I support this. It's tripped me a couple of times now. What's the reasoning behind the flag? Can the extension still do some stuff (which we haven't enabled but third parties might have) with the flag being false?

CC @Pastakhov

Maybe @Esanders can shed some light on this.

@Pginer-WMF Maybe you can take a look at this during the hackathon? :)

Okay, so here's what I know:

• CodeMirror does a poor job of supporting RTL
• The latest branch is better but far from perfect
• Some old branches of code exist aimed at improving RTL support but they're very out of date and would need tests and more to get close to being merge-able
• CodeMirror does not have an option to let the browser take care of the cursor events which is a bummer

Done! Thanks!

In T164441#3479621, @kaldari wrote:

@Niharika: Here are blue and black versions (for the on and off states):

Highlight-on.svg398 B

Download

Highlight-off.svg398 B

Download

In T171109#3479583, @Johan wrote:

There's an announcement ready for translation here:
https://meta.wikimedia.org/wiki/Community_Tech/LoginNotify/Announce

However, this will be postponed a few weeks because of a performance issue.

I'm not 100% sure but I think providing codemirror the viewport dimensions wouldn't be hard. We need to pass them as part of the initial config options.

In T161054#3475987, @kaldari wrote:

@Niharika: I'm not sure how we would have them reliably quantify the lag. Besides, the original point of this ticket was to explore how we might address the lag, not proving that the lag exists.

Are there any follow-up tickets from this investigation yet?

In T164441#3471755, @Nirzar wrote:

:( though ideal, it's kinda blocked on T147494: Refine WMF icon set to remove teardrop stylistic detail

Some questions from the meeting:

1. Is it possible to have global blacklist instead?
   1. Does Echo give us the flexibility to add a table/column and store this list for global access?
2. The current implementation (as part of Special:Preferences) will be a hurdle when/if we deploy GlobalPreferences (can't override list globally, need a way to "merge" lists everywhere, basically global blacklist). Can we think about moving it into a new Special page instead? Other options?
3. Is there a use case for having a local and a global blacklist both?

In T164441#3470634, @Pginer-WMF wrote:

Here it is the SVG version for the icon:

Highlight.svg332 B

Download

...and in case an RTL version is needed:

Highlight-RTL.svg337 B

Download

Eventually this should replace the "highlight" icon in the icon repo.

In T164441#3470471, @Nirzar wrote:

this is pau's mock

we were discussing it but he should have a final version today

Hah, nice! Any chance we can get a sneak peek at how it's gonna look? :)

@Nirzar based on feedback and follow-up discussions, we've decided to switch to using the highlighter icon (Option C in your earlier list T164441#3240304). Can you please give us the new images for the icon (both on and off state)?

@TBolliger I'd suggest that they install some basic extensions locally and look at the code. There's some reasonably up to date docs on https://www.mediawiki.org/wiki/Manual:Extensions and then https://www.mediawiki.org/wiki/Manual:Developing_extensions. Some good starting extensions can be

• https://www.mediawiki.org/wiki/Extension:Example
• https://www.mediawiki.org/wiki/Extension:Thanks
• https://www.mediawiki.org/wiki/Extension:PageAssessments

In T161054#3465427, @Deskana wrote:

Quick tests on our own devices are useful as a rough indicator. Can we also test this more comprehensively somehow? If this is put out there and users complain of performance issues, having a more rigorous study of performance would be beneficial.

@Pastakhov Why is Codemirror not being loaded via composer?

On a much more old Dell Thinkpad, it was noticeably slow at redrawing the page. It was fast initially but as I typed faster, it got slower and lag got more noticeable. It was about 1-2 seconds to render it. :(

I did the same test with an older laptop (less RAM and weaker processor) and also didn't see any significant lag. The only time I noticed some lag was when I was scrolling the page rapidly but it wasn't too noticeable.

@JMinor Nope, the issue was similar though - when you would click the Share icon and click copy to clipboard, it wouldn't actually give you the image link. That is, your clipboard won't have the image link as it should.

In T170906#3461570, @Quiddity wrote:

Possibly (?) related discussion at https://github.com/codemirror/CodeMirror/issues/4076

In T161054#3460213, @Esanders wrote:

My main concerns are not with load times, as they should be comparable to VE (slightly faster), but without the viewport optimisation every keystroke can trigger a full document re-rerender which makes typing sluggish on long articles (e.g. Obama).

I don't think we need to keep those 35G worth of data anymore even. The bot is gone forever and that data is pretty outdated. I can't think of a reason we'd ever need it.

@Pastakhov Can you tell us why we might be overriding the cursor movement over the default one? Is it possible to turn off cursor movements as handled by the Codemirror library and use the ones from the default editor?

@kaldari I talked to Moriel and she thinks there are a few bugs in how we handle RTL as well as the library demo page. The NWE takes care of those because VE has inbuilt support for cursor handling when it comes to RTL (with mixed in LTR) text. She thinks it's a crazy thing to be doing by ourselves, we should rely on the editor to do it and not try to override it.

Ah. I am going to grab Moriel and talk about this.

In T171108#3454694, @Johan wrote:

OK. Do you need the extra feedback you hope you'd get from Tech News? Otherwise I'd probably hold that another week, until it's ready for the content wikis where the Tech News readers edit. (:

In T171108#3454627, @Johan wrote:

@Niharika OK, thanks. Roughly when would you assume we're ready for content wikis?

Not reopening this yet, but I talked with a volunteer yesterday and they could not figure out for a good few minutes which is the right icon. Here's a bit of my communication:

<drewmutt> This is what I'm seeing.. http://imgur.com/wC4XYWC
<Niharika> drewmutt: Click on the button with curly brace. { }
<Niharika> To the left of "Advanced"
<drewmutt> Ohhh..
<drewmutt> Man that's obscure.

Johan I think it's ready to go out in Tech News already. We can tell them that Syntax highlighting is available on simplewiki and testwiki as a Beta feature and we're looking for feedback.

This is more tailored to MediaWiki installs but is pretty powerful: http://pythonhosted.org/mediawiki-utilities/

I copied over the Obama article to testwiki for testing it: https://test.wikipedia.org/wiki/Test_page_long and used throttling (Chrome browser devtools) to limit my connection speed. I disabled caching for testing.
My test device, however, was a ~3-year old fairly powerful MacBook Pro. Here's an analysis of what I found:

I would imagine that the average user is unaware that preferences are not already global.

Okay, I tried breaking the job queue on my local install and seeing if it would prevent me from logging in. Here are the things I tried:

1. Set $wgJobRunRate = 0; in my LocalSettings.
2. Returned false in this function, right at the top.
3. Returned false in this core function, right at the top.

This is currently blocked on T170825: Performance review of LoginNotify but should hopefully be unblocked soon.

Ah. I was under the impression it changed existing Special:Preferences. Thanks for clarifying!

@Legoktm What do you think of having a dedicated special page for handling global prefs as part of GlobalPreferences extension instead of the checkboxes we have right now?

This extension uses many hooks that might potentially slow down login.

In T167329#3444434, @dbarratt wrote:

In T167329#3442401, @Niharika wrote:

It should specify a name as mediawiki/page-assessments and a type as mediawiki-extension,

Name should be "PageAssessments"
Type should be "parserhook"

In accordance with how other extensions do this.

I'm talking about the name in composer.json I looked at other extensions at that was the format for the type which is always mediawiki/extension-name and the type is always mediawiki-extension per Composer Installers

It should specify a name as mediawiki/page-assessments and a type as mediawiki-extension,

Name should be "PageAssessments"
Type should be "parserhook"

How about we use #999 and italicize comments to make them stand out? That's fairly common in IDEs.

In T170175#3434044, @Whatamidoing-WMF wrote:

The workflow was:

1. Click the blue Save/Publish button. You will see the edit summary box. (Optionally, type your edit summary now.)
2. Click the "Review your changes" button under the edit summary box.
3. Click the "Return to save form" button to exit the diff. You will see the edit summary box again. (Optionally, type or change your edit summary now.)
4. Click the button above the edit summary box to save and publish your changes.
   
   The request was to provide this optional workflow:
5. Click the blue Save/Publish button. You will see the edit summary box. (Optionally, type your edit summary now.)
6. Click the "Review your changes" button under the edit summary box.
7. Click the blue button above the diff to save and publish your changes.
   
   The difficulty is that some people click the blue "Publish changes" button in step #3, when they probably wanted to click the "Return to save form" (where they could finish typing their edit summaries) instead.

From the discussion link:

"Before it defaulted to the end of the month, now it forces you to select a specific date; there is no default."

In T170272#3435369, @dbarratt wrote:

So what should the template be if the Takedown was not received via email?

I'd say the same. From and To fields can be used however the user needs.

I haven't been able to find any problems yet either. Works fine with different viewport sizes.

In T170175#3433098, @Whatamidoing-WMF wrote:

If they look good, I hit Publish but sadly this time I don't get a dialog box for adding an edit comment. Is this a bug or is it intentional?

Intentional, because a few editors asked for it. As always, please mind the gap between "intentional" and "best possible design". Ideas for a better design are always welcome.