What's the best way to put the "debugger;" statement inside the __doPostBack method or a way to step in the method?
__doPastBack is still javascript running in the browser.
While it's possible to debug javascript using visual studio and IE, if you want to set a break point you need to be able to open the javascript in visual studio. You can' do that for __doPostBack because it's generated by the compiler.
However, if you view the page in firefox you can use the firebug extension to set break points in the browser after the page loads.
You can manually attach to the iexplore.exe process as Script debugger and set the breakpoint accordingly on generated page. Or you could break into debugger anytime by selecting the option from menu if you had enabled script debugging in advanced tab in Internet options
In IE you can go to internet settings -> advanced -> and uncheck the "Disable Javascript debugging" boxes. This will allow you to put a breakpoint in the JS code.
It really is just a lot easier to use FireBug inside of FireFox and you don't have to go through a lot of nonsense.
Another option for JS debugging and FireFox (which I use a lot) is to use venkman. You can get it as FF extension right here.
Related
I'm a mid level website designer and manager for clients sites and I know just enough HTML/CSS to be dangerous. I use the Chrome developer tools to see where I can make CSS changes primarily.
Now for some reason, the debugging tool pauses no matter what I do. I've turned off the pause button, but it makes no difference. Has anyone else had this issue? Do I have a virus or something?
I'm trying to make CSS changes to a Wordpress login page and I can't even get it to react to my changes so I can see what I like.
Thanks in advance for any help. Here is my ugly login page that I need to fix:
http://tracoutdoor.com/wp-login.php
It sounds like your debugger may be set to break on exceptions automatically. If you open the dev tools and click the Sources tab and look at the right hand menu, ensure both the Breakpoints and Exceptions icons are greyed out (not blue) like below:
Also ensure there are no breakpoints set in the Breakpoints section.
From within my Qt application, I would like to open URLs repeatedly in the same browser tab/window. (Kind of "refreshing" this tab programmatically)
Using
QDesktopServices::openUrl(QUrl("http://www.domain.tld"));
opens a new tab/window for every call. Is there a possibility to add a "target=" parameter somewhere?
What you are asking for is impossible to do in the way you imagine it. openUrl() uses the operating system to specify the program to open the argument as mentioned in its documentation.
There might be some workarounds, but none of them will work well, or work on all browsers. It's just that this kind of fine-grained control is likely to be impossible for you.
If you want control of a tab in a browser, you could find the window represented by that tab and close it right before opening the new one. This solution is kind of hacky.
Another hacky solution is to find the HWND of the edit box holding the URL, and to try changing its text using SendMessage(). This won't work on Chrome, however, as it does not use a separate control for the URL window. It might work on Firefox or IE.
The better solution is to make your own web browser you control using the Qt WebKit. It is pretty easy to render a page in it and change the url viewed. The QWebView is an easy to use implementation of the QtWebKit.
Maybe you will found this usefull:
You can open the webpage and the reload the active tab.
If you supply the name of the browser as an argument, it'll find and reload the current page
https://unix.stackexchange.com/questions/37258/refresh-reload-active-browser-tab-from-command-line
How i can close current web form in web based application?
I have tried with following code:
mybutton.Attributes.Add("onclick","window.close()")
But its not working
Help me. Thank you.
You can use window.close() to close a pop-up window only. If you really need to close the window, use a pop-up instead. However review why the closing is important? You may consider a redirection (either server.transfer or response.redirect).
Update:
Looking at the discussion at this stage, we need to see the relevance of why wee need to close the window as desired. What is the business value that we are achieving?
You can use the following script to close the current window in Chrome and IE (I checked in IE8).
mybutton.Attributes.Add("onclick", "window.open('', '_self');window.close();");
but it still won't work in Firefox. See more info on this: How can I close a window with Javascript on Mozilla Firefox 3?
But because it is a workaround (as Kangkan said window.close() should be used only to close popup window created by window.open() ), it is not a reliable solution and can be broken if a new browser version is out.
Bottom line: there is no reliable, universal solution for your problem, there is no proper way to close a non-popup window from javascript. If you can rely on the fact that your site will be used only in IE, Chrome, etc. you can use a workaround/hack (see above - but don't forget, it can easily be broken in next browser release), otherwise you should consider a different approach of the problem, instead of closing the window.
I am trying to debug a large and complex webapp that makes heavy use of DIVs, AJAX, dynamic HTML and server-side code to do its job.
Under normal operation we do not have problems. However, when we put the webapp into an IFRAME, certain functions trigger a crash in IE7 that renders the browser inoperable (all CPU used).
What tools exist to help track down what could be happening? Loading the IE process into the debugger gives me all sorts of fascinating info about the registers, but I think the issue is in javascript.
We have tracked down one problem with the app already that involved incorrect reparenting of an element (something attached itself to window. instead of document.)
I wrote a test IFRAME page that dumps the innerHTML of the iframe into a textarea, so it can be compared during various states, but that only shows me static attributes, I can't tell what sort of javascript events are associated with elements or determine if a handler is firing out of turn.
IE8, Firefox, Chrome etc do not have the same behaviour.
Ideally I'd like something that would let me snapshot the DOM (or the javascript VM?) during a known good state, then "just before it happens" so we can figure out what's added / removed / missing / different. What is out there?
Update: I'm now trying to use the IE Developer Toolbar to track it down.
Update 2: The IE7 crash occurs following this AJAX code:
function Sys$UI$Control$get_element() {
/// <value domElement="true" locid="P:J#Sys.UI.Control.element"></value>
if (arguments.length !== 0) throw Error.parameterCount();
return this._element;
}
The return this._element; line is the last thing that happens before I lose IE.
IE Developer's Toolbar. Download it here (IEDevToolBarSetup.msi).
For JavaScript debugging refer this blog.
Some guy made a bundle that's called Internet Explorer Collection. It includes some 6 different IE browsers ranging from IE6 to IE8 in different builds. All those include Firebug (really, it sort of works) and Internet Explorer Developer Toolbar.
It was really helpful for me to debug IE7 issues.
see this link.
By placing 'debugger' in the javascript files in places where you'd like to start debugging you can debug the javascript in visual studio as well complete with trace, call stacks, etcetera.
The IE developer toolbar definitely helps alot. Visual Studios's debugger is also very good if you can get a machine with VS and IE7 on it.
DynaTrace is a profiling tool for IE7. However, it provides a great deal of information (including JS stacks), so it can also be very helpful for debugging.
IE 7 and IE 8 has built in debugging tools. Press F12 and you are ready to debug. Also firebug-firefox and chrome's inspect element options are useful/
One of the web pages on our site is extremely long. Although the page itself does not call any javascript or jquery functions, its base page registers the JQuery source script (jquery-1.2.6.js) and this seems to cause IE7 to display the "A script on this page is causing Internet Explorer to run slowly." message when you click on a link that will navigate you away from this long page.
Removing the registration of the jquery source script makes the problem go away, however there are other controls on the page that require jquery so this is not really an option.
Any ideas why this happens and is there any way around it?
Thanks.
As a crude workaround, could you unregister the script on the child page?
Did you try moving the script reference to the bottom of the page?
It looks like when you click on a link the JQuery source functions do some processing involving an array of the elements on the page. When the page, and therefore the array, is very big it triggers the IE warning.
I guess I'll have to live with it or persuade my business to drop the option that builds the enourmous page.
If it is worth it to you. you could try to optimize the jquery calls. there are some simple techniques that could really improve performance on large pages.
//cache any jQuery objects that are used frequently
$myObj = $(".someClass");
...
Also think that this is still relevant: Optimizing DOM Traversal