Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bug] Changes made in settings do not survive app restart #99

Closed
tuplasuhveli opened this issue Jun 8, 2024 · 2 comments · Fixed by #105
Closed

[Bug] Changes made in settings do not survive app restart #99

tuplasuhveli opened this issue Jun 8, 2024 · 2 comments · Fixed by #105
Labels
bug Something isn't working

Comments

@tuplasuhveli
Copy link
Contributor

SailfishOS VERSION 4.5.0.25

HARDWARE Sony Xperia 10 III

FlowPlayer VERSION 0.3.5

BUG DESCRIPTION

Any changes made in the Settings page are switched back to default after restarting the app. This is problematic especially when changing the language, since applying a new language requires a restart, but the change in the settings is reverted at restart.

STEPS TO REPRODUCE

  1. Open the top pulley menu to go into Settings.
  2. Change any setting you desire.
  3. Restart the app.
  4. Notice the change being reverted back to default.

ADDITIONAL INFORMATION

When using "Manage folders", the changes are not reverted, even though no folders are shown in the list after a restart.

@tuplasuhveli tuplasuhveli added the bug Something isn't working label Jun 8, 2024
@tuplasuhveli tuplasuhveli changed the title [Bug] Changes made in settings do not survive a restart [Bug] Changes made in settings do not survive restart Jun 8, 2024
@Olf0
Copy link
Contributor

Olf0 commented Jun 16, 2024

@tuplasuhveli, thank you for your concise bug report.

A quick question first: "the changes" you mention in the section "ADDITIONAL INFORMATION" address the changes you made on the "Manage folders" page, right? And only these changes, all other settings you alter are discarded when you close FlowPlayer, correct?

On a pre-SailJail installation of SailfishOS (3.2.1) this issue is not reproducible with FlowPlayer 0.3.5: Changes in FlowPlayer's settings survived closing and then starting FlowPlayer again.

As sandboxing was introduced by v0.3.5 (see PR #77), you can check with FlowPlayer 0.3.4 that this bug is related to it. I assume so, but better be sure.

Spontaneously I can think of two reasons:

  1. (Some or all) saved settings are in a location outside a SailJail permitted path.
    This should not be the case AFAIR, but has to be checked.
    Jolla provides some guidance for debugging apps trying to violate SailJail permissions: sailfishos/sailjail/APPDEBUG.md Maybe you have time and motivation to go through this guidance.
  2. A permission is wrongly used or missing, see sailfishos/sailjail-permissions/README.md for details.
    This README contains a list of accesses an app is allowed to do: AFAICS FlowPlayer's settings are within that, but this needs to be checked thoroughly.
    The SailJail permissions FlowPlayer currently acquires can be seen here.

Maybe @dcaliste (co-author of PR #77) or @poetaster (original author of PR #77) has an idea what goes wrong here.

P.S.: @tuplasuhveli, I wonder a bit why nobody else complained since the release of FlowPlayer 0.3.5: This should affect almost all users (i.e. all users of FlowPlayer 0.3.5 on SailfishOS ≥ 4.4.0). Can you think of anything being special about your SailfishOS installation? Does any other app behave similarly?

P.P.S.: Note that I am neither using FlowPlayer or writing code for it; I merely coordinate its maintenance and take care about release management, translations infrastructure and automatisation, CI workflows, GH repo config, RPM packaging, keeping READMEs up-to-date, etc.

@Olf0 Olf0 changed the title [Bug] Changes made in settings do not survive restart [Bug] Changes made in settings do not survive app restart Jun 16, 2024
@tuplasuhveli
Copy link
Contributor Author

Hey @Olf0, I'm so sorry I had completely missed your reply.

Apparently the issue seems to be fixed now, but since I broke my only phone capable of running SFOS, I'm not able to test the fix. Thank you both, especially @dcaliste for doing the hard work!

@Olf0 Olf0 closed this as completed in #105 Jul 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants