Bugzilla

Comment 14

•

8 years ago

I think I need some help here.

As I understand it, there are currently 4 (?) places where bookmarks are viewed in a tree form:

1. Bookmarks sidebar
2. The inline picker when using the star icon. (I do know which files control this)
3. The bookmarks button right next to the star button.
4. The full fledged bookmark manager (THIS is where I want to work)

I tried using FF Devtools to inspect the bookmark manager but wasn't able to find any useful information apart from that the implementation for the functions live in treeView.js. There are some xul nodes with the 'type' attribute set to one of the '*.js' files in the places directory but that's it.

How do I go about finding where are the tree view is getting constructed from? How do I do about making the tree's nodes editable?

Sorry if I missed something obvious.

Flags: needinfo?(mak77)

Comment 15

•

8 years ago

Really sorry for being so dense. I am now able to edit the folder names by double clicking on the left pane in the bookmark manager using this diff.

diff --git a/browser/components/places/content/places.xul b/browser/components/places/content/places.xul
--- a/browser/components/places/content/places.xul
+++ b/browser/components/places/content/places.xul
@@ -338,20 +338,21 @@
 
   <hbox flex="1" id="placesView">
     <tree id="placesList"
           class="plain placesTree"
           type="places"
           hidecolumnpicker="true" context="placesContext"
           onselect="PlacesOrganizer.onPlaceSelected(true);"
           onclick="PlacesOrganizer.onPlacesListClick(event);"
           onfocus="PlacesOrganizer.updateDetailsPane(event);"
           seltype="single"
+          editable="true"
           persist="width"
           width="200"
           minwidth="100"
           maxwidth="400">
       <treecols>
         <treecol anonid="title" flex="1" primary="true" hideheader="true"/>
       </treecols>
       <treechildren flex="1"/>
     </tree>
     <splitter collapse="none" persist="state"></splitter>

So now I need to do the same for the nodes in the right pane (the actual bookmarks themselves). Then create a command and bind it to a key (F2). Am I right?

Flags: needinfo?(mak77)

Comment 20

•

3 years ago

I know this is a super old ticket (17 years!) ... is there still a chance that this will make it into Firefox in the future?

Comment 21

•

3 years ago

