[bug] 3 column view setting doesn't work properly

norm commented

2024-06-26 19:03:49 +00:00

Contributor

Version

4211e05

What were you trying to do?

Using akkoma-fe with three columns.

What did you expect to happen?

3 column view works like it did before with the setting applying after reloading the page.

What actually happened?

Akkoma-fe only uses 2 columns unless you manually mess with that setting. This would have to be done every time akkoma-fe is loaded.

Severity

I cannot use it as easily as I'd like

Have you searched for this issue?

I have double-checked and have not found this issue mentioned anywhere.

### Version 4211e05 ### What were you trying to do? Using akkoma-fe with three columns. ### What did you expect to happen? 3 column view works like it did before with the setting applying after reloading the page. ### What actually happened? Akkoma-fe only uses 2 columns unless you manually mess with that setting. This would have to be done every time akkoma-fe is loaded. ### Severity I cannot use it as easily as I'd like ### Have you searched for this issue? - [x] I have double-checked and have not found this issue mentioned anywhere.

Oneric commented

2024-06-26 19:36:17 +00:00

Member

Even after logging out, closing/opening the browser, reloading without cache and logging back in, i don’t see a difference to before and when changing the setting it takes effect and a PUT request to store the new value occurs. The effect also persists across login session on different browsers.

What size does your browser window have and does this still occur with a slightly wider window? Maybe something slightly changed with the needed minimum space and calculations on setting change and normal load differ?

From the recently merged patches

Repeater name overflowing
Removing unnecessary deps
add minimum space (height) to empty timelines
visually fuse CW line with post content input box
dependency upgrade
consistently justify language and source format selectors

none seems related to 3 column view, though ig it’s possible dep upgrades had unintended side effects

Even after logging out, closing/opening the browser, reloading without cache and logging back in, i don’t see a difference to before and when changing the setting it takes effect and a PUT request to store the new value occurs. The effect also persists across login session on different browsers. What size does your browser window have and does this still occur with a slightly wider window? Maybe something slightly changed with the needed minimum space and calculations on setting change and normal load differ? From the recently merged patches - Repeater name overflowing - Removing unnecessary deps - add minimum space (height) to empty timelines - visually fuse CW line with post content input box - dependency upgrade - consistently justify language and source format selectors none seems related to 3 column view, though ig it’s possible dep upgrades had unintended side effects

norm commented

2024-06-26 20:17:40 +00:00

Author

Contributor

Seems like 3 column view works when I logged in from an incognito window, wonder if it means there's some sort of issue with the browser's local storage thing

norm commented

2024-06-26 20:20:06 +00:00

Author

Contributor

confirmed that it works when IndexedDB is force cleared from Firefox's inspect tool

norm commented

2024-06-26 20:21:50 +00:00

Author

Contributor

Actually, it still doesn't work once you modify the column setting.

norm commented

2024-06-26 20:46:19 +00:00

Author

Contributor

Seems like it will reappear if the browser window changes after loading.

Oneric commented

2024-06-26 21:49:34 +00:00

Member

Let’s check whether something’s off with your current server-side settings.

When creating a new settings profile from akkoma-fe it will copy the current one, and even when manually creating a new empty one some settings may be copied again from cached values.

So instead let’s back up your current settings and temporarily wipe them for testing. This assumes you’re currently using the “default” profile name; if you use another profile, you can keep it but should first switch to “default” before following the below

Open setings in akkoma-fe, in the lower left select “Settings Backup → Backup settings and theme to file”
At the top of the “General” tab show all setting profiles, then create a new one, use it and delete “default”
Immediately log out
Wipe all browser data for your instance to avoid cached values being reloaded (not only cookies)
Log back in, a fresh bog-standard “default” profile should be created
Export this blank settings profile for comparison
Test if the issue persists

Afterwards you can restore your original settings from the same backup menu, this may take a while

Let’s check whether something’s off with your current server-side settings. When creating a new settings profile from akkoma-fe it will copy the current one, and even when manually creating a new empty one some settings may be copied again from cached values. So instead let’s back up your current settings and temporarily wipe them for testing. This assumes you’re currently using the “default” profile name; if you use another profile, you can keep it but should first switch to “default” before following the below 1. Open setings in akkoma-fe, in the lower left select “Settings Backup → Backup settings and theme to file” 2. At the top of the “General” tab show all setting profiles, then create a new one, use it and delete “default” 3. Immediately log out 4. Wipe all browser data for your instance to avoid cached values being reloaded (not only cookies) 5. Log back in, a fresh bog-standard “default” profile should be created 6. Export this blank settings profile for comparison 7. Test if the issue persists Afterwards you can restore your original settings from the same backup menu, this may take a while

Oneric commented

2024-06-27 00:10:34 +00:00

Member

The culprit is "useStreamingApi": true (“Receive posts and notifications real-time”); this breaks:

notifications displaying in a third column
availability of the settings profile selector
receiving any new notifications at all

Thanks Alyssa (ezio@akko.wtf) for debugging it :)

The culprit is `"useStreamingApi": true` (“Receive posts and notifications real-time”); this breaks: - notifications displaying in a third column - availability of the settings profile selector - receiving any new notifications at all Thanks Alyssa (ezio@akko.wtf) for debugging it :)

Oneric commented

2024-06-27 00:37:13 +00:00

Member

And as expected the bug was introduced during the dependency upgrade (#397)

floatingghost commented

2024-06-27 00:38:39 +00:00

Owner

thought it might be

wonder what dep had a breaking change

thought it might be wonder what dep had a breaking change

Oneric commented

2024-06-27 01:40:44 +00:00

Member

It doesn’t like the destructuring in modules/api.js::fetchTimeline’s function declaration

idk what JS features this invokes or what elese might break from this, but replacing

fetchTimeline (store, timeline, { ...rest }) {

with

fetchTimeline (store, timeline, ...rest) {

avoids any as obvious issues as before in my particular config at least

It doesn’t like the destructuring in `modules/api.js::fetchTimeline`’s function declaration idk what JS features this invokes or what elese might break from this, but replacing ``` fetchTimeline (store, timeline, { ...rest }) { ``` with ```js fetchTimeline (store, timeline, ...rest) { ``` avoids any as obvious issues as before in my particular config at least

floatingghost commented

2024-06-27 01:47:26 +00:00

Owner

hm, so the first one implies that the third argument is an object

whereas the second is a variable argument function

I'll poke it one sec

hm, so the first one implies that the third argument is an object whereas the second is a variable argument function I'll poke it one sec

floatingghost commented

2024-06-27 01:54:22 +00:00

Owner

ok your solution probably isn't what we want to do here since we do actually pass an object as the third option most of the time

but i genuinely do not know why it's using a spread operator at all

i can fix it though

ok your solution probably isn't what we want to do here since we do actually pass an object as the third option most of the time but i genuinely do not know why it's using a spread operator _at all_ i can fix it though

floatingghost commented

2024-06-27 02:00:45 +00:00

Owner

this should be fixed by 8765491399 which has been built and deployed as develop

this should be fixed by 8765491399b76a556c237b0c445cbadd253ce751 which has been built and deployed as develop

👍 1

norm commented

2024-06-27 03:46:09 +00:00

Author

Contributor

Looks like it's indeed fixed for me as well after updating, thanks!