You can use $overlay: this.$overlay within a dialog.

T225750 might live under this task somewhere

Apologies to the web team for the speculative tagging, turned out to be just an internal issue.

We should probably add a test runner that calls instantiates every CE node, the checks that teardown works without setup.

https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Cite/+/698063 fixes a similar issue (teardown before setup)

Notifications are working for me on beta now:

The main patch has been updated with the new copy: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/DiscussionTools/+/685413/5..6/i18n/en.json

The linked to demo is using a old version of the patch. The latest one already addresses this: https://patchdemo.wmflabs.org/wikis/c647283588/wiki/Talk:Main_Page

The above patch highlights the comment in blue when you follow the link:

Implemented as:
* [https://www.mediawiki.org/wiki/Talk_pages_project/Notifications Receive notifications] when new comments are added in sections you have subscribed to.

Receive Echo notifications

"Echo" is a deprecated internal product name. They should just be called "notifications" in the UI

DiscussionTools reply widget is broken by the patch that adds mw-body-content to MW surfaces unconditionally, as the widget was already within the mw-body-content, so the font-size: 0.875em rule is applied twice.

Other places that could be affected by these changes:

• ContentTranslation
• Preview within 2017WTE
• Reference previews inside VE reference context popups
• Visual diffs (both within VE, and on the history page)

Looks like this was caused by https://gerrit.wikimedia.org/r/c/mediawiki/skins/Vector/+/682774

Demo: https://patchdemo.wmflabs.org/wikis/b1cca98add/wiki/Main_Page?veaction=editsource

I think step 0 should be "Make the existing prompt non modal" (T282789), as already implemented in https://gerrit.wikimedia.org/r/c/mediawiki/extensions/VisualEditor/+/551313. I don't think should block on step 1 above.

In T282625#7081261, @santhosh wrote:

1. The strong binding of available icons to javascript helps you to use quickly discover and pick an icon through autocompletion features of popular IDEs.
2. A build step or even real time checks by IDE make sure you are not refering an icon that does not exist. This is better than a loose dependency like CSS classnames

We built something similar when creating infrastructure for the topic subscriptions feature, so this should be mostly design work:

Sounds good. Do you need any more input from the Editing team at this point?

The above pull request needs review ^

I think bracket-less might be more plain than with brackets. Without brackets it looks like a prototype, with it looks like we consciously designed it to look like [ edit ] links?

As we are proposing applying a shorter expiry time to talk pages, our analysis should probably evaluate talk pages separately (if that is not already planned) to ensure there is no significant regression.

The above patch does indeed result in a flicker (on Android, haven't tested iOS), but I think this is neater than setting ce=true.

readOnly mode keeps ce=true so that we can detect cursor placement (which it make invisible) and launch contexts.

In T279157#7050350, @Ryasmeen wrote:

@matmarex/@Esanders :This doesn't seem to be working in Beta. When I try to filter the recent changes with #discussiontools-source-enhanced, it doesn't show the edit made with Reply tool's experimental source mode. Rather it says "No filters found".

In languages which don't vary the user namespace title by gender (e.g. English) this will result in user genders becoming a lot more visible to other users. While user gender is not considered private data, making it more visible may have unintended consequences.

Thanks - I had to recreate most of the filters and groups from scratch as well.

I've looked into this a bit more and I'm no longer sure it's a good idea to re-use the section edit link area right now:

• It makes the subscribe feature harder to pick out on the page, and it is grouped in with a tool that performs a very different action (edit)
• There will be inconsistency across pages and headings:
  • On most talk pages where VE is disabled you will see [ edit | unsubscribe ]
  • On project pages with __NEWSECTIONLINK__ you may see [ edit | edit source | unsubscribe ]
  • Any heading lower than an h2 will only show [ edit ] or [ edit | edit source ], making it harder to see quickly which sections are subscribe-able.
• Section edit links are configurable:
  • There's no user preference to disable them, but...
  • They can be disabled for a whole page using the __NOEDITSECTION__ magic word
    • It may be possible to work around this by recreating the section edit link group ourselves, and then just adding one link so you get [ unsubscribe ], but this feels hacky and flaky.

The existing sizes in OOUI are:

	small: {
		width: 300
	},
	medium: {
		width: 500
	},
	large: {
		width: 700
	},
	larger: {
		width: 900
	},
	full: {
		width: '100%',
		height: '100%'
	}

NB There is also "Read more" functionality in the media search widget: