1227374 - It's not possible to set alternate keyword to a bookmark

Status: RESOLVED DUPLICATE of bug 1183362

(Firefox :: Bookmarks & History, defect)

Description

[arni2033]

>>>   My Info:   Win7_64, Nightly 45, 32bit, ID 20151120030227
STR:
1. Open https://time.yandex.com/
2. Right-click australis menu, click "Bookmarks toolbar"
3. Drag the tab with "yandex time" to bookmarks toolbar to get 1st bookmark
4. Drag the tab with "yandex time" to bookmarks toolbar to get 2nd bookmark
5. Right-click the 1st bookmark, click "Properties", set keyword "time" to the 1st bookmark
6. Right-click the 2nd bookmark, click "Properties", set keyword "yt"   to the 2nd bookmark
7. Right-click the 1st bookmark, click "Properties"

Result:       
 The 1st bookmark has keyword "yt"

Expectations: 
 The 1st bookmark should have keyword "time", because I carefully typed it in Step 5.

ESR 38 doesn't expose this issue; Dev.Edition 44 does. The workflow is broken.

Comment 1

[Ryan VanderMeulen [:RyanVM]]

Pretty easy to see in builds where this reproduces. Going into Step 6, the second bookmark already has "time" set as a keyword when you select Properties on it.

Regression range: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=4d2d97b3ba34&tochange=b8e628af0b5c

Looks like an intentional change from bug 1125113. Will leave it to Marco to confirm, though.

Comment 2

[Marco Bonardo [:mak]]

the problem is that the current keywords UI is completely broken, cause keywords are associated to URIs while the UI associates it to bookmarks.
What's happening here is "correct", since there's space for just 1 keyword, it will be the last one you set. To have different keywords for the same uri, they should have at least different POST data.

Comment 3

[arni2033]

(In reply to Marco Bonardo [::mak] from comment #2)
> What's happening here is "correct", since there's space for just 1 keyword,
1) So what is the suggested solution?
Chrome UI which you're obviously targeting does let uset to set alternate keywords. Also, currently
I'm able to set many keywords to any URL (apparently bug 1150678, so I don't have to report it). So:
 2) What will happen with all those "accidental" alternate keywords caused by 1150678 when it's fixed?
 3)  ...when users finally get brand new UI?
 4) What will happen with all my alternate keywords I _already_ have bookmarked when 1150678 is fixed?
 5)  ...when users get new UI?

Comment 4

[Marco Bonardo [:mak]]

(In reply to arni2033 from comment #3)
> I'm able to set many keywords to any URL (apparently bug 1150678, so I don't
> have to report it). So:
>  2) What will happen with all those "accidental" alternate keywords caused
> by 1150678 when it's fixed?

I don't care what Chrome does, they can do what they think is fine for their users.
I think we should not allow alternate keywords for the same URI, unless they differ by POST data.
Alternate keywords pointing to the same exact thing will likely be removed and only the last one retained. Doesn't sound like there are valid use-cases to have multiple aliases for the same exact target.

Comment 5

[arni2033]

> Doesn't sound like there are valid use-cases to have multiple aliases for the same exact target.
I use russian keyboard layout so it's very useful to type [keyword] in any layout, then change the layout if necessary, and continue typing a correct input
This is way better than typing the whole keyword again in the right locale. I guess that's valid.
Of course one could call the whole keyword concept "not a valid use-case" because user can just find a bookmark, copy its url and replace %s with another text...
> I don't care what Chrome does
Well, looking at what firefox has become, I can't help but agree. Nobody cares what Chrome does.
Thanks for answering, but other questions remain open: You only said that multiple keywords should not be allowed, but haven't mentioned how are you going to handle duplicates users already have right now.
What should be done by user to prevent data loss?

Comment 6

[Marco Bonardo [:mak]]

There's no way to prevent that "dataloss" if we decide to remove alternate keywords. It's a really weak dataloss case though, since it's basically "loss of duplicate data" and most of it could be rebuilt (for the user it's easier to remember a keyword he set, than an url). I know it's not a satisfying answer for you but we need compromises.

I will check if the technical reasons to disallow dupes are weak, we could just ignore the problem. Regardless we must have a second look at keywords to better merge the search feature with Search service keywords.

Comment 7

[arni2033]

(In reply to Marco Bonardo [::mak] from comment #6)
> I know it's not a satisfying answer
At least explicit answers help me make right decisions
Note that if I add an anchor to a url (e.g. https://ya.ru/#b1), I still can set a different keyword for that almost-the-same bookmark. I just need to fix those of my bookmarks which relied on anchors.
I hope that this complicated workaround will ever be available (aka "please, do not improve THAT")