Display the article's external URL directly in the single entry view.
Rationale: On mobile devices, users couldn't see where a link pointed before tapping it.
Previously, the only way to view the external URL was by hovering - an action not available on touch devices.
Rationale: Opening links in the current tab is the default browser behavior.
Using `target="_blank"` on external links can lead to accessibility issues and override user preferences. It may also interfere with assistive technologies and expected browser behavior.
To maintain backward compatibility, this option is enabled by default (`true`), which adds `target="_blank"` to links.
Prior to this commit, to share an entry, a user has to click on the
share link and then copy the URL they are redirected to. The danger is
that they may right-click and copy the share link without actually
clicking on it, and therefore share a link that, when authenticated,
shares the entry, rather than actually sharing the entry.
Here, we avoid this misinterpretation by making sharing into a POST
request and using a form rather than a link.
Currently, removing a feed from `/category/{id}/feeds` redirects incorrectly to `/feeds`. This change fixes it so that
removing a feed will now correctly redirect to `/category/{id}/feeds`. Removing a feed from `/feeds` is unaffected and
will work as it does currently.
To fix this, a new UI endpoint `/category/{categoryID}/feed/{feedID}/remove` is added and a corresponding handler method
to validate and perform the removal from DB.
Shared entry does not link to any user and therefore should not display
any saved progression. Curiously, the progression of a user (the one that shared ?)
was still integrated in the page. This does not make sens regarding the sharing
feature itself. It is also a leak of user personal information onto a public page.
I simply removed the data from the template when the user object is not present.
I tested the change on "regular" entry page, ensuring the save progression feature
still works, and on shared page checking if any error happened in the JavaScript console.
Everything seems in order.
On shared entries, there is no speed configured as this
is bound to the user. Shared entries are displayed without user config.
I've changed the default view to reflect the
actual default playback speed in this case. 1x.
This adds a new "description" field to the feed settings. This allows to
save custom description regarding a feed. It is also exported and
imported as "description" in OPML.
When listening to podcast, it is usual to want to speed up the playback.
https://github.com/miniflux/v2/pull/2521 was addressing the need globally, this PR
allow to address it for just the current open enclosure media. (no save) Some Browser
already include this control directly, but firefox does not (directly anyway).
Also, it is often useful to be able to skip chunk of a podcast, to skip commercials
for example, or get back a bit because we couldn't hear the last part. I added rudimentary
seek controls with the usual +/-10 and 30 seconds chuck size. This is pretty handy when podcast
are very long and using the seek bar is way too tricky to just skip 30s.
As always, I'm French and could only provide English and French translation for the few
text I added in the locale/translations files. Any help is welcome.
Tested mostly on Firefox (121.0) and quickly on Vivaldi(6.5.3206.53), chrome based.
Fixes: #1845#1846
