When I add breakpoints to source code in the Chrome Debugger, it works as expected.
However if I then remove the breakpoint and refresh the page, the breakpoints return. Likewise, if I close and reopen developer tools, the breakpoints return.
The only way that chrome forgets the breakpoint is if I close the tab altogether and open a new tab and reload the url, but as this requires a lengthy authentication process it is not ideal.
This is a react app, and I am using React Developer Tools Chrome Plugin - the breakpoints are placed in the source files not the transpiled code.
I am transpiling using babel via webpack, if it is at all pertinant to the issue.
Does anyone know if there is a solution to this issue - I can Deactivate all My Breakpoints, but they still return on a refesh (and are reactivated).
Thanks
Related
OS: MacOS Catalina 10.15.5
Browser: Firefox 78.0.2 with React Developer Tools 4.8.0 add-on enabled
IDE: Visual Studio Code 1.46.1
Framework: React
This all of a sudden started happening today. Maybe Firefox updated in the background without me knowing, but one minute this never happened, and now it won't stop happening.
Problem: Whenever I save a local file I am working on that has a React error (could be a missing component prop, or improper syntax), Firefox reloads the page but then directs me to the Debugger DevTools tab, and pauses the page. I then have to navigate back to the Console DevTools tab, and manually reload the page. It's very frustrating.
When the browser re-directs to the Debugger, there is a dialogue on the page saying "Paused on debugger statement". The highlighted debugger code is:
// --- Welcome to debugging with React DevTools ---
// This debugger statement means that you've enabled the "break on warnings" feature.
// Use the browser's Call Stack panel to step out of this override function-
// to where the original warning or error was logged.
// eslint-disable-next-line no-debugger
debugger;t.apply(void 0,o)};n.__REACT_DEVTOOLS_ORIGINAL_METHOD__=t,// $FlowFixMe property error|warn is not writable.
The only way to stop this is to disable the React Developer Tools add-on. I don't know how to disabled the "break on warnings" feature. Any help would be deeply appreciated.
===
Edit: I looked at the React Developer Tools Profiler tab, went to Settings, then Debugging, and noticed that the "Break on warnings" was already unchecked. Still unsure what the solution could be.
It's a bug from the latest React Dev Tools (4.8.0): https://github.com/facebook/react/issues/19308
Workaround is to toggle the Break on Warnings setting on and then off. They've already cut a release (4.8.1) that fixes the problem.
I had the same issue. Toggling the setting on then off again fixed it.
I'm using Chrome. For example I need Component.jsx and put a breakpoint somewhere. I press F12, select Sources tab, press Ctrl+P but all I get is 1.chunk.js, bundle.js and main.chunk.js. It's pretty inconvinient to search for the position in the files. Can someone help me to find a solution?
Have you setup your debugger right?
Assuming you use VSCode, you need to install chrome debugger extension and add vscode debugging configuration to make it work.
VSCode team has put up a nice tutorial here: https://code.visualstudio.com/docs/nodejs/reactjs-tutorial#_debugging-react
I have a React project setup using Create React App and the Typescript/React template. Everything seems to be working fine except for when I try to debug async/await functions.
The Chrome dev tools either have the breakpoints greyed out inside the async functions or when I try to click on a breakpoint (like line 6 below) it immediately moves the breakpoint to the line where the variable is set (to line 5).
Does anyone know how to fix this?
I have a working (in development) Angular app and I've just got my Grunt distribution script working how I want it to, however when run my app through Grunt and then run it from the distribution folder I just get a blank page, no errors, no logging in console, no missing files in the network tab in Chrome etc, it appears everything loads but nothing happens.
I've run into this issue before during development and thrashed around until it worked, however this is now much more complex due to the minified files in distribution etc.
I'd like to properly diagnose this blank page issue but I'm not sure where to start, it appears that Angular is simply not bootstrapping at all after processing to dist mode.
It appears there is no such thing as a very verbose diagnostic mode for Angular, I've switched to the uniminified and there is nothing reported at all.
I checked the minified html file and my ng-app tag is still there on the html element as it should be so that's not the issue.
Also if I drop to console I can type angular and get back the output for it, so it's there, just not doing anything.
Where to start?
Start with Chrome devtools open when you load the page.
Add $log.debug statements at the top of all your services and controllers.
app.js will not work without the
['paramname1', 'paramname2', function(paramname1, paramname2) {
version (all the other files minify fine with out it.)
I am trying to figure out the best way to debug my unit tests when I break them. Typically in previous test environments I could just run the tests in the browser and breakpoint the test, or the code and see why my test was failing. I can't seem to figure out how to do that with testacular. Is there an easy way to debug unit tests?
In karma.conf.js:
browsers = ['Chrome'];
In your failing spec:
it('spec', function() {
debugger; // This is like setting a breakpoint
// ...
});
Run Karma.
Go to the newly opened Chrome Browser, open the console and refresh the page.
Now in Chrome's Developer Tools source tab you should see the execution stopped at the debugger.
Include "browsers = ['Chrome'];" in your karma.config file.
When Chrome opens, you should see "Karma - connected" at the top, with a "Debug" button to the upper-right.
Click this debug button, and a "Karma DEBUG RUNNER" tab will open. Then, simply right-click, inspect element, and debug as you normally would.
I found the following way to debug which doesn't require to make any changes in code (like adding "debugger" statement)
Set the "singleRun" as false in karma config file, such that karma will be listening on debug port and you can run the test again in browser launching the URL given below and debug:
Go to the captured browser and click the "DEBUG" button (or open
http://localhost:9876/debug.html) and use the web inspector to see
what's going on. (You may need to refresh the debug.html page for it
to kick in once the web inspector is open.)
In your console you should notified which it() statement is breaking, and why. For example:
Todos Add a new todo should add a new todo FAILED
expected todo.length to be 1 but was 0
However, you may find it useful to set
logLevel = LOG_DEBUG;
in your karma.conf.js file.