Closed
Bug 251491
Opened 21 years ago
Closed 19 years ago
Live bookmarks: Add menu item for main website (feed parent) (should link to home page)
Categories
(Firefox :: Bookmarks & History, enhancement, P3)
Firefox
Bookmarks & History
Tracking
()
RESOLVED
FIXED
Firefox 2 alpha2
People
(Reporter: gemma, Assigned: darin.moz)
References
Details
Attachments
(4 files)
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040714 Firefox/0.9.1+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040714 Firefox/0.9.1+
It would be useful to have a context menu item for livemark feeds that directs
the browser to the feed parent website. For example, browse to your feed folder,
check your favorite feed, right-click on the feed title (not necessarily the
indivdual posts), and be taken to the main website. Forum topic at
http://forums.mozillazine.org/viewtopic.php?t=99967 .
Reproducible: Didn't try
Steps to Reproduce:
Reporter | ||
Comment 1•21 years ago
|
||
And "right-click on the feed title (not necessarily the indivdual posts), and be
taken to the main website" should have been "right-click on the feed title (not
necessarily the indivdual posts), select the 'feed title home page' option, and
be taken to the main website." Oops.
Comment 2•20 years ago
|
||
Yeah, this is a serious problem. Right now you have to live bookmark the feed,
and then "normal"-bookmark the homepage. But you can't add normal bookmark items
to a live bookmark feed folder, so you have to store them separately in your
bookmarks.
I'll attach a screenshot of how I think this should be done. The feed's homepage
is simply added to the top of the list, with a separator before the feed items.
Comment 3•20 years ago
|
||
Comment 4•20 years ago
|
||
Confirming enhancement request.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 5•20 years ago
|
||
*** Bug 266441 has been marked as a duplicate of this bug. ***
Updated•20 years ago
|
Summary: Livemarks: Add menu item for feed parent website → Livemarks: Add menu item for main website (feed parent)
Assignee: vladimir → vladimir+bm
Comment 6•20 years ago
|
||
*** Bug 272449 has been marked as a duplicate of this bug. ***
Comment 7•20 years ago
|
||
*** Bug 273170 has been marked as a duplicate of this bug. ***
Comment 8•20 years ago
|
||
*** Bug 253732 has been marked as a duplicate of this bug. ***
Comment 9•20 years ago
|
||
*** Bug 274094 has been marked as a duplicate of this bug. ***
Comment 10•20 years ago
|
||
*** Bug 265754 has been marked as a duplicate of this bug. ***
Comment 11•20 years ago
|
||
*** Bug 280155 has been marked as a duplicate of this bug. ***
Comment 12•20 years ago
|
||
*** Bug 280887 has been marked as a duplicate of this bug. ***
Updated•20 years ago
|
Summary: Livemarks: Add menu item for main website (feed parent) → Live bookmarks: Add menu item for main website (feed parent) (should link to home page)
Comment 13•20 years ago
|
||
Comment 14•20 years ago
|
||
(attachment function should be integrated in main Bug filling page, to avoid
this problem :-)
Yes definitely a must have - the obvious case is when since your last visit you
notice multiple new posts, accessing directly the main page is a time saver...
Actually I almost always prefer to look at the main page, and look the live
bookmarks just to see if something is new and 'sounds intersting' - but then I
often ends up trying to look at it 'in context' that is in the main page.
I would propose a slightly different UI than what is proposed in comment #3.
The Live Bookmark folder name ('What do I know') acts as a normal bookmark: when
you click on it, the browser opens the page where the live bookmark has been
registered.
The reason is simple, when I look at the content of a live bookmark folder I
leave my pointer on the folder name and then the pop-up shows me the new item,
if I want to access the page I then just have to click - no need to move the
pointer...
Of course this may interfer with other implementation on non-window platform -
but hey this is a suggestion of what I think is an intuitive UI, unfortunately I
won't be able to implement it :-)
Thanks!
Comment 15•20 years ago
|
||
Correct me if I'm wrong but I think the backend for this is already there. I'm
not entirely sure of the structure of bookmarks.html, but if you open it and
click on what would be an RSS feed, it takes you to the site the feed is for.
This suggests firefox is recording the location of the page that you were on
when you created the livemark.
Comment 16•20 years ago
|
||
Yeah, bookmarks.html holds the feed's homepage as the href for each entry. A few
regular expressions would've been able to extract that in any case. However, we
still need to come to a consensus on how this is going to work, UI-wise. The
suggestion above won't make it in, it's confusing behaviour.
One thing to add: the image I attached a few months ago had the feed parent site
as the first entry in the live bookmark. It would be better to have it as the
last entry. Kottke.org's feed has had the same entry as the top post in one of
his feeds for the last month (promoting his fundraising drive), and it's really
distracting to have to read it again every time.
Comment 17•20 years ago
|
||
It's not quite as simple as "just use the href attribute that's there" since
there's no guarantee that you're on the home page for the feed when you add it
(individual weblog posts, mozilla.org with the feed for 'zine.org, things like
Reuters with a single page of feed links), and you need to have stored the last
good URL when a feed goes dark, in case they changed to a new URL. So every
successful parse has to see if the /channel/link is different than the bookmark
href, and rewrite it if it isn't.
Comment 18•20 years ago
|
||
Phil is right, it is not as simple as it seems on first sight - it has to be
'live'...
ross: can you explain why "The suggestion above won't make it in, it's confusing
behaviour."?
Maybe it is because you see the feed name as a bookmark directory - and clicking
on a bookmark directory does not do anything, thus you say it is confusing?
If it is the case, then consider that actually the feed is not a bookmark
directory, actually the 'normal' user won't see it like that, because, the
*icon* is different.
Actually the icon makes it look for the 'normal' user more like a bookmark (and
not like a bookmark directory) thus associating an action when we click on it
that is not 'opening the directory' seems to me (at least!) quite natural, and
that it goes to the feed source, well even more natural :-)
However I'm on windows, and it is possible that on other OS, we *need* to click
on the feed icon to see what are the entries (on windows it is a an onhover
action), in that case, yes indeed my proposal will be impossible to implement
accross browser and your proposal will be better in the sake of UI consistency.
Of course this does not solve the problems evoked by Phil...
Comment 19•20 years ago
|
||
*** Bug 290790 has been marked as a duplicate of this bug. ***
Assignee: vladimir+bm → nobody
Comment 20•19 years ago
|
||
*** Bug 315984 has been marked as a duplicate of this bug. ***
Comment 21•19 years ago
|
||
*** Bug 324051 has been marked as a duplicate of this bug. ***
Updated•19 years ago
|
Component: Bookmarks → Places
Priority: -- → P3
QA Contact: mconnor → places
Comment 22•19 years ago
|
||
I filed a duplicate (oops) bug (#324051) - it had this rough mockup attached.
Updated•19 years ago
|
Assignee: nobody → annie.sullivan
Updated•19 years ago
|
Target Milestone: --- → Firefox 2 alpha1
Updated•19 years ago
|
Target Milestone: Firefox 2 alpha1 → Firefox 2 alpha2
Comment 23•19 years ago
|
||
I think the mockup UI from 2006-01-19 15:29 PST is the best designed of them all.
Updated•19 years ago
|
Assignee: annie.sullivan → darin
Assignee | ||
Comment 24•19 years ago
|
||
This does the trick.
One issue:
A middle click on 'Open "Slashdot"' opens all feeds in tabs instead of just slashdot.org in a new tab.
Attachment #216595 -
Flags: review?(bugs)
Comment 25•19 years ago
|
||
If you don't want to do it here, that'll need a followup bug on the livemark-service to make siteURI actually useful, by parsing it from the feed - it's never been used for anything so it's never been a problem that adding a livemark from http://weblogs.mozillazine.org/darin/archives/003687.html will retain that URI for all time rather than changing it to the channel/link at the first (and every successful) parse.
Assignee | ||
Comment 26•19 years ago
|
||
Phil, I don't think I understand. What is wrong with the current value of siteURI?
Comment 27•19 years ago
|
||
I think Phil means that the feed itself can "update" the site URI after the initial addition of the Live Bookmark.
Comment 28•19 years ago
|
||
Attachment #216595 -
Flags: review?(bugs) → review+
Assignee | ||
Comment 29•19 years ago
|
||
Ah, that makes sense. And, the places annotation is not updated accordingly?
Assignee | ||
Comment 30•19 years ago
|
||
fixed-on-trunk, fixed1.8.1
Comment 31•19 years ago
|
||
The annotation isn't updated because we don't pay any attention to that part of the feed, which should have reminded me that we've got a fancy new feed parsing service coming, so you certainly don't want to rewrite the old parser here. Nevermind ;)
Comment 32•19 years ago
|
||
(In reply to comment #24)
> Created an attachment (id=216595) [edit]
> v1 patch
>
> This does the trick.
>
> One issue:
> A middle click on 'Open "Slashdot"' opens all feeds in tabs instead of just
> slashdot.org in a new tab.
Is there a followup bug for this issue? It's not what a user will expect. Is there any configuration for this in terms of tab behaviour?
Bryan
Assignee | ||
Comment 33•19 years ago
|
||
See bug 332260.
Comment 34•19 years ago
|
||
This fix appears to have broken adding a new livemark folder to the toolbar.
JavaScript error: , line 0: uncaught exception: [Exception... "Component returned failure code: 0x80040111 (NS_ERROR_NOT_AVAILABLE) [nsIAnnotationService.getAnnotationString]" nsresult: "0x80040111 (NS_ERROR_NOT_AVAILABLE)" location: "JS frame :: chrome://browser/content/places/toolbar.xml :: _rebuild :: line 132" data: no]
Comment 36•19 years ago
|
||
Is this bug's fixed1.8.1 keyword still accurate now that Places has been removed from that branch? (Has this fix been ported to the old Bookmarks system?)
Comment 38•19 years ago
|
||
Finally remembered to file bug 341972 for comment 25.
Comment 39•15 years ago
|
||
Bug 451915 - move Firefox/Places bugs to Firefox/Bookmarks and History. Remove all bugspam from this move by filtering for the string "places-to-b-and-h".
In Thunderbird 3.0b, you do that as follows:
Tools | Message Filters
Make sure the correct account is selected. Click "New"
Conditions: Body contains places-to-b-and-h
Change the action to "Delete Message".
Select "Manually Run" from the dropdown at the top.
Click OK.
Select the filter in the list, make sure "Inbox" is selected at the bottom, and click "Run Now". This should delete all the bugspam. You can then delete the filter.
Gerv
Component: Places → Bookmarks & History
QA Contact: places → bookmarks
You need to log in
before you can comment on or make changes to this bug.
Description
•