Release v1.7.6 - Several quality-of-life UI improvements

[elrido]

• ADDED: Ability to copy the paste by clicking the copy icon button or using the keyboard shortcut ctrl+c/cmd+c (Button for copy value of paste to clipboard #1390 & Copy to clipboard via button instead of [Ctrl]+[C] #12)
• CHANGED: Allow toggling tab-key-support using [Ctrl]+[m] or [Esc] in textarea for keyboard navigation (Accessibility issues: Focus trapped in textarea, labels for form controls, focus order for "Create" should be last #1386)
• CHANGED: Switched to WASM streaming and replace unsafe-eval with wasm-unsafe-eval CSP declaration (WASM streaming / eliminate unsafe-eval #1464), requires webserver to have application/wasm MIME type configured.
• CHANGED: Replaced usage of strpos with str_starts_with & str_contains (Replace usage of strpos with str_starts_with etc. #1373)
• CHANGED: Added polyfill libraries for ctype, str_starts_with & str_contains functions (Replace usage of strpos with str_starts_with etc. #1476)
• CHANGED: Turned paste delete link into a button (Stylesheet at #deletelink #266)
• CHANGED: Upgrading libraries to: DOMpurify 3.2.4, cloud-storage 1.45.0, aws-sdk-php 3.336.2
• CHANGED: bootstrap5 template UI improvements
• FIXED: Redirect to the home page after changing the language (keep paste URL, if changing language in dropdown #92)

---

This discussion was created from the release Release v1.7.6 - Several quality-of-life UI improvements.

[vdbhb59]

Loved the copy & delete one especially. Makes a lot of users happy, I guess. :)

[elrido]

Yes, those have been very longstanding items. Gotta thank @Ribas160 for that! 👌

[RedAISkye]

Upgrading to this version causes the WebAssembly error, reverting back to v1.7.5 fixes it.

[elrido]

Assuming the webassembly loading issue only affects some instances and not others, it could be due to an older server not delivering the appropriate mime-type. It would be interesting if an affected user could check that in their browsers network tab. If this is an ongoing issue, please report your findings in #814.

[RedAISkye]

Assuming the webassembly loading issue only affects some instances and not others, it could be due to an older server not delivering the appropriate mime-type. It would be interesting if an affected user could check that in their browsers network tab. If this is an ongoing issue, please report your findings in #814.

On previous build, the content type shows as "octet-stream" for zlib-1.3.1.wasm under Network but still works fine.

@alxndr42
Edit: Alright, I've fixed the issue, setting the MIME Type by manually editing the .htaccess file seems to have not worked for some reason? Maybe I forgot to add period to the extension when doing it manually, not sure.

I set it via cPanel which added the following line to my .htaccess file:-

AddType application/wasm .wasm

Then I also moved it to the top of .htaccess file, and now it finally resolves the error on the staging site with latest build. MIME Type also shows correctly as "wasm" now on both instances. I think I'm good to upgrade production site to latest now.

[alxndr42]

@RedAISkye Forcing the correct Content-Type to be returned did the trick, thank you!

[nicolafilippetto]

Unfortunately, I keep encountering the error "Your browser doesn't support WebAssembly" even after adding "AddType application/wasm .wasm" at the beginning of the .htaccess file. I use an external web hosting service where their support has already confirmed that their servers support wasm and mime. Are there any other solutions? For now, I have reverted to version 1.7.5, which works correctly.
Thanks

[RedAISkye]

Unfortunately, I keep encountering the error "Your browser doesn't support WebAssembly" even after adding "AddType application/wasm .wasm" at the beginning of the .htaccess file. I use an external web hosting service where their support has already confirmed that their servers support wasm and mime. Are there any other solutions? For now, I have reverted to version 1.7.5, which works correctly. Thanks

If your host has something like cPanel, you'll need to configure MIME Type on there to ensure it's globally set.

To confirm if it's actually set successfully, you need to check the Network tab under developer tools and ensure zlib's content type is wasm.

Also, don't forget to clear cache on the site with CTRL+F5 after you make changes.

[elrido]

I think we could now consider switching from the bootstrap 3 to the bootstrap 5 template as the default in the next release. Still need to migrate the templates of the info and directory websites to use bootstrap 5, though, so it all looks the same.

Is changing the look-and-feel of the default template, while keeping all of it's functionality the same, considered a major number change in terms of semantic versioning? We would not remove the old template, so if the old one is configured it would keep looking the same. See for example our template screenshots for a comparison of the two.

[vdbhb59]

Sure, will do that in sometime.

[RedAISkye]

A suggestion. The body box height & width are too big to cover on a small screen. Can that be minimized a bit by default please? I know resize as an option is there, but the default load needs a scroll to go down.

I had the same issue, you can set a specific height as the default by modifying the CSS file, I'm using "bootstrap-dark" so I edited the file "css/bootstrap/darkstrap-0.9.3.css" and added the following line:-

textarea.form-control#message {
  height: 200px;
}

You can see the difference before and after:-

[elrido]

So that would revert the changes we did for #1357 and #1401, where we experimented and settled on a relative height of the viewport (see screenshots in the two PRs). Could we keep a percentage value, but find a better one? In the first screenshot above, I think it only hides the footer because the extra screen estate taken up by the info message box. Maybe 65-67% would be a safer value?

[RedAISkye]

So that would revert the changes we did for #1357 and #1401, where we experimented and settled on a relative height of the viewport (see screenshots in the two PRs). Could we keep a percentage value, but find a better one? In the first screenshot above, I think it only hides the footer because the extra screen estate taken up by the info message box. Maybe 65-67% would be a safer value?

For the default view, I think it would be best to have the input area dynamically adjust so the footer will always be visible.
And only have the input area automatically increase hiding the footer depending on the usage.

I don't know the technical aspects of whether such functionality would be possible though without changing things too much.

[vdbhb59]

@vdbhb59 could you open a new issue with screenshots for that?

#1505 raised