Thanks @matmarex, I think it's enough. At least, in the unlikely case that it would happen again, we know where to look.

No problem @Aklapper , for completeness, also IE works fine now.
As said above, it would have been good to know what fixed the problem, to avoid the same issue in the future, or at least to fix it in less time.

All the three browsers I've previously mentioned worked correctly, so it's not a matter of their improvement, but a WMF patch has been delivered.
I was curious to know what solved the problem before closing the ticket.

I've test it on it:voy, en:voy, it:w and en:w and now It seems that the issue has been solved.

@matmarex I don't know if it can help with the debug, but I've noticed this different behavior in the following two situations:

This problem affect ALL wikis, I'll be glad to support on debugging, I just @matmarex feedback on how to test "a version + a set of patch" to find the one that caused the problem.

@matmarex AFAYK there is an easy way (e.g. web interface) to test a specific version with/without certain patches? I'll be glad to spend time on trying to find which is the patch that causes this problem to save your debug time, because editing an article in this way is very annoying. Once found, clearly I need someone else support to fix it :-)

sob...
I've looked into https://www.mediawiki.org/wiki/MediaWiki_1.36/wmf.1 more for curiosity than for expertise.
May CodeEditor or WikiEditor repository affect CharInsert? My guess is because I experience the problem during edit phase.

@matmarex thanks for your high level screeening. Unfortunately I'm not able to support you on debugging, so I just limit myself to share one consideration.

According to https://www.mediawiki.org/wiki/Editing_team you (@Whatamidoing-WMF , @JTannerWMF, @MFlorence, @Esanders, @iamjessklein, @Ryasmeen, @dchan, @DLynch, @matmarex, @Mvolz, @MNeisler, @ppelberg ) are the team in charge of CharInsert tool.
I'm disturbing you since I've seen in the https://www.mediawiki.org/wiki/Developers/Maintainers page that there is no maintainers associated to CharInsert.

@Aklapper it's a feature request.

On Italian Wikivoyage it still doesn't work: https://it.m.wikivoyage.org/w/index.php?title=Speciale:UltimeModifiche

@Aklapper could you help me to find out who works recently on Charinsert? Maybe they can check this out easier than other users.

@Aklapper this task still needs triage, could you support?

The issue occurs also with Safari on smartphone (I'm not able to determine its version)

You are right, but my point is another. If all the three major browsers experience suddenly the same issue, maybe the version is not relevant, and the bug has been introduced in a recent code update.
Furthermore, since it affects ALL the wikis in ALL the languages, I hope that someone would start working on it soon before any browser version would change ;-)
By the way:

• Chrome 85.0.4183.102
• Firefox 80.0.1
• IE 11.508.19041.0

Today, all is fine. I would consider this issue closed and solved.

~15min ago connection has been restored. I'll test it again tomorrow.

The lastest

In T262869#6460813, @CDanis wrote:

Today we had reports of an issue from @Andyrom75 that was happening all the time on their Wind (AS1267) mobile connection, and was happening under some circumstances on their Vodafone (AS30722) connection, but we did not get a full traceroute or an IP address, so it's very hard to say what was going on or if the issue was related.

Inside the mentioned page, I've added a case that show where the parser has inserted the second row outside the LI tag creating a layout issue and the graphical fix will generate a lint error.

@Jdlrobson, @Tacsipacsi referring to one of the previous discussed point about title area space, I would highlight how in en:wp has been managed:
https://en.m.wikipedia.org/wiki/Taumatawhakatangi­hangakoauauotamatea­turipukakapikimaunga­horonukupokaiwhen­uakitanatahu
(it dinamically adjust the horizontal leght of the title according to the actual size of the screen)

With the closure of T258256 actually this bug is solved, but in the Chrome console appear this warning each time I close the map with ESC key instead of closing it clicking with the mouse on the X button:

@Tacsipacsi inside wikivoyage there is a set of script develped few years ago by a user not anymore active. Recently I got access to this tool because some of them do not work properly anymore. If you tell me what to do I'll be glad to support.

@TheDJ, the problem in T258090 occurs even if I simply execute:

@TheDJ just a consideration. MediaWiki:Gadget-ImageMap.js is activated only on NS:File, here below the code:

On OOUI I admit I lost you :-) But I hope you'll be able to find anything that could be fixed.

@TheDJ I've applied all the suggested changes although some of them are present also in en:voy where everything works correctly.
FYI in MediaWiki:Kartographer.js there is still this link: https://tiles.wmflabs.org/hillshading/{z}/{x}/{y}.png

@TheDJ I've applied your suggested change but the issue persist.

Let me add a couple of wierd things:

