Given Marijn's response on https://github.com/codemirror/CodeMirror/issues/4076 I don't think viewport optimisation is a realistic goal.

I think that's how most editors do it as well.

My main concerns are not with load times, as they should be comparable to VE (slightly faster), but without the viewport optimisation every keystroke can trigger a full document re-rerender which makes typing sluggish on long articles (e.g. Obama).

This is still a fairly big change for a large percentage of users, so will need some announcing if we proceed.

Yeah, that would be the next logical step, but I didn't mention it here to limit the scope.

As this is quite a long list, wouldn't it be better to switch to a text logo by default (when sitename !== 'Wikipedia'), and then add SVG versions incrementally?

Going by a site config file for site name, it's 86 logos over 127 wikis:

Just looking at https://meta.wikimedia.org/wiki/List_of_Wikipedias there are probably over 100 wikis not using the Latin script, we only have 7 logos. There are also many Latin logos that aren't simply Wikipedia that we don't have.

Why is the fallback for Wikipedia to use the English logo? Surely the local name as text would be better there too?

I believe so

Thanks. I commented out mobile.site to test, and the next exception thrown is on this line in skins.minerva.editor/init.js

Should mobile.site load for all skins and all MF pages, or just Minerva?

Why do I get Error: Unknown dependency: mobile.site when trying to use Minerva on desktop?

We have a bunch of reverse loops due to how the tree diff is calculated. It looks like reference changes aren't adding sidebar items in the correct order.

If the user is talking about wikicode, why is this tagged with VE?

Also make sure you have the latest version of lib/ve that goes with your VE extension (use git submodule update). It looks like they may be out of sync.

This is an upstream issue with Ace.

Fixed with https://commons.wikimedia.org/w/index.php?title=MediaWiki%3AGadget-HotCat.js&type=revision&diff=252283079&oldid=245282108

The bug appears to be in HotCat - it uses wgCurRevisionId, but it makes a local copy of mw config: conf = mw.config.get() so even though VE updates wgCurRevisionId, HotCat doesn't see it.

Just to be clear, this behaviour should not be happening and should go away once T170269 is fixed. I think if we are to discuss changes to the reference diff display it should be starting from the feature as it is correctly working correctly in VE, otherwise things are going to get very confusing :)

It will only affect wikis that have Citoid enabled, configured, but also have it demoted from the toolbar. I think most wikis that bother setting up Citoid leave it in the toolbar...

This should also be verified to be true when creating a Flow post; T164790: Add class mw-parser-output to VE's editing area may be relevant to that.

Adding mw-parser-output to the CE surface is a trivial one line fix. If this class exists solely to support TemplateStyles then it's fine, otherwise it should be noted somewhere that this class does not guarantee the contents is parser output as the name suggests, just that it wants to be rendered as if it were.

WFM in Firefox + Ubuntu and Firefox + OSX. The image goes grey, and I get a horizontal line showing me where the image will land.

We also have crossbrowsertesting accounts although they're a little slower.

In T30980#3369956, @Nikerabbit wrote:

Tangential: In the long term my wish is to migrate also these files to JSON format and make them available for translation in translatewiki.net.

We probably want to fix T170269 before making historical visual diffs more available.

I also imagine this is quite a lot of work.

In T166088#3426109, @Whatamidoing-WMF wrote:

1. I can reproduce if doing this is the very first thing that I try to do in the document.

The current version of the visual diff makes a lot of assumptions about the internal list being append-only, i.e. that document B's internalList is a superset of document A, however if parse the documents separately from the server that is not the case.

Probably related to T170269, marking as subtask

In T168089#3423963, @Pginer-WMF wrote:

I don't know which is the rationale for using a 12.8px font in VE's UI, but in terms of consistency with other Mediawiki font sizes, this seems to be the outlier. Given the above, I'd not expect that moving from 12.8px to 14px font size would result in a major breaking change since it would align the text to a size already in use.

Example: the old timeline selector in Google Analytics:

Given most wikis are using ref list templates, and even when not, most users wouldn't want to change the responsive attribute, this isn't high priority.

Filed as T170194.

For {{reflist}] there is probably a column attribute, but we don't yet support templates but that's a separate issue. For <references> list we recently introduced the responsive attribute, so maybe we could add a message if that is changed, but given we don't have a UI for changing it in VE yet - I'd say we're done here.

Can't reproduce in FF+Safari. Can you? Can someone else with a Mac (@Jdforrester-WMF ?)

I think the most important part is to provide a way for users to leave feedback - such a feature would make it obvious that there are known issues and that the feature is under active development.

Show formatting and link changes as side notes

Show formatting and link changes as side notes

The problem is the template is invisible in the main document - in this case it only outputs to <indicators>

I think this was fixed by https://gerrit.wikimedia.org/r/#/c/363644/ , seems to work on beta labs now.

The lines thing shouldn't be an issue as both inputs have the same CSS, but they could've got out of sync for another reason. Can you test again on beta labs after https://gerrit.wikimedia.org/r/#/c/363644/ is merged?

Can't reproduce. If still broken for you can you leave more detailed steps (wiki, browser, page etc.)?

In T57370#2976776, @Esanders wrote:

The main concern is what happens when we run out of storage.

Works for me, I see a bit of scroll flickering, but generally it does what I expect.

Filed as T169975

Yes - I suppose plain images already diverge from PHP in this way already (rendering a missing image instead of text).

@matmarex was changing z-indices *points finger*

Looks like it was @matmarex's fix, locally it's trying to compare "Cite web" to "Cite web\n".

Slightly different use case, but basically the same as T103636.

This only happens when you load the page via action=edit

Just tweaking the padding and image position makes it look better in Chrome & Firefox:
(set width to 100%+1px, and background position to right 1px)

Also how is one supposed to access the image resource from the DOM in this case? Also the alt text is missing...

...unless the exception is on the thousandth iteration of a loop, in which case you need to make the breakpoint conditional, and then you need to work out what the condition is.

Turns out Safari is still garbage. Just calling e.dataTransfer.setData(..) within a dragstart listener is enough to kill the text drop cursor. Needs more trial an error bashing. *sigh*

Is it unavoidable that these exceptions will all now be caught? A logged stack trace is considerably less useful than an uncaught exception that pauses the debugger.

Above patch reduces the dialog to a single tab:

In T169219#3390768, @Mvolz wrote:

It looks like neither the Cite tool nor citoid are actually enabled on hr wiki

Firstly I think we should be able to address the issue of pasting wikitext, as we do this already in visual mode. If you paste {{foo}} into visual mode you get an instance of the template, not some <nowiki>'d code. We should be able to re-use this code in source mode.

cf mw.TemplateData.ParamSelectWidget / mw.TemplateData.ParamWidget in TemplateData

Red link code is now in Parsoid so can be removed from VE

the callout is [now placed] centrally