Note that previously the preferences had been fixed, by using in the message a nbsp character (instead of a html entity), and it was working fine.

On the other hand, there is for sure a bug in the parser...
So even if this one resulting issue may be ignored, we have here an open gate for other issues.

Same for docblock of Window::open, which should be updated according to WindowManager::openWindow.

Return value in docblock of Window::close should be updated accordingly, copying the return value from docblock of WindowManager::closeWindow.

How about using a bot to move {{Infobox/Titre en italique}} bricks into the infoboxes, i.e. above the closing brick {{Modèle:Infobox/Fin}}? Then documenting this so that editors don't reintroduce back the issue.

Closing, per the explanation above :)

For the deduplicated styles, do we really need the <link> tags? Couldn't we completely remove the tag?

Just to clarify, I was precisely concerned about TemplateStyles in small templates invoked many times. More precisely:

• Server-side: all processing time for parsing, deduplicating, etc. (CPU/RAM usage)
• Client-side (which I'm more worried about): cost of markup bloat with the numerous added <link> tags (page size, also CPU/RAM usage)

This makes sense. I am just uncomfortable with removing the "nowiki" from the sub (and main) template {{Titre en italique}}. That one "nowiki" fixes many cases of empty <p>.

The output HTML are two properly distinct elements, a div followed by a p, and the p is clearly outside of the template transclusion. Thus I maintain the issue is at the visual editor level.

Though it's quite clear these <nowiki /> are tricky, I'd say the issue discussed here is rather in the visual editor, which should properly handle the case.

Wow, that's quite an impressive reply! Thank you. Pinned.

I'll just also mention toolbar customization, which has been modified several times, and has become a real pain for users.

Not strictly deprecation/removal, but off the very top of my head:

I just found it was cumbersome to manage different versions of scripts, depending on MediaWiki version, swimming on short intervals like 6 months.
Moving to forward-compatbility implying to break backward-compatibility even for recent and supported MediaWiki versions.

I think the legacy "mediawiki.api.*" modules should be removed later than in MediaWiki 1.33.

So, there is still Modern to fix.

Looks like it's solved, the patch having been merged.

Indeed, duplicate.
Apparently the whole thing was just broken, and the fix is to be deployed soon.

I have just updated a few links, there are probably more remaining.

Thank you for these explanations :)

Bump :) Is there someone able to do it? Is the task easy or not?

At least, the self links shouldn't be blue, using some a:not([href]) CSS as it has been done for Minerva.

By the way, I checked on Timeless, and the self links are blue, as regular links. That is wrong for sure.

I mean that the bold removal and the underline on hover are by design ;) But I may be mistaken.

I think it is by design.

@MusikAnimal I figured it out exactly at the same time ;)

@MusikAnimal I've noticed your revert. Actually, there might be something missing in the extension implementation in MediaWiki. Compare the two following sets of Lua debug outputs:

Yes, please uncomment it, so you can at the very same moment check if it is running fine.

@MusikAnimal I have implemented this extension in the module.

I made the patch, but the Gerrit Patch Uploader currently fails to submit it (and there is no error message).

One week already, I got no more reports about this. If there is no one willing to nonetheless fix it, I think this ticket can just be closed.

Just to clarify, the patch that has just been merged is not for the issue of this ticket, but for a related issue.

This needs more than the single rule above. I had to add the following to fr.wiki: https://fr.wikipedia.org/w/index.php?title=MediaWiki:Mobile.css&diff=prev&oldid=143649876

Thank you for this addition. But as I stated a bit above, these missing styles are simply an overlook from T160480. There is just no reason not to add them.

If template returns #ccc and is used as style="color:{{template}}", {{#balance:inline}} would break the template, as it wraps the output with <span>...</span>.

For convenience, refs https://phabricator.wikimedia.org/T31157 (relocation of bugzilla 29157).

Phabricator's Contributing Code:

Even in this "Browse Projects" modal, there is no link to go to the tag page!

Fixed by this edit, yet I have removed this code just after as it's no longer needed.

Has been fixed in this edit (search setTimeout).

Should be working again, see notably this edit.

Any news on this?

For the demo above, note the CSS has been fixed locally.

How about just escaping all ! characters? It would escape more than necessary, but the code would be much simpler (in particular the PHP one).

So, you don't think there is the same issue with the 2nd do/while of the for loop? I haven't checked it thoroughly, but it just looks very similar, with these n+2 steps. That's why I added the "overflow fix" after the for loop in my demonstration patch, to cover the two do/while's.

Thank you for your work on this.

I was about to completely agree with Jdlrobson, but actually such links are HTML5's "placeholder links" and seem to be the recommended way…

Code references:

• non-live preview, PHP: https://github.com/wikimedia/mediawiki/blob/master/includes/diff/DifferenceEngine.php
• live preview, JavaScript: https://github.com/wikimedia/mediawiki/blob/master/resources/src/mediawiki.action/mediawiki.action.edit.preview.js

There are two different points:

• Texts "Latest revision" and "Your text" are always missing. They should be added, for consistency with the "non-live preview" mode.
• When there is no difference (i.e. empty ajax diff content) the text "(No difference)" should be added.

Also, documentation needs to be updated: https://www.mediawiki.org/wiki/API:Revisions

The JavaScript of "live preview"[1] gets deprecation warnings and has to be updated.

Thanks :) @grey-bright variable is #eee. It's a bit too light in my opinion. The next one, @grey, is #ccc, which in turn is a bit too dark. Something between the two would have been optimal.

I just noticed this border's color is varying across the skins…

I would suggest "normal" priority. This issue gives template editors many headaches, and often results in template codes much more complex than necessary. Thus, let's not forget this issue even further than now.

Yes, please do something about this issue, even (for the time being) just adding a magic word to configure behaviour of the template, would be helpful.

Indeed, the error happens only on invalid input. Still, there is a clear possibility of overflow here, fixing it is good to do. You should consider as luck it resulted in just a php notice :)

Yes, for ensuring consistency (there can be different parsers, across Special:ExpandTemplates, preview mode, etc.)

Possible fix, inserting near line 484:

Test case: JavaScriptMinifier::minify('*/');

Thanks, I had a look at the javascript code, and I'm not really a fan of this solution.

Just to mention the mobile version has this issue on all browsers actually, not only Firefox 57. Tried Chrome and Pale Moon. So maybe the mobile version has a related, but different, issue that would need to be investigated.

Looks like this feature is currently missing. (if I recall correctly, maybe it has been removed at some time)

TBH, the fault is in Firefox 57, and the same issue happens on a shitload of websites. So I don't think there is any fix or workaround to consider for MediaWiki, the issue has to be fixed in Firefox.

Here it is: T160480 (gerrit). Also, along this patch the mobile styles were probably forgotten, their omission wasn't on purpose.

Just noticed this: apparently, in the past, the generated elements were <strong class="selflink">, then at some point it has been changed to <a class="selflink">.