Here is the situation:
A page (iframe.html) has an iframe loading another page (iframe-content.html).
An JavaScript error might happen when iframe-content.html is loaded in the iframe.
I'd like that exception to be visible to the browser (e.g. shown in Firefox error console, or Firebug).
Here is what I see:
When iframe.html is initially loaded, and loads iframe-content.html with src="iframe-content.html", the JavaScript exception shows in Firebug.
However, if the page is loaded in JavaScript (document.getElementById('iframe').src = 'iframe-content.html'), the exception doesn't show.
You can reproduce this by going to:
http://avernet.googlepages.com/iframe.html with Firefox.
You'll see the exception as iframe-content.html is loaded.
Click on the button: the content of the iframe is loaded again, but this time the exception doesn't show in Firebug.
Is there a way at #3 to have the exception show, instead of it being silently ignored? (You can't use a try/catch around the JS code that sets the src, as this code returns immediately before the page is loaded in the iframe.)
It seems that your iframe page is not really loaded on the second time. Or it's loaded from the cache and the error is ignored. This is interesting, but I think I found an way around it.
function setContent() {
try {
console.log("Loading iframe content");
document.getElementById('iframe').src = 'iframe-content.html?foo=bar';
} catch (e) {
console.log("Caught", e);
}
console.log("Done loading");
}
With that the error should appear.
What I did, was to trick the browser to think that I'm loading a brand new page as the parameters after the url have changed.
'iframe-content.html?foo=bar';
You could replace my "bar" string with a changing timestamp. Sure, it would avoid the cache, but it would also force it to generate the error like you wished.
Related
Removing an iframe with:
const parentEl = document.getElementById('some-div')
const iframeEl = parentEl.querySelector('iframe')
parentEl.removeChild(iframeEl)
is causing an intermittent error "Failed to fetch" on line parentEl.removeChild(iframeEl). It pauses the debugger every time and I'm looking for a workaround to prevent dev tools from showing the error and stopping here.
So far I tried:
Call stop() inside the iframe to prevent it making any request
It's not possible to access iframe.contentWindow.document becuase it's a cross-origin iframe.
Add iframe.addEventListener('load', () => {}) to see if the iframe loaded
It only works for an initial load, but the frame seems to load some other stuff. There's no visibility of what it's loading
Add try catch around parentEl.removeChild(iframeEl)
Didn't work. The debugger keeps stopping at this line with the same "Failed to fetch" error
Solution, but only for frame content that can be changed:
This will not work with any 3rd party content only when having control over the frame source. Any fetch inside the frame which gets interrupted can have its error suppressed with a catch.
I have a JS code that creates a hidden iframe, with src="about:blank" (so that I don't load the content of the iframe if the user won't click to open it), and when the user wants to see the content of the file, I simply change the src of the iframe.
The whole code would be too much to paste, but the gist of it is:
// executed on document ready
iframeView = document.createElement('iframe')
iframeView.src = "about:blank"
// executed when the user clicks the button to show the iframe
iframeView.src = "http://example.com/some-url
However, sometimes (the keyword being sometimes -- ie. about 4/5 of times), on IE the page inside the iframe throws an error and doesn't execute any JS on that page:
Origin about: not found in Access-Control-Allow-Origin header.
I'm figuring that this has something to do with the about:blank that I'm setting on pageload. But why? And why only on IE?
Edit: Tried setting the src="", that got rid of the error, but the JS on the iframe content page is still not running.
This may be a bug in internet explorer (IE9), wondering if it is known or there is a workaround.
It can be reproduced by opening up the dev console, and executing each of these commands,
window.onresize = function() { alert("onresize"); }
At this point, when you resize the window, the event fires as expected. Now execute,
document.write("test");
After this point window.resize will be null.
That's probably expected since document.write calls document.open which clears everything.
However, even if you add back an event handler, it will never fire,
window.onresize = function() { alert("onresize"); }
You have to write the whole script block into the new document. For example:
document.write("<div>some html</div><script>window.onsize=function() { alert('onresize'); } </script>
This is because when you call document.write it creates a new document with an "empty" url. Where as your original document comes from a different Url (for example, "http://www.yoursite.com/Page1.aspx". The site for the empty Url is not the same as the site of the original Url. And a browser does not allow script in pages from one site calls script in pages from another site (to avoid cross site script attack). Thus it is not possible for you to call a function defined in "http://www.yoursite.com/Page1.aspx" from a page with null Url. As such you have to write the script code itself into the new document.
I'm loading a iframe with $.ajax():
$("#iframe_wrapper").each(function(){
$.ajax({
type: "post",
url: "http://site.com",
data: { action: 'get_the_iframe' },
context: this,
success: function(html){
$(this).html(html);
$(this).show();
$('#theiframe').load(function(){
// do stuff with the iframe...
});
}
});
});
the iframe is inside a function that gets called if $_POST['action'] is 'get_the_iframe':
<iframe id="theiframe" name="theiframe" src="http://site.com/page/"></iframe>
it works, but the problem is that the browser seems to display the entire page really slow, it seems like it waits for the iframe to load before displaying the entire content on the page, which is not supposed to happen because it's done trough ajax. This is exactly what I was trying to avoid...
Any ideas what's wrong here?
I think the key to the answer is where, or more specifically, when your jQuery fragment that performs the ajax post is being run by the browser.
I suspect the jQuery code to load the page happens sometime before the full page has loaded. And maybe your browser doesn't support asynchronous loads from the same domain.. This was the case with IE for a long time. So what's going on is the browser starts loading and processing the iframe somewhat in-step with the rest of the requests that your normal (outer) page is doing.
If this is not the case yet try putting the code that starts the ajax post in a document ready handler.
Also, check in other browsers to see if the problem occurs across the board.
The reason why you are seeing this is because IFrame is blocking element, especially in IE. IFrames are the most costly element to create in a browser, and it also will block execution of JavaScript when it's being created. There's also resource blocking rule regarding IFrame as well. If you have CSS files in your page, IFrame will not load until response for each and every CSS file is received by the browser (IE) or in Firefox, all IFrame's resources will be blocked until response is received for all resources on the main page.
Just as an example, I had a standard spinner control, that would display running snake whenever I do AJAX call to the server (to give user some feedback that something is happening). I also was create IFrame element at the body level, to overlay all dropdown elements on the page for IE6/7 bleed through bug. At some point I noticed that my web-service calls where about twice slower in IE then they were in FF. After some investigation, I realized that creation of the IFrame element is blocking everything in the browser, including code that receives response from the server.
I don't think there's a way around it, except for not using IFrames...
I'm writing a Firefox extension and need to notify an iFrame page of certain events. The iFrame page is contained within a sidebar created by the extension, and this iFrame page is controlled by me.
When I load the iFrame page, the extension code needs to send a notification and trigger something to happen within the iFrame page.
To accomplish this, I'm creating an event from the extension Javascript and firing the event, which the iFrame page is listening to.
Unfortunately, when invoking document.createEvent(), this error pops up (copied, with the quotes, straight out of Firebug):
Operation is not supported" code: "9
Any clues on the error, or suggestions on how to trigger something in an iFrame page from the extension Javascript?
Firebug helps debug web pages. From your description it appears that the problem happens in your extension, so set up the profile according to the documentation and look in the Error Console.
Other than that, remote debugging requires seeing more of your code :)
That error is NS_ERROR_DOM_NOT_SUPPORTED_ERR. Are you using the right document (the content one, not the XUL window)? Although, I'm not convinced that that would error out either (in fact, I think it should work).
This is an example of code that works for me:
var eventName = "my-event";
var event = document.createEvent('Events');
event.initEvent(eventName, true, true);
document.getElementById('my_event_listener').dispatchEvent(event)