Steps to reproduce:

it only does so when replying to other comments. This doesn't happen in edge or chrome, I tried with all extensions disabled to no avail.

I couldn't manage to reproduce this issue on my end.
Could you please verify if you are receiving any errors in the console? You can verify that by following these steps:

1. On your tiktok page right click anywhere and select "Inspect".
2. Select "Console" tab.
3. On the left click on the "garbage" icon to clear previous console output.
4. Try to post a comment again and check what error you receive in the console.

Thanks.

(In reply to Hani Yacoub from comment #1)

I couldn't manage to reproduce this issue on my end.
Could you please verify if you are receiving any errors in the console? You can verify that by following these steps:

1. On your tiktok page right click anywhere and select "Inspect".
2. Select "Console" tab.
3. On the left click on the "garbage" icon to clear previous console output.
4. Try to post a comment again and check what error you receive in the console.

Thanks.

Some cookies are misusing the recommended “SameSite“ attribute
Cookie “bm_sv” will be soon rejected because it has the “SameSite” attribute set to “None” or an invalid value, without the “secure” attribute. To know more about the “SameSite“ attribute, read https://developer.mozilla.org/docs/Web/HTTP/Headers/Set-Cookie/SameSite

Having mysterious issues with TikTok as well... Using Developer Edition 101.0b3, macOS Monterey 12.2.1:

• If I click the "Like" button on a comment, I see the following console errors:

16:49:43.899 Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://us.tiktok.com/api/comment/digg/. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing). Status code: 200.
16:49:43.899 Some cookies are misusing the “SameSite“ attribute, so it won’t work as expected 3
16:49:43.899 Cookie “odin_tt” has “SameSite” policy set to “Lax” because it is missing a “SameSite” attribute, and “SameSite=Lax” is the default value for this attribute. digg
16:49:43.914 Cookie “odin_tt” has “SameSite” policy set to “Lax” because it is missing a “SameSite” attribute, and “SameSite=Lax” is the default value for this attribute. digg
16:49:44.292 Cookie “odin_tt” has “SameSite” policy set to “Lax” because it is missing a “SameSite” attribute, and “SameSite=Lax” is the default value for this attribute. 2 digg
16:49:43.900 Error: Failed to fetch csrf token: host=us.tiktok.com error=network request failed

• If I post a comment, the following errors are reported:

16:55:03.027 Some cookies are misusing the “SameSite“ attribute, so it won’t work as expected 3
16:55:03.027 Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://us.tiktok.com/api/comment/publish/. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing). Status code: 200.
16:55:03.028 Error: Failed to fetch csrf token: host=us.tiktok.com error=network request failed

Mitigation test case results (same account used for all):

• New session in a private browsing window: ❌ issues persist.
• New session in a brand new Firefox profile: ❌ issues persist.
• New session in Safari on same Mac: ✅ behaves properly.
• New session in TikTok app (iPhone and iPad) on same network: ✅ behaves properly.

(In reply to Matthew Judy from comment #3)

Having mysterious issues with TikTok as well... Using Developer Edition 101.0b3, macOS Monterey 12.2.1:

Updated to macOS Monterey 12.3.1, experience unchanged.

This doesn't appear to be affected by the samesite=Lax change, as switching the pref in about:config doesn't make a difference?

I run mozregression with a "Like" button on a comment and the result is: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=80dea4887372866122ab8e40617789dc43589d2d&tochange=6f35bc824b37a9a885a46d58d569da1b38d4dfe1

I suspect tiktok is relying on window.navigator.plugins in some way, however it's hard to tell as the file is heavily obfuscated. I could tell that they're trying to access it in https://sf16-secsdk.ttwstatic.com/obj/rc-web-sdk-gcs/webmssdk/1.0.0.229/webmssdk.js on line 453.

Interestingly, if I block the script in question in the network panel, I can successfully "like" the comments and the rest of functionality doesn't seem to be affected.

I'll try to reach out to tiktok to see if they could help us with investigation.

Set release status flags based on info from the regressing bug 1720353

:handyman, since you are the author of the regressor, bug 1720353, could you take a look?
For more information, please visit auto_nag documentation.

The bug has a release status flag that shows some version of Firefox is affected, thus it will be considered confirmed.

I've reported this problem to tiktok through https://www.tiktok.com/feedback/

[Tracking Requested - why for this release]: Issue is affecting an important site

More reports: https://www.reddit.com/r/firefox/comments/uo89yq/tiktok_likes_dont_work/

Retriaging to Webcompat as this is likely not an actual Firefox bug, but we may need to work around it.

Thanks for the investigation. I haven't been able to reproduce any of the issues discussed in this bug. Ksenia, can you tell me a bit more about what you are seeing:

• What OS are you running? I've tried MacOS and Windows 10.
• What issue are you seeing? The OP reported an error when replying to a comment. I think these errors are displayed in notification bubbles on the page (I think I saw one go by quickly that said "Comment posted" once). You mentioned that you had a separate issue with Likes. Does that display an error somehow? Does the Like button change state?
• Do you see the issue 100% of the time? It sounds like you are, since it works with mozregression.

It's strange that the navigator values would lead to differing behavior since they are fixed strings, but that at least suggests the issue won't be very deep. FYI, bug 1720353 encoded the fixed strings for navigator.plugins/mimeTypes -- prior to that, those arrays were empty.

I can also reproduce the issue. I'm running Linux.

When I click to follow an account or to like a post, it looks normal, but after refreshing the page I can see it didn't work.

I ran mozregression before finding this bug report and the result was exactly the same, regressed by bug 1720353.

(In reply to tustamido from comment #16)

I can also reproduce the issue. I'm running Linux.

When I click to follow an account or to like a post, it looks normal, but after refreshing the page I can see it didn't work.

Thanks tustamido! That should get me started.

Thanks for the investigation. I haven't been able to reproduce any of the issues discussed in this bug. Ksenia, can you tell me a bit more about what you are seeing:

Thanks for looking into this. I reproduced the issue on MacOS by pressing on the heart icon on one of the comments, a complete STR would be:

1. Log in on Tiktok and visit a video page, for example https://www.tiktok.com/@styro_pyro/video/7094456242009132334?is_copy_url=1&is_from_webapp=v1&q=science%20experiments&t=1652731767606
2. Scroll a bit to reach the comments section and press on the heart icon to "Like" the comment.
3. Once the heart icon changes state and changes background to red, reload the page.

Expected:
Heart icon should keep the state and remain red.

Actual:
Heart icon remains transparent/not filled as if you never "liked" the comment

When I click to follow an account or to like a post, it looks normal, but after refreshing the page I can see it didn't work.

I wanted to point out that liking videos (not comments) don't work in Firefox as well, however it doesn't seem to be related to the regression as once I switch the UA to Chrome's, it starts working. This has been reported in https://github.com/webcompat/web-bugs/issues/103612 originally.

I wanted to point out that liking videos (not comments) don't work in Firefox as well,

I've never had this issue before Fx 99 and tried it again to confirm. Liking videos (posts) works fine in Fx 98. And I don't spoof UA.

In my experience, this is 100% caused by the regression.

(In reply to tustamido from comment #20)

I wanted to point out that liking videos (not comments) don't work in Firefox as well,

I've never had this issue before Fx 99 and tried it again to confirm. Liking videos (posts) works fine in Fx 98. And I don't spoof UA.

In my experience, this is 100% caused by the regression.

That's good to know, tustamido. Perhaps, tiktok has a specific code path for Firefox for "Liking" videos (based on the UA) that has stopped working since 1720353 has shipped, that would explain it.

TikTok is doing something weird with the values we return for navigator.plugins and navigator.mimeTypes. To see this, note that we only return the hardcoded arrays if pdfjs.disabled is not set. If it is set then we return empty arrays like we did before. If you set pdfjs.disabled then tiktok allows comments/likes. So this appears to be something Firefox-specific in their code since, of course, we return the same hard-coded values as other browsers for those fields. I'll dig a little more but this looks like something they would need to address to fix it properly.
(Again, we can fix it "improperly" by returning empty plugin and mimetype arrays to tiktok.)

The page has other bugs around this -- they are querying the mime type array for a "version" entry, which is not one of the fixed types. But that's looking unrelated.

We're trying to reach out to TikTok about this. I believe Dennis could help us with a WebCompat intervention to return the old, incorrect value to TikTok?

(In reply to Gian-Carlo Pascutto [:gcp] from comment #23)

I believe Dennis could help us with a WebCompat intervention

I can - but Ksenia can, too. :) I filed bug 1769762 to track adding an intervention here. We should be able to get this into 102 and have it ride the trains. If anyone things this is critical enough to warrant a faster rollout, please poke me.

I think we should try to address this in 101 at least. I could be convinced to roll out this out in a SAO update for 100 as well.

Fair. I adjusted bug 1769762 accordingly - Ksenia will take care of that.

So there seem to be 4 mains problems that have been reported here:

1. "Likes" on the comments are not saved
2. Can't reply to other people's comments
3. "Likes" on the videos are not saved
4. Can't follow an account (after refreshing "Follow" button is visible again)

Only 2 of them start working if I flip the pref pdfjs.disabled to true - able to like the videos and follow other accounts. And the first 2 are still broken. Could anyone confirm this?

I've tested an intervention that returns an empty navigator.plugins, but it has the same effect (only fixes 2 out of 4 issues). Tried returning empty mimeTypes array as well, but it doesn't seem to make a difference.

Hi David, I wonder if there is anything else that might have changed in https://bugzilla.mozilla.org/show_bug.cgi?id=1720353 that is not part of the pref switch? It seems that neither pref flip nor returning empty navigator.plugins/mimeTypes makes a difference for me for the issues with the comments (1 & 2).

I don't think there should be anything relevant to the patches in bug 1720353 that is changed if pdfjs.disabled is true (and privacy.resistFingerprinting is false, which it is by default). But I am "almost" seeing what you are seeing. I'm getting inconsistent results -- it looks like the issue is fixed only occasionally by the pref. Ksenia, are your results with a fresh Fx profile?

I tried the first 3 cases listed in comment 27 on two Fx instances: my everyday nightly profile and a local build with a new profile. The results differ. Here's what I saw:

I believe the difference between nightly and local is due to the profile. It looks like things work well with a fresh profile and pdfjs.disabled but I'm not 100% certain. And it won't matter if the profile can break things. I'll keep looking for a better explanation. Some of the weirder things:

• Liking a comment required pdfjs.disabled and a new profile. Setting pdfjs.disabled breaks this and restoring it doesn't fix it until the browser is restarted (odd).
• Commenting on comments works for me with a new Fx profile, regardless of the setting, unlike the report in comment 3. It does not on my normal profile.

Ksenia, are your results with a fresh Fx profile?

I have been testing with an existing Nightly profile. Also fwiw, was running mozregression on "Like on comment" with the same profile (mainly to avoid constantly logging in on Tiktok :) ).

Liking a comment required pdfjs.disabled and a new profile. Setting pdfjs.disabled breaks this and restoring it doesn't fix it until the browser is restarted (odd).

I've tried restarting Nightly with existing profile after setting pdfjs.disabled to true and there is similar behavior to what you describe here, except it started working after restart. So changing the pref without restart didn't make any difference on "Likes on comments" (always broken), but has started working after the restart (i.e. broken if pdfjs.disabled is false and vice versa ). Flipping the pref back and forth actually takes an effect now without any further restarts.

Not sure if it is related, but I've noticed pdfjs.enabledCache.state also gets flipped on pdfjs.disabled pref change, but sometimes it doesn't?

Trying to like a video in Fx 98 (before the regression) changeset dee2afe2b9faaaf23e7733b27beab6166d041f36:
pdfjs.disabled → doesn't matter
privacy.resistFingerprinting → works if it's false (default), doesn't work if it's true

Thanks Ksenia and tustamido. This narrows things pretty substantially.

Ksenia, are you saying that the pdfjs.disabled solution fixed all problems for you after a restart? Since any update to the browser will obviously come with a restart, this might still be a potential compat solution. It's hard to imagine why the pref-flips changes don't take effect except if started with pdfjs.disabled=true but it could be TikTok caching something in such a way that this happens.

(In reply to Ksenia Berezina [:ksenia] from comment #30)

Not sure if it is related, but I've noticed pdfjs.enabledCache.state also gets flipped on pdfjs.disabled pref change, but sometimes it doesn't?

That seems to be about internal pdfjs state. It's not part of the offending patch.

(In reply to tustamido from comment #31)

privacy.resistFingerprinting → works if it's false (default), doesn't work if it's true

It looks like their site behavior breaks when their fingerprinting attempts hit a snag. I ran an experiment where I removed some of the new plugins but not all, so the array isn't empty but doesn't exactly match the spec. This also seemed to be enough to satisfy their fingerprinting -- likes, etc all worked. It's only when they get no value from their fingerprint test that the functionality starts to break. I'm guessing privacy.resistFingerprinting is just another way to do that.

(In reply to Ksenia Berezina [:ksenia] from comment #30)

I've tried restarting Nightly with existing profile after setting pdfjs.disabled to true and there is similar behavior to what you describe here, except it started working after restart. So changing the pref without restart didn't make any difference on "Likes on comments" (always broken), but has started working after the restart (i.e. broken if pdfjs.disabled is false and vice versa ). Flipping the pref back and forth actually takes an effect now without any further restarts.

This makes likes on comments work only occasionally for me. More than half the time, it's as reported in comment 29 -- pref-flip-then-restart doesn't work w/ the old profile but does w/ the new profile.

Ksenia, are you saying that the pdfjs.disabled solution fixed all problems for you after a restart? Since any update to the browser will obviously come with a restart, this might still be a potential compat solution.

Yes, that's correct - setting pdfjs.disabled to true and restarting fixes all 4 problems. But then after flipping it back and forth it breaks at some point and doesn't seem to have an effect on 2 of them (comments likes and reply to comments), but works again on all 4 after setting pdfjs.disabled to true and restart.

I've been testing intervention with emptying the PluginArray. It's a content script with the following:

const pluginsArray = new window.wrappedJSObject.Array();
Object.setPrototypeOf(pluginsArray, PluginArray.prototype);

Object.defineProperty(navigator.wrappedJSObject, "plugins", {
  get: exportFunction(function() {
    console.log('used', pluginsArray);
    return pluginsArray;
  }, window),

  set: exportFunction(function(val) {}, window),
});

It follows the same pattern, unfortunately (consistently 2 problems are fixed, and the remaining 2 only fixed occasionally).

I ran an experiment where I removed some of the new plugins but not all, so the array isn't empty but doesn't exactly match the spec. This also seemed to be enough to satisfy their fingerprinting -- likes, etc all worked.

Maybe I could modify the intervention to do that. What kind of plugins were you removing?
(I've tried returning an array with the plugin that has index '0' in the original PluginArray, but no difference from returning an empty PluginArray)

That's odd since I tried essentially the same thing -- removing all but the first plugin (and not touching the mimeTypes) -- only I removed them from the C++ code. FTR I did that experiment with a new profile. I don't know if it would make a difference with the big, old profile, but it does seem to accomplish the same thing as pdfjs.disabled=true on a new one.

The plot thickens.

Changeset 80dea4887372866122ab8e40617789dc43589d2d is the one prior to bug 1720353 landing. Running this build with mozregression and using my old profile, I cannot like comments. I can like them, with the same build, if I use a new profile. So there is something about this that doesn't like my old profile. I've tried troubleshooting mode and reverting a bunch of settings, but to no effect. Ksenia, it sounds like your injection code is somewhere in-between, where liking comments works sometimes but not others (and I assume this is unrelated to pdfjs.disabled).

So I need to figure out why my old profile doesn't allow liking comments but that's a different bug that predates this one. For this bug, the injection would do it if it weren't intermittent for liking and replying to comments.

The plot thickens.

Changeset 80dea4887372866122ab8e40617789dc43589d2d is the one prior to bug 1720353 landing. Running this build with mozregression and using my old profile, I cannot like comments. I can like them, with the same build, if I use a new profile. So there is something about this that doesn't like my old profile. I've tried troubleshooting mode and reverting a bunch of settings, but to no effect. Ksenia, it sounds like your injection code is somewhere in-between, where liking comments works sometimes but not others (and I assume this is unrelated to pdfjs.disabled).

Ah, interesting. So I've tried installing the intervention with a new profile and it fixes liking the comments problem. I have also noticed that once I open devtools, it starts breaking again. And starts working if I close the devtools panel. It happens regardless of the profile. Same thing with flipping the pref.

David, wonder if you're getting similar results in case of flipping a pref:

1. Open a new profile in the current Nightly/dev edition, it has pdfjs.disabled: false by default
2. Verify that likes on comments don't work (without opening devtools)
3. Set to pdfjs.disabled: true
4. Reload the tiktok page (without opening devtools), try liking a comment, it should work.
5. Open devtools, reload the page and try liking comments.
6. Reload the page and the likes are not saved.
7. Close the devtools, reload the page and try liking comments again. It should work (they're saved after reload).

It works the same on an existing profile for me.

(In reply to Ksenia Berezina [:ksenia] from comment #38)

David, wonder if you're getting similar results in case of flipping a pref:

I can confirm that these steps all play the same for me on nightly (new profile). Even more fantastical -- I ran this on the build before the plugins work (same as comment 37) and ran the devtools steps:

1. Open a new profile with the mozregression build.
2. Sign into tik-tok. Confirm liking comments does work.
3. Open devtools, reload, try liking comments
4. Reload shows liking comments failed.
5. Close devtools, reload and like a comment. This works.

Looks like we're running into a number of issues with the site that don't make sense. This feels like a timing issue -- large profiles and devtools causing things to run slower could be explained by that.

Thanks for confirming. Indeed, seems like opening devtools was breaking "Liking comments" before the plugins work. I usually never open devtools during bisecting with mozregression, so it explains why it pointed to https://bugzilla.mozilla.org/show_bug.cgi?id=1720353.

Maybe for now I can ship this intervention as it fixes all 4 issues from comment 27 with devtools closed (with old and new profile). And the likelihood of users have devtools open on tiktok is low, so it should work as a temporary solution.

I thought (from comment 34) that you still had occasional problems with an old profile + intervention -- problems that weren't devtools related. If not then it sounds to me like your solution is a good workaround. The separate issues we found that existed before this are certainly more important than the devtools bug, although there is a good chance they are related. I'm still looking for something that works with my old profile.

Hopefully we can get an assist from Tik-Tok soon.

I thought (from comment 34) that you still had occasional problems with an old profile + intervention -- problems that weren't devtools related.

I didn't pay attention that devtools affect it at the time of testing :( Only discovered it today.

From my tests with an existing profile and closed devtools the intervention works 100% of the time. I'll try to land it in Nightly and then maybe you could test it with your old profile and closed devtools as well?

(In reply to Ksenia Berezina [:ksenia] from comment #42)

From my tests with an existing profile and closed devtools the intervention works 100% of the time. I'll try to land it in Nightly and then maybe you could test it with your old profile and closed devtools as well?

Sure. I already tested it with a similar behavior change (done in C++) and it didn't help so it's a long shot but it's worth a try.

Sure. I already tested it with a similar behavior change (done in C++) and it didn't help so it's a long shot but it's worth a try.

It has landed in Nightly 102.0a1 (2022-05-20), so should be good to test. I've tried liking and posting comments and liking videos, it works on my old and new profiles with devtools closed.

Hi David, wonder if you could give it a try as well?

(In reply to Ksenia Berezina [:ksenia] from comment #44)

It has landed in Nightly 102.0a1 (2022-05-20), so should be good to test. I've tried liking and posting comments and liking videos, it works on my old and new profiles with devtools closed.

Unfortunately there's no surprise here -- it's still failing to allow likes or comments on comments when I use my old profile. I can follow and I can like videos, as expected. Clearing site data does not help.

Unfortunately there's no surprise here -- it's still failing to allow likes or comments on comments when I use my old profile. I can follow and I can like videos, as expected.

Thanks for checking. I suppose I can still keep this intervention patch and maybe uplift it to Beta until there is a better solution or we hear back from Tiktok. At least it fixes all 4 issues for new profiles and partially in old (the old profile problem is seemingly case-by-case basis, as it works on my old profile with devtools closed).

I agree. I've since managed to get mozregression to work well enough that I've got a regression window for my profile -- see Bug 1770502.

This should be improved in Nightly & Beta now by way of bug 1769762. Would be great if we could get some verification of that, though.

tustamido, are you able to test a current Nightly or Beta build to see if things are working better for you now?

Nightly 2022-05-15 (before bug 1769762 patch): can't follow account or like a post
Nightly 2022-05-25, same profile: both work as expected.

Thanks for confirming! I'm going to call the status for 101/102 fixed then by way of the intervention we're shipping in Firefox. Not sure if we want to close this bug out or leave it open for an eventual fix on Tiktok's end, though.

tustamido, thanks for testing! Wonder if you could check if liking comments or replying to other comments works for you in the recent Nightly?

Liking a comment:

• v98 (before the regression): works.
• v101 (my main profile, I use Developer Edition): doesn't work unless I use this block filter:
  ||sf16-secsdk.ttwstatic.com/obj/rc-web-sdk-gcs/webmssdk/*
• Nightly 2022-05-25: does not work either.

Replying to a comment: same as above (liking a comment).

So the fix doesn't cover all cases.

(In reply to tustamido from comment #54)

Liking a comment:

• v98 (before the regression): works.
• v101 (my main profile, I use Developer Edition): doesn't work unless I use this block filter:
  ||sf16-secsdk.ttwstatic.com/obj/rc-web-sdk-gcs/webmssdk/*
• Nightly 2022-05-25: does not work either.

Replying to a comment: same as above (liking a comment).

So the fix doesn't cover all cases.

Thanks tustamido. Nightly 2022-05-25 behavior matches what David was experiencing.

FWIW, as far as I can tell, the fix is not in Developer Edition yet. The intervention supposed to be visible in about:compat under Interventions (last item in the list), but it's not there for me in 101.0b9.

We should probably keep this bug open until there is a fix for all cases.

Yeah, it missed DevEdition because it landed directly into the RC builds (which we don't ship for that channel). It'll be in 101.0b1 going out on Tuesday next week.

This function still does not work in Firefox. I am referring here to comments on the tiktok platform (hearts) and replies to comments.
I am using the latest stable version of Firefox 107.00 64 Bit.

This function still does not work in Firefox. I am referring here to comments on the tiktok platform (hearts) and replies to comments.

Thanks :kempa3, I've checked and likes on comments and replies to comments are not working for me either now. Intervention doesn't appear to be fixing it anymore. I have noticed that it starts working in Firefox if I switch User Agent to Chrome's. Wonder if you could confirm that this is the case for you as well?

Yes, you have right. When change user agent to chrome then this come back to work :D
tiktok ban firefox? :o

Looks like more regressions that we may be able to intervene against, Dennis, do you want to re-prioritize? (Though admittedly it's already S2)

I'm not a huge fan of shipping a User Agent override to a site that big, as usually, this means Firefox is dropping off their statistics entirely, which could only make things worse... :/

Ksenia, since you have looked into their code before... Do you have time to investigate deeper here, to see if there is another shim-like intervention we could ship, or if at least a partial UA override that would still indicate Firefox could work here?

Meanwhile, I'll try to see if I can find an engineering contact there to have this fixed on their end, but I assume this is going to be hard. Keeping the ni? active for that.

Ksenia, since you have looked into their code before... Do you have time to investigate deeper here, to see if there is another shim-like intervention we could ship, or if at least a partial UA override that would still indicate Firefox could work here?

Both broken features send requests to api/comment (https://www.tiktok.com/api/comment/digg/.. for likes and https://www.tiktok.com/api/comment/publish/.. for replying to comments) and the payload seem to be nearly identical with or without Chrome UA (with the exception of maybe a few cookies where format seems to be slightly different).

When replying to a comment the aforementioned request returns 200 status but with a response "Failed to comment" . Tried spoofing the UA just for this api call and it doesn't help, so there must be some other reason why it's failing. I'll try to dig a bit more to see if I can come up with an intervention that doesn't involve an override for the full site.

FWIW, it also broken in Safari for me, but spoofing as Chrome doesn't fix it in Safari :|

Me and Tom did some more investigation today and it appears that adding a partial Chrome/109.0.0.0 string is sufficient enough for these two features to work.

So a string like Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:109.0) Gecko/20100101 Firefox/109.0 Chrome/109.0.0.0 has to be present in both window.navigator.userAgent and http headers for the api requests. If it's only present in either one and not another, the functionality breaks again. It is unknown how window.navigator.userAgent is being utilized in this case, as the call stack goes through some heavy obfuscated js, similarly to what I observed in comment 7.

Even though this partial UA change makes it work, shipping it is likely too risky as it's unknown whether it will break other functionality on tiktok :/

The issue is not reproducible, regardless of the status of the UA as per https://bugzilla.mozilla.org/show_bug.cgi?id=1769762

I will update the UA Bug when the second run of interventions is performed.

Patrick, is the issue reproducible for you?

Tested with:

Browser / Version: Firefox Nightly 111.0a1 (2023-01-19) (64-bit)
Operating System: Windows 10 PRO x64
Operating System: Mac OSX Catalina 10.15.7
Operating System: Ubuntu 20.4 LTS x64

Can confirm that it works for me as well without the intervention.