Open Bug 1226918 Opened 4 years ago Updated 2 years ago

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

Categories

(Firefox :: Address Bar, enhancement, P3)

enhancement

Tracking

()

Tracking Status
firefox45 --- affected

People

(Reporter: arni2033, Unassigned)

References

(Depends on 1 open bug, Blocks 1 open bug)

Details

(Whiteboard: [unifiedcomplete][fxsearch])

Attachments

(1 file)

>>>   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
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)
I hope this answers your question
(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>"
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.
(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)   ._.
(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).
> 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
Status: NEW → UNCONFIRMED
Ever confirmed: false
Fine we can go back looking at this when we have a new keywords ui
Severity: normal → enhancement
Status: UNCONFIRMED → NEW
Depends on: 648398
Ever confirmed: true
Has STR: --- → yes
Priority: -- → P3
Blocks: 1262507
This is a dupe of Bug 1222373.
(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.
Duplicate of this bug: 1222373
See Also: → 1327137
You need to log in before you can comment on or make changes to this bug.