I can confirm this bug for cs-wiki. The thanks notification goes to the last user who edited the page. Using Firefox 52.6.0 ESR.

@ABorbaWMF the problem with the header of this infobox has nothing to do with this task. It's T168861. The infobox header can be inserted two ways: as "title" (caption over the top of the table) or as "above" (text within the uppermost cell of the table). In the mobile view, the first option results in a line of unformatted text as we can see here. The second option works as expected - the result is a formatted (centered, enlarged, custom colored etc.) caption.

Please see Talk:Community Tech/Commons deletion notification bot#Possible obstacles.

Any progress? Is this still worked on?

Proposed to Community-Wishlist-Survey-2017.

Textbook example of horrible collision between tooltips and Page Previews which I just met:

I see this was already deployed to ru-wiki, what about other languages? Is there a schedule?

If T178013 was closed with the reference to this task (perhaps merging would be a better approach), then some summarizing is in order.

In T177175#3710506, @Niharika wrote:

I am doubtful that this is being caused by Wikitext Syntax Highlighting feature. Are you sure this doesn't happen without it being enabled?
Can you check on a different browser?

Yeah. This is somewhat annoying. When there is no change, then the editor should close without asking, as is the case without using CodeMIrror. Confirming this bug for Firefox+OWE.

In T178013#3688196, @Niharika wrote:

This just got more sinister -

Using Firefox on English Wikipedia, I am able to type in the Edit summary box with CodeMirror enabled, but when I click on one of the character insert buttons (provided by the CharInsert gadget, IIRC), as I do with most of my edit summaries to get the "→" character (as in: "somethng" → "something"), it always inserts into the article edit box even when when focus is in the Edit summary box

Also seems somewhat related to T164905: function mw.toolbar.insertTags does not work with CodeMirror in Chrome and IE.

@Jdlrobson: good catch. I edited the template. The coordinates display is now managed inside the infobox. Try to get new Page Summaries for the pages Labe or Vltava now.

@Jdlrobson: The template Šablona:Souřadnice uses '#coordinates' (see second row of the code). Could it be that the real problem (for the page in question) is the repeated use of the template in the infobox?

#808 is definitely bugged (in the new version).

In T173639#3681552, @bearND wrote:

@Vachovec1
#9, #15, #23, #62, #149 – new versions unnecesarilly stripped. Why?

That's usually because the new implementation only considers text from the first paragraph.

In T173639#3680019, @Jdlrobson wrote:

I've uploaded a side by side comparison here for old versus new summary endpoint to give an idea of what you'd be trading in doing this:
http://jdlrobson.com/summaries/cs.html

I think the idea of cs-wiki as a "test wiki" for the new API is feasible. We can give you feedback (e. g. we can look for errors and report them here), to help with the development.

@Jdlrobson: when would be the new API (with this error presumably fixed) in production? This bug is very annoying. On cs-wiki it affects a considerable part of biographical articles (possibly thousands of pages).

Looks like the module implementation works (many thanks to @Johnuniq). So this bug can probably be closed (or at least the priority should be lowered).

Confirming that Page previews are working for me on wikis where jQuery3 is enabled (tested on nl.wiki, pl.wiki). They are not working on wikis without jQuery3 (tested on it.wiki, es.wiki, fr.wiki).

Tested in Firefox and Chrome. Both the same - no page previews at all. Definitely a regression from today's MediaWiki rollout, because it's still working in two Firefox panels, which I have still opened (without touching the content) since (European) afternoon. Not one functional Page Preview in newly opened/actualized panels.

In T171392#3554170, @zhuyifei1999 wrote:

Nowiki-ization was a bad hack to reduce the memory consumption. It worked
for a few pages, such as the two in the initial report, but some still have
a memory consumption higher than the threshold, unfortunately.