(In reply to Jan from comment #20)

I know this is a super old ticket (17 years!) ... is there still a chance that this will make it into Firefox in the future?

This is already in Firefox, just single click a bookmark and look at the bottom of the library window. You can change name, URL, tags, and keyword. There actually isn't any other way to change a bookmark from the library dialog. The "edit bookmark" dialog can only be opened from views in the main browser chrome

Comment 22

•

3 years ago

(In reply to Shane Hughes [:aminomancer] from comment #21)

This is already in Firefox, just single click a bookmark and look at the bottom of the library window. You can change name, URL, tags, and keyword. There actually isn't any other way to change a bookmark from the library dialog. The "edit bookmark" dialog can only be opened from views in the main browser chrome

There might be a misunderstanding here, I think the OP was referring to the bookmark sidebar (even though they wrote "bookmark manager" – in the Library it wouldn't make sense, as it's already possible as you pointed out). Also most of the subsequent comments are talking about the sidebar.
Should I open a new ticket, specifically referring to the bookmarks sidebar?

Updated

•

3 years ago

Summary: support inline editing of bookmark values → support inline editing of bookmark values in the bookmarks sidebar view

Comment 23

•

3 years ago

(In reply to Jan from comment #22)

Should I open a new ticket, specifically referring to the bookmarks sidebar?

No you're right, I misunderstood the request. So how would you think the feature should be implemented? It seems difficult to tack on inline editing to the bookmarks sidebar. I mean, single-click opens a bookmark, so that would have to go. It's conceivable that we could emulate the behavior of a file manager, wherein single-click does nothing but select an item, fast double-click opens an item, and slow double-click opens the inline text editor. Is that what you had in mind?

Comment 24

•

3 years ago

Yes, exactly, that's what I had in mind. I was thinking that from a UX perspective, the most intuitive would be that a slow double-click should open the inline text editor. That's what it does in many other applications.
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.

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.

Comment 25

•

3 years ago

Attached image example how it could look like.png — Details

Comment 26

•

3 years ago

•

Edited

(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.

Comment 27

•

3 years ago

(In reply to Shane Hughes [:aminomancer] from comment #26)
I see your points. I personally certainly wouldn't mind having to double click. But other browsers generally open bookmarks on a single click. Hence users might expect that to happen. But it might be worth a try

It could be implemented in Nightly behind an experimental pref without harming anything.
That sounds like a great first step, also to get more input from users.

Likewise, I think the context menu should have an item "Rename bookmark" right above "Edit bookmark"
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?
Yes, I was simply thinking that without renaming via slow double-click, having a rename context menu item would allow users still to implement a shortcut with their shortcut manager of choice. If this is implemented via slow double-click then that might not be necessary. It's just that the way it is currently there is no way around the pop-up window for editing bookmarks, which considerably slows down the workflow. Especially when creating a bookmark by dragging a link or a tab to the sidebar (which is super fast and convenient), the bookmark takes the name of the title of the site, which is often very long and not intuitive. Having to bring up the pop up menu for editing the entire bookmark just to rename it is tedious ... Inline editing would be a game changer.

That actually brings up another idea: When dragging a link/tab to the sidebar to create a bookmark, Firefox could automatically suggest the user to rename it by opening the in-line text edit box ...

Comment 28

•

3 years ago

When I was working on this issue my intent was to do what file managers allow people to do on trees. i.e. if you select something you can press F2 (on Windows/Linux) or Enter (on MacOS) to trigger rename.

Obviously there are input boxes below the bookmarks in the Library window but that requires either mouse interaction or Tab-ing to the correct field. It's much easier to press F2/Enter and go along with the rename. A single click for rename doesn't make a lot of sense to me since it's easy to do by mistake and people don't expect single clicks to trigger actions.

IMO:

In the "Library" window (ala Bookmarks manager) inline editing (i.e. editing without having to click elsewhere) should be possible:
a. In the tree view on the left hand side (which shows just the folders)
b. In the list view on the right hand side (which shows both folders and bookmarks)
I don't care as much about the bookmarks sidebar for now but the solution should look similar.

See comment 14 and 15 here (starting at https://bugzilla.mozilla.org/show_bug.cgi?id=287137#c14) for more details from my investigation and ideas all those years ago.

Comment 29

•

3 years ago

•

Edited

(In reply to Ashhar Hasan from comment #28)

Obviously there are input boxes below the bookmarks in the Library window but that requires either mouse interaction or Tab-ing to the correct field. It's much easier to press F2/Enter and go along with the rename. A single click for rename doesn't make a lot of sense to me since it's easy to do by mistake and people don't expect single clicks to trigger actions.

Can you clarify what you mean by "A single click for rename"? Virtually all file managers and many other similar applications work as follows:

Single clicking an unselected item selects it. That is, nothing happens except the item you clicked is selected (highlighted).
Single clicking a selected item starts a timer (usually about 3 seconds), after which the input box opens up if no further mouse button or key is pressed. So the common way to edit a file name is to "slow double click" on the text. Since an item can't be selected without user interaction, this doesn't constitute a "single click." But it would also be possible to select an item with the keyboard, and then click it once to enter the text editor.
Double clicking an item, whether selected or not, within a certain interval, activates the item.

That's pretty universal behavior for decades, so it's definitely not unexpected. What to do on middle click or modifier + left click is something on which applications frequently disagree, so that's a separate issue. I think whatever we do with regular left clicks, the middle/modifier click behavior should be left as-is. That's easy enough to implement by using mousedown event handlers on treechildren for the 3 interactions I described above; but using click event handlers on tree for the middle/modifier click interactions.

In the "Library" window (ala Bookmarks manager) inline editing (i.e. editing without having to click elsewhere) should be possible:
a. In the tree view on the left hand side (which shows just the folders)
b. In the list view on the right hand side (which shows both folders and bookmarks)

I don't care as much about the bookmarks sidebar for now but the solution should look similar.

See comment 14 and 15 here (starting at https://bugzilla.mozilla.org/show_bug.cgi?id=287137#c14) for more details from my investigation and ideas all those years ago.

I started working on this earlier today. The components are substantially different now, mainly we're concerned with PlacesUIUtils.jsm and bookmarksSidebar.xhtml. Irrespective of that, the library window and the sidebar both use the places-tree element, so once the fundamental behavior is implemented, it can be applied to any places-tree that supports editing places nodes' string parameters. However, it's not a given that the solution for the bookmarks sidebar would be the same as that for the library, because the bookmarks sidebar currently implements very different click behavior.

F2 alone would go unnoticed by most users, and Enter would interfere with the current Enter behavior (which activates the bookmark item). And first you need to actually select an item. You can do that with the mouse in the library dialog, but not in the sidebar. So the click handler has to be changed to support mouse selection without activation.

It's easy to support F2 and there's no reason not to, but that alone doesn't resolve the bug because it's not that well-known and it's also not conventional on macOS. Enter is the key for activation, so it seems a mouse interaction is required. It's conceivable that on macOS we could have Enter to rename and Accel+Enter to activate, but that still leaves only the relatively obscure F2 on windows/linux. Not to mention that, in all the cases we're discussing, these keyboard shortcuts don't exist in a vacuum. They are like aliases for the more commonly used mouse interactions. So adding the keyboard shortcuts without the mouse behavior wouldn't be very intuitive.

A change to the mouse behavior is pretty disruptive so an experimental pref seems appealing.

Comment 30

•

3 years ago

(In reply to Shane Hughes [:aminomancer] from comment #29)

Can you clarify what you mean by "A single click for rename"?

Sorry for being unclear. I meant to agree with what you said. i.e. a quick single click or double click should NOT activate rename. Agreed with slow double click.

I think whatever we do with regular left clicks, the middle/modifier click behavior should be left as-is.

Agreed 100%.

F2 alone would go unnoticed by most users, and Enter would interfere with the current Enter behavior (which activates the bookmark item). And first you need to actually select an item. You can do that with the mouse in the library dialog, but not in the sidebar. So the click handler has to be changed to support mouse selection without activation.

Enter is special in MacOS land unfortunately and people expect it to trigger renames - I don't care about this though. Existing behaviour of Enter activating the bookmark makes perfect sense to me.

Good point about sidebar and it's challenges. Are the sidebar and the library dialog even sharing any code? Would it be easier to tackle both separately?

It's easy to support F2 and there's no reason not to, but that alone doesn't resolve the bug because it's not that well-known and it's also not conventional on macOS. Enter is the key for activation, so it seems a mouse interaction is required. It's conceivable that on macOS we could have Enter to rename and Accel+Enter to activate, but that still leaves only the relatively obscure F2 on windows/linux. Not to mention that, in all the cases we're discussing, these keyboard shortcuts don't exist in a vacuum. They are like aliases for the more commonly used mouse interactions. So adding the keyboard shortcuts without the mouse behavior wouldn't be very intuitive.

Agreed. I was pretty focused on my own personal usecase back when I tried to pick up this bug in college ~5 years ago.
Mouse behaviour must match to be discoverable and intuitive.

A change to the mouse behavior is pretty disruptive so an experimental pref seems appealing.

Doesn't this apply only to the sidebar?
For the library dialog I don't see any behaviour changing at all, single click to select, double click to activate. Only a new behaviour of slow double click to trigger rename would be added which is non-breaking.

BTW thanks for helping me get out of my slumber contributing to Firefox, I'll try to see if there's something I can help with now that I have more experience with software dev and debugging/archeology.