I am newly working on a fairly old system, which uses ColdFusion if it matters. In various places, it uses Ajax.Updater for server requests which return new HTML (.cfm) fragments to update the specified element with. This HTML also includes JavaScript via <script>'s and inline event handlers, ie. <button onclick=...
The question is how can I go about debugging this code?
HTML (and .cfm) documents typically show up in the sources tab and can be debugged like normal JS, but in both Chrome and Firefox, the fetched HTML is not showing up. I can clearly see the new html being fetched in the network tab, the new elements are rendered and appear in the elements tab, and the actual JavaScript is clearly running as expected; it just doesn't show up in the debugger.
Does fetched code simply never go to the debugger? Is it because the fetched html is a fragment? Is there some other known way to debug code from Ajax requested HTML?
Related
Why is that when I edit the HTML in inspect element it will run immediately but when i edit the JavaScript it doesn't run? Are there any solutions?
When you use your browser's developer tools (via inspect element, in your case) to edit the page, you're not actually editing HTML, you're editing the live current state of the DOM tree.
When your site first loads, your HTML is parsed, and a tree of elements is built up. This is added to a Document, which is then rendered for you in the browser's viewport. As soon as that HTML is parsed, it essentially ceases to exist. When you open your developer tools, HTML is re-generated from the current DOM and displayed to you. This is for human convenience.
It's important to make this distinction, as it helps explain the difference between the way HTML and JavaScript are handled.
For JavaScript, it is parsed as soon as your browser hits the appropriate <script> tag. This code is shipped off to the JavaScript engine for parsing and execution. Unlike the browser developer tools for inspecting the DOM as HTML, there isn't really a way to poke inside the JavaScript engine to recreate a JS code representation of the currently running context. (The profiler is the closest thing to this.) Therefore, there isn't any equivalent view to live-edit the JavaScript.
However!... Some browsers such as Chrome have a feature that allows them to hot-reload content from disk, including HTML and JavaScript. This is actually directly integrated in your browser's developer tools under Sources. If you go there and add a local directory, it will allow you to edit these files. As you edit them, Chrome will reload them without reloading the whole page. If you happen to have code referencing functions in a file external to the HTML, then that code will be replaced with the new functions in the new file. It's also good to note that you can edit this JavaScript in an external editor and get the same functionality.
Just to be clear, this hot-reload functionality only works locally, and is completely different than editing the DOM with inspect element.
Please add comments if you need any clarifications!
The difference lies in the difference between HTML and JavaScript. HTML is a markup language that is used to display the content on the page, so any change made to that markup will immediately be reflected because you are changing the underlying structure of the page.
JavaScript, on the other hand, primarily executes when the page is loaded and then it's done unless you've attached event handlers for click events, etc. Editing the JavaScript on a live page doesn't change anything because the code has already been run.
You can find more answers about when JavaScript is executed and the differences on this question: When does the browser execute Javascript? How does the execution cursor move?
If that doesn't answer your question post a code sample and I'll see if I can help you further.
I'm trying to debug an issue on a single page web app that is rendered using javascript. I'm mostly unfamiliar with how the page was built.
Is there a way that I can detect how a particular element is being rendered, or at least when it's being added to the page?
I'd like to set a break point for when the item is created or added to the DOM, or first rendered in the page.
I'm open to any solutions that preferably work in Chrome, like the Chrome Developer Tools, or a debugging bookmarklet, etc.
Trying to automate some tasks on a private web application. When I use a right click > Inspect Element on a form field for example, I am shown the Inspector panel, and the HTML element is shown, with its id right there. Problem is, if I run a
document.getElementById('theId_shown_on_the_inspector');
on the console, I just get null back. This web application relies on Java by the way.
Is there anything you can think off that may throw some light on this weird behavior? Basically I need to be able to automatically populate some fields and click on some buttons, but I cant if I am not able to detect them.
As shared by Jaromanda X, the page has iframes loading content from other URLs. Since I was working with GreaseMonkey, I did not include these URLs in the list of #includes, and using the Firefox console was not working either because you have to select and load those iframes into context (again as indicated by Jaromanda X).
Firefox provides enough details about the iframe URLs which to include in the GreaseMonkey script.
My iOS app includes a UIWebView which runs some Javascript. I am able to attach Safari web inspector to my apps UIWebView instance and have the debugger invoked when a breakpoint is hit, however I am not able to view the actual javascript code.
I am able to see the variables and the call stack, but the source code window is blank.
Is there something that needs to be done in order to make the source code visible?
Switching to the DOM tree view does show the contents of the page, but this is not source level javascript debugging.
Is it possible to actually have the source code for the Javascript being debugged visible in the web inspector?
The reason that the code is not visible is because I was making use of the loadHTMLString method on the UIWebView.
Making use of a file URL and loadRequest to load the request allows for the code to become visible.
I noticed that the source code shown in Firefox appears to be incomplete. I have the latest version. When using the Firebug plugin to look at a webpage, I am able to find elements which are simply not recognized by Firefox.
This is for a automated script I am working on.
I am wondering several things:
Why is a firefox plugin able to recognize elements Firefox is not?
Is there a way to pass the source from Firebug engine to Firefox, or any other viable workaround which would enable Firefox to recognize all of the elements on the page?
My guess is that these "hidden" elements have been created by javascript after the page load, but I'm not really sure.
I'd say Firebug is displaying what's in the DOM (i.e. what is in the page at the instant you are looking at it), while View Source is displaing the source that has been received from the server (i.e. what is in the page at the first instant it's displayed).
If you want to see the "source" from the DOM, maybe the Web Developper Toolbar Extension can help : from what I remember, it provides a "view generated source" option.
For No.2
Open Any Page, and Press Ctrl+A or Select All, and right click, click View Selection Source, You should able to see any html nodes as you see in Firebug.
Your guess is correct. "View source" reveals exactly what the server has passed down to the client. What Firebug shows you is the "rendered source code", which is taking the current DOM state, and rendering it back into a HTML representation, that may or may not look very much like the actual HTML code written.
Your question is unclear.
The View Source command displays the raw HTML that was downloaded from the server.
Firebug's HTML tab shows the elements that are currently on the page.
Any changes made by Javascript will show up in Firebug (which gives a live view), but not in View Source. (Because they weren't in the HTML that was downloaded from the server)
Firefox's View Selection Source command, which appears only when some text is selected, shows the live source from the DOM and should show exactly what you see in Firebug. (Except that it won't update after you click it, so if the DOM changes again, you'll need to click it again to see the change)
To see the source for the entire page, you can press Ctrl+A, then right-click and click View Selection Source.
If theis doesn't answer your question, please elaborate.
Firefox shows the source code as it comes from the server, any alterations to it via JavaScript will not show up. Firebug keeps track of the changes to the document and updates the source code.
Doing Ctrl-U or View | Source will just give you the static HTML document that is returned by the server.
What you probably want to look at - and what you are seeing in Firebug - is the rendered DOM. If you install a Firefox addin such as Web Developer you will be able to view the rendered DOM - i.e. the HTML dynamically rendered in javascript and the actual document the renders in the browser.