Closed Bug 251491 Opened 20 years ago Closed 18 years ago

Live bookmarks: Add menu item for main website (feed parent) (should link to home page)

Categories

(Firefox :: Bookmarks & History, enhancement, P3)

Product:
Firefox
Component:
Bookmarks & History
Type:
enhancement

Tracking

()

Status:
RESOLVED FIXED
Milestone:
Firefox 2 alpha2

People

(Reporter: gemma, Assigned: darin.moz)

References

Details

Attachments

(4 files)

Mockup, with homepage heading the list of feed items
18.75 KB, image/png
Details
You click here and reach the BLOG main page
21.85 KB, image/gif
Details
Another rough UI mockup
46.13 KB, image/png
Details
v1 patch
6.50 KB, patch
bugs
: review+
Details | Diff | Splinter Review 
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:
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.
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.
Confirming enhancement request.
Status: UNCONFIRMED → NEW
Ever confirmed: true
*** Bug 266441 has been marked as a duplicate of this bug. ***
Summary: Livemarks: Add menu item for feed parent website → Livemarks: Add menu item for main website (feed parent)
Assignee: vladimir → vladimir+bm
*** Bug 272449 has been marked as a duplicate of this bug. ***
*** Bug 273170 has been marked as a duplicate of this bug. ***
*** Bug 253732 has been marked as a duplicate of this bug. ***
*** Bug 274094 has been marked as a duplicate of this bug. ***
*** Bug 265754 has been marked as a duplicate of this bug. ***
*** Bug 280155 has been marked as a duplicate of this bug. ***
*** Bug 280887 has been marked as a duplicate of this bug. ***
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)
(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!
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.
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.
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.
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...
*** Bug 290790 has been marked as a duplicate of this bug. ***
Assignee: vladimir+bm → nobody
*** Bug 315984 has been marked as a duplicate of this bug. ***
*** Bug 324051 has been marked as a duplicate of this bug. ***
Component: Bookmarks → Places
Priority: -- → P3
QA Contact: mconnor → places
Attached image Another rough UI mockup — 
I filed a duplicate (oops) bug (#324051) - it had this rough mockup attached.
Assignee: nobody → annie.sullivan
Target Milestone: --- → Firefox 2 alpha1
Target Milestone: Firefox 2 alpha1 → Firefox 2 alpha2
I think the mockup UI from 2006-01-19 15:29 PST is the best designed of them all.
Assignee: annie.sullivan → darin
Attached patch v1 patch — — Splinter Review 
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)
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.
Phil, I don't think I understand.  What is wrong with the current value of siteURI?


I think Phil means that the feed itself can "update" the site URI after the initial addition of the Live Bookmark. 
Ah, that makes sense.  And, the places annotation is not updated accordingly?
fixed-on-trunk, fixed1.8.1
Status: NEW → RESOLVED
Closed: 18 years ago
Keywords: fixed1.8.1
Resolution: --- → FIXED
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 ;)
(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
See bug 332260.
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]
I filed bug 332613 for the regression.
Depends on: 332613
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?)
I don't think this has been fixed in non-places.
Keywords: fixed1.8.1
Finally remembered to file bug 341972 for comment 25.
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.

Attachment

General

Creator:
Created:
Updated:
Size: