Fix an infinite loop of navigation under the following conditions: key is valid
but token is not present.
Fix is to match the condition used in both gallery
if (!key || !token) {
and the root page.
They seemed to have diverged in commit c3304571a9.
Was able to reproduce this when launching the desktop app such that the key was
picked up (possibly from a prior installation) from the secure keychain, but the
token was not found. I feel this is also a fix for a similar navigation loop
recently reported by QA but unreproducible so far.
https://github.com/ente-io/ente/pull/1185 updated the file but in the accounts
app. That's not the file that's used as the source - this PR updates the one we
use as the source for Crowdin.
From discussions, it seems that it was pre-emptively added but not specifically
requested by a customer. We can bring this back later if needed, or at least
offer better options to clean it, but for now I'm pruning the IPC surface to
reduce the amount of work needed for handling contextIsolation and sandboxing.
Obtained these strings from 33faadf83e/apps/accounts/public/locales/en/translation.json (L632)
I didn't have a way of exhaustively ensuring that all strings are covered, but
I've tried to manually verify.
Once this is merged and translation files synced with Crowdin, I'll do another
PR to update the `local/**/translation.json` files within apps/accounts.
Fixes: Info button is not working when videos are playing in full screen mode.
**Tested by**
Wasn't working before, but it works now. Still doesn't work with the keybinding,
have left a note about that in the code.
The current approach wasn't working. Not sure what caused it to stop working,
but anyway that was an hacky import, as evidenced by the ungainly warning
webpack would print on `yarn dev`. So instead of taking the path, we just take
the JSON contents directly, sidestepping all that.
**Tested by**
Rerunning the upload tests
Sentry has a measurable impact on page load, a metric that I'm keen to
improve. Apparently by default it loses us 8-9 page speed points, though that
can be reduced to 3-4
(https://github.com/getsentry/sentry-javascript/issues/9179).
All of this is doable, but there are bigger tasks to deal with. This is not to
say that Sentry won't be useful again at some point, when we have time to deal
with it better. But right now, we discussed that it's just better to remove
Sentry instead of piling on to the sunk cost.
This flow probably got broken when the select-all-for-a-day functionality got
added in https://github.com/ente-io/ente/pull/674 (haven't dug into this, I'm
just guessing since that's where this all got touched).
Thank you to @Bramas on our Discord for pointing this out, and also providing the fix:
https://github.com/ente-io/ente/compare/main...Bramas:ente:fix-error-on-shared-album
Tested by
---------
Run normal web app on one terminal
NEXT_PUBLIC_ENTE_ENDPOINT=http://localhost:8080 NEXT_PUBLIC_ENTE_ALBUMS_ENDPOINT=http://localhost:3002 yarn dev
Run the albums listener on another port (need to do this since we're running on
localhost, and need to bind to a different origin):
NEXT_PUBLIC_ENTE_ENDPOINT=http://localhost:8080 NEXT_PUBLIC_ENTE_ALBUMS_ENDPOINT=http://localhost:3002 yarn dev:albums
Create a shared album, copy its public link, and verify that
- Before the fix we were getting an error (trying to access properties of `galleryContext.selectedFile`)
- After the fix the shared album is visible
