Yes, I agree that it is probably the same problem.

I don't undertand the first line in the "De-duplicate access keys" Javascript code:

In T335638#8815241, @Soda wrote:

We could possibly wrap empty numbering with some kind of container instead of having them as strings.

The documentation says: "empty: the current numeral is kept, but the hyperlink to the page is removed, thus appearing as plain text" (https://wikisource.org/wiki/Wikisource:ProofreadPage#The__tag)

I believe that this change is responsible for the wrong layout at https://fr.wikisource.org/wiki/Livre:Revue_de_Paris_-_1907_-_tome_6.djvu

In T185695#4016721, @Aklapper wrote:

Wikisource uses a number of templates which are currently directly coded as /s /e versions containing the start or end tags respectively.

Any example link to share?

According to several persons at fr.wikisource, the call to the query&prop=links API dit return the links in the Page section until a few weeks ago. A Javascript gadget has been using it for that reason for years (we are going to modify it to use query&list=proofreadpagesinindex instead, but I thought it might be useful to notify this unexpected change in the API).

Here is the error message in the browser console when loading WE-Framework

Error: Unable to locate 'p-wef-label' ID on the page. Looks like site navigation menu is changed in a way that can't be modifid from JS
<anonymous> https://ru.wikipedia.org/w/index.php?title=User:Vlsergey/wef.js&action=raw&ctype=text/javascript:2
jQuery 3
using https://fr.wikisource.org/wiki/Les_Phoinissiennes line 10 > injectedScript:516
doPropagation https://fr.wikisource.org/w/load.php?lang=fr&modules=startup&only=scripts&raw=1&skin=vector-2022:6`

The WEF gadget has also disappeared from frwikisource and probably from most wikis since it is apparently linked to a change in Vector-2022. I think the change was introduced by T328692.

I confirm that setting network.prefetch-next to false solves the problem Apparently the option is activated by default and Chrome also has a prefetching option.

If I understand T320865 correctly, it's something different. I am not speaking about different revisions of the same page, but about revisions of different pages (when someone edited a range of subsequent pages in the same book). Also, this behaviour is specific to Wikisource (maybe the French Wikisource?) since it's about the Page: namespace only.

I reopen this bug report because the bug still appears, although it has changed slightly. Now, only the following page is marked as read.

In T320640#8315237, @matmarex wrote:

This seems to be caused by a performance optimization for browsing the book pages. When you visit any book page on Wikisource, the ProofreadPage extension asks your browser to also fetch the data for the previous and next page, to speed up the navigation if you view those pages next (this is done using <link rel="prefetch" …>). However from MediaWiki's perpective, this looks exactly the same as you actually viewing those pages, so they are marked as seen on the watchlist. I found some other concerns about this behavior reported at T299124.

Thank you so much! When I reported this bug this morning, I had no idea it would be solved so quickly. Congratulations!

In T317857#8239783, @Base wrote:

But I see it at https://meta.wikimedia.org/wiki/User:Seudo/Test2 which contains exactly the same wiki code (I copied it)...

I don't.

In T317857#8239745, @Base wrote:

works fine on https://meta.wikimedia.org/wiki/User:Jdlrobson/draft

Not for me, I don't see a ToC there. But I do see those on the voy:en, d: and s:fr: pages.

In T317857#8238863, @Aklapper wrote:

Hi @Seudo, thanks for taking the time to report this!
Do you imply that this still worked a few days ago? Do you have a link to a test case?
Does it work when using three instead of two headings?

The problem is now solved, although I have no idea why...

In T309374#7963125, @Jdlrobson wrote:

Perhaps caused by https://gerrit.wikimedia.org/r/c/mediawiki/skins/Vector/ /792291 ?

I'll try to translate Cunegonde1's message:

Thanks Inductiveload for explaining this issue so clearly. I share everything you said.

We noticed also the large category size (16px) on the French Wikisource, and another (more important) problem seems related, hence I report it here: the transcluded text (example) is now 576px large and not 504px any more (it still is 504px in other skins). The reason is apparently that the 36em width is set at the #text-container div, where the font size is 16px, then this font size is reduced to 14px at a lower level (mw-body-content class, which is located on the #mw-context div).

In T270530#6753660, @Larske wrote:

Here is another example of a false positive: <math>\partial</math> in the article https://sv.wikipedia.org/wiki/D

In T265571#6549793, @Xover wrote:

English Wikisource deployed a default Gadget that simply does the reverse of the original patch earlier today (it replaces character entity references with literal characters). But judging by the logs and my quick testing this appears to have now been rolled back so the Gadget is no longer needed.

This problem is particularly annoying in the French Wikisource because the HTML entities are not even valid (an extra space is added before the semi-colon, maybe because of French typography rules), which makes necessary to fix all of these entities by hand in every page (example).

It works now. Thanks!

Note that the same is true when adding a style on the whole table (in addition to the "wikitable" class").

I agree that the table of contents would be very useful. Collapsed headers are not sufficient on most articles (in a way, they even make navigation more difficult: if headers were not collapsed, at least you could search a word into the page and find what you are looking for without opening all headers one by one).

This bug was mentioned on the French Wikipedia by people who wonder why the same map displays 2 different sets of coordinates.

Apparently, the Visual Editor is not affected by this issue. One user has changed the status of several pages while other users could not (see this diff)

I confirm what Candalua says. More precisely, zooming using the mouse and moving the image do not work when I load the page. But after I click on the zoom button once, zooming and moving with the mouse work.

Here is more information. The Special:IndexPages in the French Wikisource assimilates accentuated characters and non-accentuated characters when searching For example, a search on "intitle:Molière" and "intitle:Moliere" seem to produce the same results, which is good.