Change Details

The TDMP process in /T333867 focused on finding a way for preferences to persist for anonymous users. Intentionally, no decision made for how the new client preferences API should work for temporary or registered users the existing code. As a result of this, usage of the resulting API in its current state has proved confusing leading to the following bugs: T346832, T346987 and we should seek to clarify how this should behave for users other than anonymous users. # Current state Calling the following code inside Vector 2022 skin has different results for different users: ``` mw.user.clientPrefs.set('vector-feature-limited-width', '0' ) ``` For anonymous users: A visual change occurs, and the change persists upon page reload For IP masked users and registered users: A visual change occurs, but the change persists **does not persist **upon page reload # Question to answer How should client preferences work for registered users? There are product benefits of thinking of client preferences a device preferences. These are: - Preferences can vary based on the medium. For example a different font size may be required on tablet device, mobile device, laptop or desktop device. Being able to limit the preference to the device may be favorable in certain circumstances. Requirements: - We should not jeopardize our ability to cache pages for anonymous users by setting cookies in a way that impact our ability to cache. # Possible solutions ## Option 1: Do nothing Pros: * Nothing to do. Cons: * The API is counter-intuitive to use as it works differently for logged in and anonymous users. ## Option 2: The mw.user.clientPrefs.set API should throw a JavaScript error when called for logged in users The existing mw.user.clientPrefs.set API would be modified to throw an error when not supported. Pros: * The API is marked as explicitly being unavailable to users. The error helps guide developers to use a user preferences Cons: * The solution limits our ability to ship preferences for logged in users that should vary by device. * Would require some kind of API for changing the HTML tag classes for logged in users. ## Option 3: The mw.user.clientPrefs.set API should save to a user preference for logged in users The existing mw.user.clientPrefs.set API would be updated to either use the cookie or API depending on the user state. Pros: * The API works intuitively. Cons: * The solution limits our ability to ship preferences for logged in users that should vary by device. * More (but valuable) technical work will be required: ** The solution would require us having a way to associate a user preference key with every client preference. ** The solution would require us having a way to register client preferences on the server side so that all client preferences have a preference key associated. ## Option 4: The inline script should no longer be limited to registered users. https://gerrit.wikimedia.org/r/c/mediawiki/core/+/957378 Pros: * The same solution is used for all types of users. Developers do not need to be aware of different implementations based on. * Allows us the capability of shipping preferences for logged in users that vary by device. Cons: * ? ## Option 5: A server side method should be provided to inspect client preference values In T345664#9175048 @krinkle suggests altering the layout on the server side by inspecting the cookie on the server side. This leans on the fact that server side HTML is not cached. Pros: * Allows us the capability of shipping preferences for logged in users that vary by device. Cons: * This adds avoidable further fragmentation of HTML between registered and anonymous users * We'd need to maintain 2 implementations in PHP and JS for reading the cookie and extracting values. * The API will become more complex to consumers (currently they add a class and use the client side API, but with this solution they'd also need to use a server side API)

The TDMP process in T333867 focused on finding a way for preferences to persist for anonymous users. Intentionally, no decision made for how the new client preferences API should work for temporary or registered users the existing code. As a result of this, usage of the resulting API in its current state has proved confusing leading to the following bugs: T346832, T346987 and we should seek to clarify how this should behave for users other than anonymous users. # Documentation of current state 1) Calling the following code inside Vector 2022 skin has different results for different users: ``` mw.user.clientPrefs.set('vector-feature-limited-width', '0' ) ``` For anonymous users: A visual change occurs, and the change persists upon page reload For IP masked users and registered users: A visual change occurs, but the change persists **does not persist **upon page reload 2) Client side preferences are ignored as soon as user logins If a user has a client preference enabled locally, as soon as they register an account or sign into the site, this client preference is ignored until it is set again. 3) Client preferences are restored when a user logs out. When the user logs out, client preferences are restored to their previous state. # Question to answer How should client preferences work for registered users? There are product benefits of thinking of client preferences a device preferences. These are: - Preferences can vary based on the medium. For example a different font size may be required on tablet device, mobile device, laptop or desktop device. Being able to limit the preference to the device may be favorable in certain circumstances. Requirements: - We should not jeopardize our ability to cache pages for anonymous users by setting cookies in a way that impact our ability to cache. # Possible solutions ## Option 1: Do nothing Pros: * Nothing to do. Cons: * The API is counter-intuitive to use as it works differently for logged in and anonymous users. ## Option 2: The mw.user.clientPrefs.set API should throw a JavaScript error when called for logged in users The existing mw.user.clientPrefs.set API would be modified to throw an error when not supported. Pros: * The API is marked as explicitly being unavailable to users. The error helps guide developers to use a user preferences Cons: * The solution limits our ability to ship preferences for logged in users that should vary by device. * Would require some kind of API for changing the HTML tag classes for logged in users. ## Option 3: The mw.user.clientPrefs.set API should save to a user preference for logged in users The existing mw.user.clientPrefs.set API would be updated to either use the cookie or API depending on the user state. Pros: * The API works intuitively. Cons: * The solution limits our ability to ship preferences for logged in users that should vary by device. * More (but valuable) technical work will be required: ** The solution would require us having a way to associate a user preference key with every client preference. ** The solution would require us having a way to register client preferences on the server side so that all client preferences have a preference key associated. ## Option 4: The inline script should no longer be limited to registered users. https://gerrit.wikimedia.org/r/c/mediawiki/core/+/957378 Pros: * The same solution is used for all types of users. Developers do not need to be aware of different implementations based on. * Allows us the capability of shipping preferences for logged in users that vary by device. Cons: * ? ## Option 5: A server side method should be provided to inspect client preference values In T345664#9175048 @krinkle suggests altering the layout on the server side by inspecting the cookie on the server side. This leans on the fact that server side HTML is not cached. Pros: * Allows us the capability of shipping preferences for logged in users that vary by device. Cons: * This adds avoidable further fragmentation of HTML between registered and anonymous users * We'd need to maintain 2 implementations in PHP and JS for reading the cookie and extracting values. * The API will become more complex to consumers (currently they add a class and use the client side API, but with this solution they'd also need to use a server side API)

