It would not occur to me to click on the black area to close the lightbox. If anything, in a full-screen slideshow mode, I would expect click on the image to advance through the gallery, although in MW I appreciate this takes you to the full size image.

There are 63 redirects to {{Citation needed}} on en.wiki, but just listing the first 4 most common will get us over 99% coverage:

So what you approach is trying to do is take an infobox, e.g. <table typeof="transclusion">...</table> and parse this as a paragraph-like node. However on the first parse you want to ignore the contents of the <table> so you disallowed the paragraph from containing any child nodes. The problem with this approach is it doesn't work for subsequent parses, i.e. when the document is written to/read from the database. You now have <p typeof="unadapted-transclusion"> which will use the same toDomElements/toDataElements paths, and so try to throw away the contents.

There is a gap at the bottom of the header (maybe related to T215426?)

The word loading is not centered in the header

Filed as T233099

After the latest icon fixes, most of these are now 40x40, which is just slightly below the recommended size. Was this a deliberate choice?

Indeed in this situation an exception is thrown on copy

TypeError: startNode is null ve.dm.Document.js:535:14
    shallowCloneFromRange http://localhost/VisualEditor/lib/ve/src/dm/ve.dm.Document.js:535
    shallowCloneFromSelection http://localhost/VisualEditor/lib/ve/src/dm/ve.dm.Document.js:446
    onCopy http://localhost/VisualEditor/lib/ve/src/ce/ve.ce.Surface.js:1929

This happens when the selection starts in the slug above the list. Such a selection can't be created in Chrome, but in FF you can create it by selecting backwards and ending your selection above the list. The selection then starts at offset 0.

Can you still reproduce this error? It could have been a transient server issue.

Thanks, that's very cool. I made a fork with some improvements: https://en.wikipedia.org/w/index.php?title=User:ESanders_(WMF)/veSuggestions.js&action=history (feel free to merge them across)

Could be a Parsoid issue?

@Whatamidoing-WMF does this sound like the cause (using a non-standard font size)?

Just because it's deprecated, doesn't mean we shouldn't test it.

In T208758#5392667, @Physikerwelt wrote:

In T208758#5392289, @Esanders wrote:

It's not good that in order to add popups support for a particular extension (Math in this case) the Popups extension itself needs to be modified, and know about that extension. There should really be a public API for registering extra popups functionality, c.f. https://www.mediawiki.org/wiki/Manual:Extension_registration#Attributes

I agree with you at 100%! However, we need to start from what's available. Currently, our goal is to push as much functionality to the math extension as possible and keep changes to the popup extension minimal.

1. I'd agree that the indicators set up a useful expectation of the tool not acting instantly. I think the reduced sized indicators remove a lot of the clutter they were causing
2. Either way this should be separated into a separate discussion.
3. I agree with Volker, half borders would be more code to implement, and I don't think would resolve the visual clutter issue for narrow screens.
4. Also not seeing the difference. Perhaps there's some confusion from my screenshots which were taken on desktop in mobile simulator mode, but the toolbar touches the top, left and right edges of the screen, so the shadow only appears beneath it.

In T230659#5432809, @cscott wrote:

In T230683#5432585 @Anomie proposes using the revision ID of the edit that creates the comment as its persistent identifier.

In T209266#5290007, @Pginer-WMF wrote:

@Esanders, can you tell us more about how Visual Editor is doing this? In particular:

• Can VE identify problematic references?

The patches above have fixed some known uses, but I'm concerned that the ext property should've be deprecated first as we may not have caught every case.

Not sure why that is my fault, but it looks like it should be .getExtension() instead of .extension.

There are 13,000 uses on en.wiki: https://en.wikipedia.org/w/index.php?sort=relevance&search=insource%3A%2F__NOEDITSECTION__%2F&title=Special%3ASearch&profile=advanced&fulltext=1&advancedSearch-current=%7B%7D&ns0=1&ns1=1&ns2=1&ns3=1&ns4=1&ns5=1&ns6=1&ns7=1&ns8=1&ns9=1&ns10=1&ns11=1&ns12=1&ns13=1&ns14=1&ns15=1

I assume this should be tracked in non-VE editors as well. In which case "firstTransaction" might be renamed "firstEdit" or "firstChange" as non VE surfaces don't necessarily use transactions. We should also write patches for those editors.

• This is technically a regression in VE, but this has always been the functionality in the mobile wikitext editor
• The __NOEDITSECTION__ marker which triggers this use very rarely, and usually when the section itself contains just a transclusion of another page, e.g.

== Section 1 ==
{{Included section}}
== Section 2 ==
{{Next included section}}

In these cases there aren't really meaningful section edits to be made, especially on mobile

Double tapping to enable the label editing makes sense but not single tapping.

How do the results vary by platform (iOS vs Android)? If they differ a lot we could investigate further.

Updated the prototype with more compact dropdown indicators (75%):
320px:

I don't think the action toolbar tools (on the right) need borders, see other page-level toolbars (top rows):

One option would be keeping the borders on MenuToolGroups:

This is what I meant by

Looks like this fix regressed during a recent refactor on target inheritance. The above patch should fix it again.

If we don't want to wait for Mozilla to fix this we could completely take over page up/down behaviour, but that would be annoying to have to re-implement something the browser should be doing.

This appears to be a regression in FF introduced in version 65, I've on the upstream task: https://bugzilla.mozilla.org/show_bug.cgi?id=1577058

Comparative analysis:

That's fine for the grey site-header, but there are a few overlays still to fix:

(The above patch is just the infrastructure needed for this in VE, not the citation-needed feature itself)

This is partially fixed now T140217 is resolved:

@Physikerwelt The documentation at https://en.wikipedia.org/wiki/Help:Displaying_a_formula#Chemistry states "Please note that there are still major issues with mhchem support in MediaWiki." and links to this task. Should that be updated now this task is resolved?

Even if there are no experimental features active right now, we need to decide whether the beaker icon should cover also this meaning or it should be restricted only to represent "chemical formulas".

Patch is merged, see T211789

In technical terms this would be anything that uses ve.ui.FragmentWindow

I set it to use the play icon from OOUI: https://gl.wikipedia.org/w/index.php?title=MediaWiki%3AVisualeditor-cite-tool-definition.json&type=revision&diff=5117742&oldid=3805660

+1, we should treat the link inspector differently. Should be at least all mobile inspectors and dialogs (except publish/save dialog).