Copying a mailto hyperlink should unescape HTML-escaped characters
Reported by
hol...@g.plan.io,
Dec 3
|
||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.77 Safari/537.36 Steps to reproduce the problem: Given an anchor with a mailto link with an email address containing hex-escaped characters (in this case, an escaped + character): <a href="mailto:foo%2Bbar@example.com">Mail link<a> When using the "Copy email address" menu item of the context menu of this link, the copied address is still HTML-escaped and is verbatim: foo%2Bbar@example.com What is the expected behavior? The escaped characters should be expanded so that the email address is copied as foo+bar@example.com instead. What went wrong? The copied email address contains HTML-encoded characters when they should be unescaped on copy. Did this work before? N/A Chrome version: 70.0.3538.77 Channel: n/a OS Version: OS X 10.13.6 Flash Version:
,
Dec 7
I can repro this on Linux as well. To desktop UI triage!
,
Dec 7
not really DataTransfer, so dropping that component Looks like the logic would be in WriteURLToClipboard in chrome/browser/renderer_context_menu/render_view_context_menu.cc - maybe de-escape before calling ASCIIToUTF16 ? CC-ing relevant owners
,
Dec 11
,
Jan 4
,
Jan 7
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/7a142ee78e057f46ca64b0ad5c8a1a6aa750b91b commit 7a142ee78e057f46ca64b0ad5c8a1a6aa750b91b Author: Dana Fried <dfried@chromium.org> Date: Mon Jan 07 19:44:30 2019 Unescape email addresses when copied via the context menu. A bug from 2008 caused the context menu to copy the fully URL-encoded email address for compatibility with non-Unicode software. However, it is now 2018 and we're copying to the clipboard as UTF16 anyway so it makes much less sense to avoid decoding characters (especially since URL-encoded Unicode characters are non-human-readable so it's hard to figure out what the email address even is. This also fixes the problem where a mailto: address gets URL-encoded and there's a + sign in it, which becomes %2D, again obscuring the fact that it's an address + tag (at least in Gmail). Bug: 911139 Change-Id: Ibedc95f4784512282e89f7472c85f51cefae5b21 Reviewed-on: https://chromium-review.googlesource.com/c/1395152 Reviewed-by: Avi Drissman <avi@chromium.org> Reviewed-by: Peter Kasting <pkasting@chromium.org> Commit-Queue: Dana Fried <dfried@chromium.org> Cr-Commit-Position: refs/heads/master@{#620430} [modify] https://crrev.com/7a142ee78e057f46ca64b0ad5c8a1a6aa750b91b/chrome/browser/renderer_context_menu/render_view_context_menu.cc [modify] https://crrev.com/7a142ee78e057f46ca64b0ad5c8a1a6aa750b91b/chrome/browser/renderer_context_menu/render_view_context_menu.h [modify] https://crrev.com/7a142ee78e057f46ca64b0ad5c8a1a6aa750b91b/chrome/browser/renderer_context_menu/render_view_context_menu_unittest.cc [modify] https://crrev.com/7a142ee78e057f46ca64b0ad5c8a1a6aa750b91b/components/url_formatter/url_formatter.cc [modify] https://crrev.com/7a142ee78e057f46ca64b0ad5c8a1a6aa750b91b/components/url_formatter/url_formatter.h [modify] https://crrev.com/7a142ee78e057f46ca64b0ad5c8a1a6aa750b91b/components/url_formatter/url_formatter_unittest.cc
,
Jan 9
|
||||||
►
Sign in to add a comment |
||||||
Comment 1 by phanindra.mandapaka@chromium.org
, Dec 3