After:

@Ladsgroup can you confirm this issue, and if there are any other shortcut issues with a Persian keyboard?

I think this is deliberate when we split nodes, so that wikitext formatting is preserved (not an issue for paragraphs, but for headings/table cells/lists etc.)

Oy that "targets" property....

So this is resolved then?

In T213429#4881119, @Esanders wrote:

In T213429#4869866, @iamjessklein wrote:

• In Source editing mode, selecting to edit the whole article only shows the intro section when it should reveal the entire article

This was a deliberate decision made by the then mobile team, I believe made for performance reasons. I think there is a separate ticket about create separate links for edit-whole-document and edit-lede-section. I have an update to the patch which matches this behaviour in visual mode (so it edits the lede section). If we want to change this is should be consistent in both modes and we should be aware it would be a big change to the current mobile wikitext experience.

we can consider if we need a different fix for older versions.

It looks like this floating context became standard around Android 6 or 7. Your test device (Android 4.4) is the oldest we support.

CC @Krinkle in case this is related to recent TemplateData changes?

This was a while ago, and probably before we dropped ES3 support fully, so probably not as pressing now. I think I had in mind third party support so that users could avoid loading apps built with OO if the browser didn't support them.

https://en.wikipedia.org/wiki/Beam_(music)#Positioning

To clarify, the horizontal beam would require the notes to be at the same height, as the stem should be the same height:

In T213429#4869866, @iamjessklein wrote:

• Performance - The load time feels exceptionally slow

The labs instances are generally going to be slower, this is not indicative of production, where it should be slightly faster than the existing system.

Copied from my comment on T197075:

@Neil_P._Quinn_WMF Yeah I mentioned before some controls to change back to full editing after entering section editing, or load in additional sections one at a time. With the current implementation there would be a few changes necessary, and some UI work too.

Yeah

Compare with the dialog, which doesn't show the word "Template" anywhere:

It would also be nice to show templatedata descriptions in the context when available. Our original designs had even more descriptive labels, which would probably require extra templatedata: https://commons.wikimedia.org/wiki/File:VisualEditor_context_designs_2015.png

I think the desktop version should have more verbose description, in some cases the template name itself could read like a message and so could be misleading without some context showing it is just a template name, e.g.

The problem is not the hook, but the unnecessary addPlugin call, which runs every time the target is created. The second time it runs, it fires the hook immediately to catch up with previous calls, but the new target hasn't been activated yet.

A similar issue on uploads.js

if ( $( '.errorbox' ).length === 0 ) {

@Ryasmeen can you provide a screenshot? Also details of the Android OS used.

The right one is more acceptable, although it is still uncommon to use stems of different lengths. If you really want to avoid the diagonal beam, you can just put the notes at the same height.

Where is the task for the most recent change (from the VE version to the OOUI version)?

To anyone who reads musical notation (the target audience here), as opposed to basketball fans, this just looks wrong.

you should probably leave a link to this bug in the code, to prevent someone from "fixing" this in future

The publish destination section will have an information icon that will open the corresponding documentation page in a new tab/window.

In T208981#4829513, @matmarex wrote:

So if I understand correctly, you would want something like this in the reference context menu:

So it looks like the Grafana dashboard only plots the 'activation' events, which have been disabled in mobile since 2015: T109525, https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/VisualEditor/+/242952/

Parsoid round-trips <references responsive /> to <references responsive="" />, and in fact does this with all XML-style attributes probably by design.

We record the scroll offset and restore it when the temporary editor is replaced with the full editor. I'm not sure a lot can be done as the browser probably allows scrolling while blocking JS is running.

If it is matmarex describes then there is nothing to be done here.

Another thing: how do we deal with longer depicts input?
By default, OOUI's TagMultiselectWidget element expands down. Are we ok with that? If not, what do we want? (and this will probably incur a lot of work...)
And when all elements are in a horizontal layout, this also causes the other elements (dropdown, search icon) to drop slightly since they're middle-aligned (fixing that so that the other elements remain at the top should be a pretty easy override, though)

Yes

The closest we have at the moment is ActionField, which has styles for combining text inputs and buttons, and dropdowns and buttons. There is no generic mechanism for combining widgets.

Regression was caused by moving renderHtmlAttributeList to initialize unconditionally in https://gerrit.wikimedia.org/r/#/c/VisualEditor/VisualEditor/+/195238/ (by @Catrope). I think for GeneratedContentNodes, we don't need to call renderHtmlAttributeList when updating.

This message need to be created, I think: https://hu.wikipedia.org/wiki/MediaWiki:Visualeditor-cite-tool-definition.json

Yes this is Citoid not being fully configured. Note also the manual tab is empty when creating a new citation.

After step 3 the only option is currently to insert. Can you give more detail reproduction steps?

Which wiki is this on? Citations that contain a single template should take you to the template editor instead, when the wiki is correctly configured.

Can you ask the affected users to open the developer console (F12) while loading the editor, to see if any errors are reported?

Fixed all on-wiki uses.

mwgrep "\.infuse\("
commonswiki         MediaWiki:Gadget-advanced-search.js
dewiki              MediaWiki:Gadget-old-movepage.js
hewiki              MediaWiki:Nosaving.js
huwiki              MediaWiki:Gadget-QPreview.js
jawiki              MediaWiki:Common.js/titleChecker.js
jawiki              MediaWiki:Vector.js
plwiki              MediaWiki:Gadget-sk.js
plwikibooks         MediaWiki:Gadget-sk.js
plwikinews          MediaWiki:Gadget-sk.js

Not all of these will be passing string.

they are both handling clicks with different results

From gerrit:

I think there's an argument for not using the gradient styling on the button. DropdownWidgets in Apex have hover styling, are clickable, but have no shading:

wmui	apex

Is there a way to bootstrap the loading of VE to get the first load smaller? Maybe by providing a minimal set of components to render the editing interface for typing without the toolbar? Many of the mobile overlays load quite slow these days (to the point beta cluster selenium tests timeout) and it would be great to find a way to make this less noticeable by improving performance rather than focusing on the UI portion of it.

This isn't a priority for the team at the moment, but community patches are always welcome.

Why is $element not a link? I note on https://doc.wikimedia.org/oojs-ui/master/js/#!/api/OO.ui.mixin.ClippableElement that $clippable and $clippableContainer are links. Shouldn't we be fixing $element to be a link, rather than unlinking it?