⚓ T321498 Make sure limited width toggle is persistent for anonymous users

⚓ T321498 Make sure limited width toggle is persistent for anonymous users
Page Menu
Phabricator
Create Task
Maniphest
T321498
Make sure limited width toggle is persistent for anonymous users
Closed, Resolved
Public
BUG REPORT
Actions
Edit Task
Edit Related Tasks...
Create Subtask
Edit Parent Tasks
Edit Subtasks
Merge Duplicates In
Close As Duplicate
Edit Related Objects...
Edit Commits
Edit Mocks
Mute Notifications
Protect as security issue
Assigned To
ovasileva
Authored By
Jdlrobson
Oct 24 2022, 3:57 PM
2022-10-24 15:57:52 (UTC+0)
Tags
Web-Team-Backlog-Archived
(Sprint 1 (non-milestone))
Patch-For-Review
Web-Team FY2022-23 Q3 Sprint 1
(Ready for Signoff)
MW-1.40-notes (1.40.0-wmf.21; 2023-01-30)
Referenced Files
F36544379: Screen Recording 2023-01-28 at 4.46.19 PM.mov.gif
Jan 29 2023, 12:48 AM
2023-01-29 00:48:25 (UTC+0)
F36339906: Screen Shot 2023-01-19 at 2.52.39 PM.png
Jan 19 2023, 10:54 PM
2023-01-19 22:54:14 (UTC+0)
Subscribers
Aklapper
alistair3149
BBlack
Brightgalrs
Catrope
Ciencia_Al_Poder
Edtadros
View All 20 Subscribers
Description
In
T319449
we will create a toggle for switching between max width and non-max-width mode. Initially this will only persist for logged in users. We hit a similar problem with
T246427
but decided in that case it was not worthwhile adding code for one preference however as the web interface has evolved, a generalized solution would be very valuable.
We should explore generalizing a way for certain features to be set on the client side using localStorage and a small inline script that reads localStorage prior to rendering. I've sketched out a proof of concept at
It's hoped in future this generalized code could be used to support the following future features:
Dark mode
Font-size changing
Possibly with some refactoring:
Table of contents collapse behaviour
Sidebar state (previously explored in
T246427
QA Steps
As anonymous user open any page in Vector 2022 skin
Hit the toggle button in the bottom right to disable the limited width
refresh page
Expected: limited width remains disabled
QA Results - Beta
AC
Status
Details
T321498#8566999
Details
Related Changes in Gerrit:
Subject
Repo
Branch
Lines +/-
ResourceLoader: Basic client side user preferences
mediawiki/core
master
+66
-1
Limited width made persistent for anonymous users
mediawiki/skins/Vector
master
+18
-2
ResourceLoader: Follow-up to adding ResourceLoaderClientPreferences
mediawiki/core
master
+75
-49
ResourceLoader: localStorage based client preferences
mediawiki/core
master
+2
-3
Moves feature classes from BODY element to HTML element
mediawiki/skins/Vector
master
+60
-47
Moves feature classes from BODY element to HTML element
mediawiki/skins/Vector
wmf/1.40.0-wmf.19
+60
-46
Customize query in gerrit
Related Objects
Mentions
Duplicates
Mentioned In
T333867: TDMP Proposal: Preference Persistence For Anonymous Users
T332505: Allow vector-2022 default width state to be set per project
T331681: Measure performance of cookie-based anonymous client preferences
T327979: Enable persistent fixed width setting for anonymous users
T327798: Profile Performance of LocalStorage-based and client-side cookie-based User Preference Storage
Mentioned Here
T107399: Make top queue fully asynchronous
T327979: Enable persistent fixed width setting for anonymous users
T91201: [GOAL] Accessibility settings/preferences on desktop and mobile
T246427: [Spike 8hrs] Decide how to persist state of collapsible sidebar across sessions for logged-in users, logged-out users
T319449: [M] Create toggle to control the fixed width of the content for Vector 2022 skin
Duplicates Merged Here
T327366: toggle limited content width should be persistent
Event Timeline
There are a very large number of changes, so older changes are hidden.
Show Older Changes
Restricted Application
added a subscriber:
Aklapper
View Herald Transcript
Oct 24 2022, 3:57 PM
2022-10-24 15:57:53 (UTC+0)
gerritbot
added a comment.
Oct 24 2022, 4:14 PM
2022-10-24 16:14:24 (UTC+0)
Comment Actions
Change 845667 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):
[mediawiki/skins/Vector@master] Persistent client side preferences
gerritbot
added a project:
Patch-For-Review
Oct 24 2022, 4:14 PM
2022-10-24 16:14:25 (UTC+0)
Jdlrobson
moved this task from
Incoming
to
Visual Enhancements / Layout
on the
Vector 2022
board.
Oct 24 2022, 9:41 PM
2022-10-24 21:41:28 (UTC+0)
PatchDemoBot
added a comment.
Oct 24 2022, 10:53 PM
2022-10-24 22:53:40 (UTC+0)
Comment Actions
Test wiki
created
on
Patch demo
by Jdlrobson using patch(es) linked to this task:
Jdlrobson
removed a project:
Patch-For-Review
Oct 26 2022, 4:16 PM
2022-10-26 16:16:21 (UTC+0)
Jdlrobson
moved this task from
Incoming
to
Not ready to estimate
on the
Web-Team-Backlog-Archived
board.
Oct 26 2022, 4:21 PM
2022-10-26 16:21:54 (UTC+0)
ovasileva
triaged this task as
Low
priority.
Nov 29 2022, 11:16 PM
2022-11-29 23:16:10 (UTC+0)
ovasileva
moved this task from
Not ready to estimate
to
Groomed
on the
Web-Team-Backlog-Archived
board.
Jdlrobson
merged a task:
T327366: toggle limited content width should be persistent
Jan 19 2023, 3:23 AM
2023-01-19 03:23:51 (UTC+0)
Jdlrobson
added a subscriber:
Xaosflux
Brightgalrs
subscribed.
Jan 19 2023, 6:56 AM
2023-01-19 06:56:45 (UTC+0)
alistair3149
subscribed.
Jan 19 2023, 2:01 PM
2023-01-19 14:01:48 (UTC+0)
Oznogon
awarded a token.
Jan 19 2023, 5:37 PM
2023-01-19 17:37:14 (UTC+0)
Oznogon
subscribed.
ovasileva
raised the priority of this task from
Low
to
High
Jan 19 2023, 6:24 PM
2023-01-19 18:24:10 (UTC+0)
ovasileva
subscribed.
Jonesey95
subscribed.
Edited
Jan 19 2023, 10:17 PM
2023-01-19 22:17:42 (UTC+0)
Comment Actions
While waiting for a resolution to this widespread problem, please simply make the limited-width mode opt-in for all users and let them adjust their browser window width manually (for a persistent narrower view) or click the toggle (on individual pages that they want narrower).
Jdlrobson
added a comment.
Jan 19 2023, 10:54 PM
2023-01-19 22:54:14 (UTC+0)
Comment Actions
@Jonesey95
I am not sure I understand your comment. You just need to tick these boxes which is little hardship... I don't see what the advantage is of inverting it - that would just cause annoy people who have already set that preference.
Jonesey95
added a comment.
Jan 20 2023, 12:40 AM
2023-01-20 00:40:47 (UTC+0)
Comment Actions
This bug report is about anonymous users, who, as it has been made clear hundreds of times in the last day or two by commenters on en.WP, do not have access to preferences. Disabling wide mode for them would go a long way toward improving acceptance of this new skin.
gerritbot
added a comment.
Jan 20 2023, 12:46 AM
2023-01-20 00:46:51 (UTC+0)
Comment Actions
Change 881728 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):
[mediawiki/core@master] OutputPage: Basic client side user preferences
gerritbot
added a project:
Patch-For-Review
Jan 20 2023, 12:46 AM
2023-01-20 00:46:52 (UTC+0)
Jdlrobson
added a comment.
Jan 20 2023, 12:55 AM
2023-01-20 00:55:47 (UTC+0)
Comment Actions
This bug report is about anonymous users, who, as it has been made clear hundreds of times in the last day or two by commenters on en.WP, do not have access to preferences. Disabling wide mode for them would go a long way toward improving acceptance of this new skin.
I don't agree. You'd just be switching one audience of annoyed people with another.It's my experience that people who are unhappy are more likely to express frustration than people are to express gratitude and your proposal sounds like it would just lead to complaints from people who are enjoying the current default and improved readability. I'd rather focus my time (which I'm doing as we speak) on solving this problem for everyone.
Jdlrobson
added a comment.
Jan 20 2023, 9:42 PM
2023-01-20 21:42:47 (UTC+0)
Comment Actions
Added patchdemo to
T91201
- approach looks promising and pretty generic and maintainable.
Sj
awarded a token.
Jan 22 2023, 7:42 AM
2023-01-22 07:42:09 (UTC+0)
Sj
subscribed.
Jan 22 2023, 7:44 AM
2023-01-22 07:44:14 (UTC+0)
Comment Actions
Just to say: agreed that this looks promising and maintainable. Thank you for tackling this.
Krinkle
subscribed.
Jan 23 2023, 5:48 PM
2023-01-23 17:48:54 (UTC+0)
Comment Actions
In
T321498#8542290
@gerritbot
wrote:
Change 881728 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):
[mediawiki/core@master] OutputPage: Basic client side user preferences
Notes from today's meeting:
Strongly recommend exploring server-side instead of client-side. Our CDN is already fragmented in at least two (m-dot vs canonical), with I believe a few subvariants already as well. We've previously fragmented mobile cache with its logged-out preferences for
disableImages
and
optin=
cookies which were all server-side rendered as well.
Most of those have since been decom'ed but, I suggest checking with SRE Traffic whether we can introduce 1 variant for desktop to utilize here. That would be an even simpler patch than what you have drafted as it would instead mean the server just checks the cookie and adds the class to the existing bodyClass list in Vector skin class.
If this isn't feasible, then I suggest the following restrictions on the client-side approach:
No JSON parse at runtime. Instead, prefer a plain string.
No localStorage reads. Instead, prefer cookie which are already primed in memory.
No inline script in body or after stylesheets.
These break the browser's ability to parse the article concurrently with the stylesheet download, because inline scripts are spec'ed to be able to see document.styleSheets. Instead, place the inline script in the head, before the first stylesheet.
I suggest placing it in RL/Client, which is already reponsibile for setting the documentElement

