Closed Bug 256329 Opened 20 years ago Closed 16 years ago

Have Live Bookmark Loading.... feedback persist until finished

Categories

(Firefox :: Bookmarks & History, enhancement)

Product:
Firefox
Component:
Bookmarks & History
Version:
2.0 Branch
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: tracy, Unassigned)

Details

seen on Windows, Mac and Linux branch and trunk builds

-Set up Live Bookmark
-Right click that Live Bookmark
-In the context menu, select Refresh Live Bookmark

tested results:
no feedback about the Live Bookmark updating.  

expected results:
A small drop down feeback "Live Bookmarks Loading..." should persist until
update is complete.

Note: You can right click the Live Bookmark as it is updating to see the
feedback as expected to persist.
Hmm.. I'm not sure where you're suggesting the feedback appear?  If we were
cool, we could change the livemark folder's favicon to be some kind of loading
indicator, but I don't think we're that cool.

To see where the feedback appears now, run an update on a Live Bookmark that
takes  a while to load (www.livejournal.com).  As soon as you get the update
started, click back on the Live bookmark folder (except in the bookmarks menu).
Notice the loading messege.  To see how this works even better, open bookmarks
manager.  Open the Live Bookmark folder.  Then run an update on it. Notice the
loading messege appears here automatically.  
Hmm.. so the issue is that the "Live Bookmark Loading..." item doesn't get
displayed in the submenu of the bookmark, if it's accessed via the bookmarks menu?
Vlad, the menu should stay open is the bug. It doesn't. It collapses when you
say update. Then you have to reopen it to see that it's udating.
Specifically, it doesn't remain open in the Bookmarks Toolbar and Bookmarks
sidebar. I wouldn't expect this to work in the bookmarks menu.  This does work
in Bookmarks Manager.
Ah, then this is the same issue as bug 252124 (can't fix), and possibly bug
242412 for the sidebar issue.
Vlad, can we remove the "update" context menu item then? It's really quite
confusing to not see the results of clicking it like this.
(In reply to comment #7)
> Vlad, can we remove the "update" context menu item then? It's really quite
> confusing to not see the results of clicking it like this.

Hmm... is it really that confusing?  It seems perfectly normal to me that when
yo select a context menu item, something happens -- as with all the menus, the
menus disappear in this case, and your action occurs (which is to start the
refresh).  I haven't seen one bug or complaint on mozillazine that it's
confusing, though; and I honestly have no idea where else to put that command,
considering that it's going to be a relatively commonly-desired livemark action.
Can you make the folder icon animate or something? Maybe I'm just a cook. This
feels odd to me. If no one else is complaining then we can just close this.
*complains*

It's not much use choosing to update the sub-items of a menu that you're looking
at and then having the whole thing disappear so you have to traverse your
bookmarks again. That's like pressing "Get New Messages" and having your inbox
close.

However, admittedly as this is a menu, it is harder to come up with a reasonable
alternative. Menus shouldn't persist after being clicked.

One, possibly contentious suggestion would be to refresh each live bookmark
automatically before they appear on screen, and ditch the update live bookmark
menu item altogether. Hover over the 'mark's feed name (e.g. Planet Mozilla),
and have the "about:livemark-loading" (sic: bug 254556) menu item appear. This
does sort of negate the ability of caching the feed. This could be augmented by
Vlad's idea of displaying the loading throbber beside the feed name as at the
top of a loading tab, and then dynamically updating the feed's contents when new
items are discovered.

This is similar to the way the bookmark manager and sidebar work now, removing
all entries before repopulating, except done automatically. You could perhaps
delay the update by half a second to ensure that the user does want to see the
latest entries (this time would be similar to the time taken to right-click and
choose update; time spent re-opening bookmarks disregarded...).

Since refreshing livemarks is such a common operation, this shouldn't cause too
many complaints. Some sort of timing mechanism would probably need to be brought
in as part of this though, like one update every 30 or 60 minutes (an
opportunity for Blake's machine learning!).
(In reply to comment #10)
> One, possibly contentious suggestion would be to refresh each live bookmark
> automatically before they appear on screen, and ditch the update live bookmark
> menu item altogether. Hover over the 'mark's feed name (e.g. Planet Mozilla),
> and have the "about:livemark-loading" (sic: bug 254556) menu item appear. This
> does sort of negate the ability of caching the feed. This could be augmented by
> Vlad's idea of displaying the loading throbber beside the feed name as at the
> top of a loading tab, and then dynamically updating the feed's contents when new
> items are discovered.

Sans loading throbber, this is what happens now -- if the feed needs to be
loaded or updated (based on a 30 min timeout), it will be loaded when it is
accessed.  If you hover over the live bookmark item, the "Loading" item will
disappear and the contents will show up when the loading finishes.  It only
disappears if you explicitly right-click and request a reload.. so maybe one
solution would be to just lower the default refresh time to, say, 5 minutes,
instead of 30 minutes?


(In reply to comment #11)
> Sans loading throbber, this is what happens now
Ah, excellent. That simplifies matters greatly. I hadn't noticed the automatic
loading.

> so maybe one solution would be to just lower the default refresh time to, say,
> 5 minutes, instead of 30 minutes?
This is not a good idea. If anything, the timeout should be *increased*. RSS
feeds are bandwidth-killers, and there's no way a feed needs to be updated every
few minutes. Even if we were honouring all of the mechanisms in place to stop
feeds being redownloaded all the time ( cf.
http://nick.typepad.com/blog/2004/05/rss_readers_and.html ), 30 minutes should
be considered the lowest bound the refresh should occur at.
Finding the happy medium is of course tricky, which is why I mentioned machine
learning; this would be a perfect candidate. As in the link references above,
FeedDemon, the leading Windows aggregator, refreshes only once every 3 hours.

Essentially, my thinking on this now would be to remove the "Refresh Live
Bookmark" context menu item. It is confusing. Thus, the bookmark menu, is just
that, a menu that you choose things from. And to manage your bookmarks (i.e.
force an update), you use the Bookmarks Manager or sidebar.
This isn't that important.  I am lowering severity to enhancement.  We don't
want to change the default refresh time for this or remove the ability to
refresh a Live Feed from the bookmarks toolbar.  The feedback that I was
requesting is there if the user clicks back on the Toolbar bookmark.  That's
good enough.

Vlad, if you think this is best as it is, please mark it won't fix.
Severity: normal → enhancement
I am having the same problem, It will not update
Assignee: vladimir → vladimir+bm
Assignee: vladimir+bm → nobody
sorry for bugspam, long-overdue mass reassign of ancient QA contact bugs, filter on "beltznerLovesGoats" to get rid of this mass change
QA Contact: mconnor → bookmarks
Live bookmark loading... message should be a static menuitem appearing when needed now, so WFM on 3.1
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → WORKSFORME
Version: unspecified → 2.0 Branch
You need to log in before you can comment on or make changes to this bug.