For reference (and screenshot): https://support.google.com/chrome/thread/60700949?hl=en
OS X 10.11, Macbook Air 2015. I just updated Chrome from a slightly earlier 84.x.x.x to 84.0.4147.89. Upon launching the app now, I get a completely blank gray window without even a URL bar. The death-wheel spins and then it crashes. I've never seen a legitimate app behave this way in 30 years.
Launching from terminal I see this:
[0723/152018.747279:WARNING:process_memory_mac.cc(93)] mach_vm_read(0x7fff54e1d000, 0x2000): (os/kern) invalid address (1)
[2084:34307:0723/152018.992135:FATAL:gpu_data_manager_impl_private.cc(439)] GPU process isn't usable. Goodbye.
From what I've read, the flags --no-gpu and/or --disable-gpu are no longer valid in the latest "stable" release. Here are the flags I've thrown at it so far:
/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --args --use-gl=swiftshader --disable-gpu --disable-software-rasterizer --no-sandbox --no-xshm --no-gpu --disable-accelerated-compositing --disable-gpu-compositing
Does anyone know if there's a config file I could modify or some way of getting it to launch without hardware acceleration? Not truly a coding question but it's driving me nuts. Filed this on the Chrome Help site and got no responses.
You may try to open chrome://settings/?search=hardware in your browser and then turn off Use hardware acceleration when available.
Related
All the functions starting with ui (uigetfile, uigetdir, etc...) fail to work (and return 0). They do not even pop up a Window to select files.
This happened on OSX Monterey 12.3 with MATLAB 2019b, 2020b, 2021b, 2022b.
I realized that when the MATLAB process hangs after a ui command, a new process is created for analytics and improvement. And this process apparently crashed. I tried to kill it but it did not help. I tried to disable in the preferences > Security > Privacy tab but was not able to (the GUI was not populating).
Eventually I rebooted and was able to disable Analytics and Improvements. After that MATLAB behaved fine.
Sorry you had experienced a problem.
The UI functions in MATLAB display native macOS open/save panels - native open/save panels run out-of-process and are controlled by various system services.
Therefore, if either the QuickLook or openAndSavePanel service crashed before the panel could start (or finish) displaying, instead of a crash, you may see nothing happening. It sounds like this is probably what happened.
If that's the case, this issue has nothing to do with analytics, as macOS analytics only come into play once something crashed. Rebooting the machine is likely the thing that made the issue go away, not the disabling of analytics.
To find the root cause of the issue, the best bet is to contact MathWorks tech support and provide diagnostics, such as unified system logs, spindumps, spotlight diagnostics, quicklook database cache, native crash reports, etc.
I hope this was helpful.
I'm experiencing a really weird and frustrating issue with the Android Emulator on macOS Monterey.
I have "tap to click" enabled on my Macbook Pro (Mid 2015 15"), and it works fine in all other apps. But somehow, when the emulator window is active it seems to miss almost every other tap. If I click hard instead of tapping, it catches every click. The tap sensitivity in the Trackpad settings is set to "light".
So, it seems that the emulator window is somehow less sensitive to tapping than all other apps. I don't even know how this is possible, is there even such a thing as app-specific tap-sensitivity??
What's more, it's not only the emulator window itself that has this issue, but the emulator settings window as well. If I tap the "Enable clipboard sharing" toggle, it misses about 50% of the taps. If I click hard, it catches them 100%. If I try the same in some other app (tested with the "System Preferences" window), it catches 100% of the taps.
I have tested and tested this again to make sure I'm not biasing the results, but there really is a difference, and it's driving me nuts. I think it appeared after updating to Monterey, but not 100% sure of the exact timing correlation.
Any ideas??
My problem was really similar, I am using MAC with apple mouse, so I could fix it by disabling the mouse wheel on Android Emulator Extended Controls.
Hope that help
I've noticed the same issue some time ago. Unfortunately, I didn't find any solutions.
However, there are a couple of good enough workarounds:
Launch the emulator in a tool window. Anyway, this is a default approach for modern versions of Android Studio. To enable/disable it check Preferences -> Tools -> Emulator -> Launch in a tool window.
Use alt emulators. For instance, Genymotion doesn't have such an issue.
I ran into a simmiliar issue for me and the solution that i found was enabling "tap on click" to in the "system preferences" -> "trackpad".
I am new to the Android Emulator, but am experiencing the same issue in Ubuntu, even though I have tap-to-click disabled in the OS. I hate tap-to-click, so having an ultra-sensitive-to-touch Android screen emulated on my laptop is beyond frustrating.
Looking at the documentation, I came across the SOURCE_CLASS_POINTER method, which states:
The input source is a pointing device associated with a display. Examples: SOURCE_TOUCHSCREEN, SOURCE_MOUSE. A MotionEvent should be interpreted as absolute coordinates in display units according to the View hierarchy. Pointer down/up indicated when the finger touches the display or when the selection button is pressed/released. Use getMotionRange(int) to query the range of the pointing device. Some devices permit touches outside the display area so the effective range may be somewhat smaller or larger than the actual display size.
In reading that, I've come to believe this may actually be the default behavior due to touchpad events being interpreted through the SOURCE_TOUCHSCREEN method, rather than SOURCE_TOUCHPAD or SOURCE_MOUSE.
Unfortunately, I don't have a solution as much as a workaround:
I plugged in a mouse and tested the pointer up/down movements over the screen, which this part of the document suggests should register as a press. However, with the mouse it only responds to clicks. So it suggests to me that it is indeed properly interpreted as a SOURCE_MOUSE controlled pointer and not a SOURCE_TOUCHSCREEN controlled pointer.
So unless we can find out how to make the AVD properly interpret a touchpad as a touchpad, and not a touchscreen, using a mouse seems like the best solution.
For reference, I'm including this link to the AVD manual: https://developer.android.com/studio/run/emulator
UPDATE: Somehow over the period of about 18 hours and several restarts, my AVD no longer does tap-to-click on its virtual screen. It would be very hard to pinpoint exactly what changed because I've been updating packages frequently since I'm running a pre-alpha release of Ubuntu, but I think it's from using X11 instead of Wayland.
Which got me thinking, you could try changing your display server from Cocoa to X11. Thankfully, MacPorts, the MacOS version of the FreeBSD Ports Tree, makes it fairly easy to cross-compile software. It contains build recipes for multi-platform unix-like software, much like HomeBrew but often allowing for more customization.
That tap issue was annoying enough it's probably worth giving a shot.
(from macports website) The X11 windowing environment, for ports that depend on the functionality it provides to run. You have multiple choices for an X11 server: https://www.macports.org/install.php
I would build them in this order:
MacPorts: X11 - If you build it, you'll have a bunch of libraries already
MacPorts: QEMU - use make configure menu to select GTK3+, if there's no option for X11, try this build flag with make after you install X11 (pointing it at your X11's lib dir):
make -L/opt/X11/lib -lX11
Lastly, MacPorts: Android Platform tools
Related StackOverflow Q/As:
Compiling a C program that uses OpenGl in Mac OS X
Running x11 on Mac OS
As of Safari 11, they have started supporting WebRTC apis natively.
In my web application I am using navigator.mediaDevices.getUserMedia to get control of the microphone.
I noticed that, only in Safari, when my code calls getUserMedia, the sound on my computer gets low then comes back up to normal volume after a second.
I have tested this on another website: https://simpl.info/getusermedia/
When I loaded the website, I did not see the issue..
The site above only requests for video, but the code is very simple and not minified. I put a breakpoint right where it calls getUserMedia and added the constraint for audio and I was able to reproduce the issue.
Has anyone else had this problem? I am unable to find anything online describing this issue.
I am running Mac OSx El Capitan. I know I am out of date but people have told me that this happens on Sierra as well.
The same on High Sierra.
My guess is they try to avoid audio spikes or to go easy on the echo canceler.
The "Warn Before Quitting" feature stopped working for me. When I click Cmd-Q Chrome closes immediately instead of showing me the "Hold ⌘Q to close" message.
I want to debug the code responsible for that, but I can't seem to find a way. On Windows I can attach to Chrome, get the PDBs from Google's symbol server, and get the appropriate sources using SrcSrv.
Is there anything similar on OS X?
(Firefox apparently has a script to download symbols for Linux/OS X, though I never tried using it.)
It doesn't happen on another user on my machine or on Chromium. I tried copying my profile to ~/Library/Application Support/Google/Chrome of another user and to ~/Library/Application Support/Chromium (for a Chromium build I made). In both cases the bug did not present itself (though other bad things have happened), so using Chromium doesn't seem like a solution.
(Although I did build Chromium's HEAD rather than the tag corresponding to the version of Google Chrome I'm running. Maybe if I do that I would be able to reproduce the problem in Chromium. Nonetheless the question remains.)
Is it possible to perform source debugging of Google Chrome on OS X? If so, how?
Note: I'm not interested in attempts to solve the "Warn Before Quitting" bug, suggestions to report it to Google, etc. That's not the point. I want to be able to debug Chrome myself.
Ever since Flash Player 10 came out, the debugger version causes what seems like a crash in my browser, either Safari, or Firefox, on Mac OS X. It's been consistently happening with 10.0, 10.1 and 10.2.
And it's not just on the applications I develop. Six or seven times out of ten, when I visit sites like Gamespot with Flash video delivery and a banner ad or two, the debugger kicks out an error and, upon dismissing that error, I can't regain focus of my browser. Clicking a window does nothing but trigger the Mac OS X error sound. I have to force-quit and start again.
The Adobe forums have been no help, and everything else I've seen relative to the debugger crash issues doesn't seem to solve my problem. Any ideas?
I'm not sure if this works on a Mac as well, but on a Windows machine, this hack saved me already some time: Often it is just enough to kill the task "plugin-container.exe". This will stop all flash movies immediately and unfreeze your browser. So you can work on without losing all work done in other browser tabs and waiting for your browser to restart.