Closed Bug 170096 Opened 20 years ago Closed 10 years ago

File bookmarks without opening the "File bookmark..." window ("Add bookmark here" feature)

Categories

(SeaMonkey :: Bookmarks & History, enhancement)

x86
Linux
enhancement
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: psychonaut, Unassigned)

Details

(Whiteboard: [2012 Fall Equinox][Extension Fodder])

I'd like to be able to add bookmarks by simply navigating through the bookmarks
menu.  Each folder would have a meta-entry called "Add bookmark" at the bottom
which would add the current page to that folder.  Konqueror currently has
support for this feature.

This feature would obviate the need to open a separate window to file bookmarks,
as is currently the case.
Did you know that you can just drag the site icon (on the left side of the url
field) to the Personal Toolbar or any folder it contains (also Bookmarks)? This
way you get to choose the exact position for the bookmark.
I do now, thank you.  However, the fact that you can do this is very
non-obvious, at least compared to Konqueror's "add bookmark here" feature.
Resolving as invalid since Mozilla already has the ability to file bookmarks as
stated in comment #1.
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → INVALID
I'd like to see this request reconsidered, since I feel that the method proposed
by Ere has a couple of problems associated with it.  They stem from the fact
that to add bookmarks in that way, one needs to drag the location icon with the
mouse.  First, many people find navigating cascading menus difficult enough
without having to keep the mouse button pressed.  (I'm sure we've all had a
recently-opened cascade menu frustratingly disappear on us because we clipped
the corner between the menu and its parent rather than making the prerequisite
90-degree turn with the mouse.)  Second, there's no easy way of using the
click-and-drag method via keyboard navigation.

Another good justification for having an "Add bookmark" option in each folder is
because many people want to review their current bookmarks before adding a new
bookmark (for example, to make sure that they are not adding a duplicate
bookmark, or to verify that the folder is appropriate for the bookmark).  Since
the "File bookmark" window displays only folders and not the bookmarks
themselves, it does not allow this functionality.  The click-and-drag method
does allow this functionality, but only after making the user commit to some
course of action (i.e., adding a bookmark) which he may be forced to abort.

Finally, I reiterate that dragging the site's icon from the location bar is not
an obvious way of creating a bookmark.  Few users are going to realize that it
is possible to do this unless someone tells them about it.  I'm not suggesting
that that feature be removed; just that an alternative way of adding bookmarks
be added for ease of use.
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
A similar RFE for Firebird, Bug 217490, has been WONTFIXED. However, here the
situation is a bit different, as we don't clutter the menu with "Open in tabs".

Leaving as UNCOFIRMED, appending “("Add bookmark here" feature)” to make this
bug easier to find.

Prog.
Summary: File bookmarks without opening the "File bookmark..." window → File bookmarks without opening the "File bookmark..." window ("Add bookmark here" feature)
this should be resolved as wontfix. need a UI czar to evaluate.
Status: UNCONFIRMED → NEW
Ever confirmed: true
was this 4xp?
Assignee: bugs → neil.parkwaycc.co.uk
In theory if we give ids to the appropriate bookmarks template menupopups then
an extension could come along and overlay the template thus automatically
generating "Add bookmark here" menuitems in each folder.
Product: Browser → Seamonkey
Assignee: neil → nobody
QA Contact: claudius → bookmarks
MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
Status: NEW → UNCONFIRMED
MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
Sorry--can't confirm on nightly build, but can confirm on Iceweasel 3.0.11 (in safe-mode under Debian Unstable).

I agree with comment 4: this long drag is slow, awkward, and prone to failure.  I do like that I can control where the bookmark goes, but that's moot if I want to have firefox automatically sort them.  "Add bookmark here" worked brilliantly in Galeon, and I miss it.
Confirmed with Firefox 3.5.2.  As there has been no activity on this RFE I think it's pretty safe to confirm.

There is one more source of extreme annoyance in the current method that Comment #4 did not mention:

I have a bookmarks toolbar under the URL toolbar.  Frequently when dragging a bookmark from the latter, I try to drag it into a bookmark close under the URL.  Just before the bookmark dropdown opens, a popup appears and occludes the target.  It says

"This website does not supply identity information."

I now cannot drag the bookmark to where I want it.  Grrrrrrrr.

This is not to say that the popup should be moved.  It is to say that forcing people to do long complex drags is stupid not only because it requires a great deal of careful mouseing on the part of the user but also because of any number of unforseen issues like interfering with popups.  Maybe popups could be disabled during a drag, but it's a shame that this one design decision requires behaviour changes throughout the product.  What about popups in add-ons?  In embedded apps?  etc...?  Other non-popup occlusions?  etc...

Thanks!
Status: UNCONFIRMED → NEW
Ever confirmed: true
I don't think that polluting folders with another useless item (same as Open all in Tabs) is good idea, second for WONTFIX this
Whiteboard: [2012 Fall Equinox][CLOSEME 2012-11-01 WONT?]
WONTFIX. This is extension Fodder. There are several "Add bookmark here" extensions for Firefox that could also be adapted to work in SeaMonkey
Status: NEW → RESOLVED
Closed: 20 years ago10 years ago
Resolution: --- → WONTFIX
Whiteboard: [2012 Fall Equinox][CLOSEME 2012-11-01 WONT?] → [2012 Fall Equinox][CLOSEME 2012-11-01 WONT?][Extension Fodder]
Whiteboard: [2012 Fall Equinox][CLOSEME 2012-11-01 WONT?][Extension Fodder] → [2012 Fall Equinox][Extension Fodder]
You need to log in before you can comment on or make changes to this bug.