In Google Chrome when inspecting a web page from a mobile device connected via USB, the javascript console does not print console.log statements. It also doesn't respond to alerts. It doesn't seem to support any interaction at the command line, such as setting variables. Is there something I need to do to get the console to behave normally, as if I was debugging Chrome for desktop?
Figured it out immediately. I had turned off Javascript on the mobile browser and forgot to turn it back on.
Related
So it seems that the device toolbar usually present in any regular DevTools instance is missing when inspecting a remote instance.
And in such cases the device type is set to "Mobile", with the mouse pointer set to a circle, as to indicate that.
Here's how to reproduce this:
start a new headless instance, e.g., with:
/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --remote-debugging-port=9222 --headless https://example.com
using another Chrome instance navigate to chrome://inspect and inspect the remote tab.
as you can see there is no device toolbar.
I also tried to send some Chrome DevTools Protocol commands like:
Emulation.setTouchEmulationEnabled
Emulation.setEmitTouchEventsForMouse
Emulation.setDeviceMetricsOverride
But to no avail, something happens but the behavior looks broken... I suspect that this is something concerning the DevTools frontend, and not the inspected Chrome instance.
Do you have any idea about how can I work around this? My ultimate goal is to manually interact with a remote headless instance using a desktop device type.
If I understand you correctly, you want to do manual interactions with a remote instance using a desktop device. You should just be able to click the device icon at the top left of your devtools window to turn off mobile.
I am trying to solve a mystery:
A page from a React web app can be loaded in Safari on iOS
That page can be loaded in Chrome on iOS if you choose "Request Desktop Site"
That page is blank when attempting to load it in Chrome on iOS if you go with the default "Request Mobile Site"
The page works fine in desktop browsers
I have taken steps to enforce a timeout on the server side, in case there is a connection that is hanging. But when I consult the logs, the requests complete quickly without any of the usual follow-on activity. My guess is that there is a JavaScript error of some kind that is causing the React app to bail.
What is a good next step that might be helpful in troubleshooting this issue?
ETA: Added new information that confirms the requests are making it from Chrome to the Golang server, as expected.
I think what's going on is that the "Request Mobile Site" mode falls over when there's a large JavaScript bundle, whereas the "Request Desktop Site" doesn't for some reason.
For anyone who runs into this situation, something that worked for me was to decrease the amount of JavaScript that the iOS Chrome app has to load, e.g., using code splitting, user agent sniffing and redirection to a less memory-intensive page in the case of iOS Chrome. After doing this, things worked fine. I'm guessing that less memory is available to apps running in the "Request Mobile Site" mode than in the "Request Desktop Site" mode.
Does anybody know how to implement receiving of push notifications outside and without running browser?
There is some nuance to this:
Chrome for Android: Push messages will wake up the Service Worker and Web App even if the browser is closed. This is the default and our ideal position across all platforms
Desktop Chrome: Push works and will wake up the service worker if the browser is still open. However it will not work if the browser is closed. You can force the browser to remain open if you have a Chrome App that is set to run in the background. Other than that we (the Chrome team) are working out how we enable this by default on Windows, Mac and Linux.
Chrome for iOS: Push just does not work on this platform
Chromium blog has a post with code examples: http://updates.html5rocks.com/2015/03/push-notificatons-on-the-open-web
And the documentation was updated too: https://developer.chrome.com/apps/cloudMessaging
It is possible to write Chrome extension where background script can run if Chrome is allowed to run in the background (configurable in settings) and it can use GCM.
This is a question about debugging a project, not about writing the code.
I am on the final stages of developing an HTML5 web app. Fairly last minute, our client tells us it should run on IE8. Since I use the HTML5-canvas in the app, this required the addition of Google Chrome Frame. Once installed and testing, however, IE8's developer console no longer prints any data, and the HTML viewer never loads. Is this a bug? Is there a way to fix it? It will really suck if I need to debug with alerts...
From Google Chrome Frame documentation:
You can use the Web Inspector in GCF just as you would in the Google Chrome browser. To use it, right-click and choose "Inspect Element". Logging is available via the console.log method, and you can set breakpoints and inspect network activity.
One of the best features about Firefox and Firebug is that you can see exactly what your AJAX calls responses are.
Safari and Chrome have Developer Tools, but the Console is lacking. It doesn't show anything except for warnings and errors.
Am I missing something? Without having to place a breakpoint is the script, is it possible to see the response within Safari or Chrome's Developer Tools?
To elaborate:
"Network" doesn't show you what the actual response is that I can see. It just shows all of the loaded resources.
If I make an AJAX call to a web service, I want to be able to see the JSON response.
You can use the Network tab.