Troubleshooting technical issues is much easier when both the user and support agent practice clear communication. For this reason, we have provided the template below for you to fill out with information about your issue. Please provide as much detail as possible so we can most efficiently resolve your problem.
Brave Version: Version 1.95 (104) (not new to this version, don’t know when it started)
Mobile Device details: ios: 18.7.10, iphone-XS-Max (not new to this ios version, don’t know when it started)
BUG: The reader-view routinely/reproducably displays entirely wrong/inaccurate content: from the previous page (not the current page) in the browsing history.
WA: Usually just: toggle out of reader-mode, refresh the page, then re-enter reader-mode and all is well for that page.
Similar & simpler to do the refresh: click in the location-bar and hit return: you’ll accomplish a refresh and be in non-reader-mode.
I say “reproducable” but reader-mode as a whole is not rock-solid. Sometimes a page may not offer reader-mode, as though it is not supported, but will after a refresh. I’ve known reader-mode to truncate long pages too, but this I believe is not trivial/reliable to reproduce.
Apologies: The web-site to replicate the bug is known for adult content. (I’m reporting this bug for a friend.) The test-case URLs (below) are chosen for being categorized as “Non-[E]rotic” peotry or stories, but: the text could still have an adult nature, and original rendered page will still have banner-ads that are of an adult nature.
I assume other sites experience similar issues, but I don’t off-hand know of them.
Two varieties are shown. For each variety I give two URLs.
For both follow the event sequence (all in one/same tab, private-mode): Visit URL-1; SHRED site data; visit URL-1; visit URL-2, trigger reader-mode. Observe reader content is a match for URL-1, not URL-2.
Of course SHRED will close the starting tab of URL-1, so next step is from a new/empty tab; but post-shredding, the next transition from URL-1 to URL-2 and toggling reader mode are all done in one tab.
A: comparing reader mode of two unrelated pages.
URL-1: "THE BEGGERMAN" hxxps://www.lit[e]rotica[.]com/p/the-beggerman "the beggerman walks in..."
URL-2: "THE HOUSE" hxxps://www.lit[e]rotica[.]com/p/the-house-6 "Dark, vacant windows..."
B: comparing reader-mode for pages whose URL differ only in the query-string (using query-string to indicate a page#). You navigate to next page using arrow after list of pages below the body of text of that page (which adds the “?page=2” query-string to the URL).
URL-1: hxxps://www.lit[e]rotica[.]com/s/the-man-called-gideon "When I was a kid..."
URL-2: hxxps://www.lit[e]rotica[.]com/s/the-man-called-gideon?page=2 "He'd hoped that would be enough..."
What does happen (the bug):
For case-A URL-2 reader mode shows after the title the wrong text: “the beggerman walks in…”
For case-B URL-2 reader mode shows after the title the wrong text: “When I was a kid…”
EXPECTED: What should happen: In each case, as soon as URL-2 is shown, and reader-mode 1st invoked for that URL the accurate title and text of URL-2 should be rendered.
For case-A, URL-2 after the title: “Dark, vacant windows…”
For case-B, URL-2 after the title: “He’d hoped that would be enough…”