class.
No elaborate JavaScript processing code beyond taking a cookie value and appending it after a space to
className
Avoids the untestable nature of the inline script, as you can test the JS method that stores the cookie instead, which will include all the processing logic there. The cookie is internal, direct setting isn't allowed.
No classList (too new) or try-catch (de-opt).
Use a simple
className
assignment instead. See the current inline script for reference.
You'll need to be prepared for changes in the future, where e.g. we're dealing with cached HTML interpreting newer-style cookie values, or new HTML reading old-style cookie values placed by long-running tabs. By making the contract as small as possible (cookie X becomes a class name) you eliminate pretty much all need for manual testing and maintenance/upgrade risk.
ovasileva
edited projects, added
Web-Team FY2022-23 Q3 Sprint 1
; removed
Vector 2022
Jan 23 2023, 7:39 PM
2023-01-23 19:39:49 (UTC+0)
ovasileva
moved this task from
Incoming
to
Doing
on the
Web-Team FY2022-23 Q3 Sprint 1
board.
Jan 23 2023, 7:55 PM
2023-01-23 19:55:22 (UTC+0)
Jdlrobson
added a comment.
Jan 23 2023, 8:36 PM
2023-01-23 20:36:45 (UTC+0)
Comment Actions
Latest patchset takes care of the feedback above (
). I'll be adding a follow up that moves from localStorage to cookies but I had a question about that: How would you suggest reading the cookie without $.cookie being available without using elaborate JS processing?
No elaborate JavaScript processing code beyond taking a cookie value and appending it after a space to className.
Could you expand on this? While the other points seem like restrictions we can work with. I think this one is problematic as we have -enabled and -disabled variants as we need different CSS for both versions and we need to set a default version of this on the body tag - for example in the case of the limited width, limiting width is the default, so the class would need to remove that class and add a new one. We considered enabled only classes a while back, but ran into issues with CSS specificity problems which is why we have specific classes for the 2 binary states.
Avoids the untestable nature of the inline script, as you can test the JS method that stores the cookie instead, which will include all the processing logic there. The cookie is internal, direct setting isn't allowed.
I'm sure we could make the code testable. For example, having a local version of it with unit tests would be one option, or adding the code to JavaScriptTest.
No classList (too new) or try-catch (de-opt).
Too new for which browsers? Note, this feature is not expected to work in grade C browsers. In fact, enabling it there might lead to unexpected (broken) results.
I can modify this to use string replacement, but that seems like added JS complexity to me.
gerritbot
added a comment.
Jan 23 2023, 11:22 PM
2023-01-23 23:22:42 (UTC+0)
Comment Actions
Change 882756 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):
[mediawiki/core@master] ResourceLoader: Cookie based client preferences
Krinkle
added a comment.
Edited
Jan 23 2023, 11:31 PM
2023-01-23 23:31:04 (UTC+0)
Comment Actions
In
T321498#8551075
@Jdlrobson
wrote:
How would you suggest reading the cookie without $.cookie […]?
document.cookie
Codesearch
In
T321498#8551075
@Jdlrobson
wrote:
No elaborate JavaScript processing code beyond taking a cookie value and appending it after a space to className.
Could you expand on this? […] I think this one is problematic as we have [use cases and CSS limitations].
Afak none of that relates to the current task. As I understand it, this is an urgent task. I suggest de-scoping anything you don't need for the width toggle, as it requires more complexity than you have time and space to handle responsibly.
It seems like the highest complexity we might encounter, is that the default changes to fluid width, which could mess with a
-disable
cookie. To avoid that conflict, we can in the same deployment both change the default and remove/change the inline script. Scap deployments have been atomic by default for about a year, across both wmf-config and mediawiki repos.
Long-term, if this general direction is proven viable (it isn't yet). Then we can incorporate extra complexity and generalised capabilities, and think through how to manage that appropiately such that we only need to deal with a single string, yet enjoy all the developer experience benefits you seek. I'm confident that's very feasible. It might require a few minutes of brainstorming between various people to map out. For example, one might use an idle callback after the page renders, similar to how we do other housekeeping in VE, CN, RL, mw.storage, etc. The idle callback would look at the "current" skin defaults and perhaps invert or prune things that are no longer needed. None of this needs to happen now, however.
I note that Patch Set 2 doesn't just compute values that are constant, it also calls various functions and reads DOM properties that generally force a recalc. There is a reason that the current inline script is just a static assignmment. Writing to the DOM is cheap for things that have a naturally deferred impact on the next rendering.
Reading
the DOM, however, generally causes a forced style recalc.
No classList (too new) or try-catch (de-opt).
Too new for which browsers? Note, this feature is not expected to work in grade C […]
I can modify this to use string replacement, but that seems like added JS complexity to me.
What I meant is, it is unsafe to use unconditionally as otherwise the payload would crash. Thus to use classList, requires adding complexity, which is exactly what I found in Gerrit. Patch Set version 2 currently adds 20 lines of code with function calls, try-catch blocks, conditionals, loops, and inline comments.
I am not suggesting to add more complexity to meet the restrictions. I am suggesting to internalise the restrictions and look back at changing/reducing the code to meet the restrictions. For example, the 20 lines can be reduced to a single line that reads:
if
/(^|; )mwclientpref=limited-width-disabled/
test
document
document
documentElement
className
replace
'vector-feature-limited-width-enabled'
'vector-feature-limited-width-disabled'
);
gerritbot
added a comment.
Jan 23 2023, 11:56 PM
2023-01-23 23:56:02 (UTC+0)
Comment Actions
Change 882758 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):
[mediawiki/core@master] ResourceLoader: Minimize client side preference code
Jdlrobson
added a comment.
Jan 23 2023, 11:56 PM
2023-01-23 23:56:23 (UTC+0)
Comment Actions
How would you suggest reading the cookie without $.cookie […]?
Sorry I guess I wasn't clear here. I am aware of how to use document.cookie. However, what was not clear was whether using match and in particular regular expressions / string parsing would count as "elaborate JavaScript processing code". Your Gerrit review implies that it's not so nothing further needed here.
I note that Patch Set 2 doesn't just compute values that are constant, it also calls various functions and reads DOM properties that generally force a recalc. There is a reason that the current inline script is just a static assignmment. Writing to the DOM is cheap for things that have a naturally deferred impact on the next rendering. Reading the DOM, however, generally causes a forced style recalc.
I am not suggesting to add more complexity to meet the restrictions. I am suggesting to internalise the restrictions and look back at changing/reducing the code to meet the restrictions. For example, the 20 lines can be reduced to a single line that reads:
Okay that's great context. If replacing works, that definitely seems like a viable approach. We can also limit it to this single class. I'm not convinced this can be a single line however -we currently vary the class for logged in users, and need to cater for users who use the toggle, and then login. Does
go far enough?
NBaca-WMF
mentioned this in
T327798: Profile Performance of LocalStorage-based and client-side cookie-based User Preference Storage
Jan 24 2023, 3:49 PM
2023-01-24 15:49:37 (UTC+0)
PatchDemoBot
added a comment.
Jan 24 2023, 6:26 PM
2023-01-24 18:26:38 (UTC+0)
Comment Actions
Test wiki
created
on
Patch demo
by Jdlrobson using patch(es) linked to this task:
Ciencia_Al_Poder
subscribed.
Jan 24 2023, 6:45 PM
2023-01-24 18:45:03 (UTC+0)
gerritbot
added a comment.
Jan 24 2023, 7:14 PM
2023-01-24 19:14:10 (UTC+0)
Comment Actions
Change 883267 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):
[mediawiki/skins/Vector@master] Moves feature classes from BODY element to HTML element
Catrope
subscribed.
Edited
Jan 24 2023, 7:44 PM
2023-01-24 19:44:21 (UTC+0)
Comment Actions
In
T321498#8550182
@Krinkle
wrote:
Strongly recommend exploring server-side instead of client-side. Our CDN is already fragmented in at least two (m-dot vs canonical), with I believe a few subvariants already as well. We've previously fragmented mobile cache with its logged-out preferences for
disableImages
and
optin=
cookies which were all server-side rendered as well.
Most of those have since been decom'ed but, I suggest checking with SRE Traffic whether we can introduce 1 variant for desktop to utilize here. That would be an even simpler patch than what you have drafted as it would instead mean the server just checks the cookie and adds the class to the existing bodyClass list in Vector skin class.
To close the loop on the task here: SRE Traffic rejected the idea of doing this server-side, so we're now pursuing a client-side-only cookie solution.
If this isn't feasible, then I suggest the following restrictions on the client-side approach:
No JSON parse at runtime. Instead, prefer a plain string.
No localStorage reads. Instead, prefer cookie which are already primed in memory.
Just to confirm:
discourages client-side-only cookies, and favors localStorage instead. I'm assuming that that's valid as general advice, but that in this particular instance you're making the opposite recommendation because we're talking about accessing it in a performance-sensitive place, is that right?
gerritbot
added a comment.
Jan 24 2023, 11:25 PM
2023-01-24 23:25:17 (UTC+0)
Comment Actions
Change 883220 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):
[mediawiki/skins/Vector@wmf/1.40.0-wmf.19] Moves feature classes from BODY element to HTML element
gerritbot
added a comment.
Jan 24 2023, 11:46 PM
2023-01-24 23:46:55 (UTC+0)
Comment Actions
Change 883220
abandoned
by Jdlrobson:
[mediawiki/skins/Vector@wmf/1.40.0-wmf.19] Moves feature classes from BODY element to HTML element
Reason:
Legoktm
added subscribers:
suffusion_of_yellow
Legoktm
Edited
Jan 24 2023, 11:58 PM
2023-01-24 23:58:47 (UTC+0)
Comment Actions
In
T321498#8554742
@Catrope
wrote:
In
T321498#8550182
@Krinkle
wrote:
Most of those have since been decom'ed but, I suggest checking with SRE Traffic whether we can introduce 1 variant for desktop to utilize here. That would be an even simpler patch than what you have drafted as it would instead mean the server just checks the cookie and adds the class to the existing bodyClass list in Vector skin class.
To close the loop on the task here: SRE Traffic rejected the idea of doing this server-side, so we're now pursuing a client-side-only cookie solution.
It would be appreciated if a more detailed rationale could be provided than just "X said no" as this has come up a few different times on-wiki now; in
@suffusion_of_yellow
said:
Given the backlash from non-logged-in editors here, I think some "hard numbers" would go a long way. If you can say straight out "Desktop requires X terabtyes, mobile requires Y terabytes, and adding support for classic vector would require Z terabytes. We have X + Y < W < X + Y + Z capacity, and increasing storage would cost D dollars" would at least get us all on the same page. Right now all we have in the FAQ is something vague about "overloaded" servers.
I replied with "Someone on the SRE team could probably get you numbers. ..." - since the SRE team has considered this, a more detailed explanation would be helpful for the rest of us to communicate to others why this is infeasible or not practical or whatever.
Jdlrobson
moved this task from
Doing
to
Code Review
on the
Web-Team FY2022-23 Q3 Sprint 1
board.
Jan 25 2023, 12:20 AM
2023-01-25 00:20:24 (UTC+0)
gerritbot
added a comment.
Jan 25 2023, 12:43 AM
2023-01-25 00:43:35 (UTC+0)
Comment Actions
Change 883267
merged
by jenkins-bot:
[mediawiki/skins/Vector@master] Moves feature classes from BODY element to HTML element
Peachey88
subscribed.
Jan 25 2023, 12:56 AM
2023-01-25 00:56:17 (UTC+0)
Catrope
added a subscriber:
BBlack
Jan 25 2023, 12:58 AM
2023-01-25 00:58:22 (UTC+0)
Comment Actions
In
T321498#8555546
@Legoktm
wrote:
In
T321498#8554742
@Catrope
wrote:
In
T321498#8550182
@Krinkle
wrote:
Most of those have since been decom'ed but, I suggest checking with SRE Traffic whether we can introduce 1 variant for desktop to utilize here. That would be an even simpler patch than what you have drafted as it would instead mean the server just checks the cookie and adds the class to the existing bodyClass list in Vector skin class.
To close the loop on the task here: SRE Traffic rejected the idea of doing this server-side, so we're now pursuing a client-side-only cookie solution.
It would be appreciated if a more detailed rationale could be provided than just "X said no" as this has come up a few different times on-wiki now; in
@suffusion_of_yellow
said:
Given the backlash from non-logged-in editors here, I think some "hard numbers" would go a long way. If you can say straight out "Desktop requires X terabtyes, mobile requires Y terabytes, and adding support for classic vector would require Z terabytes. We have X + Y < W < X + Y + Z capacity, and increasing storage would cost D dollars" would at least get us all on the same page. Right now all we have in the FAQ is something vague about "overloaded" servers.
I replied with "Someone on the SRE team could probably get you numbers. ..." - since the SRE team has considered this, a more detailed explanation would be helpful for the rest of us to communicate to others why this is infeasible or not practical or whatever.
I was not in this meeting due to time zones, but pretty good notes were taken, so I'll answer based on that. I'll paraphrase what
@BBlack
said and he can supplement/correct me if needed. Caching anonymous page views is critical to the performance and resilience of the site. Splitting the cache based on a flag like this makes that cache less efficient, and if we expect this to be used for multiple features, it'd get exponentially worse, we'd have to split the cache 2^n ways. It doesn't make sense to split the cache for such a tiny change (just one CSS class name in the

