Issue metadata
Sign in to add a comment
|
[Forum Prestable] Unable to paste text in Omnibox |
||||||||||||||||||||||
Issue descriptionUser comment : I brought this up to Google Chrome via Twitter and they tried to help me but all solutions have failed to work and they have asked me to post here. I am unable to paste anything into my Chrome address bar. Here is a video showing what happens when I try. This affects me on two different machines, my personal laptop and my work laptop (both running Windows, different versions, not sure which but one professional, one for home), which is owned by my employer. Video evidence You can see the video, which I tweeted to Chrome at: https://twitter.com/gavinesq/status/890605874741338113
,
Jul 27 2017
,
Jul 27 2017
Not a Blink issue.
,
Jul 27 2017
jainabhishek@, thank you for the report. I saw you've requested for chrome://version details through forum, so would be great if we get those details first.
,
Jul 28 2017
Got details from the user Google Chrome: 60.0.3112.78 (Official Build) (64-bit) (cohort: 60_78_win) Revision : f901216ec1e383df23283fec9bc8f4e8b67aa0fb-refs/branch-heads/3112@{#671} OS : Windows JavaScript : V8 6.0.286.44 Flash : 26.0.0.137 C:\Users\frittog1\AppData\Local\Google\Chrome\User Data\PepperFlash\26.0.0.137\pepflashplayer.dll User Agent : Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.78 Safari/537.36 Command Line : "C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --flag-switches-begin --flag-switches-end Executable Path : C:\Program Files (x86)\Google\Chrome\Application\chrome.exe Profile Path : C:\Users\frittog1\AppData\Local\Google\Chrome\User Data\Default Variations 98ee9f3e-98ee9f3e 241fff6c-4eda1c57 c68ab9a3-ca7d8d80 3095aa95-3f4a17df 6c43306f-ca7d8d80 7c1bc906-f55a7974 47e5d3db-3d47f4f4 1c752ce9-33c3eba5 d43bf3e5-ad6ab04f ba3f87da-b4a760c3 5ca89f9-ca7d8d80 f3499283-7711d854 9e201a2b-1359b0af 68812885-ca7d8d80 b791c1b8-ca7d8d80 9773d3bd-ca7d8d80 2e109477-f3b42e62 99144bc3-3cc2175e 9e5c75f1-ed8691fc f79cb77b-3d47f4f4 b7786474-d93a0620 27219e67-b2047178 23a898eb-e0e2610f d39326b0-d93a0620 e856c60b-ca7d8d80 4ea303a6-ecbb250e 7aa46da5-669a04e0 64224f74-5087fa4a 56302f8c-2f882e70 de03e059-e65e20f2 2697ea25-ca7d8d80 f56e0452-ca7d8d80 b2f0086-93053e47 6844d8aa-669a04e0 494d8760-3d47f4f4 f47ae82a-746c2ad4 3ac60855-486e2a9c f296190c-f2ffe33a 4442aae2-a5822863 ed1d377-e1cc0f14 75f0f0a0-d7f6b13c e2b18481-cdc3d902 e7e71889-4ad60575 288c530e-3d47f4f4 61b920c1-ca7d8d80 828a5926-ca7d8d80 a88c475d-3d47f4f4 CompilerMSVC 2015 (PGO)
,
Jul 28 2017
Adding "src/components/omnibox/OWNERS" for further inputs until we get a consistent repro. I do see lot of 'Omnibox' related changes from previous to current stable (https://chromium.googlesource.com/chromium/src/+log/59.0.3071.115..60.0.3112.78?pretty=fuller&n=10000), however not very sure which one is related. Thank you!
,
Jul 28 2017
Can someone with a Windows machine on this version reproduce? That could possibly save time before we begin sifting through the long blamelist / sync to the right version and debugging ourselves. I'd be surprised if paste was entirely broken on Windows and we hadn't heard about it until stable...
,
Jul 29 2017
So far, i'm unable to reproduce this issue on reported version#60.0.3112.78 for Win10.
,
Jul 31 2017
Tested on the environment mentioned below and unable to reproduce the issue. Google Chrome: 60.0.3112.78 (Official Build) (64-bit) (cohort: 60_78_win) Revision : f901216ec1e383df23283fec9bc8f4e8b67aa0fb-refs/branch-heads/3112@{#671} OS : Windows 10 JavaScript : V8 6.0.286.44 Flash : 26.0.0.137 C:\Users\frittog1\AppData\Local\Google\Chrome\User Data\PepperFlash\26.0.0.137\pepflashplayer.dll User Agent : Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.78 Safari/537.36 Attached the screen-cast for reference.
,
Aug 1 2017
It looks to me like what's happening here is that after the user copies the URL, their clipboard is empty. Notice that when they copy the URL, the "Paste" and "Paste and go" options are not disabled. But after they select the "Copy" action, now the paste actions are disabled (which is what we do when we think the clipboard is empty). The user demonstrates that the paste options in the right-click menu on the search box in the NTP are not disabled, but doesn't actually select either of them. I can confirm that with an empty clipboard, that the paste options in the search box menu are *not* disabled. I asked the user on the help forum to report back with what happens if they actually try to paste into the search box on the NTP to confirm. I've also looked at the omnibox code and we don't do any special handling of the copy command so there's no obvious culprit there. Adding Needs-Feedback while I wait on a response from the user.
,
Aug 1 2017
The user reported back that attempting to paste in the search box on the NTP did in fact result in the URL appearing. Given that putting text in the NTP search box results in focus moving to the omnibox, they were satisfied with this workaround. But something's gone wrong here. My original hypothesis was off. It would appear that we're successfully copying text but then refusing the enable the paste options in the drop-down menu in the omnibox. There are two possibilities, based on [1]. Either the omnibox (a views::TextField) has been put into a read-only state erroneously or GetClipboardText() is returning an empty string erroneously. I suspect the latter given that that function is doing various interesting things and then falls back to returning an empty string. Since we can't reproduce, I'm not going to take any further action. But I'm leaving this open in case the user reports anything else. If not, this can be closed on the NextAction date. [1] https://cs.chromium.org/chromium/src/chrome/browser/ui/views/omnibox/omnibox_view_views.cc?l=848&rcl=21ab642e0d18f0926778e97416c9e9098b5c4033
,
Aug 1 2017
I wonder if the copied text is being put into the clipboard in an odd format. https://cs.chromium.org/chromium/src/ui/base/clipboard/clipboard.h?l=215-245 The Views code only looks at certain formats for pasting; I think the context menu in the NTP box (which I believe uses Blink) might be more forgiving about formats. I agree that it's not worth spending time on unless it turns out to be more widespread.
,
Aug 2 2017
Removing the label 'Needs-TestConfirmation' as issue is not reproduced as per the comment #9. Please let us know if any help is required from TE's end. Thanks.
,
Aug 3 2017
Based on #11 removing RBS
,
Jan 9 2018
The NextAction date has arrived: 2018-01-09
,
Jan 10 2018
Per comment #11: >>> Since we can't reproduce, I'm not going to take any further action. But I'm leaving this open in case the user reports anything else. If not, this can be closed on the NextAction date. >>> The next action date has arrived and we haven't heard any additional reports / details. |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by gov...@chromium.org
, Jul 27 2017