@zhuyifei1999 : I see that this bug blocks solving fallout from T171392 for Commons. The problematic template is "nowikized", but the pages are still broken (from this bug, not from T171392) until cache invalidation is forced? Perhaps Mediawiki-Cache project should be added and contacted. Evidently, the cache invalidation for (rather) all pages with the problematic template is needed, but "normal" ways won't work.

In T170039#3553607, @Mbch331 wrote:

When I try to purge the page in the previous link through the API (with forcelinkupdate, which has the same effect as a null edit) also results in a Internal Server Error. Tried another year and that gives the same problem. Selected a random cat on my watchlist (https://commons.wikimedia.org/wiki/Category:Psychologists_from_the_Netherlands) and I can purge that one through the API. But I don't know if that error has anything to do with this ticket or that it's a coincidence.

24 hours after purging affected pages on cs-wiki, everything looks good:

@Johan : I would reccomend something like this:

@Jdlrobson: I am a little bit confused. Task T168848 is about Mobile(Apps) Content Service. I thought that new API would serve all requests, not only requests from mobile devices?

@Jdlrobson: this looks almost like dupe to T169370. Merge?

@Mooeypoo : this task is not about MediaWiki:Recentchangestext as a whole, but about interwiki links provided by it. Note that no interwiki links are present in your examples. They should be provided by MediaWiki:Recentchangestext page, they are part of the code (see https://cs.wikipedia.org/w/index.php?title=MediaWiki:Recentchangestext&action=edit). But nothing is displayed. This worked well a few weeks ago.

In T170039#3545358, @Anomie wrote:

@Vachovec1: I already answered you about that in T170039#3467750. If a page is reparsed without updating link tables, a transient warning might be cleared while leaving the page in the error category until something does trigger a link table update.

Side note: the Category:Pages with script errors (cs-wiki version) contained a lot of false positives. We found similar false positives in Category:Pages where expansion depth is exceeded and Category:Pages with malformed coordinate tags (cs-wiki versions). Is this another bug, which would be hopefully solved with deployment of the new HHVM-Luasandbox too?

We did purging (for both categorized and uncategorized errors) on cs-wikipedia project. Crossing fingers now.

For the clarity, this bug is not about usual popup window with watchlisting information (which is shown in the previous comment from @Deskana above). It's about dialog which is opened in the new page, and you are asked to confirm your (un)watchlisting choice. The trigger for the "unusual" dialog could be expired token (as hypothesised by Schnark). The problem is no warning if you are in middle of editing when you trigger the dialog.

@Schnark: an expired token (associated with the watchlist) is definitely a possibility as the trigger (see below). But anyway, NO warning is shown, the dialog is launched immediately (no meddling with the preferences).

To disallow page watchlisting in the middle of a page editing is also a possibility. One gets used to it. Perhaps the icon should be hidden in this case so the editors are not confused.

@aude: any progress?

I am still able to find affected pages:

In T170039#3476825, @Vachovec1 wrote:

In T170039#3475644, @IKhitron wrote:

You can try to purge all the page with the old message, and check tomorrow if there is a new one, or more, @Vachovec1,

OK, I purged/null edited everything. No positive search results now. We will see in 24 hours.

In T170039#3475644, @IKhitron wrote:

You can try to purge all the page with the old message, and check tomorrow if there is a new one, or more, @Vachovec1,

@daniel: I am not sure, but I am inclining to the version where both errors occurs independently. The category is completely unreliable (or the pages are reported with a long delay?). On cs-wiki someone probably just made a purge run through it (no affected pages are shown, not mentioning false positives), but when searching directly for the error massages, I can easily found about 100 pages with the "line 34" error message (almost no false positives) - that is much more then two days ago. About 20 pages with the "line 37" error message (again, almost no false positives). Independently of the type of the error message, the effect on the affected page is the same.

I see that from about Jun 13, there are ongoing problems with WMF ParserCache - T167784, probably as consequence of https://gerrit.wikimedia.org/r/#/c/354504/. Could it be related? A real root cause for bugs like this and T168040? Both bugs seem to be a consequence of some parser cache failure. And the dates sum up (first reports for T168040 are before Jun 20, first reports here are from Jun 23 - at en-wiki).

In T170039#3469186, @JohnBlackburne wrote:

One of the new error messages at the bottom of en:Higgs Boson as I type:

Lua error in mw.wikibase.entity.lua at line 37: data.schemaVersion must be a number, got nil instead.

In T170039#3467750, @Anomie wrote:

@Vachovec1: Desynchronization between the displayed version and the category membership is easily explained: not every parse of the page updates the links tables. If you have certain user preferences set, you see the page parsed according to your preferences but that result does not necessarily correspond to the state of the links tables. Further, the web UI action=purge doesn't update the links tables either (which is why null editing is a "stronger" version of purging).

In T171392#3463675, @zhuyifei1999 wrote:

In T171392#3463671, @Vachovec1 wrote:

even without langswitch sufix

What do you mean by "langswitch sufix"?

In T171392#3463648, @zhuyifei1999 wrote:

@Vachovec1 it's transcluded on 117893 pages, many have the potential to break (although the exact conditions are still hard to tell). If someone really needs to access the page, they are free to ?uselang=en. I don't see much benefit in removing the templates from the affected pages.

@zhuyifei1999: I removed the {{Countries of Europe}} template from both above mentioned affected pages and they are accessible again. The {{Countries of Europe}} template definitely needs fixing/reworking, though.

I don't think this is primarily a Lua bug. I think Larske in T170039#3451753 has something with his "timing error" hypothesis. It really looks like this:

In T171392#3463575, @zhuyifei1999 wrote:

^ was with X-Wikimedia-Debug. without it I get: Lua error in mw.wikibase.entity.lua at line 34: The entity data must be a table obtained via mw.wikibase.getEntityObject for the link to Belgium.

@Jdlrobson: Is T143009 another dupe? The visual gif provided there exactly matches the behaviour I tried to describe in T171211.

Confirming that it works for me now. Thank you.

In T170893#3448267, @Jdlrobson wrote:

@Vachovec1 does this list seem sensible to you?

An observation: today I got manually through the Category: Pages with script errors equivalent at cs-wikipedia (https://cs.wikipedia.org/wiki/Kategorie:%C3%9Adr%C5%BEba:Str%C3%A1nky_s_chybami_skript%C5%AF) – about 60 pages. A lot of false positives (all purged), three real cases of this error (one purged /important page/, two remaining : https://cs.wikipedia.org/wiki/Litold_Znojemsk%C3%BD and https://cs.wikipedia.org/wiki/PlayStation_3, if someone is able and willing to catch and post the cache version info here). But I found that there are pages with this error which are NOT displayed inside the category. Examples: https://cs.wikipedia.org/wiki/Svat%C3%A1_Lucie_(osoba), https://cs.wikipedia.org/wiki/B%C3%ADlsko_u_Ho%C5%99ic. Some of these can be found via search (https://cs.wikipedia.org/w/index.php?search=mw.wikibase.entity.lua&title=Speci%C3%A1ln%C3%AD:Hled%C3%A1n%C3%AD&go=J%C3%ADt+na&searchToken=4gqaprg0qyc783z3awbaaa7yn), but there are false positives too.

Yeah. It's not only de-wikivoyage problem. A false positives are shown (T170039 can be connected only to part of them), some real errors are NOT displayed: for example pages https://cs.wikipedia.org/wiki/Svat%C3%A1_Lucie_(osoba) and https://cs.wikipedia.org/wiki/Robert_Louis_Stevenson show error (T170039) but no entry in the category (https://cs.wikipedia.org/wiki/Kategorie:%C3%9Adr%C5%BEba:Str%C3%A1nky_s_chybami_skript%C5%AF) is shown.

The error can be persistent (if the affected page is not purged). I am watching this page: https://cs.wikipedia.org/wiki/Ole%C5%A1nice_(Polsko) for several days and the error is still present (not purging as it can be useful for debugging).

In T170039#3441616, @Liuxinyu970226 wrote:

In T170039#3441308, @Vachovec1 wrote:

Bumping priority. This NEEDS attention.

Are you sure, absolutely sure, that without resolving this task many pages and many scripts will not render/work properly? If not, how do you think this is suitable for UBN?

In T170687#3441602, @Jcb wrote:

I think the best thing for now is to revert the change that leaded to all these problems, so that we could finally use [[Special:ShortPages]] again. It will show a lot of test-pages now the report has been out of service for several weeks. And then maybe reapply the change as soon as it is in a state in which it does not break several reports.

Adding MediaWiki-Parser, because this looks like some bad caching (like T168040).

In T170169#3441229, @pmiazga wrote:

@Tbayer The underlying goal is to not ship PagePreviews to pages where this feature isn't useful (less bytes shipped, less processing, faster rendering) - as Special:Login or Special:Preferences.

Bumping priority. This NEEDS attention.

An example of a completely broken page:

I presume this will go live next week?

Because this error can completely break pages (although the problem can be repaired through a purge), I suggest UBN! priority.

In T170039#3431944, @ValterVB wrote:

Also in it wikipedia we have the problem. You can check this with search: https://it.wikipedia.org/w/index.php?search=The+entity+data+must+be+a+table+obtained+via+mw.wikibase.getEntityObject.&title=Speciale:Ricerca&go=Vai&searchToken=awzuqflixgt8xl9yuq0lzqmtg

Two questions:

Still happening. Today, checking some of our featured articles, I found this pages missing TOC:

In T168861#3387788, @Nirzar wrote:

@Dvorapa

For the question whether infobox title (in heading or caption) should be hidden on mobile I suggest to open a new task.

Do you think that's a possibility? Would love to know your thoughts on that.

In T168861#3387349, @Jdlrobson wrote:

Yes, consistency is important, but in mobile the caption is displayed very close to the title of the page when you compare to desktop.

In T168861#3384733, @Nirzar wrote:

Side note: Any reason why we repeat the title in the infobox?

No idea why. sometime it links to another article...

@Vachovec1

properly formatted (bigger font, centering)

I would want to know what you mean by "proper"?

In T168905#3384369, @Jdlrobson wrote:

@Vachovec1 can you confirm whether you have the same problem on https://cs.m.wikipedia.org/wiki/Speci%C3%A1ln%C3%AD:Mobiln%C3%AD_rozd%C3%ADl/14452842 ?

If we want 100% row width, why are we trying to force 100% width into cells, not rows?

Other examples (no TOC at this time):

The same problem occurs at cs-wiki just now. First report is from Jun 22. The TOC is/was missing in many arcticles. The relevant discussion is here. Some articles were already purged by bot, but the articles with this problem could be still easily found, see for example https://cs.wikipedia.org/wiki/Harappsk%C3%A1_kultura.

The rule can be probably removed safely if another way how to ensure 100% infobox width (on the mobile devices) is found.

This issue indeed affects mobile devices only (mobile frontend). It was implemented in T162913 because some infoboxes could be narrower than the display width (the infobox width did not automatically matched the display width, it was adapting to the text width instead). But the new rule makes the column width unpredictable. Another example of the suboptimal behaviour could be seen in this article (mobile view). Only two columns, but it's in multiple columns infobox. In the mobile view, the first column is much wider than the second column.

Do you have some feedback on this? I don't think this was the brightest idea. The introduction of the article is usually made of compact text (consisting of 2 to 5 paragraphs). You are breaking this text with a long "table". As a reader, I would not be overly impressed about such a great interruption. You should either move full introduction before infobox or move nothing at all.

This is not deployed yet? I stumped into this issue yesterday at cs-wiki.

It happens regardless if I am logged in or logged out.