Spinoff from bug 320402: When dragging a URL to the Bookmark Bar, often the pages have very long titles. Similar to what Safari does, we could pop up a sheet offering the user to rename it.
As a workaround, you can right/control-click the bookmark, choose "Get Info", and rename it from there.
Having something pop up like that could potentially be pretty annoying....
The main reason for this is that most pages have very long titles - often very much longer than you want it to be in your Bookmark Bar. Thus it's very natural to want to change the title before adding it. However, if you do want to add the page with the default title, you can just press enter when it asks to rename, so no real annoyance. Safari has this, so try it there and see.
I agree this would be annoying. I also agree this would be fairly trivial to implement. What we really need here is some guidance from Mike and Simon. :)
Command-drag to get the Rename dialog?
(In reply to comment #5) > Command-drag to get the Rename dialog? Aside from the fact that we'd be associating a totally new feature to the Command key and that this seems fairly undiscoverable, that sounds like a fine suggestion to me. I think we can fix the undiscoverable thing by documenting it somewhere. :) cl
*** Bug 348222 has been marked as a duplicate of this bug. ***
-> me. Anybody have a problem with cmd-drag to get the sheet?
Assignee: mikepinkerton → stridey
is cmd-drag used for any other drag modifiers (force copy, or an alias or something)? otherwise, it's fine, but totally undiscoverable.
No, cmd-drag isn't currently used. Here are some implementation details we need to think about: - Cmd-drag won't work for URL bar favicons, since it's reserved for getting rid of the toolbar item. - Do we want to be able to show the dialog when moving/copying existing bookmarks, or only when creating new ones? If the answer to the second is "No", then we could use option-drag, which would solve the first (and isn't currently being used for URL bar and tab favicons). Also a question: is it possible to drag multiple urls (non-existing bookmarks) to the bookmarks bar? There's support for it in the code, but I sure can't figure out how to do it. Obviously, this is something we need to think about when displaying a sheet. Also, I think we should consider making the dialog be default behavior, with the modifier key disabling it. I'd rather have the convenient shortcut for skipping the bookmark naming dialog be the totally undiscoverable behavior.
Status: NEW → ASSIGNED
(In reply to comment #10) > No, cmd-drag isn't currently used. > > Here are some implementation details we need to think about: > > - Cmd-drag won't work for URL bar favicons, since it's reserved for getting rid > of the toolbar item. Sure it will. That toolbar isn't a Cocoa toolbar, at least not in the sense that the "real" toolbar is. (I just checked this in a trunk nightly, and I can Command-drag anything I want in the bookmarks bar just fine.) cl
(In reply to comment #11) > Sure it will. That toolbar isn't a Cocoa toolbar, at least not in the sense > that the "real" toolbar is. (I just checked this in a trunk nightly, and I can > Command-drag anything I want in the bookmarks bar just fine.) No, "that toolbar" *is* the "real" toolbar. I'm talking about the site favicons that appear in the location bar.
Opt-drag won't work in content (not unless you hold down opt after you begin dragging, the same as cmd-drag for the favicons in the toolbar). I also think that the modifier should be required for invoking the sheet, and the default behavior should continue for unmodified drags.
It would be nice if this behaved in exactly the same way as adding a bookmark using command-d since the user is trying to achieve the same goal. These are different ways of doing the same thing and should be viewed as that so that we don't confuse anybody.
I like Desmond's idea. We could simply pop up the Add bookmark dialog with the title field prefilled... that would also make this bug very easily fixable.
(In reply to comment #15) > I like Desmond's idea. We could simply pop up the Add bookmark dialog with the > title field prefilled... that would also make this bug very easily fixable. You'd also have to remove the tab group box, and the location selector, or you'll be popping up a very over-engineered sheet. And in that case, the sheet behavior *really* better require a modifier. ;)
Given that it really doesn't need the same stuff as the cmd-D sheet (location, bookmark all tabs), and that it could be nice (and wouldn't be too crowded) to have keyword and description fields (like get info), I think a totally separate sheet would be nice. Either way though, that still leaves the original question, specifically, should it be default behavior, or should you have to hold a modifier? If so, what modifier? ie, it should be synchronized with what we do for bug 159230.
(In reply to comment #17) > Either way though, that still leaves the original question, specifically, > should it be default behavior, or should you have to hold a modifier? If so, > what modifier? ie, it should be synchronized with what we do for bug 159230. When you drag a bookmark into the bookmark bar you are trying to achieve the same goal as pressing command-d. Therefore, a sheet should pop-up as the default behavior to ask you to enter a title.
Please read the bug I just mentioned. What I'm saying is that cmd-D isn't necessarily going to pop up a sheet either.
Per status meeting, the default here should be no dialog. We still have the modifier conundrum though.
QA Contact: toolbars
Target Milestone: --- → Camino1.2
Is there a possibility that we could at least have a pref to control whether the default shows a dialog or not? I've renamed every single bookmark I've dragged to the toolbar in recent memory, and would definitely prefer having the dialog by default. Also, is there a related bug for Firefox? Would fixing this have any impact on Firefox? I don't want to make a new bug report if there's already one or it would be just as easy to fix both at once.
(In reply to comment #21) > Also, is there a related bug for Firefox? Probably. > Would fixing this have any impact on Firefox? No, almost certainly not, since the front-end UI is essentially two different browsers. cl
Mass un-setting milestone per 1.6 roadmap. Filter on RemoveRedonkulousBuglist to remove bugspam. Developers: if you have a patch in hand for one of these bugs, you may pull the bug back to 1.6 *at that point*.
Target Milestone: Camino1.6 → ---
You need to log in before you can comment on or make changes to this bug.