Looks like it has data-diff-move="null", I don't think that attribute should be there at all if the value is null
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
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
Sat, Jan 16
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
Fri, Jan 15
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
Verified on https://en.wikipedia.beta.wmflabs.org/wiki/Main_Page using OO.ui.Element.static.scrollIntoView( $('#footer-info-credits') )
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.
Thu, Jan 14
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.
Wed, Jan 13
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.
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.
Tue, Jan 12
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?
Mon, Jan 11
Re-using this task for the Scribunto (Lua modules) support.
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
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.
Sat, Jan 9
Fri, Jan 8
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.
Thu, Jan 7
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 “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.
Tue, Jan 5
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:
Mon, Jan 4
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)