How to attach the Debug points with the Safari Browser. As I have implemented my application in the Firebreath Framework which supports the unmanaged Code. To verify the Functionality in the Safari Browser as well, I am attaching the Debug Points but Debug Points will not hit. Is it necessary to set any kind of Property for the same . Please Let me know how to attach the Firebreath code with Safari browser?
Note that Safari starts your plugin in another process. If you look at np_macmain.cpp you'll see that there is a define that you can set that will cause it to pause and wait for the debugger to attach -- this is your best option if you need to attach early. Note that I've seen Safari kill plugins that don't respond soon enough, which tends to lead to your plugin getting killed any time it's stuck in a breakpoint.
see http://www.firebreath.org/display/documentation/Debugging+Plugins -- the Safari stuff is a little out of date, but the concepts are the same. I think the process name has changed.
Related
I am currently working on a new frontend javascript framework. In past few days I refactored the DOM updater and few another code to look nicer and to get rid of some memory leaks when DOM elements stayed detached in memory.
Unfortunately, Safari on both, iPhone and iPad 2 started crashing now from unknown reason (the rest of browsers I am testing on are fine
windows:
IE10emu/11, edge 14, chrome, opera, FF - latest versions
android:
Webview 4, 38, chrome, opera, ff - latest versions
and there is no problem).
I tried to debug it with remote debugging using the Chrome on Windows and ios_webkit_debug_proxy but unfortunately it does not show anything to me.
I am almost convienced the problem occurs when I am working with the main DOM document or with the shadow DOM document.
What is strange: when I switch logging to console on (there is extensive logging
feature in the framework) just for the DOM updater module and use the remote debug feature, everything seems to be working fine (except its slow of course) and it does not crash anymore so I can't even see when it crashes.
As I have no Mac even the Apple dev license I am looking for help of somebody who owns Mac and have some dev experience. I would like to know if it is possible to somehow debug these kind of unexpected crashes or at least if it is possible to get the reason why it is crashing (some kind of safari log?) - memory leaks, out of memory... whatever what can help me to do some workaround.
The previous version was working fine. Compared to it I am not doing anything special, especially when manipulating the DOM but the code is reordered, placed in more functions / methods and optimized a little bit.
The working (less or more :) version can be found here: http://ajsfw.azurewebsites.net/
The problematic version can be found here: http://ajsdoc.azurewebsites.net/ with logging switched off (i can switch on if necessary)
Sources for the working code can be found here: https://github.com/atomsoftwarestudios/ajsdoc.
I can also provide new, problematic sources if necessary but I don't want to push them to the main until it will get fixed so I can i.e. fork or send it as zipped package. The problem is it is a visual studio solution so bit incompatible with Mac at this time :) But I am pretty sure we can find a way.
The code is quiet complicated already and it will probably require bit of coopeartion by my side to find what is going on.
Hope you can help.
Update (problem resolved):
It was crashing on adding/removing "ontouchmove" event listeners.
I am using multiple HTML documents (document.implementation.createHTML) for templates and the main document (window.document) as a managed render target. When I loaded templates to the "shadow dom" using the innerHTML the ontouch... attribute assigned to the template tag was causing the problem so before I set the template innerHTML I rename it and later during rendering to the main DOM I addEventListener with the original name.
What is strange: before refactoring it didn't matter the event listener was registered in the template "shadow DOM". But I also added some new features so maybe one of them is causing it. Hard to debug, especially when the browser is crashing. Important is it works like charm again even with small complication in the code.
Results can be seen on links provided before, ajsdoc... is with logging so slower (slow as hell with IE10/11), ajsfw if unoptimized (unminimized) release without logging so faster.
Fixed sources commited if sbdy is interrested
So I have finally obtained some crash logs from Safari.
It is crashing on adding "ontouchmove" event listener. Now I have to figure out why it didn't crash in previous version and register it in a different time.
So, just to summarise where the problem was, I am using multiple HTML documents (document.implementation.createHTML) for templates and the main document (window.document) as a managed render target. When I loaded templates to the "shadow Dom" using the innerHTML the ontouch... attribute assigned to the template tag was causing the problem so before I set the template innerHTML I rename it and later during rendering to the main DOM I addEventListener with the original name.
What is strange: before refactoring it didn't matter the event listener was registered in the template "shadow DOM". But I also added some new features so maybe one of them is causing it. Hard to debug, especially when the browser is crashing. Important is it works like charm again even with small complication in the code.
I have more general question on how you usually approach on debugging page with tons of javascript (mostly third-party add-ons) and event watchers to discover the problematic line, which in my case causes the Chrome to crash or Firefox to freeze?
I have a landing page with many external dependencies: the usual suspects like jquery and bootstrap, but also many add-ons like sliders, re-size watchers. When I re-size there is a micro-freeze on Firefox and a crash on Chrome. This is from any block of code (some watchers most probably).
After page crashes I lose all of my dev tool data. Firebug doesn't have the timing control over scripts execution, and if I start with breakpoints I have to put dozens.
How you usually proceeding to identify the script that causes the problem and further more the block of code?
If I start with breakpoints I have to put dozens.
I used to have this problem a lot back with Internet Explorer 4/5. Those browsers made such poor use of memory that almost any significant error wold result in the browser crashing. And even before it did, the browser debugging tools were far, far worse than the Chrome ones. So what did I do? Sadly, debugger and console.log.
You must have some idea, or ideas, as to where the problem lies, so just start at wherever you are certain your code is working and add a console.log (if you can still see the logs up to the crash) or a debugger (if you can't) to every point along the way to the crash. Eventually you won't make it to one of your debugging statements, and then you'll know that the problem is in-between that statement and the previous one.
It's a really lame way to debug, I know, and as you said you will have to add a lot of debugging statements, but sometimes it's all you have.
I noticed that in my angular app the property
window.navigator.pointerEnabled
returns true
Now, because I would like to do some testing which involves pointer-events inside a jsfiddle.net I noticed that these events are not present there. This probably has something to do with the fact that here the pointerEnabled property is undefined.
My question is, how is this property controlled, how can I enabled it?
If you're testing your code in Firefox, you need to configure the browser to enable pointer events, as they're not enabled by default at the moment (my current latest upgrade as of 2017.xi.15 is Firefox Quantum 57.0.2 (64-bit), what I post here may change in later versions!).
To do this, you have to launch a new tab, and type "about:config" in the address bar. Then, search for the entry:
dom.w3c_pointer_events.enabled
and change the status of this boolean value to true.
Unless you do this, Firefox won't, as yet, handle pointer events at all. This will probably change in the future, but for the moment, be aware that pointer event handling is likely to be a minefield if you're interested in cross-browser compatibility. For example, the latest version of Chrome running on my machine, namely Version 63.0.3239.84 (Official Build) (64-bit), handles pointer events without having to dive in and reconfigure the browser, but Firefox caused me no end of headaches until I discovered the above config issue, and similar woes are likely to appear on other browsers as well.
Just to compound the issue, the Windows version of Firefox allows you to enable pointer events, but they are not supported as yet at all on the Firefox Mobile for Android version of the browser. So the same browser is likely to behave differently when one changes platform, just to add to your coding nightmares.
I'm not familiar with Safari or Opera, but users of those browsers are strongly advised to check whether or not similar support issues apply when using pointer events!
As a consequence, it won't matter whether you're trying to handle pointer events natively, or via a framework such as Angular, if the browser doesn't enable pointer events from the get-go. I wasted several hours on this issue, and thought it would be a good idea to spare others the same frustration.
Of course, this will not solve the problem of your end users not knowing this, and your app failing on their systems when they try to run it without configuring their browsers to do so. Or, worse still, your app failing because their browsers don't support pointer events at all (e.g., Firefox Mobile for Android I cited above). End users expect apps to run out of the box, regardless of their hardware & browser choices, except that to make this happen, you currently have nasty hurdles to negotiate. One of these being that touch event support is also hidden behind a config flag in Firefox, so you can't even guarantee that falling back on separate touch events in case pointer events are not supported, will save your app from failure.
At the moment, the only major browser that maintains some consistency across platforms in this regard is Chrome. Code I've written using pointer events works both on a desktop machine and a tablet when I fire up Chrome, but I'm now aware that Firefox is going to present me with headaches on its own, when I try running the code on the tablet.
There are probably other issues lurking in addition to the above waiting for you (especially if you're using the new CSS pointer event features as well!) but they're properly reserved for elsewhere.
Pointer events offer a new way to handle mouse and touch events with one interface. Support for pointer events is currently still rather sparse. Currently, IE11 and Edge have direct support, IE10 with prefix. FF and Chrome (>=53) are actively developing it and have it hidden behind flags (See: chrome://flags/#enable-pointer-events ).
From Safari there are no public signals so far.
There is no way to activate or deactivate it for your users. Either a browser supports or it does not.
window.navigator.pointerEnabled is the deprecated way to check if the browser supports it. The recommended way is to check if window.PointerEvent is defined.
There is a polyfill, to support FF, CH, IE10 and Safari.
I need to debug JavaScript in Internet Explorer 7.
Unfortunately, its default debugger doesn't provide me with much information. It tells me the page that the error showed up on (not the specific script) and gives me a line number. I don't know if that is related to my problem.
It'd be nice if it could narrow down the error to a line number on a specific script (like Firebug can).
Is there an addon to debug JavaScript in IE7 like Firebug does in Firefox?
Thank you!
See also:
Does IE7 have a “developer mode” or plugin like Firefox/Chrome/Safari?
Web Development Helper is very good.
The IE Dev Toolbar is often helpful, but unfortunately doesn't do script debugging
The hard truth is: the only good debugger for IE is Visual Studio.
If you don't have money for the real deal, download free Visual Web Developer 2008 Express EditionVisual Web Developer 2010 Express Edition. While the former allows you to attach debugger to already running IE, the latter doesn't (at least previous versions I used didn't allow that). If this is still the case, the trick is to create a simple project with one empty web page, "run" it (it starts the browser), now navigate to whatever page you want to debug, and start debugging.
Microsoft gives away full Visual Studio on different events, usually with license restrictions, but they allow tinkering at home. Check their schedule and the list of freebies.
Another hint: try to debug your web application with other browsers first. I had a great success with Opera. Somehow Opera's emulation of IE and its bugs was pretty close, but the debugger is much better.
you might want to try
microsoft script debugger
it's pretty old but it's quite useful in the sense if you stumble on any javascript error, the debugger will popup to show you which line is messing up. it could get irrating sometimes when you do normal surfing, but you can turn if off.
here's a good startup on how to use this tool too.
HOW-TO: Debug JavaScript in Internet Explorer
I've found DebugBar.
Not as good as Firebug, but close.
In IE7, you can bring up firebug lite for the current page by pasting the following in the address bar:
javascript:var firebug=document.createElement('script');firebug.setAttribute('src','http://getfirebug.com/releases/lite/1.2/firebug-lite-compressed.js');document.body.appendChild(firebug);(function(){if(window.firebug.version){firebug.init();}else{setTimeout(arguments.callee);}})();void(firebug);
See http://getfirebug.com/lite.html.
Microsoft Script Editor is indeed an option, and of the ones I've tried one of the more stable ones -- the debugger in IE8 is great but for some reason whenever I start the Developer Tools it takes IE8 a while, sometimes up to a minute, to inspect my page's DOM tree. And afterwards it seems to want to do it on every page refresh which is a torture.
You can inspect contents of variables in Microsoft Script editor: if you poke around under Debug > Window you can turn on local variable inspection, watching etc.
The other option, Visual Web Dev, while bulky, works reasonably well. To set it up, do this (stolen from here):
Debugging should be turned on in IE. Go into Tools > Internet Options > Advanced and check that Disable Script Debugging (Internet Explorer) is unchecked and Display a notification about every script error is checked
Create a new empty web project inside of VWD
Right-click on the site in the Solutions Explorer on the top right, go to Browse With and make sure your default browser is set to IE (it's reasonable to assume if you're a web developer IE is not your default browser in which case that won't be the default.. by default)
Hit F5, IE will open up. Browse to the page you want to debug.
VWD will now open up any time you have a script error or if you set a breakpoint in one of the JS files. Debug away!
UPDATE: By the way, if you experience the same slowdowns as me with IE8's otherwise decent debugger, there is a workaround -- if you encounter or make IE encounter an error so that it pops up the "Do you want to debug" dialogue and hit Yes, the debugger will come up pretty much instantly. It seems like if you go "straight" into debugging mode the Dev Tools never inspect the DOM. It's only when you hit F12 that it does.
IE8 has much improved developer tools. Until then it's best to write javascript for firefox first and then debug IE using alert() statements.
Microsoft Script Editor can be used to debug Javascript in IE. It's less buggy than Microsoft Script Debugger but has the same basic functionality, which unfortunately is pretty much limited to stepping through execution. I can't seem to inspect variables or any handy stuff like that. Also, it only shipped with Office XP/2003 for some bizarre reason. More info here if you're game.
I downloaded the Visual Web Developer 2008 Express Edition mentioned by Eugene Lazutkin but haven't had a chance to try it yet. I'd recommend trying that before Script Editor/Debugger.
It's not a full debugger, but my DP_DEBUG extensions provides some (I think) usful functionality and they work in IE, Firefox and Opera (9+).
You can "dump" visual representations of complex JavaScript objects (even system objects), do simplified logging and timing. The component provides simple methods to enable or disable it so that you can leave the debugger in place for production work if you like.
DP_Debug
The IE9 developer tools worked for me. Just set the "Browser Mode" menu item to IE7.
Hey I came across the same problem and found this the application IETESTER. It's pretty awesome, it's an app that has IE 5.5,6, and 7 bundled into it. It doesn't matter what IE version you currently have. This allows you to have multiple versions side by side.
If you enable javascript debugging in IE options and have Visual Studio installed you can even debug the javascript in VS with all the debug options available to you(watches, conditional breakpoints ,etc.)
If you want to start debugging before an error occurs you simply have to put the line
debugger;
into your JS code and this bring you into VS to begin debugging after this statement.
This is absolutely amazing to me for testing backward compatibility for JS code.
Use Internet Explorer 8. Then Try the developer tool.. You can debug based on IE 7 also in compatibility mode
FireBug Lite:
http://getfirebug.com/firebuglite
The answer is simple.
Get Internet Explorer 9
Press F12 to load up Developer Tools
Switch the browser mode to IE7
Running your code through a Javascript static analysis tool like JSLint can catch some common IE7 errors, such as trailing commas in object definitions.
IE8 Developer Tools are able to switch to IE7 mode
If you still need to Debug IE 7, the emulation mode of IE 11 is working pretty well.
Go to menu: Dev Tools, then to emulation and set it.
It also gives error line information.
The following tools works great for me:
1) http://www.debugbar.com/
Provide a convenience UI to with feature like source, style, DOM, Script, HTML check. It also show the actual error in your JS file (which line, which file).
2) http://www.my-debugbar.com/wiki/CompanionJS/Installing
Provide a console for IE6 or IE7 ( which originally does not support)
Screenshot
I do web site debugging with Internet Explorer (as well as other browsers), but my problem is with Internet Explorer, as it is the browser I usually use for regular browsing.
In order to debug you need to turn on debug mode in the advanced options. OK, fine. It's turned on. But the issue I have, that is quite annoying, is that it seems 30% of websites have JavaScript errors, and Internet Explorer in debug mode causes a popup. This is now also the case with Stack Overflow as well, where I spend a lot of time now. Every time I edit I get a JavaScript error pup up.
I guess it comes down to this: Is there a way to QUICKLY enable and disable debug mode, such as a Hokey, or an add-in, so you don't have to go into Advanced Options to enable and disable?
I should mention I do mainly ASP.NET development and use Visual Studio. I do already use Firefox/Firebug for some scenarios and non Internet Explorer-related issues. I'm not really looking to switch around what I do or how I do it, mainly looking for a solution to the problem at hand. Even a workaround that doesn't involve using other browsers/debuggers.
The quickest way I can think of would be to write a small utility to:
Close all IE windows
Toggle the REG_SZ registry value HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main\Disable Script Debugger (from "yes" to "no" or vice versa)
Optionally restart IE
As far as I know, there's no way to make IE recognize the changed registry value without restarting it, even using an IE plugin.
As an aside, unless the IE/VS integration is critical for you, you may want to look into the combination of Firefox and Firebug for Javascript debugging: I find it much nicer in general, and debugging can easily be enabled or disabled, either interactively or on a per-site basis.
I recommend using Firefox + IE Tab, which would allow you to easily and quickly change the rendering engine used for sites that require IE. This way the bulk of your browsing can be done in non-IE tabs and you can avoid the debug popups.
Have a look at debugbar. It's free for personal use, and it has a 60 days trial for commercial. It works a bit like fireug for Firefox, but obviously it's going to cost to use.