Surprisingly, voting didn't come up very high in the TPC. I think it's only covered under "Workflows": https://www.mediawiki.org/wiki/Talk_pages_consultation_2019/Phase_1_report#Workflows

Ran fine for me with fresh:

Running "karma:firefox" (karma) task
07 08 2020 21:46:05.332:WARN [filelist]: All files matched by "/ve/node_modules/qunit/qunit/qunit.js" were excluded or matched by prior matchers.
07 08 2020 21:46:05.412:INFO [karma-server]: Karma v5.0.9 server started at http://0.0.0.0:9876/
07 08 2020 21:46:05.412:INFO [launcher]: Launching browsers FirefoxHeadless with concurrency unlimited
07 08 2020 21:46:05.414:INFO [launcher]: Starting browser FirefoxHeadless
07 08 2020 21:46:07.793:INFO [Firefox 68.0 (Linux x86_64)]: Connected on socket wsnpt1qoY8bSQkiSAAAB with id 29299701
................................................................................
................................................................................
................................................................................
......................................................................
Firefox 68.0 (Linux x86_64): Executed 310 of 310 SUCCESS (12.555 secs / 12.457 secs)

+1 we could do with a video icon as well :)

Expected the Reply tool's compose window to open right beneath the comment being replied to.

Sticky is positioned relative to the parent element, so I don't think position sticky can be used here due to the widget being embedded deep in the DOM to take the correct position within the list.

This should be testable on Beta now.

I filed and fixed this in T259828

the Special page tab is somewhat in the middle

Increased width and colours fixed:

We weren't using the content language for the prefix message, this should be fixed at http://patchdemo.wmflabs.org/wikis/03cf1da7dd9d63e9e8bb70b558d6086b/w/index.php/Talk:Main_Page

In looking into this with Jess, the summary edit message is heavily customised on many wikis, for example on zh.wiki it is used to provide a gadget that adds clickable common edit summaries:

Not also that on article pages the edit summary label is defined in the message summary which many wikis override, for example in en.wiki it links to a help page and says "Briefly describe your changes" in small text: https://en.wikipedia.org/wiki/MediaWiki:Summary

Of the three, it seems least likely to catch the attention of, and [potentially] subsequently confuse, Junior Contributors

Note the above patch is in in OOUI, so this won't be testable on beta until the next OOUI release.

As part of our investigation into notifications, we believe we will be able to identify when comments have been posted using any tool (see https://gerrit.wikimedia.org/r/c/mediawiki/extensions/DiscussionTools/+/614907)

Thanks, can you link to a diff of this happening?

I think this is very low priority. I don't think we need to design too much for very low widths on desktop. In general the whole interface, not just our tool, breaks down below a certain size.

This appears to be the first bad edit: https://office.wikimedia.org/w/index.php?title=Community_Relations_Specialists/Audiences/Meetings_with_Product&diff=prev&oldid=271810&diffmode=source ?

http://patchdemo.wmflabs.org/wikis/34a9f7f45cb7952af0528ea2bbff9f17/w/index.php/Talk:Main_Page

Note that all the implementation will be done on T250332. This ticket will just be editing a message on ar.wiki to change it from '@' to '◀'.

I could reproduce this when changing the browser zoom, but not at 100%:

What browser/OS?

Of the email notifications that are sent for talk page events, what proportion of them are opened?

Most email clients prevent this being tracked even if we tried (and I don't think we do try)

It's possible but very unlikely to get edit conflicts with this tool. The two requests would need to arrive at the server probably within a second of each other. That said when it does happen, the behaviour you describe in (2) sounds correct as these are the rules for same-user edit conflicts.

I would guess that T259272 and the top margin issue will be fixed in one patch, as they both stem from a single line of CSS (that applies negative margins to the toolbar).

(2) is visible in the TemplateData dialog:

I verified this fix on the live site with iOS 14 beta. @Ferdi2005 does this work for you now in iOS13.4?

Note that the toolbar doesn't left align with the tabs when it should:

@Tacsipacsi do you know the keyboard shortcut for indenting in Gmail in Hungarian?

Peter filed the resize issue as T258840. As this was merged last week it will be deployed this week unless reverted.

Also the error is coming from deep within Ace, so there may not be a lot we can do.

After:

Some clarifications:

In T255190#6330633, @Arlolra wrote:

@Esanders As of T255190#6313944, we've removed HTML4BlockTags. But why are you copying this list? Is it to mimic some Parsoid specific behaviour that we should account for or just a convenient place to lookup what was once considered block tags?

There's a technical issue here as the resize is done outside of the IME code, which make it harder to notify the IME that a resize has taken place.

This appears to have been resolved at some point:

In T254263#6333935, @ppelberg wrote:

In T254263#6281012, @Tacsipacsi wrote:

I think it does know—the author is the user who hit the save button. This should be available even without DT. The other two pieces of information aren’t, though, and probably it won’t be possible ever to reliably guess them, like when someone replies to several people in one edit.

We might have a way to detect all three pieces of information, regardless of the tool/interface being used to post the comment. Although, it's still too early to say for certain.

@santhosh has merged the patch on GH, so this is back with the Editing team. Thanks.

The easy way to fix all of this is to unbind tab/shift+tab from VE completely as we already have CTRL+[ and CTRL+] bound (this is what GMail does). The only issue is if this works on other keyboard layouts that may not have easy access to '['.

Setting to 7em:

FYI both the mobile apps, which also implement lede paragraph reordering, apply the transform to images:

All the blocked tasks have been resolved

Since this was filed, the horizontal alignment as been fixed:

Related: anywhere outside these outlines is not clickable and does not get cursor:pointer

@Lofhi I would expect so.

https://github.com/wikimedia/WhoWroteThat/pull/167

It appears they are used for this feature, which is loaded even later (also async):

These are the messages which are fetched: