An example consumer would be my script https://de.wikipedia.org/wiki/Benutzer:Schnark/js/diff.js, which adds a different diff view (like WikEd's diff). Currently it uses the hook ve.saveDialog.stateChanged, which works, but is a bit ugly.

Let's decline this in favor of OOUI widgets. These are easily reusable already.

In T88305#2019746, @IKhitron wrote:

Does not matter, it works now. 4 hours earlier it was not, I checked even Console css styles. Maybe it started later from some reason.

No more reports, so let's assume it is fixed.

Seems to be fixed.

Note that this makes some tables much wider than they should be, e.g. https://de.wikipedia.org/wiki/Fu%C3%9Fball-Bundesliga_2015/16#Tabellenverlauf (below are some more tables with disabled arrows where there shouldn't be any).

The change that updated the notification timestamp was on Wikidata: https://www.wikidata.org/w/index.php?title=Q5896997&action=history As this could have changed the page on he.wikipedia marking the page as unread is IMHO the correct behavior.

T125297 contains some ideas about how to implement a fix.

In T125297#1984043, @matmarex wrote:

(Duplicate of T67468?)

There is also a proposal to remove the numbers entirely: T44059: Kill section auto-numbering

In T113928#1836116, @Ricordisamoa wrote:

JavaScript support for IE8 will be dropped in January: T118303

In T122737#1915416, @TheDJ wrote:

Hmm, for me it generates:

<track kind="subtitles" data-mwtitle="TimedText:Edward_Snowden_speaks_about_NSA_programmes_at_Sam_Adams_award_presentation_in_Moscow.webm.en.srt" data-mwprovider="local" type="text/x-srt" src="//commons.wikimedia.org/w/index.php?title=TimedText:Edward_Snowden_speaks_about_NSA_programmes_at_Sam_Adams_award_presentation_in_Moscow.webm.en.srt&amp;action=raw&amp;ctype=text%2Fx-srt" srclang="en" data-dir="ltr" label="English (en) subtitles"></track>Sorry, your

As the source code has <span style="display:none">1:43.86</span>'''1:42.00''', it is not surprising that the sort order is not as expected. You have to either fix the invisible sortkey or the shown value, whichever is wrong.

Disabling all beta preferences does not fix the issue, so we can't blame "Compact language links" or "Content Translation".

I can reproduce this in Vector (and Firefox, though the browser shouldn't matter as the language links are already missing in the HTML, even before JS execution):

This only happens when "Live preview" is enabled in preferences, or when using VisualEditor. MediaWiki:Editing should not use parser functions.

In T53583#1844576, @Krinkle wrote:

In T53583#1606076, @Schnark wrote:

Not mentioned yet, but IMHO makes sense, too: #firstHeading

Why?

In T76997#1836034, @Nemo_bis wrote:

If I understand correctly, all the examples are about edits to different sections, which were merged incorrectly.

This looks really ugly for lists containig only one item with a space (at least in FF 41):

I can no longer reproduce the issue on de.wikipedia, neither with new uploads, nor with re-uploads. So let's just close it as resolved.

In T110492#1771068, @Physikerwelt wrote:

1. Add the styles to math extension style

It should be checked whether the styles are still in use before moving them, at least the texhtml class seems to refer to the HTML display mode that was killed long time ago. If this class really is no longer used, then it should just be removed.

This is caused by your personal CSS on https://www.mediawiki.org/wiki/User:Saper/vector.css.

Is this a duplicate of T110501: redirectToFragment script (redirects to section headers) behaving unreliably? BTW, I cannot reproduce the issue with the above example in current Firefox.

CCing aaron, since he seems to have worked on caching issues recently a lot. When you really fixed this, you might want to claim this task and get praised for it.

I can't reproduce this any longer, either, so somebody fixed this bug without knowing about it.

Could this be caused by the StashEdit feature (https://gerrit.wikimedia.org/r/#/c/174628/ ff)?

Disallowing identical image names on local and shared repositories is not possible: You can check and disallow uploads to the local repository with names that exist on the shared one (that's actually possible right now, since there is a user right for it, which currently is granted to sysops), but you cannot check whether a new upload to Commons has the same name as an existing file on any local repository (including uncountably many wikis using InstantCommons).

Is this a duplicate of T59840?

Well, I'm not going to provide a patch for this, but it should be really easy:

Reopening per "We can reconsider the proposal if diffs are provided which caused such unexpected merges.".

My browser tells me that the error is in the zoomviewer gadget, and really: https://commons.wikimedia.org/wiki/MediaWiki:Gadget-ZoomViewer.js there it is (line 11). Please ask a sysop on Commons to escape the double quotes in the page name when building the attribute selector.

Yet another example, only a few days old: first edit, second edit As the first edit changed the title of the section, but the second still has the old title in the summary, you can easily see that this was an automatically resolved edit conflict. In the result this looks like Ireas read Doc Taxon's comment before he left his comment, though in reality he wasn't able to do so, since he commented first.

Well, since it is a problem with IE9 and CSS, this might be some issue in the neighborhood of T108727: IE9 executing our MediaWiki:Print.css stylesheet in screen media and the fix for that bug.

In T76997#1692932, @Nemo_bis wrote:

Are all the examples about section-editing different sections?

Another example: Serten commented on GEEZERS comment, but after the automatic merge of SchirmPower's comment it looked like he commented on SchirmPower instead. The automatic merge was probably possible, because Serten added a blank line before his comment, while SchirmPower didn't. This behaviour was reported here, there are some more examples in that report.

In T76997#1692402, @Nemo_bis wrote:

Agreed. The proposed use case seems quite fat fetched too: automatic merge definitely fails if a line before the one you edited is changed. We can reconsider the proposal if diffs are provided which caused such unexpected merges.

IMHO at least my first example use case is valid: If a vandal vandalizes one section while you expand another, you're likely to miss his change when your edit is automatically merged. And other users looking at the recent changes will probably not look at the change when a trusted user edited the page just after it, so such vandalism can easily be unnoticed. A note informing you that an automatic merge occurred could prevent that.

In T114081#1684175, @PerfektesChaos wrote:

1. mw.user.generateRandomSessionId() is referenced in line 11.
   1. This might be always the case at this point of time.
   2. As the error message above shows, one cannot rely on such assumptions.
   3. It would be more clean to declare all dependencies with .using() first.

The animated GIF was replaced by a static PNG fallback when T37335: Vector: Add SVG version of the watch star icon was fixed.

• I checked that no script I'm using even references mediawiki.ui.anchor.
• This error should occur only when you call mw.loader.using( 'mediawiki.ui.anchor' ) before the module is loaded. Since Echo loads this by default, and the module is top-loaded, it seems very unlikely that any script actually could trigger this.
• There was one unguarded call to mw.user.isAnon in MediaWiki:Common.js, which might have something to do with this, but when really this is the cause it still is a MW bug that it is reported as an error in the callback for mediawiki.ui.anchor.

mediawiki.ui.button currently (and only temporarily) uses a simple string search on server side over the whole HTML for the class it provides: SkinTemplate.php, line 65, which actually works good enough in most cases, though it feels a little bit like a hack for me.

Though admittedly this is really minor issue, it has a huge impact on whether VisualEditor is accepted by power users or not. Because of this issue it is actually frowned upon to create biographies with VE in de.wikipedia, users have been told already to use the normal source code editor instead.

In T108588#1639613, @Jdforrester-WMF wrote:

In T108588#1611584, @Ciencia_Al_Poder wrote:

The cause is Visual Editor changing the text of the source edit tab with JavaScript after page load

But that doesn't happen (unless there's a cache invalidity)…

For a short while I thought adding the link to the existing mw-editsection-span would fix the issue. This actually would work, but not on pages with __NOEDITSECTION__.

Though not in the dropdown, the statistics actually do work: http://stats.grok.se/www.w/latest30/MediaWiki

In T47731#1611566, @Platonides wrote:

Too easy to abuse: <noscript>Buy our great viagra [http://pharmacyscam.com here]</noscript>

Not mentioned yet, but IMHO makes sense, too: #firstHeading

This is probably T108727: IE9 executing our MediaWiki:Print.css stylesheet in screen media, but Phabricator doesn't let me merge it in for some reason.

In T42618#1604298, @Timeshifter wrote:

How does this fail in Internet Explorer 7? Is it just a blank column? If so, that is not important in my opinion.