Closed Bug 1416305 Opened 2 years ago Closed 2 years ago
copying from address bar gives back http url
59 bytes, text/x-review-board-request
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.
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
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 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 email@example.com: https://hg.mozilla.org/integration/autoland/rev/f49f83a6971a Copying a search suggestion from the address bar gives back an http url. r=adw
You need to log in before you can comment on or make changes to this bug.