* Add a reference to the check where the warning is triggered
Note:
This is the place where the admin sees the browser pointing to.
Adding this information here allows the admin to find the matching
documentation entry.
* Update Content-Security-Policy section of english ServerConfig documentation
Note:
This fixes some minor formating/typping issues and adds some clarity to
the fact that this warning is also triggered on correctly configured
hosts, simply due to the nature of how correctness of CSP rules are checked.
* Move CSP infor source-code comment into console.info
Note:
Improve visibility of why this is happening.
* Point towards static website documentation instead of git
This URL should also remain more fixed even accross new branches/releases.
Co-authored-by: Inverle <inverle@proton.me>
* Minor fixes
* Remove overwrite part
---------
Co-authored-by: Inverle <inverle@proton.me>
Co-authored-by: Alexandre Alapetite <alexandre@alapetite.fr>
Follow-up of https://github.com/FreshRSS/FreshRSS/pull/8281
todo:
* [x] Include labels (prefix `t_`) too
* [x] Keep sidebar scrollTop when using the nav menu
* [ ] ~~Make this work in the reader view's sidebar too~~ for separate PR
* [x] Prevent whole page from scrolling on `scrollIntoView()` call, just scroll in the sidebar (probably related: https://github.com/FreshRSS/FreshRSS/pull/8306#issuecomment-3647414618)
This TODO will be done in a separate PR since it requires optimizing the sidebar toggle code.
edit: it does work on Chrome already though, but only if `#stream` isn't too large / breaks randomly (Firefox is slower it seems)
Previously if you were to go to for example *Subscription management* and filter a feed, the feed wouldn't be visible in a sidebar with lots of feeds, since you'd have to scroll to it first. Now, this is no longer the case.
Note that if the navigation comes from the sidebar itself, the original behavior remains. (scroll into previous `scrollTop` value of sidebar)
Also improves experience of using shift+j/k (see https://github.com/FreshRSS/FreshRSS/pull/8057)
Fix https://github.com/FreshRSS/FreshRSS/issues/8268
To better support user management on FreshRSS instance with many users.
SQL speed improved. On a reduced test with 5 users, including some large accounts (PostgreSQL on a very tiny and slow server), improving from ~2.3s to ~1.8s, which gives ~20% speed improvement.
Then tested with 1000 users, with only the default feed (on my old desktop computer):
```sh
for i in {1..1000}; do ./cli/create-user.php --user=freshrss$i --password=freshrss; done
app/actualize_script.php
cli/access-permissions.sh
```
SQLite:
```console
$ time cli/user-info.php | wc -l
1001
real 0m1.366s
user 0m0.908s
sys 0m0.475s
```
PostgreSQL:
```console
$ time cli/user-info.php | wc -l
1001
real 0m28.498s
user 0m12.137s
sys 0m2.217s
```
MariaDB:
```console
# time ./cli/user-info.php | wc -l
1001
real 0m49.485s
user 0m1.276s
sys 0m2.258s
```
Yes, SQLite is much faster - not a surprise for such use-cases, where the TCP connection is not re-used.
I have added some CLI options to disable some statistics:
```sh
cli/user-info.php --no-db-size --no-db-counts
```
For the Web UI, I have disabled detailed user statistics if it takes too long, and retrieve missing user statistics asynchronously via JavaScript. Lazy loading of the user details based on IntersectionObserver, with maximum 10 requests in parallel.
Web UI tested on 1000 users as well. Checked with SeaMonkey.
* Fix 7307 - Scroll after load
Closes https://github.com/FreshRSS/FreshRSS/issues/7307
- Wrap the body of `loadDynamicTags()` into a Promise
- inside `mylabels()`, wait for the promise to complete, then scroll
- when `loadDynamicTags()` is not being called, return a self-resolving promise
How to test the feature manually:
1. Click on an long article
2. press keyboard shortcut `l` to go to "My labels"
3. page should scroll down
4. the `My labels` popup should be fully visible
* Rewritten as async/await
* Explicit HTTP Accept application/json
---------
Co-authored-by: Alexandre Alapetite <alexandre@alapetite.fr>
Before, the shortcuts marked in red and blue behaved the same way (with shift modifier)
Specifically <kbd>Shift + J</kbd> had the same behavior as <kbd>Shift + K</kbd> which means it only jumped to unread and not read/unread.
<img width="719" height="396" alt="image" src="https://github.com/user-attachments/assets/8ebd1efc-c186-4dcf-9b54-b9acbf3bbbe5" />
Now the shift modifier shortcuts match the behavior of the alt and no modifier shortcuts.
<kbd>Shift + K</kbd> was corrected too, but there is no alternative for it yet, since I don't know which default key should be used for it - <kbd>l</kbd> is already taken by *My labels* shortcut
## Screenshots
<details>
<summary>Before</summary>
<img width="773" height="652" alt="image" src="https://github.com/user-attachments/assets/89a0e58c-8c4a-41ff-b5d6-3e916079d563" />
</details>
<details>
<summary>After</summary>
<img width="1006" height="646" alt="image" src="https://github.com/user-attachments/assets/f4575103-7365-4870-a170-2742bf10eb27" />
</details>
This is an example on Firefox, where the `Master authentication token` field was incorrectly being autofilled.
Red borders are indicating that the fields are required.
## List of changes
* `required="required"` is now being added to the password fields if the section is open
* The `challenge` field is being added if section is open instead of when at least one of the password fields isn't empty due to autocomplete
* Added `autocomplete="new-password"` on fields that shouldn't be autocompleted
* Unfortunately Chrome requires a workaround with CSS
* Not tested on Safari yet
* User will be redirected to profile page after successfully changing their password instead of index page
## How to test
Autocomplete related changes should be tested on a HTTPS page with saved credentials for FreshRSS
Regression from #7763
Earlier regression which was fixed before #7626
In addition:
* get rid of `data-toggle` (refactor)
* show invalid login message if deleting account and entered incorrect password instead of redirect to 403
* remove unused reference to `r` parameter
* `forgetOpenCategories()` on login not on any crypto form
This error would print in the console if navigating to last article with <kbd>J</kbd> or <kbd>K</kbd> key:
<img width="836" height="173" alt="image" src="https://github.com/user-attachments/assets/0ae88d1c-26eb-4ebe-8d15-4bf03c24cef6" />
---
To reproduce the bug:
<ol>
<li>Select unread + read view, while having all articles marked as read</li>
<li>Mark two as unread and go to unread only view</li>
<li>Navigate with either <kbd>J</kbd> or <kbd>K</kbd> until you go past the last article or before first article</li>
<li>See error in console and no navigation with <code>first_feed()</code> or <code>last_feed()</code></li>
</ol>
note: I'm not sure if the fix is what the expected behavior is supposed to be
I found this todo and just did it. 😆
Changes proposed in this pull request:
- use `open-class` instead of `.box a`
How to test the feature manually:
1. go to global view
2. click on a box title link: it will open the whole category in the panel
3. click on a feed name: it will open the feed articles in the panel
4. nothing will be different for the user as before
* Show warning when unsafe CSP policy is in use
* Fix bare markdown URL
* i18n: fr
* Minor i18n: fr
* Add target="_blank" to i18n strings
---------
Co-authored-by: Alexandre Alapetite <alexandre@alapetite.fr>
Instead of a repeating pattern like: `<input type="text" value="something" data-leave-validation="something">`, you can now put a `data-auto-leave-validation="1"` attribute on a `<form>` for example, and it will automatically set the `data-leave-validation` attributes inside the form elements.
`data_auto_leave_validation(parent)` from `extra.js` is called on slider open and page load.
---------
Co-authored-by: Alexandre Alapetite <alexandre@alapetite.fr>
Co-authored-by: Frans de Jonge <fransdejonge@gmail.com>
List of changes:
* The temporary document for printing is now in an `<iframe>` instead of a new tab
* The whole `<head>` element is copied to the temporary document, except for `<script>` tags to copy over the `<meta>` tags as well
* URLs that contain the instance base URL are now removed from the printed PDF
* The saved filename (PDF) will now default to the article title
* `<details>` is auto expanded
* Styling:
* The main document's `<html>` class is copied over to preserve some styling that might use those classes
* Instead of writing `content_el.innerHTML` to the temporary document, `content_el.outerHTML` is now written instead to apply the styles that select `.content`
* `.dropdown-menu` is now hidden in the printed document, because it can't be expanded anyway
* Headers and footers are hidden in the printed document
* The printed document will now display correctly all the time, by waiting for it to load before calling `print()`
* Before, the stylesheets might've not finished loading and the document was broken
* Better browser support on mobile for this feature
* Before, the document would fail to print on Chrome Mobile
Tested on:
* Firefox - both desktop and mobile, works ✅
* Chrome - both desktop and mobile, works ✅
* Opera - desktop, works (same as Chrome) ✅
* Brave - both desktop and mobile (same as Chrome), works ✅
* Safari - both desktop and mobile, works✅
* Microsoft Edge - both desktop and mobile, works ✅
* GNOME Web - desktop, works ✅
* SeaMonkey - desktop, works ✅
Known issues:
* Images may not finish loading the first time the print dialog is opened
TODO:
* [x] Test on Safari
* [x] Try to fix GNOME Web
* Implement sudo mode / reauthentication
* i18n: fr
* generate flags
* Improvements
* Remove HMAC check
* Don't require reauth to access logs when signed in as admin
* Notify user of bad login via notification instead
---------
Co-authored-by: Alexandre Alapetite <alexandre@alapetite.fr>
* Prevent onbeforeunload from showing a popup before leaving
* Send mark as read request when leaving and revert interval
* Use visibilitychange event instead of onbeforeunload, and refactor send_mark_read_queue to use fetch
* Move removed code to the new `catch` block
* Refactor with async fetch
Closes#3789, #6503
Icon setting when no custom icon is set yet:
- `Change...` button opens a file dialog, and after selecting a file shows the chosen icon in the preview on the left. `Submit` must be clicked after selecting the icon.
- `Reset to default` changes the preview icon to the default one, and also requires `Submit` to be clicked to apply the changes.
Full list of changes:
- CSP now includes `blob:` in `img-src` for
- `indexAction()` and `feedAction()` in `subscriptionController.php`
- all of the view actions in `indexController.php`
- Introduce new attribute `customFavicon (boolean)` for feeds that indicates if the feed has a custom favicon
- `hashFavicon()` in `Feed.php` is dependent on this attribute
- `hashFavicon()` has a new parameter called `skipCache (boolean)` that allows the reset of the favicon hash for the Feed object
- `resetFaviconHash()` just calls `hashFavicon(skipCache: true)`
- `f.php` URLs now have the format of `/f.php?h=XXXXX&t=cachebuster`, where the `t` parameter is only used for serving custom favicons
- if `t` parameter is set, `f.php` returns a `Cache-Control: immutable` header
- `stripos` and `strpos` were changed to `str_contains` in various places (refactor)
- JS for handling the custom favicon configuration logic is in `extra.js` inside `init_update_feed()` which is called when feed configuration is opened from the aside or when the subscription management page with the feed is loaded
- Server-side code for uploading the icon in `subscriptionController.php` under `feedAction()`
- Errors that may occur during the setting of a custom favicon:
- Unsupported image file type (handled only server-side with `isImgMime()`)
- When the file is bigger than 1 MiB (default), handled both client-side and server-side
- Standard feed error when `updateFeed()` fails
- JS vars `javascript_vars.phtml` are no longer escaped with `htmlspecialchars()`, instead with json encoding,
- CSS for disabled buttons was added
- Max favicon file size is configurable with the `max_favicon_upload_size` option in `config.php` (not exposed via UI)
- Custom favicons are currently deleted only when they are either reset to the default icon, or the feed gets deleted. They do not get deleted when the user deletes their account without removing their feeds first.
- ` faviconPrepare()` and `faviconRebuild()` are not allowed to be called when the `customFavicon` attribute is `true`
- New i18n strings:
- `'sub.feed.icon' => 'Icon'`
- `'sub.feed.change_favicon' => 'Change…'`
- `'sub.feed.reset_favicon' => 'Reset to default'`
- `'sub.feed.favicon_changed_by_ext' => 'The icon has been set by the <b>%s</b> extension.'`
- `'feedback.sub.feed.favicon.too_large' => 'Uploaded icon is too large. The maximum file size is <em>%s</em>.'`
- `'feedback.sub.feed.favicon.unsupported_format' => 'Unsupported image file format!'`
- Extension hook `custom_favicon_hash`
- `setCustomFavicon()` method
- `resetCustomFavicon()` method
- `customFaviconExt` and `customFaviconDisallowDel` attributes
- example of usage: https://github.com/FreshRSS/Extensions/pull/337
- Extension hook `custom_favicon_btn_url`
- Allows extensions to implement a button for setting a custom favicon for individual feeds by providing an URL. The URL will be sent a POST request with the `extAction` field set to either `query_icon_info` or `update_icon`, along with an `id` field which describes the feed's ID.
* Implement loading spinner for marking as favorite
* Ensure that the correct previous icon gets set
* Remove delay
* Improve compatibility with various parsers
Co-authored-by: Alexandre Alapetite <alexandre@alapetite.fr>
* Support multiple icons (top, bottom)
* Remove preload for now
* Fix CSS, remove !important
* Implement read/unread and alt
* Ensure correct bookmark icon gets set after error
---------
Co-authored-by: Alexandre Alapetite <alexandre@alapetite.fr>
* add shortcut in config
* open my labels menu with shortcut
* the first 9 items are selectable + input field
* i18n
* Update app/i18n/nl/conf.php
Co-authored-by: Frans de Jonge <fransdejonge@gmail.com>
* index.menu.mylabels
* order fixed
---------
Co-authored-by: Frans de Jonge <fransdejonge@gmail.com>
Add option to sort results by received date (existing, default), publication date, title, URL (link), random.
fix https://github.com/FreshRSS/FreshRSS/issues/1771
fix https://github.com/FreshRSS/FreshRSS/issues/2083
fix https://github.com/FreshRSS/FreshRSS/issues/2119
fix https://github.com/FreshRSS/FreshRSS/issues/2596
fix https://github.com/FreshRSS/FreshRSS/issues/3204
fix https://github.com/FreshRSS/FreshRSS/issues/4405
fix https://github.com/FreshRSS/FreshRSS/issues/5529
fix https://github.com/FreshRSS/FreshRSS/issues/5864
fix https://github.com/FreshRSS/Extensions/issues/161
URL parameters:
* `&sort=id` (current behaviour, sorting according to newest received articles)
* `&sort=date` (publication date, which is not indicative of how new an article is)
* `&sort=title`
* `&sort=link`
* `&sort=rand` (random order - which disables infinite scrolling, at least for now)
combined with `&order=ASC` or `&order=DESC`
## Implementation notes
The sorting criteria by *received date* (id), which is the default, and which was the only one before this PR, is the one that has the best sorting characteristics:
* *uniqueness*: no entries have the exact same received date
* *monotonicity*: new entries always have a higher received date
* *performance*: this field is efficiently indexed in database for fast usage, including for paging (indexing could also be done to other fields, but with lower effective performance)
In contrary, sorting criteria such as by *publication date*, by *title*, or by *link* are neither unique nor monotonic. In particular, multiple articles may share the same *publication date*, and we may receive articles with a *publication date* far in the future, and then later some new articles with a *publication date* far in the past.
To understand why sorting by *publication date* is problematic, it helps to think about sorting by *title* or by *link*, as sorting by *title* and by *publication date* share more or less the same characteristics.
### Problem 1: new articles
New articles may be received in the background after what is shown on screen, and before the next user action such as *mark all as read*. Due to the lack of *monotonicity* when sorting by e.g. *publication date* or *title*, users risk marking as read a batch of articles containing some fresh articles without seeing them.
Mitigation: A parameter `idMax` tracks the maximum ID related to a batch of actions such as *mark all as read* to exclude articles received after those that are displayed.
### Problem 2: paging / pagination
When navigating articles, only a few articles are displayed, and a new "page" of articles needs to be received from the database when scrolling down or when clicking the button to show more articles. When sorting by e.g. *publication date* or *title*, it is not trivial to show the next page without re-showing some of the same articles, and without skipping any. Indeed, views are often with additional criteria such as showing only unread articles, and users may mark some articles as read while viewing them, hereby removing some articles from the previous pages. And like for *Problem 1*, new articles may have been received in the background. Consequently, it is not possible to use `OFFSET` to implement pagination (so the patches suggested by a few users were wrong due to that, in particular).
Mitigation: `idMax` is also used (just like for *Problem 1*) and a *Keyset Pagination* approach is used, combining an unstable sorting criterion such as *publication date* or *title*, together with *id* to ensure stable sorting. (So, 2 sorting criteria + 1 filter criteria)
See e.g. https://www.alwaysdeveloping.net/dailydrop/2022/07/01-keyset-pagination/
### Problem 3: performance
Sorting by anything else than *received date* (id) is doomed to be slow(er) due to the combination of 3 criteria (see *Problem 2*). An `OFFSET` approach (which is not possible anyway as explained) would be even slower. Furthermore, we have no SQL index at the moment, but they would not necessarily help much due to the multiple sorting criteria needed and involving some `OR` logic which is difficult to optimise for databases.
The nicest syntax would be using tuples and corresponding indexes, but that is poorly supported by MySQL https://bugs.mysql.com/bug.php?id=104128
Mitigation: a compatibility SQL syntax is used to implement *Keyset Pagination*
### Problem 4: user confusion
Several users have shown that they do not fully understand the difference between *received date* and *publication date*, and particularly not the pitfalls of *publication date*.
Mitigation: the menus to mark-as-read *before 1 day* and *before 1 week* are disabled when sorting by anything else than *received date*. Likewise, the separation headers *Today* and *Yesterday* and *Before yesterday* are only shown when sorting by *received date*.
Again here, to better understand why, it helps to think about sorting by *title* or by *link*, as sorting by *title* and by *publication date* share more or less the same characteristics.
* [ ] We should write a Q&A and/or documentation about the problems associated to *sorting by publication date*: risks of not noticing new publication, of inadvertently marking them as read, of having some articles with a date in the future hanging at the top of the views (vice versa when sorting in ascending order), performance, etc.
### Problem 5: APIs
Sorting by anything else than *received date* breaks the guarantees needed for a successful synchronisation via API.
Mitigation: sorting by *received date* is ensured for all API calls.
For some browsers (I tested desktop Edge and mobile Safari), setting document.scrollingElement.scrollTop to zero does not seem to be enough to reset the scroll position at start. Setting history.scrollRestoration = 'manual' seems to fix it for these browsers.
Firefox seems to work without this fix but works also with it.
