1226918 - New location bar UI takes away the possibility to see and copy the actual url of bookmark if user types keyword in urlbar

Status: NEW

(Firefox :: Address Bar, enhancement, P3)

Description

[arni2033]

>>>   My Info:   Win7_64, Nightly 45, 32bit, ID 20151119030404
STR:
(A)
1. Bookmark url "https://www.google.com/searchbyimage?image_url=%s" with keyword "gi"
2. Open new tab, type "gi https://i.imgur.com/DEHPlhG.png" in urlbar
3. Try to copy the actual url you're going to visit (including protocol)
(B)
1. Bookmark url "https://time.yandex.com/" with keyword "yt"
2. Open new tab, type "yt" in urlbar
3. Try to copy the actual url you're going to visit (including protocol)

Result:       
 With new UI that is impossible. Currently, to send the url to a friend, I have to visit it first.
 But if a bookmark implies a redirect, I have to open Library and search for that bookmark manually.

Expectations: 
 There should be an easy way to see and to copy the actuall url I'm going to visit

Note:
 While good old UI isn't killed completely, the desired behavior can be restored by switching pref
 browser.urlbar.unifiedcomplete -> false

Comment 1

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

Sorry, how did you could copy the url from the old UI? I can't find a way, if you were typing
"keyword something" you were shown a keyword result, the same way as currently, and there's no contextual menu...

Or do you mean copying on paper? (The use-cases here are so rare that I'm not sure it's a problem at all)

Comment 2

[arni2033]

Attachment: video 1 - this is how I was able to copy keyword URL using Old UI.webm

I hope this answers your question

Comment 3

[arni2033]

(I use "il" keyword to search image by url)
Note that using new UI I don't see the actual url I'm going to visit. Video also represents that.

Actually, there's a relatively easy solution for that (if the developers will approve it):
just to show the actual url as the second item in suggestions list:   "Visit <actual_url>"

Comment 4

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

Ah I see, when selecting the keyword entry we were filling the urlbar with the final url. The problem is that it was not done on purpose, it was sort of a grey area... So I don't know how we could support that in the new flow.
I don't think showing the url is something we plan to do, for various reasons:
1. we are moving towards a single line UX
2. it's a search operation and they don't show urls cause it's usually a pointless information for most users
3. The plan is to move keywords to search engines, at that point the url would be easily reachable from Preferences / Searches

I actually think the best fix is likely just wait for keywords to become custom searches, then it will be easy to copy the url from Preferences.

Comment 5

[arni2033]

(In reply to Marco Bonardo [::mak] from comment #4)
> 1. moving towards a single line UX
You mean, you're going to simply remove some capabilities and only leave those which require only 1 line? [keyword][space][input] may (and often does) match some items in history/bookmarks.
Are you going to delete those lines as well?
If not, then "1-line-UI" is impossible, so I can't see how second line with actual url could affect it
> just wait for keywords to become custom searches
This implies a long time period when user is (again) forced to use impaired UI
> then it will be easy to copy the url from Preferences
You mean, these steps will be easy and fast enough?
 1)  Click the searchbar, click "Change Search settings"  (to navigate from forum page to preferences)
 2)  Scroll down to the search engines table. 
 3)  Scroll the table itself, searching for desired engine (maybe not trivial for bookmarked searches)
 4)  Doubleclick a line   (I suppose?)
 5*) Copy that line, switch back to a chat/forum, paste that line
 6)  Go find the [input] string   (e.g. image link, in my case. Or string I copied from someone's post)
 7)  Go back to chat/forum, search "%s" in the line from Step 6, replace it with [input]
I marked Step 5 with (*), because that's what I'm going to do anyway, except that now I don't have to leave the web page with chat/forum.
Firefox is going to have so few advantages over Chrome soon (if any)   ._.

Comment 6

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

(In reply to arni2033 from comment #5)
> You mean, you're going to simply remove some capabilities and only leave
> those which require only 1 line?

No it will stay the same, urls will move to the right. Sill entries not having a url now, won't have an url in future as well.

> > then it will be easy to copy the url from Preferences
> You mean, these steps will be easy and fast enough?
>  1)  Click the searchbar, click "Change Search settings"  (to navigate from
> forum page to preferences)

urlbar will also have search settings button.
99% of the cases it will be fine to just copy the final url from the urlbar.
In those few cases where you want the non-redirected url, it wont' be that terrible to copy from search settings (and if it will be you may ask to add copy support to the list or such).

Comment 7

[arni2033]

> entries not having a url now, won't have an url in future as well
But some entries having a url now, won't have an url in future. I got it.
> It'll be fine to just copy the final url
So user has to visit the url in another tab, save it in (limited) History, losing time & traffic, and then copy it with all the garbage added by google.com.
I don't see why you called that 'fine'; I could _never_ agree. Perhaps you'd want to set low priority
for the future or something like that(?) because any discussions will not reduce the issue.
> and if it will be you may ask to add copy support to the list or such
This is basically why I filed this bug... I'm asking not_to_regress, so it's barely "enhancement" IMO

Comment 8

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

Fine we can go back looking at this when we have a new keywords ui

Comment 9

[avada]

This is a dupe of Bug 1222373.

Comment 10

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

(In reply to avada from comment #9)
> This is a dupe of Bug 1222373.

I'm duping he opposite cause here there are better STR.