tag). ESI or something like it might be able to do something like this, but we're not remotely ready to implement that now. Custom code at the edge cache could potentially be used, but is very fragile and complex.
All this considered we decided to go with a client-side-only cookie-based approach, rather than a server-side cookie-based approach. We'll set a cookie from JavaScript, and read it in render-blocking JavaScript. This is basically the originally proposed approach, but with "localStorage" replaced with "cookie" per
@Krinkle
's guidance.
ReleaseTaggerBot
added a project:
MW-1.40-notes (1.40.0-wmf.21; 2023-01-30)
Jan 25 2023, 1:00 AM
2023-01-25 01:00:40 (UTC+0)
gerritbot
added a comment.
Jan 25 2023, 1:16 AM
2023-01-25 01:16:32 (UTC+0)
Comment Actions
Change 882758
abandoned
by Krinkle:
[mediawiki/core@master] [For testing] Enable skin client preferences
Reason:
gerritbot
added a comment.
Jan 25 2023, 1:17 AM
2023-01-25 01:17:02 (UTC+0)
Comment Actions
Change 882758
restored
by Krinkle:
[mediawiki/core@master] [For testing] Enable skin client preferences
gerritbot
added a comment.
Jan 25 2023, 4:00 AM
2023-01-25 04:00:17 (UTC+0)
Comment Actions
Change 883298 had a related patch set uploaded (by Krinkle; author: Krinkle):
[mediawiki/core@master] ResourceLoader: Follow-up to adding ResourceLoaderClientPreferences
gerritbot
added a comment.
Jan 25 2023, 4:12 AM
2023-01-25 04:12:32 (UTC+0)
Comment Actions
Change 881728
merged
by jenkins-bot:
[mediawiki/core@master] ResourceLoader: Basic client side user preferences
gerritbot
added a comment.
Jan 25 2023, 4:15 PM
2023-01-25 16:15:16 (UTC+0)
Comment Actions
Change 882756
abandoned
by Jdlrobson:
[mediawiki/core@master] ResourceLoader: localStorage based client preferences
Reason:
Abandoning for now.
LGoto
assigned this task to
nray
Jan 25 2023, 5:50 PM
2023-01-25 17:50:13 (UTC+0)
gerritbot
added a comment.
Jan 25 2023, 7:36 PM
2023-01-25 19:36:52 (UTC+0)
Comment Actions
Change 883298
merged
by jenkins-bot:
[mediawiki/core@master] ResourceLoader: Follow-up to adding ResourceLoaderClientPreferences
gerritbot
added a comment.
Jan 25 2023, 8:08 PM
2023-01-25 20:08:25 (UTC+0)
Comment Actions
Change 845667
merged
by jenkins-bot:
[mediawiki/skins/Vector@master] Limited width made persistent for anonymous users
Jdlrobson
moved this task from
Code Review
to
QA
on the
Web-Team FY2022-23 Q3 Sprint 1
board.
Jan 25 2023, 10:26 PM
2023-01-25 22:26:15 (UTC+0)
Jdlrobson
updated the task description.
(Show Details)
Jdlrobson
mentioned this in
T327979: Enable persistent fixed width setting for anonymous users
Jan 26 2023, 12:37 AM
2023-01-26 00:37:45 (UTC+0)
Jdlrobson
added a subscriber:
Edtadros
Comment Actions
Summarizing the plan from this morning.
We decided we will let this ride the train
On Tuesday we will configure MediaWiki.org and/or group 0 wikis to enable the feature flag.
@nray
will run tests.
I've captured this in
@Edtadros
we'd like to QA this on the beta cluster by end of day Monday using the usual process. Can you make that happen? (Skip QA in production for this one)
Jdlrobson
reassigned this task from
nray
to
Edtadros
Jan 26 2023, 12:38 AM
2023-01-26 00:38:50 (UTC+0)
Jdlrobson
updated the task description.
(Show Details)
Jdlrobson
added a subscriber:
nray
Krinkle
added a subscriber:
matmarex
Edited
Jan 26 2023, 1:39 AM
2023-01-26 01:39:03 (UTC+0)
Comment Actions
In
T321498#8554742
@Catrope
wrote:
In
T321498#8550182
@Krinkle
wrote:
[…]
No localStorage reads. Instead, prefer cookie which are already primed in memory.
Just to confirm:
discourages client-side-only cookies, and favors localStorage instead. I'm assuming that that's valid as general advice […]
That's right. Thanks for connecting the dots! Indeed, our advice is and remains to generally avoid cookies when working within JavaScript, and favour localStorage. My above point does not stand as general advice. I do note that, the above page has only existed for a month and I wasn't aware of it. It does accurately reflect current consensus and recommendations though, so all good! (Thanks
@matmarex
for summarising it there!) Perhaps we can factor some of that into
Performance/Guides
, e.g. under the "Frontend performance practices" chapter.
The mere notion of JavaScript code on our platform
before
page render is effectively non-existent and intentionally made impossible. The concept was deprecated and subsequently removed in 2015 with
T107399
(and related tasks). The ResourceLoader\ClientHtml class in MediaWiki controls the one singular