The TDMP process in /T333867 focused on finding a way for preferences to persist for anonymous users. Intentionally, no decision made for how the new client preferences API should work for temporary or registered users the existing code. As a result of this, usage of the resulting API in its current state has proved confusing leading to the following bugs: T346832, T346987 and we should seek to clarify how this should behave for users other than anonymous users. # C# Documentation of current state 1) Calling the following code inside Vector 2022 skin has different results for different users: ``` mw.user.clientPrefs.set('vector-feature-limited-width', '0' ) ``` For anonymous users: A visual change occurs, and the change persists upon page reload For IP masked users and registered users: A visual change occurs, but the change persists **does not persist **upon page reload 2) Client side preferences are ignored as soon as user logins If a user has a client preference enabled locally, as soon as they register an account or sign into the site, this client preference is ignored until it is set again. 3) Client preferences are restored when a user logs out. When the user logs out, client preferences are restored to their previous state. # Question to answer How should client preferences work for registered users? There are product benefits of thinking of client preferences a device preferences. These are: - Preferences can vary based on the medium. For example a different font size may be required on tablet device, mobile device, laptop or desktop device. Being able to limit the preference to the device may be favorable in certain circumstances. Requirements: - We should not jeopardize our ability to cache pages for anonymous users by setting cookies in a way that impact our ability to cache. # Possible solutions ## Option 1: Do nothing Pros: * Nothing to do. Cons: * The API is counter-intuitive to use as it works differently for logged in and anonymous users. ## Option 2: The mw.user.clientPrefs.set API should throw a JavaScript error when called for logged in users The existing mw.user.clientPrefs.set API would be modified to throw an error when not supported. Pros: * The API is marked as explicitly being unavailable to users. The error helps guide developers to use a user preferences Cons: * The solution limits our ability to ship preferences for logged in users that should vary by device. * Would require some kind of API for changing the HTML tag classes for logged in users. ## Option 3: The mw.user.clientPrefs.set API should save to a user preference for logged in users The existing mw.user.clientPrefs.set API would be updated to either use the cookie or API depending on the user state. Pros: * The API works intuitively. Cons: * The solution limits our ability to ship preferences for logged in users that should vary by device. * More (but valuable) technical work will be required: ** The solution would require us having a way to associate a user preference key with every client preference. ** The solution would require us having a way to register client preferences on the server side so that all client preferences have a preference key associated. ## Option 4: The inline script should no longer be limited to registered users. https://gerrit.wikimedia.org/r/c/mediawiki/core/+/957378 Pros: * The same solution is used for all types of users. Developers do not need to be aware of different implementations based on. * Allows us the capability of shipping preferences for logged in users that vary by device. Cons: * ? ## Option 5: A server side method should be provided to inspect client preference values In T345664#9175048 @krinkle suggests altering the layout on the server side by inspecting the cookie on the server side. This leans on the fact that server side HTML is not cached. Pros: * Allows us the capability of shipping preferences for logged in users that vary by device. Cons: * This adds avoidable further fragmentation of HTML between registered and anonymous users * We'd need to maintain 2 implementations in PHP and JS for reading the cookie and extracting values. * The API will become more complex to consumers (currently they add a class and use the client side API, but with this solution they'd also need to use a server side API)