Inconsistent copy behaviour of IDN domains (Omnibox versus "Copy link address") |
||||||
Issue descriptionChrome Version: 60.0.3095.5 OS: Linux What steps will reproduce the problem? Consider these two links: a) https://xn--caf-dma.example.com/ b) https://café.example.com They are the same domain, just one is IDNA-encoded and the other is in Unicode. 1. Middle-click either of them to open in a new tab. (The Omnibox will always normalize so it appears as "https://café.example.com".) 2. Select the text in the Omnibox and hit Ctrl+C. 3. Paste into another application. 4. Now come back to the bug and this time, right-click on either of the links. [Edit: There is no way to make the second link clickable in crbug, but it's irrelevant since the href would be the same on both links anyway.] 5. Choose "Copy link address". 6. Paste into another application. What is the expected result? Consistency. Probably the correct behaviour is to copy the IDNA-encoded version, since that is a proper URL (as opposed to the Unicode version, which is user-readable but technically not a valid URL, at least according to RFC 3986; there are multiple competing URL specifications that disagree on this definition [1][2]). What happens instead? Step 3 (pasting from Omnibox) pastes in IDNA: https://xn--caf-dma.example.com/ Step 6 (pasting from Copy link address) pastes in Unicode: https://café.example.com The latter might be a Blink thing which explains the difference (historically, a WebKit thing). [1] https://www.ietf.org/rfc/rfc3986.txt [2] https://url.spec.whatwg.org/
,
May 14 2018
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
May 14 2018
,
May 14 2018
Still valid. Adding Blink>DataTransfer because that's listed as the component in Blink that deals with copy and paste issues. Ideally I think we'd always want right click -> "Copy Link Address" to always paste in IDNA, not unicode.
,
May 22 2018
I agree with #0 and #4 that "Copy link address" should copy the actual link address (rather than a Unicode representation of the address). i.e. regardless of what the Omnibox is doing, "Copy link address" should do what it says it's doing. I also agree with #0 that consistency is preferred. But if pressed, I'd find it more acceptable for Omnibox to copy as Unicode and "Copy link address" to copy the link address (i.e. the reverse of what is described). mpearson@ WDYT of removing the UI>Browser>Omnibox component?
,
May 22 2018
> mpearson@ WDYT of removing the UI>Browser>Omnibox component? I'm okay with that, but only after we know this handoff to the Blink folks has succeeded. I don't want to remove the component and then have this bug get lost in unmonitored oblivion.
,
May 22 2018
Yeah, now that I'm reading it in detail we can keep this as Blink>DataTransfer.
,
Jun 18 2018
|
||||||
►
Sign in to add a comment |
||||||
Comment 1 by mgiuca@chromium.org
, May 12 2017