Open
Bug 1185918
Opened 8 years ago
Updated 4 months ago
Bookmarking a page in Reader Mode links to Reader Mode instead of the URL shown in the URL-Bar
Categories
(Toolkit :: Reader Mode, defect, P2)
Tracking
()
NEW
People
(Reporter: designakt, Unassigned)
References
(Blocks 1 open bug)
Details
(Whiteboard: [reader-mode-firefox-integration])
Attachments
(2 files)
Bookmarking a page while in Reader Mode will result in not having bookmarked the actual page. Meaning as soon as you leave RM you will not see a blue star any longer.
Comment 1•8 years ago
|
||
Does this count as a bug or a feature? The user still have a way to get to the original page, by clicking the "Close Reader View" button. Would users prefer having the ability to bookmark a page in RM, or it is not intuitive enough to be useful for most?
Comment 2•8 years ago
|
||
(In reply to Wei-Yin Chen from comment #1) > Does this count as a bug or a feature? The user still have a way to get to > the original page, by clicking the "Close Reader View" button. Would users > prefer having the ability to bookmark a page in RM, or it is not intuitive > enough to be useful for most? I admit it's a bit confusing since the URL doesn't match what would be loaded if it were to be copy/pasted in to a fresh tab, but I think the behavior of storing the bookmark to the Reader Mode view is correct. If a user is reading a page using Reader View and then proceeds to bookmark it, when the user visits the bookmark later they should see what they were seeing when they bookmarked the page. That being said, we should do something about indicating if the page has been bookmarked even when they're not in the reader view. We could modify http://mxr.mozilla.org/mozilla-central/source/browser/base/content/browser-places.js#1496 to check both the about:reader prefix and sans-prefix, and mark the star if either of them match. Marco, what do you think about that?
Flags: needinfo?(mak77)
Reporter | ||
Comment 3•8 years ago
|
||
Yes, it would be nice if the user could return to what they originally bookmarked. Conceptual question there is what users think is being bookmarked: the content, the URL or the view. I assume it is the content, or for more technical users the URL, but not the view. Therefor the bookmark should direct to the page itself, not the view the page was in when bookmarking. When building reader view we decided to treat it as a view, much like zoom, page style or full-screen, none of which are represented in the bookmark. And if we would mark both, the reader view version, and the page itself with one bookmark, how would the user know which it is, or what to expect when clicking a bookmark? If we want to treat the reader view of a page like a bookmark-able object itself, we have to give it more "pageness", meaning an own URL (visibly) , and the ability to be accessible everywhere, not just in Firefox. Be part of the web, so to speak. (And possibly a prefix to the title to be identifiable.) Much like what pocket does as a web service. Currently in Reader View even our Share Plane is disabled because it is nothing that can be shared, which is strange as well as one would expect the article (not the view) to be shareable. (Bug 1188380) And sharing per mail produces a link that only works in Firefox which is not optimal either. (Bug 1188382)
Comment 4•8 years ago
|
||
(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #2) > We could modify > http://mxr.mozilla.org/mozilla-central/source/browser/base/content/browser- > places.js#1496 to check both the about:reader prefix and sans-prefix, and > mark the star if either of them match. Marco, what do you think about that? I think it's not so easy, cause that woul just update the star state, but then when clicking it, it would behave considering the current location and not the star state. that means clicking the starred icon would actually add a bookmark... it's generally dangerous to detach the indicator and the underlying code. Alternative solutions might be: 1. when the page is bookmarked in reader mode, bookmark both the page and the reader mode page. though this creates duplication 2. never bookmark reader mode, always bookmark the base url and always compare with the base url in all the code (this means updating not just the star state but also the panel code). Though the page won't reopen into reader-mode 3. 2, but also store a bookmark annotation stating the page should be opened in reader-mode, and handle it like Open in Sidebar (also adding a checkbox to the bookmark properties panel) This is sort of a shared question between engineering and UX. Markus said right, if these "things" should be handled as separate entities, they should have their own identity on the Web.
Flags: needinfo?(mak77)
Comment 5•8 years ago
|
||
(In reply to Marco Bonardo [::mak] from comment #4) > Alternative solutions might be: > 1. when the page is bookmarked in reader mode, bookmark both the page and > the reader mode page. though this creates duplication > 2. never bookmark reader mode, always bookmark the base url and always > compare with the base url in all the code (this means updating not just the > star state but also the panel code). Though the page won't reopen into > reader-mode > 3. 2, but also store a bookmark annotation stating the page should be opened > in reader-mode, and handle it like Open in Sidebar (also adding a checkbox > to the bookmark properties panel) Chrome on Android picked solution 2. Just providing a data point. BTW, it seems Firefox on Android grays out the star when inside reader mode. If we pick solution 2 here, it makes sense to re-enable it.
Reporter | ||
Comment 6•8 years ago
|
||
Some more data points on that: Comparing Firefox, Edge, Safari https://www.dropbox.com/sh/cpo6qsknp6ixyme/AABcO63_V5ToPDr9i7rvCPhja?dl=0 (Same content as attachment.) Firefox and Edge currently behave the same way, with the exception that the reader view URL is different. Edge only prefixes the URL with "reader:" which opens every shared link (on every Win 10 installation) in Edge and not the default browser. And Edge is very sloppy in indicating if a page is already bookmarked. Only if one opens Favorites the Star turns yellow, or if one tries to add a page again one will be prompted with "Update". Safari has a separate Reading List which preserves the state the page has been when added to reading list, but which will replace any other instance of this page in the Reading List despite the state. Besides Reading List Safari has Bookmarks which only store the page, not the state of the page. So even when bookmarked in Reader View, only the normal URL of the page will be saved. (In reply to Marco Bonardo [::mak] from comment #4) > 2. never bookmark reader mode, always bookmark the base url and always > compare with the base url in all the code (this means updating not just the > star state but also the panel code). Though the page won't reopen into > reader-mode > 3. 2, but also store a bookmark annotation stating the page should be opened > in reader-mode, and handle it like Open in Sidebar (also adding a checkbox > to the bookmark properties panel) Both options (2 & 3) seam reasonable to me. (2 is what Safari does with their Bookmarks, and 3 is what they are doing in Reading List.)
Comment 7•7 years ago
|
||
Feels like we should just have a single point in gBrowser that you can ask for the 'sharable' URL of a page that avoids giving out about:reader things (and could potentially modify other URLs?) that we use from bookmarks, the URL bar copy/paste code, the share/mail plane, etc.
See Also: → 1188382
Comment 8•7 years ago
|
||
(In reply to :Gijs Kruitbosch from comment #7) > Feels like we should just have a single point in gBrowser that you can ask > for the 'sharable' URL of a page that avoids giving out about:reader things > (and could potentially modify other URLs?) that we use from bookmarks, the > URL bar copy/paste code, the share/mail plane, etc. To be clear, that'd be solution #2 in comment #4 .
Priority: -- → P2
Updated•7 years ago
|
Whiteboard: [reader-mode-firefox-integration]
Updated•8 months ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•