+2 (pun intended)

the scrolling behavior is fixed in all modern browsers.

i don't consider this to be a bug. it's just how it works. I don't see a good alternative implementation for this.

Users informed:
https://commons.wikimedia.org/w/index.php?title=MediaWiki_talk:WatchlistMessageCreator.js&diff=328114921&oldid=110512750&diffmode=source
https://en.wikibooks.org/w/index.php?title=MediaWiki_talk:Common.js&diff=3487667&oldid=3218875
https://bn.wikibooks.org/w/index.php?title=মিডিয়াউইকি_আলোচনা:Gadget-Special_characters.js&oldid=19514

This is similar to T58228: "replace all" does not work with a regular expression that contains a caret or a dollar

This ticket is so old, so are the browsers on which this was reported..
I'm closing this. If anyone has a specific problem, please file a new ticket with detailed reproduction steps.

@He7d3r these browsers are no longer supported are they ? I suspect most of these issues have been fixed through the years, either by actual fixes, or by excluding the browsers in question from those that are elegible for JS execution.

Found the cause of this. It's because there is no initial selection, because 'find' has not been used before 'replace' is used. This messes up the offsets that the panel keeps internally.

@Tpt a because the VE only knows about #wpTextbox1 so without this change it's not getting the version with the header and footer content...
hmm.. sounds like revisionslots/mcr cannot come quick enough ;)

Rolling out on the next phabricator deploy/update

Just to be clear, I still don't understand Timeshifter's problem.

Browser/OS problem

WikiEditor uses it as:

	latin: {
		labelMsg: 'special-characters-group-latin',
		layout: 'characters',
		characters: mw.language.specialCharacters.latin
	},

and VE

$.each( mw.language.specialCharacters, function ( groupName, groupCharacters ) {
			groupObject = {}; // button label => character data to insert
			$.each( groupCharacters, function ( charKey, charVal ) {
				// VE has a different format and it would be a pain to change it now
				if ( typeof charVal === 'string' ) {
					groupObject[ charVal ] = charVal;
				} else if ( typeof charVal === 'object' && 0 in charVal && 1 in charVal ) {
					groupObject[ charVal[ 0 ] ] = charVal[ 1 ];
				} else {
					groupObject[ charVal.label ] = charVal;
				}
			} );
			characters[ mw.msg( 'special-characters-group-' + groupName ) ] = groupObject;
			groupObject.attributes = { dir: rtlGroups.indexOf( groupName ) !== -1 ? 'rtl' : 'ltr' };
		} );

So the question is.. what was the purpose of calling mw.language.setSpecialCharacters() and at what time (during the page load) was this done? As both editors only build their table of characters once, the moment of calling it would be rather critical.

@Tpt so why is it overriding the getSelection anyway ? which tools is this trying to support ?
Have we considered making the individual header/footer areas textSelection compatible instead ?

Since all the modules are unified now (T165112), this no longer seems like a relevant problem to me.

why is it very difficult ? selectors make this easy right ? I'd rather not introduce new classes unless we really need to.

The video makes it clear that the user is WE2017
Sort of critical information. Could also have been deduced from the description's: "publish again, in the summary window"

worksforme

action: {
	type: 'callback',
	execute: function () {
		console.log( "testing" );
	}
}

lol, i was looking at this only yesterday ;)

In T188817#4748104, @Fomafix wrote:

A simple styling for disabled buttons is

opacity: .5;

Would look like:

So.. the wikiEditor patch avoids the double load, and when backported to 1.31, 1.32 and 1.33 (yikes...) should fix this ticket. I could remove the double load from lqt, but really this was always not entirely safe in WikiEditor, so might as well fix it there and this way, we don't FU the lqt compatibility with various branches even further.

This is only if the editor was force loaded, by something else having a dependency on it. MediaWiki-extensions-CodeMirror indeed does this. I suspect that reftoolbar might as well....

This seems like something for Phabricator admins. I'm not aware of an acl groups for token management and it doesn't seem part of project-admins, so i assume @mmodell or @demon as actually administrators might have to do this. And if not, they should know who CAN do this.

@1Veertje for future reference, in such cases, don't assign tickets but instead mention the person in the comments and ask them. Assigning usually only happens either through team processes (employees) or by self-assigning (volunteer work).

The infuse is not related to this:

These files are still up btw...

The element no longer has that

ah, I was mistaken, it's still there, just in a 2nd block of CSS definitions.

@MichaelSchoenitzer_WMDE is this still an issue ? I remember this got fixed in OOUI at some point. The element no longer has that

.oo-ui-buttonElement-frameless.oo-ui-iconElement > .oo-ui-buttonElement-button {
    min-width: 1.42857143em;
    min-height: 1.42857143em;
}

so i'm unless you say otherwise, i'll close this.

Definetly seems to be about VisualEditor-MediaWiki-2017WikitextEditor

@Mvolz Are you sure this was about WikiEditor and not VisualEditor-MediaWiki-2017WikitextEditor ?

Not going to happen. target audience too small, and we can't even get the bugs fixed in what we have now. Tools and gadgets seems more suited for this purpose.

Can this be closed or are there still things we want to change ?

We no longer have the mode without dialogs since MW 1.31 T165112: Kill of most/all the WikiEditor RL modules

Hmm, indeed doesn't seem to do much. What's the history here ?

This wasn't the 2010 WikiEditor, but the 2006 toolbar.

Related request T88767: Special Character inserter in wikitext editor is missing some IPA combinations

The only way to make this work is with JS manipulation. I guess we can do something with touch start and remove the readonly attribute temporarily. But really, this seems like something that should be fixed at the OS level.

I can reproduce now the key is: " bottom edge of the editing window is below the scroll" and you need to have the ULS menu enabled of course.

No longer valid. All browser black/whitelists were removed in change https://gerrit.wikimedia.org/r/c/mediawiki/extensions/WikiEditor/+/400697

Note, CodeMirror has related issue with T200280: Syntax highlighter disables Undo button in 2010 wikitext editor

Dear editing team, do you guys want to keep this ticket open ?

With the beta of MediaWiki-extensions-TemplateWizard having been deployed T202545: Deploy TemplateWizard, I'm calling this resolved. Any related issues should be filed against that component.

Realistically, this will not be implemented.

We no longer have the mode without dialogs since MW 1.31 T165112: Kill of most/all the WikiEditor RL modules

This seems duplicate with T27068: Non-technical way to customize the WikiEditor editing tools

This is actually a problem in core's mediawiki.action.edit.editWarning.js

Before and after shots of the it.wikipedia additional toolbar buttons gadget:

We no longer have the mode without dialogs since MW 1.31 T165112: Kill of most/all the WikiEditor RL modules

This was fixed a LONG time ago.

diffs to master of wikiEditor and LQT. I can't spot the difference that could be responsible for this so far...
Is this a public wiki ? It would make debugging a lot easier.

IE-only perhaps ? Because Safari, Chrome and Firefox all scale the toolbar buttons when zooming the browser.

Is this still a problem ?

This is an known upstream issue, for which there is no workaround, because browsers don't support this level of integration with the pasteboard yet.

Very much suspect this is related to the Google Trans gadget. We have also seen reports of it having issues with the search box input.

This was dealt with in the 2nd iteration of T198781: Add toggle/state buttons to WikiEditor.

@Krenair That's a good point I think. An included readme/explanation describing the boundaries of the included information seems wise.

Seems duplicate with T200145: Text on multiple lines is not shown for video subtitles

Hmm, it seems that the renderer prints before the page is finished downloading all the images for the page is finished.

@Schnark that is a well thought through argument.. thank you.