I am trying to debug in chrome dev tool. My form shows some weird validation error when I type something into the input field and then quickly click somewhere outside the field. I found the browser debugger is not able to catch my last click behavior and it becomes very difficult to debug where things go wrong. Is there a way to slow down the debugger's reaction?
Related
A while ago I was working on a webapp and for the purpose of debugging I've added a listener function directly in the console of Chrome Dev Tools and I've included a js debugger keyword in it to have a breakpoint there.
Now I can't get rid of that debugger and whenever I try inspecting the page, click on Select an element in the page to incspect it and I click anywhere on the page to take me to that node in the DOM structure I'm entering the breakpoint and I need to Continue script execution multiple times.
The debugged code looks like this:
I've tried triggering Never pause here option on each possible line, but it just opens a new VMxxxxx file. The breakpoint is not available in the Breakpoints list so I can't remove or uncheck it from there. Do you know how to get rid of it?
I was having the same issue, i found that one of my browser extentions was throwing the anonymous debugger. I solved the problem by disabling all my extentions, confirming the anonymous debugger issue went away and then reenabled one extention at a time.
With Pry (but also with Rubymine), I'm trying to debug a certain point in the code (using binding.pry). After calling Capybara's save_screenshot, I'm unable to execute any Capybara related commands (all commands die on time-out). This works out of a "debug mode" and in other web-drivers like Poltergeist.
I took a couple of hours today trying to debug it. I think I found the problem - or at least a way around it.
Our web site has a couple of links that open content in another browser window. Since the automation is quite ancient, and in that time Selenium didn't have a decent way to switch window-context, what we do is to visit the opened page by URL, and by this keep only a single window open at any given time.
This works, but something strange happens when running this test on "debug mode" (using binding.pry for example). Right before we do any actions on that specific page, we take a screen-shot using Capybara's save_screenshot method. On debug this results a corrupted image, and any following Capybara methods will fail on time-out. Opening this page using the link, and handling the windows context switching with Capybara's handle_window method solves the issue. It's still a mystery why it only happens with Capybara wekit though (as other web-drivers work properly). I'm guessing that perhaps the DOM might be structured differently.
Bounty Update
I am leaving the question essentially the same, but I just want to point out at the beginning here that I'm most interested in help trying to get the socket between flash (Adobe Animate) and the native debugger working again, as I believe that is the issue I'm having. Or is it a socket between flash and Windows?
Original Question
I've apparently turned something off? Even when I write really bad code (like trying to call a function that isn't there or divide an integer into a fraction), the flash player boots, shows a background color and stops there. No messages in the output window or compiler errors window. If I fix my code, it all runs fine, but for about 30 minutes (ever since I started trying to work with bitmaps for a sprite sheet) I get no runtime errors no matter what kind of mistake I type in my code. Anyone know how to turn it back on?
I've checked my actionscript settings and I have both warning mode and strict mode checked on.
Could it be a socket issue? I admit I have little to no experience working with sockets and only a surface understanding of what that even means. I've added the socket tag. If someone can see that this is clearly nothing to do with sockets, by all means, I'll remove the tag.
UPDATE: 6/22/16
I just reinstalled Adobe Animate CC 2015.2 and no change. I'll try compiling it in flash builder when I get a chance to help pigeon hole the problem. (Edit 6/24: flash builder worked! But my trial version expired the next day so is no longer a viable option).
And I just tried something in the command prompt in Windows 10 as an administrator:
netsh winsock reset catalog
netsh int ip reset reset.log hit
which I found another user on flashdevelop.org used to fix a similar issue, but no change.
And I just tried debugging in Flash Builder. It worked fine (debugger caught bugs) but my trial version expired the next day.
update 6/24
I've tried launching debugger for AIR from within the Adobe Animate CC IDE and it works fine if there are no bugs; it fails to do anything visible (no Iphone emulator, no swf window) if I put a typo or error in the code.
I also just deleted winsock and winsock2, rebooted Windows, then reinstalled winsock and winsock2. No change.
update 6/25
Just tried a system restore in Windows to set all my files and settings and drivers etc. to the way it was a week and a half ago... Also completely uninstalled all Adobe products and reinstalled. No change. I can only imagine that wiping my hard drive and reinstalling Windows would do the trick, but come on, it hasn't come to that has it?
As VC.One suggested, I checked the compile error window (cannot believe I didn't check before! Maybe when I checked before there were no compile errors... Only runtime errors?) and the errors are showing up there. Does this mean that it's catching compile errors but just not runtime errors?
When you force/test a runtime error... make sure you check
Compiler Errors (ALT+F2) and also Output (F2). By Output I mean the window that shows traces (and runtime issues). One of those two should have some feedback for you.
A possible solution is to save a new Workspace. So with those windows for Compiler Errors and Output both open (or tabbed, I tab them next to my Timeline) go to Window (in top options like File/Edit/Debug etc) and choose Workspace, then into that you choose New Workspace. Give it a name in the pop-up and okay everything.
Flash should always load that current workspace (next time, go to Workspace option again, check that your specified workspace [by name] has a tick next to it...).
Possible pitfalls:
1 - Use the debug player
2 - Make sure there isn't somewhere a try/catch enclosing the portion of code that triggers the event that may lead to an error
3 - Socket issue: may be exported in debug mode but swf cannot connect to debugger (it waits in a blank state for 60 seconds I guess)
4 - Does it compile ok? If there are compilation errors you may get an SWF anyway but then it will not start
...
I'm new to Eclipse. I may need a better understanding or a plugin that would provide me with features described below. While doing some Android development, and I while making changes to my code at one point Eclipse warned me that this emulator doesn't support hot-swapping and if I want to disconnect. I'm used to see status in either the toolbar or in some log from Visual Studio. Is there a way to see this feedback in Eclipse?
My problem is that there are quite much implicit stuff in eclipse I would like get feedback of and control, like whether I'm
connected or not to a device,
if I'm attached to a process on it or not with debugger,
some kind of build log with a timestamp so I know it happened,
the automatic uninstalling and installing of the project on the device
which project is "active" ("featured") in "Run" and "Debug" buttons/configurations
Is there a plugin that can give me explicit commands over these automatic features? Like a toolbar or command. What I would expect of this tool:
be able to indicate the current status (eg. currently connected or not)
gives me control to eg. connect
gives me control to eg. disconnect
Preferably on a toolbar, as I know some of these are available as menu commands.
Furthermore I tried to configure my toolbar by Window menu -> Customize perspective..., but pin-pointing the features I want made my Eclipse put empty space up for the buttons I disabled, and next time I got to the same config screen it got the checkboxes wrong and displayed some stuff active what was actually disabled.
While trying to use GWT Super Dev Mode, I followed those guidelines :
GWT-2.5-Super-Dev-Mode
Introducing Super Dev Mode
How does GWT's Super Dev Mode work?
However, I am stuck at the step trying to turn on Super Dev Mode :
Once I fully compiled my project, I run the code server and the dev mode, go at http://127.0.0.1:8888/myapp.html (without the ?gwt.codesvr=127.0.0.1:9997) and then click on the bookmark Dev Mode On. It detects my module, asks me to recompile, a glass screen appears with a message Compiling MyApp ... and then nothing ... No error, no stack trace either in Chrome or Eclipse. Just nothing happens.
Debugging the js code from dev_mode_on.js file, the script is interrupted at line 324 :
...
function getBindingParameters(module_name, get_prop_map) {
var session_key = '__gwtDevModeSession:' + module_name;
--> var prop_map = get_prop_map(); <--
...
Once the function get_prop_map is called, a few more obfuscated functions run and the debugger returns.
I know it is still experimental, but do you have any idea of what I could have done wrong ?
PS: I am using GWT 2.5, GWT-maven-plugin 2.5 and Chrome 23.0.1271.64 m
We have found a similar issue and tracked down the cause, looks like a boundary case not handled in GWT.
More info can be found here: http://code.google.com/p/google-web-toolkit/issues/detail?id=7894
I don't have an answer, but I can give some general debugging tips for this sort of problem.
Super Dev Mode currently (as of 2.5) doesn't report any progress to the web browser while it's compiling. It won't update the dialog until the compile finishes. So it's possible that it's just very slow for your program for some reason, or the compile stopped and somehow didn't report an error like it normally does.
However, there are other ways you can monitor its progress. The compiler log is available as a web page by following links from the code server's front page; you will have to refresh the page to see updates. Or you could look at the log on disk in the code server's work directory. (You can set the work directory with the -workDir argument when you start it.)
Another way is to start the code server from the command line. Any stack traces from the code server will be printed there. You should also be able to look at the output in Eclipse or IntelliJ if you're running it from there.
From this you should be able to tell whether the compiler is slow, but still working (it's still printing output) or has actually stopped with a stack trace.