Blocking Sentry breaks the In-Context script

Having got through working out which security-related responses headers to change to allow the in-context script to work, I found it stuck on the log-in prompt. Clicking ‘log in’ sees the page reload, showing the log-in prompt again.

I’m using Brave, which is blocking the Sentry script that the editor includes. The editor then errors as it seems to require Sentry being available (there’s a Sentry.onLoad(...) that fails with a Uncaught ReferenceError: Sentry is not defined). Turning Brave’s protections off sees the Sentry script load at the in-context editor work as expected.

Could the interactions with Sentry fail gracefully?

Hello @thewilkybarkid

In context requires access to these cookies:

I guess the recent changes are kind of similar to the one Mozilla and Firefox introduced about 1-2 years ago (some kind of cookie blockers).

Not sure about this new Sentry script loader, but if it’s on the browser level, there’s not much we can do from our end. I’ve passed your request to our product team, we’ll consider that for the future roadmap.

Not sure about this new Sentry script loader, but if it’s on the browser level, there’s not much we can do from our end

Just dug into this again and the problem looks to be on Crowdin’s end:

This line is in https://crowdin.com/editor?jipt_access_storage=true&jipt=[some-url]; I think it should be

typeof Sentry !== 'undefined' && Sentry.onLoad(function() {
   ...

Hi @thewilkybarkid, let us check this with the team

@thewilkybarkid

Thank you for reporting this. I’ve received a reply from our product development team, and next week, we should deploy a fix that will remove errors from the in-context console and the editor.

I hope this will solve your issues!

1 Like

Thanks @Dima, will let you know!

I can see the change has been deployed, there’s no error in the console anymore.

Unfortunately, I’m still stuck in a log in loop in Brave with its shields up. I think the Sentry problem was a red herring on this front. Having been through Brave’s granular options, it seems that it’s the ‘block third-party cookies’ option is causing the problem after all.

I can access https://translate.crowdin.com/ and crwdns6476944:0crwdne6476944:0 fine, but they’re under the crowdin.com domain. I’m don’t know any other public in-context use I could test, but I suspect they wouldn’t work either.

I tried Firefox with the equivalent option enabled and I can see there’s feature-detection in place:

I think Brave disables the Storage Access API entirely, so it would need separate feature detection to be able to display a useful error message (I wonder if testing setting then reading a cookie is enough?).

In the meantime, we’ll enable the in-context editor on our site and will just let our translators know to report any issues like this to us. I don’t know if any of them use Brave (or another browser with/without a plugin with similar behaviour), but hopefully they’ll all be able to access it ok. :slightly_smiling_face:

Thank you very much for the detailed feedback, really appreciated it.

While we have plans to improve the In-Context feature and your comments about error handling are added to our future improvement possibilities roadmap, we keep gathering feedback and if/once/when we receive lots of the same ones - this change about more detailed error responce will be implemented.

As for now, I’d suggest using an alternative browser or allowing all cookies from this list.

1 Like