This refers to talk page posts on Wikipedia. For example it happened here.

I could log in again after checking "Keep me logged in". However, it should also work without checking that box and I think that box was previously checked (so I used to log in with that) but wasn't anymore.

The problem still exists with 102.3.0esr. The TOC is not readable, this should be fixed asap, albeit I don't know how many users are affected.

It is the latest in Debian, 91.13.0esr

Don't have that. But here's how it looks like when I change the Firefox preferences to Font size 16 where it used to be size 24:

(here's mine)

So the issue seems to occur only with a certain font-size (if it's supposed to look like in my screenshot). I thought the font-size 24 was the default but maybe it isn't or it's only the default for some configuration. Whether or not it's the default doesn't matter much as it should work with all reasonable font-size configs.

In T310893#8198740, @Jdlrobson wrote:

I can't replicate the issues with line heights in Firefox ESR 102.2.0.esr. What I see replicates the screenshot that Alex shared.

In T310893#8197991, @Aklapper wrote:

@Prototyperspective: Regarding F35496804, does the tense text also show on https://en.wikipedia.org/wiki/Restoration_ecology?safemode=1&useskin=vector-2022 ?

Maybe the 3rd screenshot that I just added makes it clearer just how incredibly bad it is. Now that the issue with it overflowing into the article text is fixed, this bug really should get fixed as well.

I don't remember changing the font-size and until recently this wasn't a problem. Moreover, in these settings I have "Allow pages to choose their own fonts, instead of your selections above" checked.

It happens with all widths and zoom levels that I tried with (earlier Firefox than 102) and also when I add ?safemode=1 to the url. Restarting the browser didn't help. I never had this problem until 22 July and it's very annoying as it hides parts of all articles. What did you change on 21/22 July?

No, wouldn't know which page would be more relevant than a VillagePump discussion, but after all it's in English Wikipedia's code so thought it would best go here. Also I'm not that worried about this issue, it simply should get fixed asap but it isn't particularly important or annoying to me personally. I wondered why nobody solved this yet and searched for discussions about it but found none.

In T310893#8013763, @Max.loh0424 wrote:

Providing an option to auto expand TOC (like the one in the tested version) would fix T307867 too.

In T310956#8013540, @Aklapper wrote:

Note that the image F35252843 in this ticket is restricted to the task author and cannot be seen by anyone else. Which piece of software is this about?

Filtering for "Automated contributions" (either "Bot" or "Human (not bot)" is already possible on Special:Watchlist.

I don't consider what I proposed simple, I only consider showing links to the categories at the bottom of the page relatively simple. These are plain HTML links and can be retrieved with the API afaik,

This has been authored in 2014 and has still not been implemented in 2022 even though it would be simple to show this information at least in a simple way. I'd just like to add that one could implement this by adding a category trees browser instead of a plain list of wikilinked categories.

Done. Also: this Wishlist proposal seems relevant to the issue and vice versa: Grouping watched pages.

Fair point and that's why I only raised this in a comment at that task. Most likely, it depends on some substantial core changes implemented first. But still this could become a Global Watchlist -only or -first feature instead of getting built into the current main Watchlist.

Yes, that's true – I should have made it clearer that it would be implemented so that it only loads these after pressing the button to show the watchlist (maybe it could preload and only show the first few items for each watchlist) ie per AJAX.

This could be built into the global watchlist (currently here).

It's a clear and common use case. It's so simple and quick to just hide a div which is why even a relatively small advantage of this would make it worth. Once they have been hidden one could show day-headers, just like on the English Wikipedia. I'm not sure why it wasn't built like this in the first place: why put timestamps on the left without any option to change that instead of having a header per day (which people are used to, makes a lot of sense, and is the well-tested approach)?

Very useful info but I would disagree if you're saying that custom common.css would be a solution to this:
it should be configurable on the GlobalWatchlist page. Meaning somewhere at the top of the page you have a small gear icon where you can find settings where there is a tab, e.g. "UI", to customize the UI with a few, clear options, including a checkbox for "show timestamps". This option could use this css class or just hide the div the timestamp is contained in. Wasn't it decided that VueJs will be used in the future? In that case it would be even simpler to toggle this.

In T298919#7611966, @Aklapper wrote:

Why color instead of filter?

Alright, thanks for the info – didn't notice there were separate task forms.

I think the extension isn't of much use if it's not known and used. Hence, there should be a config at the Watchlist page of English Wikipedia and other language Wikipedias once the extension is ready for it.

On mobile the code is functional, however looks a bit odd. We likely want to tweak the CSS to fully fix this issue

In T176668#7590067, @Aklapper wrote:

The "Software Development" link goes to https://www.mediawiki.org/wiki/Developer_hub which is clearly about MediaWiki, so you're statement seems wrong.

In T171717#7555616, @kostajh wrote:

AIUI from looking at https://en.wikipedia.org/wiki/Wikipedia:Gadget, you need to propose it in order for it to be listed in preferences: New gadgets should be proposed at the technical Village Pump

Thanks for the infos. Will propose it there (albeit having even more options could be a problem and this should be in the options of the Watchlist page if it's not enabled by default). Probably has been proposed earlier too.

This is already implemented here: https://en.wikipedia.org/wiki/User:Prototyperspective/gadgets/aWorkingWatchlist.js

Okay Clump managed to actually address my reasons. He stated that "they are all mediawiki projects".
That is false in that they are not the MediaWiki software.
See https://en.wikipedia.org/wiki/MediaWiki:

The only question I ignored is whether I developed MediaWiki so far. It's irrelevant. As I already stated even if it was the hardest thing in the world it should still be on that page because it's about MediaWiki development. Currently that page doesn't even list a MediaWiki extension. In contrast, you keep ignoring all my points and don't address them. These include the context of the link and the title/purpose of the page. New MediaWiki developers requires MediaWiki development.

In T176668#7548555, @Jayprakash12345 wrote:

In T176668#7548551, @Aklapper wrote:

https://www.mediawiki.org/wiki/New_Developers says "This page is a simple and guided landing page for new Wikimedia developers."

It's good to have this discussion and I think it's moving closer to reasons. However, I still can't see reasons for why MediaWiki shouldn't be there. I repeat what I have said before:

Well fine, that's your opinion. Apparently you'd like to have volunteers to not develop MediaWiki. Is MediaWiki not important software to you? I'd like to understand why you oppose this and also think that it's necessary to provide a reason for closing this.

Reopened: it makes absolutely no sense to not even mention MediaWiki even though it's the core, main Wikipedia/Wikimedia project and has a large backlog of open issues (even utterly basic ones like a working Watchlist) and a severe lack of new developers.

I rendered a smaller version and the upload went through. I think that it was caused by the filesize. Please fix the error-message and please consider raising the filesize-limit.

This seems to be related: T279407
Do I need to rerender to be able to upload it? I'm asking because the rendering (with Kdenlive) takes a lot of time and in that case the error-message should say so.

@Aklapper Please see (including the link):