121751 - Add ability to easily mark bookmarks to check for updates, like in 4.x

Status: RESOLVED DUPLICATE of bug 74627

(SeaMonkey :: Bookmarks & History, enhancement)

Description

[Joel Nelson (don't send email)]

Mozilla 5 does not make checking bookmarked pages for updates as 
easy as 4.x.   In 5 the properties panel for each bookmark has to be 
opened to set a schedule.   I would like to see it similar to 4.x where from 
the main Manage Bookmarks window I could just check something for 
each bookmark that would then flag the bookmark to be included in the 
Update Bookmarks routine.  (Having to open the properties panel for each 
bookmark you want to check for updates on when you have 150 
bookmarks is quite a hassle!)  Then make an option in Preferences for 
"automatically check selected bookmarks using schedule" or "manually 
update bookmarks".   In Netscape 4.7x I could do this and it worked just 
fine.   Now in Mozilla 5 beta I can't do this anymore.  I would like to see that 
feature included in Mozilla 5.

Comment 1

[xyzzy]

Reporter, can this be merged with the discussion in bug 74627?  If not, please
clarify the reasons why not.

Comment 2

[Joel Nelson (don't send email)]

Yes, I think it can be merged with 74627.

Comment 3

[Chris Lyon]

Marking as duplicate based on reporter's comment.

*** This bug has been marked as a duplicate of 74627 ***

Comment 4

[Nahor]

This bug is not fully similar to bug 74627.
This report talk about "Update bookmarks", like in 4.x which is not part of bug 
74627. This other bug is only about mass assignment of schedule checks, not 
forced manual checks.

Comment 5

[Joel Nelson (don't send email)]

Reopening due to comment by "Nahor".    Feel free to mark this once 
more as a duplicate if needed.

Comment 6

[Daniel Jensen]

"notify global immediately" == "update all bookmarks now"
These bugs are, in a way, interdependent- if you want to be able to force a
check instead of having a check by schedule, you need this bug fixed, and if you
want to be able to mark bookmarks in a way other than by modifying each one's
individual properties, you need the notify folder option. The individual
bookmark selection for update through just clicking on each bookmark you want
updated is a non-core issue here (though still, I guess, 4xp if you want to be
picky about it). I would propose breaking this bug into two parts, one for the
notify immediately option and one for the selection manner which the reporter
described. Then fixing this bug and bug 74627 would allow the update all
bookmarks behavior, and the other bug (for selecting a update behavior by just
selecting a number of bookmarks) would be an independent and presumably futured
p5 bug. However, the notify immediately option, this bug, and the setting folder
properties for global/directory notification, are definitely 4xp and should, in
my opinion, be in for moz1.0 (unless coding this ends up being a much harder job
than it looks).

Comment 7

[Nahor]

The "Update bookmarks" feature is already reported in bug 51207.

Comment 8

[Daniel Jensen]

In that case, this bug should be dependent on 51207.

Comment 9

[Andrew Hagen]

Unconfirmed bug. Milestone 1.0 --> future.

Confirming as enhancement request. Marking dependent on bug 51207. That bug is
also milestone future.

Comment 10

[Claudius Gayle]

I'd really prefer this bug remained a dupe of 74627. I believe between that bug
and bug 51207 we've got it covered. It's clear that there is a pending set of
enhancements wanted and necessary for bookmarks scheduling and notifications (it
really is all one feature). Let's minimize the bugs in order to focus and
coalesce  on the entire set of changes necessary to make this as effective(and
moreso) as it was in 4.x.

We're at a point where someone can begin to spec out(volunteers?) the exact set
of  necessary features to make this all work smoothly. Let's not get this all
muddled with separate enhancement request bugs for each individial little nit.

Let's stick with 74627, we can morph it a little bit if necessary to be more
inclusive in scope.

*** This bug has been marked as a duplicate of 74627 ***

Comment 11

[Nahor]

Too me it makes more sense to close this bug as a dup of bug 51207 instead of
bug 74627. And then you could close bug 51207 as a dupe of 74627 if you wish (as
also proposed in bug 51207#c13).