<ul dir="auto">
<li>Electron version: 1.8.2</li>
<li>Operating system: macOS 10.13.3</li>
</ul>
<h3 dir="auto">Expected behavior</h3>
<p dir="auto">It seems like you should be able to copy text in the devtools using Cmd-C <em>regardless of whether or not the app itself has those keys assigned as menu items</em></p>
<h3 dir="auto">Actual behavior</h3>
<p dir="auto">Cmd-C does nothing (apparently you have to add menu items to get this to work). My app as no need of Copy so those keys are not assigned and no menu is added. The normal app keys do not affect the devtools, why should Cmd-C be any different? In other words pressing Cmd-F in devtools will start a search even though my app has no menu for Cmd-F. Similarly it seems like Cmd-C should copy when devtools has the focus regardless of what my app is doing.</p>
<h3 dir="auto">How to reproduce</h3>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="git clone -b cmd-c-not-working https://github.com/greggman/electron-quick-start.git
cd electron-quick-start
npm install
npm start"><pre class="notranslate"><code class="notranslate">git clone -b cmd-c-not-working https://github.com/greggman/electron-quick-start.git
cd electron-quick-start
npm install
npm start
</code></pre></div>
<p dir="auto">Then try to copy something in devtools by pressing Cmd-C. Nothing happens. Notice that Cmd-F works even though there is no Cmd-F menu item and even though the app is trapping all keypresses. The point being it seems like Electron's devtools shouldn't rely on the App's setup for basic functionality. That works in Chrome because a webpage can't change the App's menus but in Electron arguably Electron's devtools should be checking for Cmd-C/Cmd-X/Cmd-V in some other way, maybe the same way it's checking for Cmd-F.</p>
<ul dir="auto">
<li>Electron version: 1.7.10</li>
<li>Operating system: Windows 7 64-bit</li>
</ul>
<h3 dir="auto">Expected behavior</h3>
<p dir="auto">Sandboxing doesn't cause Electron to crash for anyone.</p>
<h3 dir="auto">Actual behavior</h3>
<p dir="auto">A smallish fraction of users report crashes.</p>
<p dir="auto">We're working on an Electron app and we estimate 1-5% of users encounter Sandboxing issues: the app crashes. Our app calls app.enableMixedSandboxing() to enable sandboxing, but I would expect this issue to occur with --enable-sanbox as well. We have devs running Win 7 and the same A/V software as the users with the repro with no issues When we look at the stack trace, we see:</p>
<blockquote>
<p dir="auto">Project Maestro.exe!base::debug::BreakDebugger() Line 21          C++<br>
Project Maestro.exe!logging::LogMessage::~LogMessage() Line 762          C++<br>
Project Maestro.exe!content::<code class="notranslate">anonymous namespace'::CheckDuplicateHandle(void * handle) Line 514    C++ Project Maestro.exe!content::</code>anonymous namespace'::DuplicateHandlePatch(void * source_process_handle, void * source_handle, void * target_process_handle, void * * target_handle, unsigned long desired_access, int inherit_handle, unsigned long options) Line 563 C++<br>
Project Maestro.exe!sandbox::ProcessPolicy::OpenProcessAction(const sandbox::ClientInfo &amp; client_info, unsigned int desired_access, unsigned int process_id, void * * handle) Line 158   C++<br>
Project Maestro.exe!sandbox::ThreadProcessDispatcher::NtOpenProcess(sandbox::IPCInfo * ipc, unsigned int desired_access, unsigned int process_id) Line 187             C++<br>
Project Maestro.exe!sandbox::SharedMemIPCServer::InvokeCallback(const sandbox::SharedMemIPCServer::ServerControl * service_context, void * ipc_buffer, sandbox::CrossCallReturn * call_result) Line 279         C++<br>
Project Maestro.exe!sandbox::SharedMemIPCServer::ThreadPingEventReady(void * context, unsigned char __formal) Line 398           C++<br>
[Frames may be missing, no binary loaded for ntdll.dll]<br>
ntdll.dll!00000000775ced52()      Unknown</p>
<p dir="auto">If we attach a debugger and look at the log message, we see:</p>
<p dir="auto">[12224:0322/155853.691:FATAL:sandbox_win.cc(511)] Check failed: !(basic_info.GrantedAccess &amp; kDangerousMask). You are attempting to duplicate a privileged handle into a sandboxed process.</p>
<p dir="auto">Please contact <a href="mailto:security@chromium.org">security@chromium.org</a> for assistance.</p>
</blockquote>
<p dir="auto">plus some other stuff (can attach if you really want it, but it's probably not really relevant to the fix).</p>
<p dir="auto">We did notice the user had Chrome installed on their machine and reported no problems with it.</p>
<p dir="auto">If you look at <a href="https://chromium.googlesource.com/chromium/chromium/+/trunk/content/common/sandbox_win.cc" rel="nofollow">https://chromium.googlesource.com/chromium/chromium/+/trunk/content/common/sandbox_win.cc</a> line 545, the sandoxing code only patches the DuplicateHandle Win32 API with DuplicateHandlePatch when the OFFICIAL_BUILD macro isn't defined.</p>
<p dir="auto">I reached out the Chromium security folks and they confirmed that many of the sanity checks only run when you don't define the OFFICIAL_BUILD precompiler macro while building Chromium. They explicitly turn this off for release builds because anti-virus and god knows what tends to break these sandbox sanity checks.</p>
<p dir="auto">I would attach the email thread to this bug, but their email boilerplate says not to, as it is security related. I'm sure whoever needs to cab get looped into the thread if you ask them.</p>
<p dir="auto">Disabling sandboxing resolves the issue on afflicted users' machines.</p>
<h3 dir="auto">How to reproduce</h3>
<p dir="auto">No idea. Happens deterministically on a small fraction of users' machines. Our 2 datapoints so far indicate both users had Win 7 and Sophos anti-virus installed, but others in our org have this same setup and have had no issues.</p>