I am using Angular 8, and I am using web workers.
I created web worker according to angular standard documentation https://angular.io/guide/web-worker.
I have problem to debug my code into the web worker. In Firefox debugging works perfectly but in chrome I cannot set break point to any line of the my code. Chrome version is: 83.0.4103.
When ever I want to put breakpoints to the code I wrote in the web worker it automatically jump to the line:
module.exports = __webpack_public_path__ + "1.worker.js"
After it I see that breakpoints is here, but code never stop at that line, sometimes even console log does not work.
Image below show how breakpoints are there but debugger never stops.
Is there any trick here which I do not get it ?
I had the same problem when debugging and had to downgrade to version 81, and I still can't find a solution for higher versions
Related
My Javascript Apache Cordova app builds fine but doesn't behave debugging on the emulator or real device.
I see a bunch of messages rush by in the Visual Studio Javascript Console but the app then immediately crashes and the Javascript Console becomes unavailable.
I've tried setting breakpoints to pause the app which doesn't work.
How can I view these Javascript Console logs after the debugger stops ?
EDIT: this if for Windows Phone (Universal) with plugins for Windows Phone and not debuggable in the browser
this is the only way i've figured ;
Ensure JS console button "Clear on navigate" is not set
Start the app so that the errors appear albeit momentarily
Remove plugins and associated code one by one until your app doesn't crash
View original error messages in the JS console from previous sessions
This doesn't answer your question but it may help to check the exception settings via:
Debug -> Windows -> Exception Settings
They determine whether or not the debugger will break when exceptions are thrown.
Before I get into the details, please note:
I'm using Meteor 1.2 and the latest version of WebStorm 11.
Client-side debugging works fine, at least using the Chrome Web Inspector, client-side logging is shown in the console.
My issue is I can’t get server-side debugging to work. I’ve now tried all of the following to no avail:
Running meteor debug and launching Node Inspector (it hooks into my Meteor instance but doesn’t log anything server side or hit any breakpoints I've set using debugging; statements in the code, code execution was not suspended)
Launching Meteor from WebStorm, putting console.log() statements all over the place. Nothing would get printed, breakpoints wouldn’t be hit
Running meteor shell and trying to see logging there
Using Atom IDE instead, however this is not suitable for me because of a company proxy which the Atom plugin manager isn't able to circumvent (doesn't route proxy info).
WS 11.0.2 definitely broke this. Although not listed on JetBrains' website, typing in the download executable URL for WS 11.0.1 by hand (http://download.jetbrains.com/webstorm/WebStorm-11.0.1.exe) allowed me to get back to the previous minor version. After installing 11.0.1, I am able to debug my code in the WebStorm IDE, set and hit breakpoints and see server-side logging.
I'm looking for a way to open the WebKit “developer tools” from a script attached to a web-page. I need solutions for both Google Chrome and Safari, that will open the developer-tools pane if it's not already open, and (hopefully, if you can figure out how) also switch to a particular tab/section of said pane upon opening.
(Use-case, if anyone's interested: I want to open the console.log output-window if there's been an error and a developer is looking at the page; this particular page will be the output of some JavaScript unit-tests.)
I'm setting a bounty on this question because it's obviously one that hasn't been answered to anyone's satisfaction before, and the answer is a hairy one. Please don't answer it unless you have a real answer that both: 1) works in both browsers, and 2) doesn't require private extension APIs that won't work from a static web-page.
See (related, but specific to Chrome, and extensions): Can I programmatically open the devtools from a Google Chrome extension?
Simply: You can't.
The Dev Tools are not sandboxed (unlike any web page), thus granting sandboxed environments the power to open and control an unsandboxed environment is a major security design flaw.
I hope this answers your question :-)
You cannot directly use the Chrome's Dev Tools from your web pages. It is bundled with the browser.
But you can use it like a regular web application. Go to Chrome Developer Tools, then go to Contributing. You will find help on using Dev Tools for your app.
Setting up
Install Chrome Canary on Mac OS / Windows or download the latest Chromium build from the Chromium continuous builds archive on Linux
Clone Blink git repo from https://chromium.googlesource.com/chromium/blink.git
Set up a local web server that would serve files from WebKit/Source/WebCore/inspector on some port (8090)
Running
Run one copy of Chrome Canary with the following command line flags: --remote-debugging-port=9222 --user-data-dir=blink/chromeServerProfile --remote-debugging-frontend="http://localhost:8090/front_end/inspector.html". These flags cause Chrome to allow websocket connections into localhost:9222 and to serve the front-end UI from your local git repo. (Adjust the path to chromeServerProfile to be some writable directory in your system).
Open a sample page (eg www.chromium.org).
Run a second copy of Chrome Canary with the command line flag: --user-data-dir=/work/chromeClientProfile. Open http://localhost:9222. Among the thumbnails you will see the sample page from the other browser instance. Click on it to start remote debugging your sample page.
The DevTools web page that opens is served from the remote-debugging-frontend in the first browser instance, which serves from the git repo your local filesystem. Debug this Devtools Web page and edit its source like any other web app.
I hope this is what you need.
There's no way to control the web developer tool from an in-page script, other than through the Console API which provides mostly logging facilities. Letting scripts control more than that would be a serious security issue, since it would allow a web page to control parts of the browser.
The only API remotely related to what you're trying to do is the debugger command, which switches to the script pane only if the developer tools were already open.
But who are you trying to develop this feature for?
If it's for developers working on the site, then it's better to just use the existing developer tools manually, by setting breakpoints, or the pause on exceptions toggle.
If it's for end users, don't. Unless your site is supposed to be used by highly technical web developers, you're only going to scare away users if the developer tools suddenly pop up with errors.
If you really want to show errors you can implement your own logging framework and the UI for error reporting, which works with basic JS and doesn't depend on a specific browser environment.
here's another answer that proposes a solution to your mentioned use case/objective (detecting errors, getting & displaying console logs) and not the not possible objective in the title.
you can make and use a console wrapper and use it in your code
and/or you can monkey patch the console functions if you use/import external js, but you need to apply it before loading them.
No, Any secure Browser will not allow a script to open an extension, as it leads to insecurity.
But, You may design an Add-On/extension OR Console API's to do the same.. for specific site.
Create an Add-On like this to achieve that requirement.
You can try sending keys 'CTRL' + SHIFT' + 'I'
that may work for Chrome any FireFox (in I.E you need to use 'F12'
I am using it when required as few utils in this add-on use to work better then the built-in.
EDIT:
Now a days Chrome is advanced with many new advancements source.
I hope this helps!
Hate to answer such an old question, but was surprised to not see this as an answer, so I thought I'd add it in case it can help someone in the future.
Assuming you have access to the source code, you can place an alert("open devtools"); statement immediately before the first line you're interested in debugging. This alert will give you an opportunity to open DevTools and set a breakpoint on that first line before clearing the alert thus allowing the code to continue and hitting the breakpoint.
I get the following error in Chrome when loading a trivially simple html file with a jQuery Mobile reference. The error is not present with just the jQuery reference.
Uncaught SecurityError: Failed to execute 'replaceState' on 'History':
A history state object with URL 'http://stacksnippets.net/js' cannot
be created in a document with origin 'null'.
<html>
<head>
<script src="https://code.jquery.com/jquery-2.1.4.js"></script>
<script src="https://code.jquery.com/mobile/1.4.5/jquery.mobile-1.4.5.js"></script>
</head>
<body></body>
</html>
You can also "Run code snippet" and see the error in the console.
This error did not happen before today. I have not changed my code or method of loading the html file in the browser. It used to work perfectly - I use the same code for all my PhoneGap apps.
Does anyone know if there was a Chrome security update that causes this SecurityError or whether I'm missing something? How would you go about debugging this? Thank you.
UPDATE
This discussion I think points out what is going on, which I suspected, since the error does not appear when running with a web server: Origin null is not allowed by Access-Control-Allow-Origin .
But I am still wondering why this changed in the past day, whether Chrome has had a change in their security policy, or why it was working before, and whether any of my PhoneGap apps will be affected.
This error is same as the origin is null error. This error occurs because of the security feature of Chrome.
A simple solution to test the application is to bypass this security on chrome.
Steps:
create a chrome browser shortcut on desktop.
Close all the instances of chrome on your machine.
Right click on the desktop shortcut of chrome and click on Properties.
in Target field, append " -allow-file-access-from-files" at the end.
Save and close properties.
Open chrome via this shortcut only.
Hurry, the error has gone. App works perfectly.
NOTE: This is just a work-around I use to test my cordova apps on desktop browser for UI testing.
Temporary solution: I've commented out all history.replaceState calls in jquery mobile, didn't need to manipulate browser history in my app anyways.
I wonder if it's chrome security bug or model and future behavior.
On a Mac I was able to fix this by running a webserver instead of loading it from a "file://" url:
http://lifehacker.com/start-a-simple-web-server-from-any-directory-on-your-ma-496425450?utm_expid=66866090-49.VYy4WCNHSyuP6EmjnM93MQ.0&utm_referrer=https%3A%2F%2Fwww.google.com%2F
python -m SimpleHTTPServer 8000
In the directory should make it available from Chrome via 0.0.0.0
I don't seem to have the same problem, not on the stable version of Chrome (45) or the Dev version (47).
However, I have personally seen issues with the CORS header, too. If you can cause the problem to happen reliably, I suggest filing a bug at crbug.com and a Chrome developer will have a look at it.
I want to debug my PhoneGap app in Xcode, but its Console can not show javascript errors.
The most elegant way to view and debug JavaScript errors in your Cordova/PhoneGap App is by attaching the Web Inspector from your Safari browser to the Web View in your iOS App (but, like Tom Clarkson already mentioned, you will need at least iOS 6).
On your iPad or iPhone use the Settings App to enable Web Inspector in the Advanced Settings for Safari
Connect your device to a Mac via USB (it will then appear under the Develop menu of Safari)
Start your App
Navigate to the Web View you want to debug
On the Mac, from the Safari Develop menu, select the name of your device and the App (its HTML-page), from its sub menu
A Web Inspector window will open, enabling you to browse the DOM, set breakpoints etc.
Apples documentation on setting this up
A thorough third party tutorial
Alternatively you could connect Chrome’s Web Inspector to iOS devices after installing iOS WebKit Debug Proxy. This also opens up the ability to do the inspection from Linux or Windows.
Remote access to your iOS’s HTML, CSS and JavaScript has gotten even more flexible nowadays because you can install the RemoteDebug iOS WebKit Adapter on top of aforementioned Debug Proxy. Because this adapter translates the WebKit Remote Debugging Protocol to the Chrome Debugging Protocol, these (on all their supported platforms) become available as alternative debugging and inspection tools:
Visual Studio Code
Chrome DevTools
Mozilla Debugger
BTW, remote debugging with the Safari Web Inspector works even in combination with the iOS Simulator.
Minimum version of Desktop Safari per iOS version
For each version of iOS you will need a specific minimum version of Desktop Safari in order to use remote web inspection, see the list below.
iOS 6
Safari 6+
iOS 7
Safari 6.1+
iOS 8
Safari 7.1+
iOS 9
Safari 8+
iOS 10
Safari 9+/10+? Please comment; always try Safari Technology Preview
iOS 11
Safari 11+
iOS 12
Safari 12+
Paste the following somewhere near the start of your document so that it gets executed before any of your other JavaScript.
<script type="text/javascript">
window.onerror = function(message, url, lineNumber) {
console.log("Error: "+message+" in "+url+" at line "+lineNumber);
}
</script>
And enjoy viewing details of your Javascript errors in the Xcode console window.
UPDATE: The above technique will log errors such as undefined variables. But syntax errors such as missing commas will still cause the entire script to break without logging anything.
Therefore you should add the following to the start of your onDeviceReady function:
console.log('Javascript OK');
If you don't see "JavaScript OK" appearing in your log window when the app launches, then it means you have a syntax error somewhere.
To save hunting for missing commas, the easiest thing is to paste your code into a Javascript validator such as this one:
http://www.javascriptlint.com/online_lint.php
and let it find the error for you.
Hopefully that takes some of the pain out of debugging.
Note that with 0.9.2 (released today), console.log has been standardized across the platforms for logging (with debug.log deprecated).
There is a function that is available on the desktop WebView that is not exposed in the iOS UIWebView that will catch all errors (I'm trying to hack that functionality into a plugin, which uses private APIs, but the plugin would only be for development), but for now do what Kris suggested above and put try catch blocks on code and use console.log
To quickly catch possible syntax errors, when developing I have the page loaded in desktop Safari and quickly refresh it with the webkit error console viewable.
debug.log will send messages to the XCode console in Phonegap (allowing you to either log the result of an exception or do some debugging), however, you are correct that you have to debug other javascript errors in Safari (either on the desktop or on the iphone with Debug Console turned on). I have yet to find a Javascript error, that was caused by running on the iphone and wasn't present when debugging with the console turned on in Safari (though I know there are a few differences between the WebView and Safari on the iphone).
I just came across Weinre
It's a remote javascript debugger for phonegap. You can either setup your own Weinre server, or use the one at http://debug.phonegap.com/
It seems to work well - very impressed so far.
If you use iOS 6, you can simply attach the safari web inspector (on the develop menu of desktop safari) to your app and get full javascript debugging.
There are a couple of areas where it is a bit limited - startup errors and plugin calls - but it works well for pretty much anything else.
For making javascript debugging work in Xcode I would take a look at the following.
http://phonegap.com/2011/05/18/debugging-phonegap-javascript/
http://www.daveoncode.com/2010/01/12/debugging-phonegap-applications-using-xcode-console/
As as far as additional troubleshooting goes...
To start with you could run the app in safari on you pc and utilize safari's debugger (or chrome as both are running similar rendering engines). This won't hit on the advanced logic errors and many of your api issues but it at the very least should help with troubleshooting many issues (basic javascript, HTML5 etc....).
To view all errors in javascript console, I agree to use this event listener
<script type="text/javascript">
window.onerror = function(err,fn,ln) {alert("ERROR:" + err + ", " + fn + ":" + ln );};
var errorVar = objectDoesntExists.properyDoesntExist;//this will simulate an error
</script>
However, unless you have the cordova plugin installed, it wont show on XCodes "console". Go to your project folder and type this:
? cordova plugin add cordova-plugin-console
This will allow the javascript command 'console.log('some string') to show on XCode.
Note you will need git, etc... but if you are editing your phonegap project in xcode, you will most probably have it!
PS Make sure you put the cordova.js script plug-in before any use of console.log
<script type="text/javascript" src="/cordova.js"></script>
Put this in the beginning of your index.html
<script type="text/javascript">
window.onerror = function(err,fn,ln) {alert("ERROR:" + err + ", " + fn + ":" + ln);};
var errorVar = objectDoesntExists.properyDoesntExist;//this will simulate an error
</script>
Here's a simple way that worked for me:
cd to the directory containing your index.html file in the terminal
Start a http server using python by invoking (I used python 2.7):
python -m SimpleHTTPServer
View the page in safari by entering the address of the HTTPServer in a browser, for me the URL was:
http://0.0.0.0:8000/
Open developer tools:
In chrome this is alt+command+i. View the console tab, may need to refresh the page.
In Safari: Safari --> Preferences --> Advanced --> check "Show Develop Menu". Develop menu --> Show error console (or alt+command+c). Refresh the page. Hitting CTRL+5 opens the issues tab.