Bugzilla

(In reply to Jan from comment #24)
> That wouldn't necessarily mean that behavior of a single click (opening the bookmark) would have to change (which I don't think would be a good idea). A single-click (or the first click of the slow double-click) should still open the bookmark, while keeping the bookmark selected, and then a delayed second click should open an inline text editor.

Opening the bookmark on single-click but allowing further actions on double-click would significantly deviate from other aplications. That is, in every application I've seen where slow double-click does something, the primary action only happens on fast double-click, and single-click does nothing except focus/select the control. And that's a very reasonable scheme. Conversely, it seems less reasonable for single-click to perform an action that can change views when other interactions require further clicks on the same view.

I don't see a huge problem with moving the "open" behavior from single-click to double-click, since this is already how the main bookmarks places view (in the library dialog) works. It could be implemented in Nightly behind an experimental pref without harming anything.

> Likewise, I think the context menu should have an item "Rename bookmark" right above "Edit bookmark" 
> which also brings up the inline text editor,  while Edit bookmark should continue to bring up the pop up window where other attributes of the bookmark can be edited.  That way people could also assign their own shortcuts (for example cmd-click, or fn-click or something) to in-line edit the bookmark name.

Can you elaborate on that a bit? I'm not sure I see how adding a context menu item would allow people to create shortcuts. Do you mean with the aid of something like autohotkey?

As for your screenshot, yeah that's what I was expecting, as it's pretty easy to do this already because Firefox already has a tree input feature. The main problem is it's only used in trees that don't do anything on single-click except change selection.

(In reply to Jan from comment #24)
> That wouldn't necessarily mean that behavior of a single click (opening the bookmark) would have to change (which I don't think would be a good idea). A single-click (or the first click of the slow double-click) should still open the bookmark, while keeping the bookmark selected, and then a delayed second click should open an inline text editor.

Opening the bookmark on single-click but allowing further actions on double-click would significantly deviate from other aplications. That is, in every application I've seen where slow double-click does something, the primary action only happens on fast double-click, and single-click does nothing except focus/select the control. And that's a very reasonable scheme. Conversely, it seems less reasonable for single-click to perform an action that can change views when other interactions require further clicks on the same view.

Edit: Also, I think there are prefs that change the "where to open"  behavior to make bookmarks open in a new window. So that would mean single-click completely obscures the view and prevents further interaction. There might be some other more subtle problems I haven't considered, but the main issue even for the default prefs is that user doesn't want the bookmark to open (and thereby navigate the current tab or open a new tab, depending on prefs) when they're only trying to rename it. Making it _mandatory_ to launch a bookmark before you can rename it wouldn't produce a pleasant UX. I think I'd avoid it altogether if that was the case.

I don't see a huge problem with moving the "open" behavior from single-click to double-click, since this is already how the main bookmarks places view (in the library dialog) works. It could be implemented in Nightly behind an experimental pref without harming anything.

> Likewise, I think the context menu should have an item "Rename bookmark" right above "Edit bookmark" 
> which also brings up the inline text editor,  while Edit bookmark should continue to bring up the pop up window where other attributes of the bookmark can be edited.  That way people could also assign their own shortcuts (for example cmd-click, or fn-click or something) to in-line edit the bookmark name.

Can you elaborate on that a bit? I'm not sure I see how adding a context menu item would allow people to create shortcuts. Do you mean with the aid of something like autohotkey?

As for your screenshot, yeah that's what I was expecting, as it's pretty easy to do this already because Firefox already has a tree input feature. The main problem is it's only used in trees that don't do anything on single-click except change selection.

(In reply to Jan from comment #24)
> That wouldn't necessarily mean that behavior of a single click (opening the bookmark) would have to change (which I don't think would be a good idea). A single-click (or the first click of the slow double-click) should still open the bookmark, while keeping the bookmark selected, and then a delayed second click should open an inline text editor.

Opening the bookmark on single-click but allowing further actions on double-click would significantly deviate from other aplications. That is, in every application I've seen where slow double-click does something, the primary action only happens on fast double-click, and single-click does nothing except focus/select the control. And that's a very reasonable scheme. Conversely, it seems less reasonable for single-click to perform an action that can change views when other interactions require further clicks on the same view.

Edit: Also, I think there are prefs that change the "where to open"  behavior to make bookmarks open in a new window. So that would mean single-click completely obscures the view and prevents further interaction. There might be some other more subtle problems I haven't considered, but the main issue even for the default prefs is that user doesn't want the bookmark to open (and thereby navigate the current tab or open a new tab, depending on prefs) when they're only trying to rename it. Making it _mandatory_ to launch a bookmark before you can rename it wouldn't produce a pleasant UX. I think I'd avoid it altogether if that was the case. And there would certainly be a ton of bug reports from users thinking that is unintended behavior.

I don't see a huge problem with moving the "open" behavior from single-click to double-click, since this is already how the main bookmarks places view (in the library dialog) works. It could be implemented in Nightly behind an experimental pref without harming anything.

> Likewise, I think the context menu should have an item "Rename bookmark" right above "Edit bookmark" 
> which also brings up the inline text editor,  while Edit bookmark should continue to bring up the pop up window where other attributes of the bookmark can be edited.  That way people could also assign their own shortcuts (for example cmd-click, or fn-click or something) to in-line edit the bookmark name.

Can you elaborate on that a bit? I'm not sure I see how adding a context menu item would allow people to create shortcuts. Do you mean with the aid of something like autohotkey?

As for your screenshot, yeah that's what I was expecting, as it's pretty easy to do this already because Firefox already has a tree input feature. The main problem is it's only used in trees that don't do anything on single-click except change selection.