1416305 - copying from address bar gives back http url

Status: RESOLVED FIXED

(Firefox :: Address Bar, defect, P1)

Description

[thexvital]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:58.0) Gecko/20100101 Firefox/58.0
Build ID: 20171110100139

Steps to reproduce:

To reproduce this issue let's say I am typing "test" in the address bar or any word such as "Firefox"
-Using the arrow keys in the keyboard, find the exact search term that will lead into the search engine. (The term with Magnifying glass)
-Without adding anything else select all the term and copy it 
- paste it back to any notepad or to the address bar directly, the term becomes http://test/ or http://firefox/



Actual results:

The given copy and paste result is http://test/ or http://"search term/


Expected results:

Copying should always give the term written itself without the http:// part. 
Some users, like me, uses the address bar to get a neutral results from a text, and this makes it a bit harder.

Comment 1

[Marco Bonardo [:mak]]

It's a valid concern that should be investigated. We have code adding back http when a full url is selected, but should not act on this case.

Comment 3

[Brian Birtles (:birtles)]

See also duplicate bug 1416969 where a user is using the search suggestions as a spell checker--a habit they apparently picked up from using Chrome where this works as expected.

Comment 4

[Marco Bonardo [:mak]]

Attachment: Bug 1416305 - Copying a search suggestion from the address bar gives back an http url.

Review commit: https://reviewboard.mozilla.org/r/213160/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/213160/

Comment 5

[Drew Willcoxon :adw]

Comment on attachment 8942891 [details]
Bug 1416305 - Copying a search suggestion from the address bar gives back an http url.

https://reviewboard.mozilla.org/r/213160/#review219042

Thanks, this will be nice to have fixed.

The patch is fine, but I think this check should come later, right before the URI fixup, here: https://dxr.mozilla.org/mozilla-central/rev/21ddfb9e6cc008e47da89db50e22697dc7b38635/browser/base/content/urlbarBindings.xml#1013

A couple reasons:

(1) Let selection checks happen first because, when not all the text is selected, in no case do we want to copy/return anything other than the selected portion.

(2) In this case we want to skip the URI fixup specifically (and the subsequent makeURIReadable(), etc.).

Also, I wonder whether there are other cases/actions where we may want to skip fixup.  The only other such action I see is `extension`.  It's conceivable that an extension could autocomplete a single word that uriFixup will fix up, right?

Comment 6

[Marco Bonardo [:mak]]

(In reply to Drew Willcoxon :adw from comment #5)
> Also, I wonder whether there are other cases/actions where we may want to
> skip fixup.  The only other such action I see is `extension`.  It's
> conceivable that an extension could autocomplete a single word that uriFixup
> will fix up, right?

A WebExtension can return anything, a url-like or a string, thus I'm not sure how to distinguish, in the case of search suggestions we explicitly decided to filter out url-like entries, that simplifies the decision task.

Comment 7

[Marco Bonardo [:mak]]

Comment on attachment 8942891 [details]
Bug 1416305 - Copying a search suggestion from the address bar gives back an http url.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/213160/diff/1-2/

Comment 8

[Marco Bonardo [:mak]]

Comment on attachment 8942891 [details]
Bug 1416305 - Copying a search suggestion from the address bar gives back an http url.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/213160/diff/2-3/

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/f49f83a6971a
Copying a search suggestion from the address bar gives back an http url. r=adw

Comment 10

[Tiberius Oros[:tiberius_oros]]

https://hg.mozilla.org/mozilla-central/rev/f49f83a6971a