Would it be possible to implement obfuscatedFeatures toggles?

[enchanted-sword]

window.___INITIAL_STATE___.obfuscatedFeatures is a property set by Tumblr that contains a base64-encoded object with a list of enabled "hidden settings" likely not meant to be accessed by users. If these settings are set from true to false between when the property is initialized and when its value is read, such as via changing the property to a getter that redirects to a proxy variable, you can effectively toggle these hidden settings.

Among these hidden settings are keys such as redpopDesktopVerticalNav, activityRedesignM3, messagingRedesign experimentalBlockEditorIsOnlyEditor. Modifying these settings is by far, the simplest way to revert cosmetic changes to site, and would allow resolving a whole slew of issues including but not limited to #972, #1149, #1151, and #1155. The list of cosmetic changes in these settings goes far enough back that you can make your dashboard look like this, if you really wanted to for whatever reason.

Of course, there are difficulties with implementing toggles for these settings. I've ironed out a lot of kinks in my own experiments with it, but essentially the method for adding the getter differs based on how fast the page is loading. It has to be added before the property is accessed by the page regardless, but if window.___INITIAL_STATE___ has not yet been set, such as when opening Tumblr in a new tab, It's necessary to add a setter as well so that when Tumblr defines it the value can be sent to the proxy variable. There are no doubt improvements that can be made to my method, but it's still a finicky property to work with.

It's a minor drawback, but changing these settings obviously requires a reload to take effect.

I guess what I'm asking is if there is an efficient way to implement obfuscatedFeatures toggles that fits within the scope of the project. I couldn't find anything in the repo mentioning window.___INITIAL_STATE___ so I assumed it either hadn't been considered as a utility, or wasn't being used for a specific reason. There is likely a reason why Tumblr obfuscates these settings, but at the same time modifying at least the cosmetic ones doesn't seem to have any adverse effect.

[marcustyphoon]

The obfuscation seems pretty light to me; I'm really not sure why it's done at all. I mean, why not, I guess, but.

Re: is it a good idea/within the project scope:

I think the major risk of modifying Tumblr feature flags is that one no longer has full control of what their web extension actually does. If (making up an example) Staff deprecates some version of the UI but doesn't yet remove it from the frontend, and enabling some combination of flags results in that UI screwing up post content, that's not a great situation. Obviously that's quite unlikely and the modifications XKit Rewritten does in the usual web extension way have the potential to screw things up too, but there is definitely a level of predictability and checking-for-the-unexpected that one can do when writing declarative code that doesn't apply to flipping a flag. I do think that, as compared to user scripts or more niche web extensions that more technical users can seek out, XKit is expected to cater to a wide audience and put a lot of effort into not breaking anything (although, I mean. I say that, but legacy XKit currently horribly breaks a bunch of the site and we don't put much effort into preventing that, so maybe it's not really about the XKit brand).

Similarly, the code underlying those currently-unused flag options will of course go away at some point, and there's something to be said against putting in features with an expiration date. But, then, all XKit features have an expiration date in the grand scheme of things, whether that's from changes to the site or, you know, the heat death of the universe, and the point of this whole thing is to serve users' desires; if a flag-based feature would serve a lot of users' strong desires for a while, why not?

tl;dr: I see upsides and downsides to this, if it's possible.

Re: how one would actually do it:

The major problem I can see with using the window.___INITIAL_STATE___ intercept method in an actual web extension (clever, btw, whoever came up with that) is that we can't access extension preferences synchronously, so how would we know what to set the flags to?

edit: oh—in an MV3 extension, you can dynamically register/unregister content scripts, which would definitely be one solution. Your flag changes would only occur after a page refresh, so you couldn't do XKit Rewritten's "all preference toggles apply immediately" thing. But I would love to see someone make that web extension, just since it sounds like a neat solution to a fun code problem.

[marcustyphoon]

Oh, additionally: something about consistent user expectations goes here. If "reverting Tumblr UI changes" is easy and reliable and something we want XKit to do, we should aspire to always offer it when possible. If we don't aspire to offer it reliably, we should probably point people to e.g. user scripts instead, to set the expectation that XKit isn't usually going to do that, so that people aren't disappointed when it doesn't.

This ship has already left the harbor and circumnavigated the globe, to be clear. I follow the XKit tag and the number of people one hundred percent convinced that they don't have the new layout because XKit is somehow magic (and does things without you telling it to? I guess?) instead of because it's an A/B is truly remarkable.

[enchanted-sword]

I definitely see the point you're making here in regards of feature lifespan; however one thing I don't think I got across well in my original discussion post is that by default, every single flag is enabled. Rather than being an option to disable certain features when enabled, these flags for UI updates instead represent additions onto some "base" version of the UI. In the case of features currently undergoing A/B testing, these flags are simply not present in the obfuscatedFeatures property of blogs that are not part of the A/B test. This structuring implies there being a decent system in place for rolling back UI updates, as has occasionally happened in the past. If I remove all of the flags by changing the getter to return undefined it reverts the post UI to looking like this (ignore the misplaced timestamp):


I couldn't tell you when this layout was the standard, but it's definitely been a while. Using Tumblr with this layout seems to work just fine, though, and at least for the time being, I think it's safe enough to rely on being able to revert UI features.

And these are just my thoughts, but:
There are definitely advantages to using declarative code to revert UI changes. However, Tumblr's feature testing is rather unpredictable, and for me at least, simply disabling the update seemed like a more practical option than continuing to updating my script every time something gets moved in the UI. And just moving stuff around isn't enough once Tumblr starts changing event- and data-related elements; sure, I could probably re-add the button and event that changes the palette to the account submenu, but I wouldn't want to tackle the activity feed, messaging updates, or the disappearance of the legacy editor. A more experienced person probably could, but at a certain point, is it worth it to make so many changes to the document and document events just for the sake of the feature being toggleable with a single click?