Many times I've faced this problem when a code will generate exception( eg. method not defined in object) it will not show up in the Firefox console. Firefox will simply skip that part of code.
After unable to figure the problem out, I'd need to use Chrome console to see the exception. Or I can wrap code in try-catch to see exception when run in Firefox console
Any solution so that Firefox only will show the exception code without wrapping the code within try-catch where it is happening?
You can visit the debug console directly by opening about:devtools-toolbox?type=extension&id=<extension id> in a new tab, then click the Console tab in the debug console. Any console log (console.log, console.info, etc) will appear there if no filter is specified. Uncaught exceptions will also appear here.
You can find your extension id in the overview of addons, or by supplying one manually in your manifest:
"browser_specific_settings": {
"gecko": {
"id": "addonname#yourdomain.org",
}
}
This is what it looks like for an addon of mine:
You could also use the web-ext tool developed by Mozilla to debug your addons, which will also show console logs, however it is less useful than about:devtools-toolbox because it cannot expand nested objects.
npm install --global web-ext
cd /path/to/your/extension
web-ext run --verbose
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 am attempting to run protractor tests locally using chrome but in headless mode, I have seen the docs and added the appropriate options to my config file:
capabilities: {
browserName: 'chrome',
shardTestFiles: true,
chromeOptions: {
args: [ '--headless', '--disable-gpu', '--window-size=800,600' ]
}
}
Upon running, I encounter the following error:
[1009/122000.081:ERROR:gpu_process_transport_factory.cc(1007)] Lost UI shared context.
I tried removing the --disable-gpu flag as I read this may not be needed in future version of Chrome. I currently have latest Chrome installed (69.0.3497.100) and am using windows 7.
What do I need to do in order to get the tests running in headless mode? My intention is to check I can run in headless mode fine locally and then I want to get it running also in Chrome headless mode on a linux Jenkins node, where we are currently using XVFB but its proving to be too flaky with timeouts in tests for example.
Thanks
EDIT
With regards to others marking this as a duplicate - I should have said that my tests fail to run when I attempt to use the headless option, without the chrome options set, Chrome launches as expected and the test run and pass successfully.
My tests fail with no such element found type errors and if I view the screenshots taken on the failures, I just see a white square inside a black background (probably as per the --window-size option I was setting)
As you mentioned you are using Chrome headless mode on a linux Jenkins node you need consider a few factors as follows:
--disable-gpu
When Headless Chrome was first released as GA (General Availability) by Google Team the article Getting Started with Headless Chrome mentioned that :
--disable-gpu \ # Temporarily needed if running on Windows.
A note was added as :
Right now, you'll also want to include the --disable-gpu flag if you're running on Windows.
As per the discussion Headless: make --disable-gpu flag unnecessary it was clear that :
The --disable-gpu flag is no longer necessary on Linux or Mac OSX. It will also become unnecessary on Windows as soon as the bug SwiftShader fails an assert on Windows in headless mode is fixed.
You can find a detailed discussion on What happened under the hood in the discussion ChromeDriver showing Lost UI Shared Context
So as a first step you need to remove the argument: '--disable-gpu'
flaky tests
You seem to be executing your tests with the argument --window-size=800,600 which implies a reduced Viewport.
In order to utilize the maximum possible Viewport you must initialize the Chrome Browser in maximized mode through the argument: 'start-maximized'
angular
From Angular perspective, you can avoid timeouts by using the proper expected_conditions. You can find a detailed discussion about different expected_conditions in WebDriverWait not working as expected
--headless
Finally, I am not sure what exactly you meant as in ...my tests fail to run when I attempt to use the headless option, without the chrome options set.... Perhaps the argument '--headless' can be invoked only through chromeOptions and no other alternative.
I have the same error while running [1010/161441.019:ERROR:gpu_process_transport_factory.cc(1007)] Lost UI shared context.
but my test runs perfect.I have you referred this https://gist.github.com/cvuorinen/543c6f72f8ec917ebfd596802d387aa3
I hope this below may help you
https://cvuorinen.net/2017/05/running-angular-tests-in-headless-chrome/
https://developers.google.com/web/updates/2017/04/headless-chrome
Our angular app sometime does not load on chrome canary (Version 41.0.2237.0 canary (64-bit)) saying
Failed to instantiate module ngHintModules due to: RangeError: Maximum
call stack size exceeded
But it loads fine in firefox, chrome (Version 39.0.2171.71 (64-bit)), safari.
Probably not sure whether there is something to do with angular or not.
Full error
Uncaught Error: [$injector:modulerr] Failed to instantiate module ngHintModules due to:
RangeError: Maximum call stack size exceeded
at Array.forEach (native)
at module.exports (chrome-extension://ighdmehidhipcmcojjgiloacoafjmpfk/dist/hint.js:2333:21)
at module.exports (chrome-extension://ighdmehidhipcmcojjgiloacoafjmpfk/dist/hint.js:2384:5)
at chrome-extension://ighdmehidhipcmcojjgiloacoafjmpfk/dist/hint.js:2387:7
at Array.forEach (native)
at module.exports (chrome-extension://ighdmehidhipcmcojjgiloacoafjmpfk/dist/hint.js:2385:21)
at chrome-extension://ighdmehidhipcmcojjgiloacoafjmpfk/dist/hint.js:2387:7
at Array.forEach (native)
at module.exports (chrome-extension://ighdmehidhipcmcojjgiloacoafjmpfk/dist/hint.js:2385:21)
at chrome-extension://ighdmehidhipcmcojjgiloacoafjmpfk/dist/hint.js:2387:7
NB: The Error I am showing here is from
Version 41.0.2237.0 canary (64-bit)
I also had this problem which was resolved by disabling Batarang.
This issue is opened on the Batarang Github here: https://github.com/angular/angularjs-batarang/issues/156
You can load the prior version of Batarang from this zip file: https://github.com/angular/angularjs-batarang/archive/v0.4.3.zip
Open More Tools->Extensions in Chrome
Locate AngularJS Batarang and click on the trash can to remove the extension
Download the .zip
Extract the file
Open More Tools->Extensions in Chrome
Check Developer Mode at the top
Click 'Load unpacked extension'
Select the directory where you extracted the zip
If you get an error about the manifest file, then you probably selected one directory level too high. Make sure that you select the bottom level angularjs-batarang-0.4.3 directory
Load up an AngularJS page and use Batarang again with Inspector just like before
This will restore the previous version which while having issues does have some mostly working features like Performance profiling, scope inspector, options, and a help tab which are gone from the latest version. The 0.7.1 version fixes the major breakage of apps, but it only provides the scope tree (no inspector) and the new angular-hint functionality.
You don't need to disable Angular batarang; just do the following:
Open the developer tools and navigate to the hint.js file (the one that is triggering the stack overflow)
Go to line 453 add add a breakpoint
reload the app, and when it hits the breakpoint just comment it out (setupModuleLoader(window)) and click continue
It will still throw an exception, (Uncaught ReferenceError: angular is not defined) but you will be able to run batarang
I know it's not the best solution, but that's the quickest thing I could find without going too deep into the problem
Update:
Checking more to what is happening I noticed that the problem happens when we have define multiple modules and we are adding the same dependencies for all of them.
for example:
angular.module("app", ["moduleB", "moduleC"]);
angular.module("moduleB", ["moduleC"]);
When I define the moduleB without passing the same deps with it's parent module, then there is no stack overflow.
angular.module("moduleB", []);
Our team just experienced this error and it was fixed by updating the Batarang Extension in Chrome to the latest.
Update...
With the new update of Chrome, the problem is back, so if anyone experienced this error, revert back to previous build of Chrome.
All builds available here, don't pick the first one.
http://www.slimjet.com/chrome/google-chrome-old-version.php
Then it should work fine!
I had the same problem with GitHub pages site (with Jekyll).
Searched for hours why does AngularJS app didn't show up (ng-cloak was never resolved).
Figured out that was Batarang which causing the issue.
Great thanks for #kpg's answer.
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.