Closed Bug 1416305 Opened 2 years ago Closed 2 years ago

copying from address bar gives back http url

Categories

(Firefox :: Address Bar, defect, P1)

58 Branch
defect

Tracking

()

RESOLVED FIXED
Firefox 59
Tracking Status
firefox59 --- fixed

People

(Reporter: thexvital, Assigned: mak)

References

Details

(Whiteboard: [fxsearch])

Attachments

(1 file)

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.
Component: Untriaged → Address Bar
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P2
Whiteboard: [fxsearch]
Duplicate of this bug: 1416969
Priority: P2 → P1
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.
Assignee: nobody → mak77
Status: NEW → ASSIGNED
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?
Attachment #8942891 - Flags: review?(adw) → review+
(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.
Pushed by mak77@bonardo.net:
https://hg.mozilla.org/integration/autoland/rev/f49f83a6971a
Copying a search suggestion from the address bar gives back an http url. r=adw
https://hg.mozilla.org/mozilla-central/rev/f49f83a6971a
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 59
You need to log in before you can comment on or make changes to this bug.