(1) Clipboard broken on Mac when Chrome is executed from tmux (WONTFIX) & (2) Right click in omnibox causes DCHECK failure (FIXED) |
||||||||||||
Issue descriptionVersion: Chromium top of tree (appeared sometime last week, I think) OS: macOS 10.12.1 I suspect these two problems may be related as I started seeing them at the same time. What steps will reproduce the problem? Problem 1: (WONTFIX) (1) Copy and paste appear to be no-ops (in omnibox, on webpages, etc.) - clipboard doesn't change, nothing is pasted. Cut deletes but doesn't change clipboard. Problem 2: (FIXED) (1) Build Chromium with DCHECKs enabled (2) Right click in omnibox (clipboard contents don't seem to matter) - causes DCHECK failure. [56910:775:1121/143413:FATAL:omnibox_view_mac.mm(998)] Check failed: model()->CanPasteAndGo(text). 0 libbase.dylib 0x0000000113f922c3 _ZN4base5debug10StackTraceC1Ev + 19 1 libbase.dylib 0x0000000113fb93e7 _ZN7logging10LogMessageD2Ev + 71 2 libchrome_dll.dylib 0x000000010f3048fe _ZN14OmniboxViewMac22GetPasteActionStringIdEv + 110 3 libchrome_dll.dylib 0x000000010f2ec38a -[AutocompleteTextFieldEditor menuForEvent:] + 474 4 AppKit 0x00007fffce3f6fca -[NSView _showMenuForEvent:] + 58 5 AppKit 0x00007fffcdfc1387 -[NSView rightMouseDown:] + 100 6 AppKit 0x00007fffcdfc1317 -[NSTextView rightMouseDown:] + 181 7 libchrome_dll.dylib 0x000000010f2ec72f -[AutocompleteTextFieldEditor rightMouseDown:] + 111 8 AppKit 0x00007fffce45a0b4 -[NSWindow(NSEventRouting) _reallySendEvent:isDelayedEvent:] + 6458 9 AppKit 0x00007fffce4583ae -[NSWindow(NSEventRouting) sendEvent:] + 541 10 libchrome_dll.dylib 0x000000010f296b9f -[ChromeEventProcessingWindow sendEvent:] + 79 11 AppKit 0x00007fffce2f8cca -[NSApplication(NSEvent) sendEvent:] + 3190 12 libchrome_dll.dylib 0x000000010df0aecc __34-[BrowserCrApplication sendEvent:]_block_invoke + 172 13 libbase.dylib 0x0000000113fbab3a _ZN4base3mac15CallWithEHFrameEU13block_pointerFvvE + 10 14 libchrome_dll.dylib 0x000000010df0ae18 -[BrowserCrApplication sendEvent:] + 72 15 AppKit 0x00007fffcdbd9589 -[NSApplication run] + 1002 16 libbase.dylib 0x0000000113fd6177 _ZN4base24MessagePumpNSApplication5DoRunEPNS_11MessagePump8DelegateE + 359 17 libbase.dylib 0x0000000113fd56f7 _ZN4base24MessagePumpCFRunLoopBase3RunEPNS_11MessagePump8DelegateE + 119 18 libbase.dylib 0x0000000113fd0e62 _ZN4base11MessageLoop10RunHandlerEv + 354 19 libbase.dylib 0x0000000114002623 _ZN4base7RunLoop3RunEv + 51 20 libchrome_dll.dylib 0x000000010df106f8 _ZN22ChromeBrowserMainParts18MainMessageLoopRunEPi + 280 21 libcontent.dylib 0x0000000116605094 _ZN7content15BrowserMainLoop23RunMainMessageLoopPartsEv + 52 22 libcontent.dylib 0x0000000116607e26 _ZN7content21BrowserMainRunnerImpl3RunEv + 166 23 libcontent.dylib 0x0000000116600eac _ZN7content11BrowserMainERKNS_18MainFunctionParamsE + 124 24 libcontent.dylib 0x0000000116e30def _ZN7content21ContentMainRunnerImpl3RunEv + 607 25 libcontent.dylib 0x0000000116e2feb6 _ZN7content11ContentMainERKNS_17ContentMainParamsE + 54 26 libchrome_dll.dylib 0x000000010dac4a2c ChromeMain + 60 27 Chromium 0x000000010da58daa main + 522 28 libdyld.dylib 0x00007fffe5028255 start + 1
,
Nov 21 2016
Jayson, Erik: do you think you could have someone triage this with high priority? It looks like it slipped through the cracks. Thanks. Note that these were reproduced (I think) with a Release build with dcheck_always_on=true.
,
Nov 22 2016
[mac triage] I can't reproduce at r433461 (debug build, DCHECKs enabled). I get past that DCHECK and hit another -- filed Issue 667662 , which I'll triage tomorrow. I don't think anything has changed recently. I looked recent changes in components/omnibox/browser/omnibox_edit_model.cc and chrome/browser/ui/cocoa/omnibox/omnibox_view_mac.mm I suspect (1) is caused by some kind of system deadlock. When was your last reboot? *but* before rebooting - it would be good to get input on the rest. Then poking around code, (2) might be caused by having something in the clipboard (which apparently isn't updating) which Autocomplete somehow generates an invalid URL for. Can you help us debug this by adding some diagnostic logging in bool OmniboxEditModel::CanPasteAndGo(const base::string16& text) const { if (!client_->IsPasteAndGoEnabled()) return false; AutocompleteMatch match; ClassifyStringForPasteAndGo(text, &match, nullptr); return match.destination_url.is_valid(); } to see where it's failing. And report back with the values for |text| and |match.destination_url|? I looked into client_->IsPasteAndGoEnabled() by inspection, but I don't think it can ever be false for a browser window on mac. Either Browser::is_type_tabbed() should be true, or the UI is hidden and the IDC_OPEN_CURRENT_URL command disabled, but there is bool BrowserWindowCocoa::ShouldHideUIForFullscreen() const { // On Mac, fullscreen mode has most normal things (in a slide-down panel). return false; } so the command should never be disabled on Mac.
,
Nov 22 2016
(1) To be clear, my clipboard is working fine in other applications, such as Chrome Stable and iTerm. I think this issue has persisted through a reboot but I don't actually remember. (2) It makes it all the way through OmniboxEditModel::CanPasteAndGo before crashing. With "hello" on my system clipboard, 'text' is an empty string (length=0) and destination_url.is_valid() returns false.
,
Nov 22 2016
,
Nov 23 2016
I don't have an explanation for why the clipboard isn't working :/. What Chrome revision are you at? Does it work in Canary? Is any text/error output to the console? But https://codereview.chromium.org/2523053003/ should fix the DCHECK. I don't think it's a regression. It doesn't fix Issue 667662 (which might be a really old regression).
,
Nov 23 2016
Right now I'm branched off of crrev.com/433609 . It works in Canary. Nothing is output to the console on Release with dcheck_always_on. Still broken after a reboot. I haven't tried a build without dcheck (but I don't know what that would change since nothing is logged). It sort of seems like there is something going on with the clipboard code that trickled down to causing that DCHECK failure. If I manage to figure out anything new I'll update here.
,
Nov 23 2016
https://codereview.chromium.org/2523053003/ will get around the DCHECK. To test it I just made omnibox/clipboard_utils.cc's GetClipboardText() return an empty string, which it is allowed to do. That CL fixes the menu, e.g., for an empty clipboard, to not DCHECK. But "With "hello" on my system clipboard, 'text' is an empty string (length=0)" suggests GetClipboardText() is failing. i.e. GetClipboardText() *shouldn't* be returning an empty string - that sounds like a bug, but I don't know where. GetClipboardText() is a cross-platform method, but that file hasn't changed in over a year. We'll need more diagnostics around clipboard_utils.cc's GetClipboardText() (and maybe the ui::Clipboard methods) to get the bottom of this.
,
Nov 23 2016
drive-by comment: could this have to do with Mac's new universal clipboard feature?
,
Nov 23 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/6da03d5709d85234907de200ad5bda09a7442782 commit 6da03d5709d85234907de200ad5bda09a7442782 Author: tapted <tapted@chromium.org> Date: Wed Nov 23 23:49:19 2016 Mac: Fix errors in adding the "Paste & Go" menu item. AutocompleteTextFieldObserver::GetPasteActionStringId() says "Must not be called unless CanPasteAndGo() returns true." But it doesn't look like -[AutocompleteTextFieldEditor menuForEvent:] ever actually checked `CanPasteAndGo()` before adding the menu item. Currently, if the clipboard is empty (or Chrome failed to access it), GetPasteActionStringId() will DCHECK when omnibox/clipboard_utils' GetClipboardText() returns an empty string. To fix, check CanPasteAndGo() and disable the menu item if it returned false. BUG= 667512 Review-Url: https://codereview.chromium.org/2523053003 Cr-Commit-Position: refs/heads/master@{#434284} [modify] https://crrev.com/6da03d5709d85234907de200ad5bda09a7442782/chrome/browser/ui/cocoa/location_bar/autocomplete_text_field_editor.mm [modify] https://crrev.com/6da03d5709d85234907de200ad5bda09a7442782/chrome/browser/ui/cocoa/location_bar/autocomplete_text_field_editor_unittest.mm
,
Nov 24 2016
mpearson: Seems like a possibility. I tried disabling it, but that doesn't change anything (even after a reboot). BTW, I can still repro with a clean build off ToT (434288) and a clean profile. But still not on Canary. Right click problem is fixed.
,
Nov 28 2016
kainino: what are your GN args? It seems crazy that the Chromium continuous builds wouldn't reproduce this, but that your local build does.
,
Nov 28 2016
I'm seeing a lot of Clipboard related issues on our first test bot on 10.12: https://bugs.chromium.org/p/chromium/issues/detail?id=665691#c5
,
Nov 28 2016
Nothing very special, just: is_debug = false use_goma = true is_component_build = true dcheck_always_on = true I haven't tried any other configurations yet because full rebuilds take a long time.
,
Nov 29 2016
Is it possible that the SDK that's compiled against is different on kainino's setup? Is that hermetic or is it using the system version?
,
Nov 29 2016
,
Nov 29 2016
+justincohen for question about mac hermetic builds. Seems like it could be a compiled SDK issue.
,
Nov 29 2016
Does functionality change if the gn arg use_system_xcode is set to true vs false?
,
Nov 29 2016
I'm looking into this. Still seems to be broken with use_system_xcode=false. My computer is offering me an Xcode upgrade (8.0 -> 8.1), so I'll try that too.
,
Nov 30 2016
Also broken with: * use_system_xcode=true, Xcode 8.0 * use_system_xcode=true, Xcode 8.1 (assuming the use_system_xcode setting is actually working, I can't tell)
,
Dec 1 2016
Possibly a red herring, but there are some Mac Pasteboard shenanigans in ui_base_unittests being investigated in Issue 665691
,
Dec 1 2016
,
Dec 1 2016
I had a breakthrough today wrt reproducing this bug on my machine. It turns out that the differences I was seeing between Chrome versions was this: * No bug when the *.app file is opened * Bug when *.app/Contents/MacOS/* executable is opened I can now reliably reproduce on my machine on ALL versions of Chrome (including stable, canary, continuous, and my own build). HOWEVER: There is still something special about my machine. I can't repro on an off-corp 10.12.2 beta, and I can't repro on zmo's on-corp 10.12.1. Lowering to P2 because it seems this bug should never reach users if they open the .app package the usual way.
,
Dec 1 2016
You can get the log files to see what the error is: https://bugs.chromium.org/p/chromium/issues/detail?id=665691#c13 """ sudo log show --info --debug --predicate 'subsystem == "com.apple.CFPasteboard"' """
,
Dec 1 2016
Thanks Erik, here's what I have:
2016-12-01 13:41:34.205253-0800 0xab632 Default 0x0 19619 Google Chrome Canary: (CoreFoundation) [com.apple.CFPasteboard.general] failed to create global data
2016-12-01 13:41:34.205270-0800 0xab638 Error 0x0 19619 Google Chrome Canary: (CoreFoundation) [com.apple.CFPasteboard.general] Connection to 'pboard' server had an error: <error: 0x7fffd9beeca0> { count = 1, transaction: 0, voucher = 0x0, contents =
"XPCErrorDescription" => <string: 0x7fffd9beef18> { length = 18, contents = "Connection invalid" }
}
2016-12-01 13:41:34.205520-0800 0xab632 Error 0x0 19619 Google Chrome Canary: (CoreFoundation) [com.apple.CFPasteboard.general] Failed to obtain 'pboard' service port: <error: 0x7fffd9beeca0> { count = 1, transaction: 0, voucher = 0x0, contents =
"XPCErrorDescription" => <string: 0x7fffd9beef18> { length = 18, contents = "Connection invalid" }
}
Looks exactly the same as 665691. However:
After reading that message, I suspected there could be something going on with the terminal. Thusly I discovered that the bug crops up specifically when I run the chrome executable from within tmux. This explains why running it from the .app fixes it.
Lo and behold, it turns out that if I run ANY application from my tmux shell, it can't access the clipboard (tried Notes and TextEdit). Notes even prints an error:
2016-12-01 14:13:19.851 Notes[20760:721249] --error: [ShareKit] error calling +[NSExtension extensionsWithMatchingAttributes:error:]: Error Domain=PlugInKit Code=4 "Connection invalid" UserInfo={NSLocalizedDescription=Connection invalid}
This turns out to be the same problem I started having recently where vim (in tmux) could no longer directly access the system clipboard via "+p (which I promptly forgot about after first noticing it). I suspect that tmux (tmux 2.2 from homebrew) is somehow severing the connection between its shell session and the external world (probably due to how it daemonizes itself).
I'm changing this to Fixed (for problem #2) and saying WontFix for problem #1. Sorry, all, for wasting time on this weird problem! I hope this hint helps with the diagnosis of 665691.
,
Dec 1 2016
,
Dec 1 2016
,
Dec 1 2016
Thanks for the detailed update!
,
Dec 1 2016
One more thing I forgot to mention: it does NOT seem to be environment variables - if I tried cloning the environment variables from the broken environment to the working one, it was still working.
,
Dec 1 2016
The problem is probably caused because tmux has the wrong session type. See https://bugs.chromium.org/p/chromium/issues/detail?id=665691#c19 for more details.
,
Aug 28 2017
If anyone ever comes across the tmux clipboard issue again there is a workaround which I recently started using: https://github.com/ChrisJohnsen/tmux-MacOSX-pasteboard
,
Feb 20 2018
Assigning back to tapted for the record, as they fixed this issue. |
||||||||||||
►
Sign in to add a comment |
||||||||||||
Comment 1 by kainino@chromium.org
, Nov 21 2016