Looks like it has data-diff-move="null", I don't think that attribute should be there at all if the value is null

https://patchdemo.wmflabs.org/wikis/b47a017de5c94e68321e246f05fbd175/w/index.php/MediaWiki:Common.css

Actually it turns out that the previous hack of user-select:none is causing FF to split the selection into multiple ranges, which adds the linebreaks. Removing that hack fixes FF.

Well that's annoying. I can see no reason for FF to add those linebreaks, and I've tried messing around with the styling of the numbers (resetting white-space:pre on them, using different display values) to no avail.

Yes, eventually: T251207: [Epic] Scale DiscussionTools to all Wikipedias

In T267404#6746658, @Marostegui wrote:

@Esanders is this something that can be disabled/expired if needed?

• what if once this is deployed it causes disk issues on our parsercache infra? can this be rolled back/disabled/keys deleted

It's pretty easy to rollback this feature, we will also have a flag so it can disabled via config.

Not much to sign off here either.

This seems sensible and uncontroversial:

• they cause problems
• they add no real value
• they are extremely rare
• it is already implied that you aren’t supposed to use them because the signature input is single line

Also the test suite fails.

This also affects the sticky button bar on Special:Preference (for save/cancel buttons). The patch above appears to fix it.

nb we can link straight to the discussion section using Special:Preferences#mw-prefsection-editing-discussion

In T272076#6752917, @ppelberg wrote:

In T272076#6749886, @Esanders wrote:

After talking with @Ryasmeen, we came to think there is value in keeping the New Discussion Tool deployed as a beta feature on the beta cluster initially [i] to ensure the pre-deployment QA we have planned [ii] will happen in an environment that closely resembles the environments where it will be available.

Once we verify the tool is working as expected in this environment, we can graduate it to an opt-out setting on the beta cluster.

It appears that talkpagetext is not included in the VE edit notices API (which the tool would use) so is not currently an issue. Clearly we never bothered to add it because VE is not supposed to be used on talk pages.

Verified on beta cluster: https://he.wikipedia.beta.wmflabs.org/wiki/%D7%9E%D7%93%D7%99%D7%94_%D7%95%D7%99%D7%A7%D7%99:Common.css

This still appears to be happening today on wmf26: https://dtcheck.toolforge.org/dtcheck-2021-01-15.html

In T259865#6683562, @Whatamidoing-WMF wrote:

Is this vote easy enough to figure out?

Verified on https://en.wikipedia.beta.wmflabs.org/wiki/Main_Page using OO.ui.Element.static.scrollIntoView( $('#footer-info-credits')[0] )

Could be https://gerrit.wikimedia.org/r/c/mediawiki/core/+/630182 ?

Thanks for this. The extension is actually supposed to support <syntaxhighlight dir=rtl>.... In this case the line numbers would be on the right, so I've amended your patch to position line numbers based on code block directionality (which defaults to LTR on all wikis).

Note also that the newtopictool was enabled by default on beta for the last 2 days, as we hadn't touched the config file for the beta cluster (only the file for production wikis). After the patch above was merged it is now a beta feature.

I think we should just make the tool available by default on the beta cluster, as we did with the reply tool in T255223.

I agree, I don't think the beta feature needs to be visible if it does nothing, we just don't want it to wipe a user's previous preference.

I agree that on a very dense template definition page, the bracket matching benefits from being stronger, however syntax highlighting is used on all pages and I suspect the vast majority of users are using it to just edit article content, so most bracket matching will be for simple wiki links. This is the use case I encountered and where I found the background change to disrupt the readability of the content.

@Krinkle You might want to cross post the above comment to T9356, as it’s out of scope for this task, but is a good outline for how that task might be resolved.

@Pginer-WMF @santhosh We've had a brief look at this, but we're struggling to reproduce the issue. Could you provide or highlight the reproduction steps?

I've fixed the links in the task description.

I see the error if the hash is set to #/search

Also can't reproduce, or see the error in logstash with the link provided

@LSobanski we are adding a new parser cache option, which can only ever be set on talk pages (approximately).

