Closed Bug 387485 Opened 14 years ago Closed 3 years ago

Tag Editor


(Firefox :: Bookmarks & History, defect)

Not set



Tracking Status
blocking2.0 --- -


(Reporter: mano, Unassigned)



(Whiteboard: [places-ui])


(5 files, 3 obsolete files)

some notes from Alex on the tag editor:

I think we should start by trying to match the functionality of how
Apple deals with grouped sections of text, since it seems to work
really well.  Once we've prototyped that with xul, we can start
tweaking the behavior after playing around with it.

Here is a basic spec of the behavior I would like us to prototype:

Left and right arrows move the cursor between tags.

Hitting the backspace key selects the tag to the left of the
cursor, hitting it again deletes it.

Single clicking a tag selects it.

Double clicking a tag converts it back to selected text.

If a tag is in the text state and you create a new tag elsewhere, it
converts the text state tag back into the blue tag state.

Typing a new tag produces a drop down list of completions, the first
suggestion is filled out and selected.

Typing a comma or hitting enter creates the tag.

Hitting backspace when typing a new tag clears the selected area (as
expected) and also hides the current suggestions.

This field also has drag and drop functionality, but that isn't going
to be important for tagging since we are dealing with a single field.
Assignee: mano → swon
Here is a mockup of the ideal tag editor behavior, based on iteration 7 of the tagging and bookmarking UI.

See Dietrich's comment above for the text in the mockup.
Attached patch checkpt 2 (obsolete) — Splinter Review
Checkpoint 2.
Attachment #271578 - Attachment is obsolete: true
Blocks: 387748
Attached patch Checkpt 3 (obsolete) — Splinter Review
Another checkpoint.
Even though not perfect, most of the basic functionalities should be there other than autocomplete.
Attachment #273015 - Attachment is obsolete: true
Autocomplete can be done in a follow up IMO.
Flags: blocking-firefox3? → blocking-firefox3-
Whiteboard: [wanted-firefox3]
Attached patch PatchSplinter Review
This is still not perfect, but I think it covers most of the basic functionalities.

Mano, can I get some feedback on what's done so far and what needs to be added/fixed?
Attachment #273200 - Attachment is obsolete: true
Attachment #274546 - Flags: review?(mano)
Whiteboard: [wanted-firefox3] → [wanted-firefox3], [places-ui]
Assignee: stevewon → nobody
No longer blocks: 387748
Hey Mano.
Any update on the review?
Assignee: nobody → stevewon
I tried the patch with patches from bug#385609 & bug#387486.
When integrated into the bookmarks property dialog, the problem with editor extending too far is seems partially fixed. Height seems a little too short. I will attach a screenshot.

When integrated into the starring popup, the events don't seem to get caught correctly. I will attach the patch for that.

Screenshot of Starring Popup after replacing tags textbox with editor.
RE: Comment #12
The bottom input box is supposed to be the editor.
So, there's still a problem.
When testing this make sure to test out larger fonts, since we may eventually try to use the same type of tag editor field in a KUI:
Depends on: 394353
Target Milestone: Firefox 3 M8 → Firefox 3 M9
Assignee: stevewon → nobody
Target Milestone: Firefox 3 M9 → Firefox 3 M10
Target Milestone: Firefox 3 M10 → Firefox 3 M11
Version: unspecified → Trunk
Comment on attachment 274546 [details] [diff] [review]

Clearing review request until we can actually use the editor element in panels.
Attachment #274546 - Flags: review?(mano)
Are you still expecting to land the tag editor within the Firefox 3 timeframe? If so, before this lands, I'd like to put it through manual a11y testing to make sure we don't introduce a lot of SEC508 issues:

1. Is the focus properly transitioning from the editor to the popup list and back?
2. is the popup list navigable using Up and DownArrows, and are proper a11y events fired so the new selection can be recognized by ATs?

Flags: wanted-firefox3+
Whiteboard: [wanted-firefox3], [places-ui] → , [places-ui]
Whiteboard: , [places-ui] → [places-ui]
Reassigning to tjduavis at his request.
Assignee: nobody → tjduavis
Depends on: 413486
Target Milestone: Firefox 3 beta3 → ---
Assignee: tjduavis.opensource → nobody
Priority: -- → P2
Anything which can be done here for Firefox 3.1?
Flags: blocking-firefox3.1?
Currently I'm reorganizing all my bookmarks and tagging them. As what I can see it's hard to do this without the auto-complete feature. It would be great to have this feature in the next version of Firefox. It's already supported by a lot of other applications and we shouldn't miss that.

Shall we create a new bug for only this feature if the work on the tag editor will takes too long?
That's bug 415960, I'd think. In the meantime use the "tweez" extension!
Thomas, thanks for the information!
Depends on: 415960
Flags: wanted-firefox3.1+
Flags: blocking-firefox3.1?
Flags: blocking-firefox3.1-
Target Milestone: --- → Firefox 3.2a1
Flags: wanted-firefox3.2?
Flags: blocking-firefox3.2?
Target Milestone: Firefox 3.6a1 → ---
Flags: wanted-firefox3.6?
Flags: wanted-firefox3.6+
Flags: wanted-firefox3.5+
Dietrich; moved the nomination to Firefox 3.7, dunno if you want to mark this in some way that indicates that it's some nice visual polish that we'd like to see done.
blocking2.0: --- → ?
Flags: blocking-firefox3.6? → blocking-firefox3.6-
Bug 451915 - move Firefox/Places bugs to Firefox/Bookmarks and History. Remove all bugspam from this move by filtering for the string "places-to-b-and-h".

In Thunderbird 3.0b, you do that as follows:
Tools | Message Filters
Make sure the correct account is selected. Click "New"
Conditions: Body   contains   places-to-b-and-h
Change the action to "Delete Message".
Select "Manually Run" from the dropdown at the top.
Click OK.

Select the filter in the list, make sure "Inbox" is selected at the bottom, and click "Run Now". This should delete all the bugspam. You can then delete the filter.

Component: Places → Bookmarks & History
QA Contact: places → bookmarks
This is not a blocker for 1.9.3. I'd like to see this prototyped by an extension before determining if it's something we want in core. Definitely not blocking.
blocking2.0: ? → -
Removing uiwanted, faaborg's mockup seems to be a good direction — I'm unable to test the patch myself, but feel free to tag for ui-review of this, if there's a tryserver build (or even a screencast) showing how it works.
Keywords: uiwanted
Priority: P2 → --
Per policy at If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.
Closed: 3 years ago
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.