1637408 - Copying an autosuggested URL does not include protocol

Status: VERIFIED FIXED

(Firefox :: Address Bar, defect, P3)

Description

[Asif Youssuff]

This has been annoying me for a while and I finally looked for a reliable STR to report.

Steps to reproduce:

1. Open https://musicbrainz.org
2. Open tab
3. Close original tab
4. type music and allow Firefox to autosuggest to musicbrainz.org/
5. Select all
6. Paste anywhere

What happens:

Protocol information (https://) is not included, making the pasted string much less useful to people receiving it in chat applications (since the URL is not clickable).

Expected result:

The copied string should be https://musicbrainz.org/ as it was previous to regression.

30:17.50 INFO: No more integration revisions, bisection finished.
30:17.50 INFO: Last good revision: 45856f355629679c4f8708fe4d1d97027aa58e8d
30:17.50 INFO: First bad revision: 202e520935200bc0ed6da749bc11673244f3089d
30:17.50 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=45856f355629679c4f8708fe4d1d97027aa58e8d&tochange=202e520935200bc0ed6da749bc11673244f3089d

Comment 1

[Marco Bonardo [:mak]]

according to the STR, we are in the pageproxystate != "valid" case, and the code is doing what it's supposed to do, by inspection.
We used _resultForCurrentValue before that of course had information about the origin of the value, but that method was not reliable when another page started loading because it was overridden already by _loadURL.
additionally the user could pick a url result, modify the text and then copy it, expecting a url, since it started from a url.
If the view is open, we could rely on the heuristic result.
When the view is closed, we don't know, we could try to still use _resultForCurrentValue, or pass the string to URIFixup, and if the only difference is the protocol use the fixup url.
I just noticed that in Chrome pressing ESC doesn't just close the view, but also reverts input to the current page, that way they don't have to deal with this problem!

Comment 2

[Marco Bonardo [:mak]]

I'll file a separate bug about the different ESC behavior across browsers since it's not completely related to the issue at hand.

Here we could probably use the currently selected result or heuristic result when the view is open, otherwise use a cached context or the URIFixup method to check if the string is potentially a url.

Comment 3

[Daisuke Akatsuka (:daisuke)]

Attachment: Bug 1637408: Append the protocol when copying if the urlbar value is autofilled

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/57d2786f4fd4
Append the protocol when copying if the urlbar value is autofilled r=adw

Comment 5

[Iulian Moraru]

https://hg.mozilla.org/mozilla-central/rev/57d2786f4fd4

Comment 6

[Ardelean Oana, Desktop Test Engineering [:oardelean]]

Reproducible on a 2023-09-03 Nightly build on macOS 12.
Issue is verified as fixed on Firefox 119.0b2(build ID: 20230927091517) and Nightly 120.0a1(build ID: 20230928035326) on macOS 12, Windows 10, Ubuntu 22, using only the following scenarios:

• Selection of the autocompleted string was done using either triple click( in order to select the whole url), or the Ctrl+A keyboard shortcut.
• Copying/Pasting the selection in a new tab/document using only Ctrl+C/Ctrl+V keyboard shortcuts.

If context menu options are used( Select All/Copy), protocol string is not copied. Paste and Paste all options seem to work as long as the string was copied and selected using the above mentioned scenarios.
I have opened bug 1855717 for the context menu specific issues.