Cannot turn off "Extract Full Content" if fetch blocked by site #2205
Replies: 2 comments
|
This sounds like a UX bug because changing the feed setting should not require a successful fetch. The safest behavior would be to write the disabled state immediately, without making a network request. When enabling full-content extraction, the app can attempt a fetch and keep the old state if the fetch fails, while showing the error. The Edit Feed screen should also expose the same toggle as a fallback, so a blocked site cannot make a feed setting impossible to change. The UI should make clear whether the setting is saved locally, and a failed refresh should not silently undo a deliberate setting change. Regression tests for a Cloudflare or offline response, disable while offline, retry after recovery, and feed sync or restore would cover the important cases. This keeps network availability from becoming a prerequisite for editing local configuration. |
|
Now that I think about it, I feel it would be better to add the full content setting to Edit Feed and make the button in the reader screen non-persistent (so it reverts to the "default" option after changing or exiting the article). Would be more convenient if extracting being blocked is due to a temporary issue (e.g. a website outage) instead of being "intentional". |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
If you turn on the "Extract Full Content" option for a feed where fetching is blocked by its website (e.g. due to Cloudflare), you cannot turn it off for the whole feed since pressing the button instead attempts to fetch the site again and the option saves for the whole feed (unless there is an article which does not block it).
The simplest solution would probably be to change the behaviour of the button so it instead turns off the option if the fetch fails and/or to allow you to toggle the option in "Edit Feed".
All reactions