• Yesterday I've noticed that the breadcrumb failed to works only on it:voy (that I've locally patched waiting for bug resolution) and de:voy while en:voy and other language versions works correctly
• Still today the font shown in NS:Tematica (e.g. https://it.wikivoyage.org/wiki/Tematica:Fuso_orario ) is smaller than the the font shown in NS:0 (e.g. https://it.wikivoyage.org/wiki/Olmedo_(Italia) )

Is it completed?

@Jdforrester-WMF could you support as already done with T253096?

IMHO it could worth to clean all the other NSs, not only the main one.

In T254820#6203868, @RhinosF1 wrote:

Is that discussion complete?

Only 3 users have commented on a medium size wiki with 500+ active users

In T75299#6166630, @Jdlrobson wrote:

a trivial first step could be placing indicators at the bottom of an article so at least they are present on the page, however the lack of prominence is likely to be a problem.

Indicators are important so they are not supposed to stay at the bottom but inside "div.pre-content", if you think that there are cases with many indicators, maybe the could stay in their own new line.

@Jdlrobson Although I'm still working on the itwikivoyage homepage, could you set $wgMFSpecialCaseMainPage = false to disable the different mobile view?

In T75299#3461485, @Andyrom75 wrote:

For sure I'm simplify too much the issue, but maybe could be enough to add the block <div class="mw-indicators mw-body-content">...</div> (or maybe the renamed mw-mf classes) to allow the whole indicator mechanism.

Can this be tried one single minor wiki to test it?

@Jdlrobson I can't belive that showing banner in diff pages (as happened before) is technically not feasible. Could you refresh the status of this task and eventually give us some feedback?

@TheDJ it's clear that the extension works on the original wiki-code (let's call it "unsorted") but an idea that would solve this issue, is to implement the same sorting script inside the extension and when it recognize the presence of certain templates (e.g. Template:Citylist), it applies this sorting function before rendering the final HTML code.
I think it will work in this way. Isn't it?

@Jdforrester-WMF confirmed.
No one use that feature in it:voy. It was developed and used long time ago in de:voy.

In T253096#6147684, @Aklapper wrote:

@Andyrom75: Please always follow https://meta.wikimedia.org/wiki/Requesting_wiki_configuration_changes when requesting such kinds of changes. Thanks.

@TheDJ as a mere example you can look at https://it.wikivoyage.org/wiki/Lago_di_Garda#Centri_urbani
In that article there is 3 occurrence of Template:Destinationlist. First 2 are already alphabetically ordered inside the wikicode, so the markers near the text and the map are fine.
The third occurrence is not alphabetically ordered on the wikicode so I've hidden the marker on the the text because the ones on the map (look top right) wouldn't match.

! In T236188#5611628, @sbassett wrote:
Seeing the alert within a developer console is normal, expected behavior for the time being. Again, it should just be a notice-level warning, not an error which blocks a resource from loading. I'm going to resolve this for now unless it can be demonstrated that the CSP in question is actually blocking a resource from being loaded.

In T236188#5609523, @Aklapper wrote:

@Andyrom75: It is still unclear to me how to reproduce a problem, and what the exact problem is here. I go to https://it.wikivoyage.org/wiki/Template:MappaDinamica and I don't see such output in the Developer Tools in Firefox. What are exact steps to reproduce, the expected outcome, and the actual outcome? Thanks.

@Aklapper sorry for late answer.
I've used Chrome Version 77.0.3865.90 (Build) (64 bit).
I get the same result with Firefox Quantum 69.0.2 (64 bit)

Thanks for your findinds, now my question is if it really make sense.
If there is no problem is term of security or performance I suppose that this block can be reverted.

Any update on this regression?

IMHO a warning message is not a solution, but a temporary patch. A solution should be to use icons that will allow to show POI with counter greater than 99, then any editor will decide if it's a good idea (or even necessary) to use such high number of POI.

Unfortunately the problem still happens but rarely :-(
It seems that no error has been generated.

@Jdlrobson, by now it seems that the patch works. IE11 doesn't send any error but several warnings most likely not related to this issue.
Since also other language versions should be affected by this problem, I think that the bug should be fixed soon.
Thanks by now.

@Jdlrobson, I've tried to implement the patch but it seems that it doesn't work. I'll keep it few days more in case you'll need it for a test.

Any update?
Today an Italian article has been shown on TV (http://www.teleboario.it/tbnews/turismo-per-iseo-un-altro-riconoscimento-dal-web/) without the proper banner and honestly it's a bit embarassing for the whole project.

Focus has been not restored. It's so difficult the regression of this bug?

@MaxSem can your patch be integrated into the LUA script mentioned above?
In the affirmative case it could be an efficient patch, otherwise the same LUA order function should be inserted inside the extension and activated any time the above templates are used inside the wiki-code.

Sorry, @Aklapper you are right, I was in rush.
It happens anytime with traditional wikitext editor using either Chrome, IE and Firefox (last versions).

For sure I'm simplify too much the issue, but maybe could be enough to add the block <div class="mw-indicators mw-body-content">...</div> (or maybe the renamed mw-mf classes) to allow the whole indicator mechanism.

I don't know if it has been already highlighted but I've just noticed that also the interwikilink goes to the desktop version.

Thanks @Aklapper, T53189 is the bug I was mentioning, while this bug is focusing to this new behaviour.

@Aklapper, I'm not sure if it's the same problem but it looks like.

Thanks for your excellent clarification!

@Krinkle, could you explain me better this point: @import rules for proper ResourceLoader modules (e.g. not legacy modules 'site' or 'user') is only supported if they are loaded dynamically through mw.loader.?

@matmarex do you think that in the (very?) long term can MediaWiki:Common.css/js be managed through resourceLoader having the benefit of compression and speed without giving the possibility to any user to disable it?
Or maybe there is a technical constraint that preclude this possibility?