Personally I don't think this is worth the effort. A message which just describes the possible features with links to your preferences would be sufficient, given the nature of beta features.

Follow-up: T271956

CC @LSobanski . We are planning to merge this for next week's train. It will split the parser cache on talk pages for user who have this feature enabled.

Some users have reported that sessionStorage does not appear to persist in Firefox when the browser crashes.

I set them to the same colour as they are in the editor. They could probably be a bit lighter but we will need to maintain an accessible contrast and consistency between interfaces.

This can currently be verified on mediawiki.org. The reply tool option now shows in the Editing section of Special:Preferences.

@Tsevener do you find that most users auto-update to the latest version of the app quite quickly? i.e. should we expect to see edits with the <p> tags dry up soon after the deployment?

Re-using this task for the Scribunto (Lua modules) support.

In T221908#6722309, @Esanders wrote:

• the editor loads faster (sometimes much faster)

Because fr.wiki uses the same template for a simple "citation needed" number and also wrapped text (Template:Citation_needed_span on English Wikipedia) I would advise not setting it up until T265907 is resolved, otherwise people using the tool on wrapped text usages would get the text deleted.

If the wiki is already using the feature successfully, you can copy the params config from en.wiki: https://en.wikipedia.org/wiki/MediaWiki:Visualeditor-template-tools-definition.json

Documentation task is here T265878, but we need to close out T265907 before rolling out to more wikis. Which wiki were you thinking?

Appears to be working on beta: https://en.wikipedia.beta.wmflabs.org/w/index.php?title=User_talk:ESanders_(WMF)&type=revision&diff=469806&oldid=469805&diffmode=source

If it is essentially to list which features are still in beta, that would be easiest to do as an actual list, then we can build it dynamically, e.g.

Enables experimental talk page features:

• a new workflow for [replying to specific comments]
• [adding new discussion topics]
• [visual enhancements]

...I like this idea; I've updated the task description to incorporate the above.

In T29531#6733471, @Nardog wrote:

In T29531#6728446, @Esanders wrote:

@Johan, correct.

And why is that? Why exclude Lua? Bizarre choice.

I was wondering why the patchdemo wasn't working, but I remembered that the feature is currently disabled by default behind a feature flag. Currently you can't change mediawiki config while setting up a patchdemo (unless you create a patch to change the config).

unchecked vector skin.

The above patch just bails if the editor input no longer has WikiEditor data when the initialisation runs.

The offending change made sure that the syntax highlight plugin runs more reliably by running as a hook instead of an event.

Also https://fr.wikipedia.org/?diff=178528344 and maybe https://fr.wikipedia.org/?diff=178513936 (a self-closing nowiki removed)

In T29531#6727418, @DannyS712 wrote:

Is there a way to opt-out of this?

@Johan, correct.

Also “contents” in the table of contents.

If we wanted to give people the option to use the new discussion tool on empty pages, we would need to intercept red links. We would likely still want to give people the option to use the full page editor.

Sorry @Ryasmeen, the patch was reverted, hence the “re-apply” patch that is still in review.

I feel like the word order should be changed to be increasing specificity, so <namespace>-<feature>-<modifier> instead of <namespace>-<modifier>-<feature>.

I don't think we should be rounding up to 0.1kb. That's silly IMO and I suspect rounding up by say 0.5kb would reduce the frequency of these errors.

Copied from Slack:

In T221908#6678146, @iamjessklein wrote:

2. I would feel more comfortable if we did some kind of test between the solutions to:
   • validate if this is a change that is warranted (although I personally am a fan of the standardization)

PR: https://github.com/wikimedia/wikipedia-ios/pull/3818

This looks like the source: https://github.com/wikimedia/wikipedia-ios/commit/f64a83b00275d13439b2d9c5cf5dcaf169b8226f

@matmarex How do users get linebreaks in their signatures in the first place? (e.g. https://simple.wikipedia.org/w/index.php?target=Fehufanga&namespace=3&tagfilter=&start=&end=&limit=50&title=Special%3AContributions)