Owned projects open as immutable

[azmec]

What happened?

Opening projects that you own should bring you to an editable instance or buffer for that project. Instead, some projects open as immutable instances or buffers when opened from external hyperlinks or the "Projects" page.

1. Log into a Wordplay account.
2. Open an arbitrary project that you own and copy its URL.
3. Open a new tab, paste the URL into the search bar, and visit the page.
4. Observe that the project may be immutable despite your owning it.

The above steps reproduce the defect with the following projects:

• https://wordplay.dev/project/1737a8e6-98e0-48e4-bd7d-257438e23f1b
• https://wordplay.dev/project/e28a5923-e07c-4da3-859c-4e0b9422cc90
• https://wordplay.dev/project/c1c7f4be-05ce-46ed-9045-7c4c196f5d8f

For the above projects, appending ?play to the project ID in the URL and loading the URL will produce the defect described below.

---

A related defect may be that some projects, when opened from the "Projects" page, initially appear to be immutable when in "play" mode (?play is appended to the project ID in the URL) but is found to be mutable when the code is revealed (when ?play is removed from the tail of the project ID in the URL).

1. Log into a Wordplay account.
2. Open an arbitrary project that you own.
3. Observe that the project may appear immutable when in "play" mode, as indicated by "copy this project" appearing in the top-right.
4. View the source code for the project.
5. Observe that the project is mutable.

Anything else?

Below is a screenshot of an owned Wordplay project opened from an external hyperlink. The project was opened with an account that owns the project, but it is immutable.

---

Below is a screenshot of an owned Wordplay project opened from the "Projects" directory with an account that owns the project. In the top-right, it states "copy this project", suggesting the code is immutable.

However, clicking the eye button to see the project's code reveals that it is mutable (when ?play is removed from the tail of the project's ID in the URL).

What browsers are you seeing the problem on?

Firefox, Chrome

What operating system are you using?

macOS, Linux

[amyjko]

Reproduced, added to my list.

[amyjko]

Hm, only intermittently reproducible, per the report. Hypothesis:

• New page loads
• [projectid] > +page.svelte calls Projects.get to retrieve the corresponding project
• It's not found in read only database, or in editable project histories (because Firebase hasn't returned the query yet), and so it checks the local database, and if not found there, it's retrieved from Firebase.
• ProjectsDatabase.track is called to track the project retrieved from Firebase, but it's set to not editable even if it's owned by the person retrieving it.

This would only happen if the +page.svelte asks for the project before the Firebase query returns, which could easily happen intermittently.

The fix would be to ensure we mark the project editable in ProjectsDatabase.get based on the current user, and then update the project loaded to editable if the user later changes.

[amyjko]

I believe I reproduced this successfully and that it should be resolved. Check, and if you can still reproduce, please reopen.