@Edtadros the "new" user is determined by the date the account was created. This date is set in the configuration (below). Currently beta has the date set to April 9th 2024, so anyone registered after that date is considered a new user. This value will change in production based on when we deploy this feature, so I think prod QA should be tied to the eventual deployment task.

Just some technical follow-up notes:
Previously we were rendering pinned containers in the correct location server-side, now, due to the browser-based nature of client-preferences, we're moving the pinned container to either the pinned/unpinned container in the browser. With this update, I didn't notice any flash of unstyled content (because the appearance menu is rendered in the browser anyway) but there are still $this->isPinned properties in PHP that we should remove, and also rename the appearance menu to 'appearance menu' in the code instead of 'client preference menu' (the class .vector-feature-client-prefs-pinned-clientpref-1 is not great :P )

Just to clarify the rationale for this request:
For the night-mode feature, the skins modify the :root selector quite heavily. We support night-mode via media-query as well as a user-preference, requiring us to redeclare the night-mode color palette in two place. We duplicate the day-mode color palette in the same way, but instead of using a mixin, we use the Less :extends feature: i.e: :root:extend( .skin-invert ) {...}

Just digging into this a bit, some context: the watchlist and history pages look similar, but they actually have totally different markup. The history page has html taken from core and made to look like the watchlist page, whereas the watchlist page has html tailored for mobile.
Regardless, it looks like the overlap is actually caused by the different time format used by ptwiki. If using that same format on enwiki, the overlap would appear there too:

Oh your right, I guess that column has had a static 70px width before.

This is largely the same issue as T362297 introduced in this patch: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/MobileFrontend/+/1015636.
that patch modifies the thumbnail styles to add a grey background and a fixed width. The watchlist table uses the thumbnail class for the +/- column.
Hopefully this is address in https://gerrit.wikimedia.org/r/c/mediawiki/extensions/MobileFrontend/+/1019178.

@Punith.nyk, @Tacsipacsi is right, we shouldn't be blindly calling response.json() in httpGet, but converting the response to JSON when necessary is still a nice convenience to have. We can make the following edit to httpGet() to wrap the JSON.parse() in a try catch statement:

Just sharing what we've learned so far. It turns out this behaviour is somewhat intentional and has been implemented by design as a solution to T88270.
Basically the behaviour (as implemented) checks the users edit count, and if it is less than 10, redirects them from Special:Watchlist to Special:EditWatchlist. (thank you @SToyofuku-WMF for tracking down this codepath!).

it looks like the overlay issue was an existing bug that was made visible by the addition of a grey background. The screenshot below shows the positioning of the elements *before* the patch. By adding a grey background to the element, as the patch did, the text beside it overlaps. The offending patch did not change the positioning of the elements. Instead of reverting this patch, I think it would be simpler to remove this grey background. As a follow-up, we should fix the positioning and re-introduce this grey background (which was intended for thumbnails).

Using git bisect and testing locally, I can verify that https://gerrit.wikimedia.org/r/c/mediawiki/extensions/MobileFrontend/+/1015636 is the offending commit.
Regarding the redirect, I'm able to reproduce that too, and I see that it's a separate issue, not produced by the offending patch :/
On my local, I can see that the redirect from Special:Watchlist to Special:EditWatchlist only happens for non-admin users.
admin users are still able to visit Special:Watchlist.

✅ We must have the ability to set a different default size for new accounts vs existing accounts

✅ The accessibility settings menu must have the ability to set different defaults for logged-in and logged-out users on desktop

@JScherer-WMF could you clarify, on pages where the settings are overridden, should the radio buttons still be active or should they be disabled?

@JScherer-WMF thanks for raising this issue. There's one place in Vector where we're not using hyphens but we really should: the TOC. We're using word-break: break-word; instead of hyphens: auto; which breaks words without hyphens. I'd consider this a bug.

We didn't estimate this one as currently written since the engineers felt we needed more documentation around the current behaviour/design for this menu. (Does it currently work for logged out users? are we putting it in the "..." menu for anons? )

Justin just needs list of pages

Generally, I'd say that all Special pages fall into to the category of being "table-based". These pages are not all technically tables, but I'd group them into the following categories:

• page-list based
• change-list based
• table based
• form based

Sorry @Edtadros there's still one patch that needs to be merged, so I'm putting this back into code review.

hi @MusikAnimal I've tried to get some clarity on the expected usage of wikipage.content but I wasn't able to come to any definite conclusions. As you point out though, the defacto usage suggests that passing in just the changed html is OK.

I'm still a little confused about what we're doing for recent changes

Right now, no, but we can work on that next. I have filed T361325 for this. It's a little tentative because I'd first like to discuss whether the other DST engineers think it's a good idea, and if so, where this mixin would live. In the meantime, it's my understanding that this isn't a blocker, because the :extend( :root ) hack works for now, is that right?

@Seb_az86556 I went ahead and made the change to common.js. It looks like it fixed the heading issue. It still works on legacy Vector. Regarding common.js, it seems to be working for me, e.g changing "C" to "Ch'":

hi @Seb_az86556 I've looked into it and I know what the font issue is. Vector 2022 has slightly different HTML markup than legacy Vector.

We talked about this during estimation but determined that this is not ready to estimate because it needs some more conversation. The labels in the menu are easy enough to change but the underlying technical naming would require an extensive refactor. We recently completed a task T359983 that changed the classes to the following:

moving to sign off assuming the design portion of this ticket is sufficient. @Jdlrobson feel free to move back to doing or design review if this is not the case. Needs implementation tickets for sign-off.

@KSarabia-WMF to followup with Content transform team to see if there's any work needed from our end.

Per conversation, the team agreed to scope this task to the Appearance menu in Vector and create a new task for Minerva.

hi @Dzahn, could you ask the user to elaborate on the headline/font issues on nv.wikipedia.org? If there's special consideration required for that wiki we'd like to know about it. On my computer, I can't see the issue: " ę́ doe not work... neither does į́" or how "all the headlines are a mess" . If possible, a screenshot would be great (below is what I see).

@MusikAnimal just looking at the logs again, and it looks like this hook is causes errors in more than one place in Minerva and MobileFrontend. I don't see anything wrong with making it compatible with Minerva 👍
but, given the error rate, I think we should disable the gadget for this skin until that happens.

@MusikAnimal I agree that it should only return a jQuery object for an HTMLElement. I added guards in Minerva to check for $content && $content[ 0 ] but it looks like that's not enough. Maybe it's because the lines
$result = $('#xtools_result'); returns undefined in Minerva because #contentSub doesn't exist, but that should still have been caught by $content[ 0 ]. I might add an additional check in Minerva for $content[0] instanceof HTMLElement .

@Lofhi thanks for raising this, @Jdlrobson is out this week.
Images in night mode are hard, and the issue isn't limited to multimedia viewer either. Images can appear black on black in the content as well.

hi @Catrope, the following sounds good:
✅ Less variables and CSS variables in separate files
✅ A dedicated night mode mixin
✅ Only includes tokens required for night mode

It looks like the error suppression was ineffective, which means that checking for $container && $container[ 0 ] was insufficient.
The following error: TypeError: Cannot read properties of undefined (reading 'addEventListener') is still thrown when attaching an eventHandler, i.e $container[ 0 ].addEventHandler(...)
Which means that maybe $container it's not a typeof HTMLElement.

After several conversations I've documented the different options in the following google doc

@Edtadros thanks for catching this

@ThurnerRupert I see how having multiple scrollbars can be an inconvenience. You scroll the page expecting the ToC to scroll, but then it doesn't.
@Jdlrobson pointed out that the ToC in the header needs a separate scrollbar because it sticks to the top of the page, but, the same is true for the ToC in the sidebar.

As part of this ticket, I wanted to leave a comment documenting any edge-cases or workarounds I ran into with the initial implementation.

Hi @Punith.nyk would you like to work on this task? I started a Work in progress patch with an updated configuration:
https://gerrit.wikimedia.org/r/c/wikimedia/portals/+/1009785
There's a handy gerrit shortcut for pulling down someone else's patches
git review -d 1009785 .
You can then amend the patch and push updates to it.
I think most of the linting errors can be auto-fixed with npm run lint:fix but there might be some that need attention. If you want to push a patch but git commit --amend fails, you can add git commit --no-verify to skip the pre-commit hook.

@Edtadros thanks for pointing out that scrollbar issue. That seems to be caused by the following rule in OOUI:

I've posted an alternative patch to the one @Jdlrobson originally wrote. This second approach adds the .notheme class to the teleportTarget element that VE uses for menus and overlays. This results in a state where the mobile editors are in light-mode but the content remains in night-mode. I might be overlooking some usecases here, but if it works, I think this produces a less jarring experience than switching the entire content to light mode.

I've started a spreadsheet with the tasks in the description:
https://docs.google.com/spreadsheets/d/1POmYm3VtPiOYBxDT95dcRun83GD2QPfD2eKyk94CHjs/edit#gid=0

@Maryann-Onyinye thanks, I just added a second mentor the the project :)

@Krinkle thanks for the detailed response, it looks like we agree on the desired outcome

The build above was produced after the fix, proving the fix works.

Hi @Theklan the language name comes from translatewiki:
https://translatewiki.net/wiki/Wikimedia:Portals-language-name/eu
It looks like the translation was reverted last week, so I'll try to deploy the fix this week after fixing T358511