513064 - Edit this bookmark dialogue: Entering another known tag at the end of several tags, you cannot see what you are typing (autocomplete causes cursor position to disappear with many tags that exceed the length of the textbox)

Status: RESOLVED WORKSFORME

(Firefox :: Bookmarks & History, defect)

Description

[Thomas D. (:thomas8)]

When editing a bookmark's tags property in Edit this bookmark dialogue (from yellow star), as soon as the length of all entered tags exceeds the visible length of the tags textbox, and you enter another existing(!) tag, autocomplete will hide what you are currently typing (you have to type blindly), making it virtually impossible to add more existing tags to any bookmark. The user experience of this is very bad (--> severity: major).
(Sorry for the clumsy summary, but it's hard to describe)

Steps:

1.) click yellow star to edit this bookmark
2.) enter a couple of random new or existing tags (total length must exceed tags textbox length)
3.) enter another existing(!) tag after the tags that are there

Actual results
- Autocomplete causes tags textbox content to scroll back so that only the first tags are visible
- You cannot see what you are currently writing into the tags textbox
--> user is confused and virtually unable to enter any existing tags (most people don't like typing blindly)

Expected results
- Currently typed tag should always be visible (no matter if new or exsisting), so that user doesn't have to type blindly

Comment 2

[Maxwell]

Wouldn't this be a duplicate of Bug 505541?

Either way, Bug 513064 would not necessarily have needed to be submitted if a search found the previously posted Bug 505541.

I will also comment that Bug 505541 maybe should not be marked as "RESOLVED"? Though, I agree that one of these two need be marked "DUPLICATE".

Comment 3

[Thomas D. (:thomas8)]

(In reply to comment #2)
> Wouldn't this be a duplicate of Bug 505541?

Probably yes. It doesn't make much of a difference, though, because both of them have been submitted within a very short time frame of about a month, and both of them have reasonable summaries and descriptions.

> Either way, Bug 513064 would not necessarily have needed to be submitted if a
> search found the previously posted Bug 505541.

I wouldn't have submitted this bug had I found yours. Perhaps the spelling mistake in the current summary of bug 505541 spoiled it.

> I will also comment that Bug 505541 maybe should not be marked as "RESOLVED"?
> Though, I agree that one of these two need be marked "DUPLICATE".

"Resolved duplicate" doesn't mean that the duplicate bug has been "solved". It just means that a decision (resolution/"resolve") was taken that considers one bug a duplicate of the other, i. e. they are about the same issue. The duplicate bug will be closed and its issue will be dealt with in the remaining bug. Usually the younger bug is closed, but sometimes it isn't, blame it on intuition :) Let me know if you think your bug should live and we should make this bug the duplicate.

Comment 4

[Thomas D. (:thomas8)]

This is a daily workflow breaker for normal tagging, very annoying, very exposed.
Can we have some indication that devs are aware of this?

Comment 5

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

even if this is an annoyance we don't think it should block the release.

Comment 6

[Johnathan Nightingale [:johnath]]

(In reply to comment #5)
> even if this is an annoyance we don't think it should block the release.

I agree - would like very much to have this fixed, but we wouldn't hold the release if this were the last bug.

Comment 7

[Thomas D. (:thomas8)]

Maybe this could have a target milestone set?

Comment 8

[Shawn Wilsher :sdwilsh]

Not blocking for the same reasons in comment 6.

Comment 9

[Mark Banner (:standard8)]

The UX has changed here now, when autocomplete happens, it doesn't scroll back, and if anything scrolls more to the right. Therefore I think we can call this WFM now as we don't know what fixed it.