- Implement a better/simpler polyfill for web browsers that don't supported
trusted types yet
- Use two separate policies: one to create HTML, another to create/use script
urls
- Instead of having the policy live in the top-level scope, they're now
declared at the lowest possible scope, right before they're used, making them
inaccessible outside of it. This puts their usage completely out of reach of
an attacker unable to gain some control outside of those two (small) scopes,
and thus removes the need to tighten the policies.
- Remove the now-unused tt.js file
This has been tested on Firefox (doesn't support trusted types) and on Chromium
(does support trusted types).
Replaces usage of the word "bookmark" with "star"/"starred" in order to be more
consistent with the UI and database models, and to reduce confusion with
"bookmarklet" and integration features.
This is in preparation of future work on read-it-later features.
Which are also not called "bookmarks" to prevent any further confusion.
https://github.com/orgs/miniflux/discussions/3719
Related-to: https://github.com/miniflux/v2/pull/2219
The unread page may show outdated entries when navigating back from an article, due to Chrome's back/forward cache (bfcache) restoring the page from memory.
Reference: https://web.dev/articles/bfcache
- The JS bundle has its own isolated scope
- There is no need to use IIFEs anymore (Immediately Invoked Function Expressions)
- Modules are executed after the HTML document is fully parsed, similar to `defer` attribute
- There is no need to use `DOMContentLoaded` anymore
- Module scripts inherently run in strict mode (no need to define `use strict` anymore)
This commit adds a policy, and make use of it in the Content-Security-Policy.
I've tested it the best I could, both on a modern browser supporting
trusted-types (Chrome) and on one that doesn't (firefox).
Thanks to @lweichselbaum for giving me a hand to wrap this up!
There are a few things that need to be done, to make this work.
First, we need to register `Enter` as another hotkey that opens the
selected item.
However, by default the `KeyboardHandler` will override all default
actions. That might make sense for any other key, but for the `Enter`
key, we want to keep the default behavior (i.e. follow a selected link
or press a button). So for this single key event, we do not call
`preventDefault()`.
I see this as unproblematic for the following reasons.
1. With the changes from #2348, when we're in a list of items (articles,
categories, feeds), there is no link selected. This is what made the
`Enter` key work _implicitly_ in the past. With nothing selected, the
`Enter` key will do nothing by default.
2. If we have **any** link selected (including when we are in a view
with a list of selectable items), we'll get the default action of
`Enter` (i.e. follow a link), which is exactly what we had before.
Lastly, we need to update the list of keyboard shortcuts displayed when
pressing `?`.
This fixes#2366.
