Is there any way to catch an error when loading an iframe from another domain. Here is an example in jsfiddle. http://jsfiddle.net/2Udzu/ . I need to show a message if I receive an error.
Here is what I would like to do, but it doesn't work:
$('iframe')[0].onerror = function(e) {
alert('There was an error loading the iFrame');
}
Anyone have any ideas?
The onerror is applicable only for script errors. Frame content error checking must be done using any other method. Here's one example.
<script>
function chkFrame(fr) {
if (!fr.contentDocument.location) alert('Cross domain');
}
</script>
<iframe src="http://www.google.com/" onload="chkFrame(this)"></iframe>
Due to cross domain restriction, there's no way to detect whether a page is successfully loaded or if the page can't be loaded due to client errors (HTTP 4xx errors) and server errors (HTTP 5xx errors).
If both the parent site and the iframe-url is accessible by you, a way to know that the page is fully loaded (without "sameorigin" issues) is sending a message (postMessage) from the child to the parent like this;
Parent site (containing the iframe)
//Listen for message
window.addEventListener("message", function(event) {
if (event.data === "loading_success") {
//Yay
}
});
//Check whether message has come through or not
iframe_element.onload = function () {
//iframe loaded...
setTimeout(function() {
if (!iframeLoaded) {
//iframe loaded but no message from the site - URL not allowed
alert("Failure!");
}
}, 500);
};
Child site (URL from the iframe)
parent.postMessage("loading_success", "https://the_origin_site.url/");
You could get the_origin_site.url by using a server-side language like PHP if you want the possibility for multiple origins
The accepted answer only works if the domain you're trying to put in an iframe is the same as the one you're requesting from - this solution works for cross-domain where you have access to the scripts on both domains.
I am using following code to detect whether a x-frame-option error occured or another with jquery
$(iframe).load(function (e) {
try
{
// try access to check
console.log(this.contentWindow.document);
// Access possible ...
}
catch (e)
{
// Could not access. Read out error type
console.log(e);
var messageLC = e.message.toLowerCase();
if (messageLC.indexOf("x-frame-options") > -1 || messageLC.indexOf('blocked a frame with origin') > -1 || messageLC.indexOf('accessing a cross-origin') > -1)
{
// show Error Msg with cause of cross-origin access denied
}
else
{
// Shoe Error Msg with other cause
}
}
});
Related
I have a JQuery ajax request that can return error status and messages.
To handle them I use this code :
$.ajax("url", {
options: options
}).done(function(text, statusText, data) {
//Manage data
}).fail(function(data) {
//Manage fail
});
In the fail handle I want, in case of 500: internal server error, to open a new tab with the response text (for debug purposes)
I do it this way :
if (data.status === 500) {
var w = window.open("App error", "blank");
w.document.write(data.responseText);
}
And it works !
Except one point : my browser loads the page, the content is displayed (and as it's static content all of this is not a real problem), but the tab is marked as loading... Loading... Loading...
I'm using Firefox 63.0(64bits).
Does anyone know where this comes from ? It's not really annoying, it's just a (fun ?) behavior I don't understand.
Here is a fiddle on which I get the exact same behavior.
It has to do with the w.document.write line. If you close the document, the loader will finish. Change the code to:
if (data.status === 500) {
var w = window.open("App error", "blank");
w.document.write(data.responseText);
w.document.close();
}
Source: Open about:blank window in firefox
The problem is that you are opening a tab without an url, and most browsers expect an url, that's what I do in order to get rid of it:
const newWindow = window.open('#');
if (newWindow) {
newWindow.addEventListener('load', () => {
newWindow.document.open();
newWindow.document.write(request.responseText);
newWindow.document.close();
newWindow.stop();
}, true);
You can replace # with any url path that doesn't exist, the important thing is that once it's loaded, you'll be able to override the content.
It's not the best solution but at least it makes the trick
I have an application running inside an iframe on a "foreign" page (different domain etc.). To allow some basic communication between the iframe & the parent, I load some script of mine on the parent page and use postMessage to do some cross document messaging.
Most of the time this communication works as intended, but sometimes I see some errors reported to my error tracking tool and can't figure out why they happen.
Here's some exemplary code:
PluginOnParent.js
// ...
window.addEventListener('message', function(e) {
// Check message origin etc...
if (e.data.type === 'iFrameRequest') {
e.source.postMessage({
type: 'parentResponse',
responseData: someInterestingData
}, e.origin);
}
// ...
}, false);
// ...
AppInsideIFrame.js
// ...
var timeoutId;
try {
if (window.self === window.top) {
// We're not inside an IFrame, don't do anything...
return;
}
} catch (e) {
// Browsers can block access to window.top due to same origin policy.
// See http://stackoverflow.com/a/326076
// If this happens, we are inside an IFrame...
}
function messageHandler(e) {
if (e.data && (e.data.type === 'parentResponse')) {
window.clearTimeout(timeoutId);
window.removeEventListener('message', messageHandler);
// Do some stuff with the sent data
}
}
timeoutId = window.setTimeout(function() {
errorTracking.report('Communication with parent page failed');
window.removeEventListener('message', messageHandler);
}, 500);
window.addEventListener('message', messageHandler, false);
window.parent.postMessage({ type: 'iFrameRequest' }, '*');
// ...
What happens here, when the timeout hits and the error is reported?
Some more info & thoughts of mine:
I have no control over the parent page myself
It doesn't seem to be a general "configuration" issue (CORS etc.) since the error happens on the same page where it works most of the time
We don't support IE < 10 and other "legacy" browser versions at all, so those are no issue here
My error reporting tool reports a multitude of different browsers amongst which are the latest versions of them (FF 49, Chrome 43 on Android 5, Chrome 53 on Win and Android 6, Mobile Safari 10, ...)
Therefore it doesn't seem like it's an issue related to specific browsers or versions.
The timeout of 500 ms is just some magic number I chose which I thought would be completely safe...
The problem appears to be in your PluginOnParent.js, where you are sending your response. Instead of using "e.origin" (which upon inspection in the developer tools was returning "null") -- try using the literal '*', as it states in the following documentation on postMessage usage (in the description for targetOrigin):
https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage
Also, as a bonus, I just tested this across two different domains and it works as well. I placed Parent.html on one domains web server, and changed the iframe's src to be child.html on a completely different domain, and they communicated together just fine.
Parent.html
<html>
<head>
<script type="text/javascript">
function parentInitialize() {
window.addEventListener('message', function (e) {
// Check message origin etc...
if (e.data.type === 'iFrameRequest') {
var obj = {
type: 'parentResponse',
responseData: 'some response'
};
e.source.postMessage(obj, '*');
}
// ...
})
}
</script>
</head>
<body style="background-color: rgb(72, 222, 218);" onload="javascript: parentInitialize();">
<iframe src="child.html" style="width: 500px; height:350px;"></iframe>
</body>
</html>
Child.html
<html>
<head>
<script type="text/javascript">
function childInitialize() {
// ...
var timeoutId;
try {
if (window.self === window.top) {
// We're not inside an IFrame, don't do anything...
return;
}
} catch (e) {
// Browsers can block access to window.top due to same origin policy.
// See http://stackoverflow.com/a/326076
// If this happens, we are inside an IFrame...
}
function messageHandler(e) {
if (e.data && (e.data.type === 'parentResponse')) {
window.clearTimeout(timeoutId);
window.removeEventListener('message', messageHandler);
// Do some stuff with the sent data
var obj = document.getElementById("status");
obj.value = e.data.responseData;
}
}
timeoutId = window.setTimeout(function () {
var obj = document.getElementById("status");
obj.value = 'Communication with parent page failed';
window.removeEventListener('message', messageHandler);
}, 500);
window.addEventListener('message', messageHandler, false);
window.parent.postMessage({ type: 'iFrameRequest' }, '*');
// ...
}
</script>
</head>
<body style="background-color: rgb(0, 148, 255);" onload="javascript: childInitialize();">
<textarea type="text" style="width:400px; height:250px;" id="status" />
</body>
</html>
Hope that helps!
Most of the time this communication works as intended, but sometimes I
see some errors reported to my error tracking tool and can't figure
out why they happen.
What happens here, when the timeout hits and the error is reported?
I have no control over the parent page myself
Not certain what the function errorTracking.report does when called, though does not appear that an actual error relating to message event occurs?
The timeout of 500 ms is just some magic number I chose which I
thought would be completely safe...
With duration set at 500, setTimeout could be called before a message event fires at window.
timeoutId = window.setTimeout(function() {
errorTracking.report('Communication with parent page failed');
window.removeEventListener('message', messageHandler);
}, 500);
Adjust the duration of setTimeout to a greater duration.
Alternatively substitute onerror handler or window.addEventListener for setTimeout
Notes
When a syntax(?) error occurs in a script, loaded from a
different origin, the details of the syntax error are not reported to
prevent leaking information (see bug 363897). Instead the error
reported is simply "Script error." This behavior can be overriden in
some browsers using the crossorigin attribute on and having
the server send the appropriate CORS HTTP response headers. A
workaround is to isolate "Script error." and handle it knowing that
the error detail is only viewable in the browser console and not
accessible via JavaScript.
For example
// handle errors
onerror = function messageErrorHandlerAtAppInsideIFrame(e) {
console.error("Error at messageErrorIndex", e)
}
to handle any actual errors during communicating between different contexts, or origins.
Use postMessage at load event of iframe to communicate with message handlers at parent window.
http://plnkr.co/edit/M85MDHF1kPPwTE2E0UGt?p=preview
I am trying to check the url of an iframe, but I just realized that I don't need the actual url, just information of whether the url is within my own domain or not.
I figured I could use
document.getElementById("frameid").documentWindow.location.href
and it will return an error if the url is not within my domain. But how do I intercept this error?
The post in the comment I got was helpful, but I did not find the post on my own, so I thought I'd post my final solution here in case somebody else comes here with a similar question.
$('#iFrame').on('load', function () {
try {
// checks if iframe content is internal
test = this.contentWindow.document.location.href;
showIframe = false;
}
catch (err) {
// if an error is thrown, iframe content is external
showIframe = true;
}
if (showIframe) {
// do some stuff
}
}
I've got some code running in an iframe on 3rd-party sites. Some will be directly in the top page, some will be inside another iframe and some of these may be cross-domain. I need to find a way to get the URL value of the top page using any means necessary.
The furthest I can go up due to cross-domain policy is until the browser stops what the code is doing. I catch the error and look at the referrer of the current window context I'm in. Most cases the page above this is the top page, but not necessarily.
The only way I can see around this is building up a list of URLs which I think are the top page, and then sending a bot with a JS browser validate by seeing if the iframe my code got up to was in fact directly nested in them.
That's still not particularly accurate though, and I'm sure there must be another way of doing it...
Thanks to anyone who can help.
There is actually a way to get the domain in both Chrome and Opera, (in multiple nested cross-domain iframes), though it is not possible in other browsers.
You need to use the 'window.location.ancestorOrigins' property.
I have created a snippet of code below, which should work for you and if you think you can improve the code or comments, please don't hesitate to edit the gist on Github so we can make it even better:
Gist: https://gist.github.com/ocundale/281f98a36a05c183ff3f.js
Code (ES2015):
// return topmost browser window of current window & boolean to say if cross-domain exception occurred
const getClosestTop = () => {
let oFrame = window,
bException = false;
try {
while (oFrame.parent.document !== oFrame.document) {
if (oFrame.parent.document) {
oFrame = oFrame.parent;
} else {
//chrome/ff set exception here
bException = true;
break;
}
}
} catch(e){
// Safari needs try/catch so sets exception here
bException = true;
}
return {
'topFrame': oFrame,
'err': bException
};
};
// get best page URL using info from getClosestTop
const getBestPageUrl = ({err:crossDomainError, topFrame}) => {
let sBestPageUrl = '';
if (!crossDomainError) {
// easy case- we can get top frame location
sBestPageUrl = topFrame.location.href;
} else {
try {
try {
// If friendly iframe
sBestPageUrl = window.top.location.href;
} catch (e) {
//If chrome use ancestor origin array
let aOrigins = window.location.ancestorOrigins;
//Get last origin which is top-domain (chrome only):
sBestPageUrl = aOrigins[aOrigins.length - 1];
}
} catch (e) {
sBestPageUrl = topFrame.document.referrer;
}
}
return sBestPageUrl;
};
// To get page URL, simply run following within an iframe on the page:
const TOPFRAMEOBJ = getClosestTop();
const PAGE_URL = getBestPageUrl(TOPFRAMEOBJ);
If anybody would like the code in standard ES5, let me know, or simply run it through a converter online.
Definitely not possible without communicating with some sort of external system. The cleanest/most accurate way to gather data is to get the top window URL if the browser lets you, but catch errors and use the referer with a flag to note it's the referer.
I'm trying to extend some of the handling of messaging between my background process and content scripts. In the normal course of things my background process sends a message via postMessage() and the content script replies via another channel with a response. However I would like to now extend the background process to fall-back to something else if the content script can't find a valid thing on the page. It's when looking at this I discovered a problem when sending a message to blank or system pages. As the tabs don't have content scripts loaded there is nothing to receive the posted message. This generates warnings in the console logs but otherwise no ill effects. However:
// Called when the user clicks on the browser action.
//
// When clicked we send a message to the current active tab's
// content script. It will then use heuristics to decide which text
// area to spawn an edit request for.
chrome.browserAction.onClicked.addListener(function(tab) {
var find_msg = {
msg: "find_edit"
};
try {
// sometimes there is no tab to talk to
var tab_port = chrome.tabs.connect(tab.id);
tab_port.postMessage(find_msg);
updateUserFeedback("sent request to content script", "green");
} catch (err) {
if (settings.get("enable_foreground")) {
handleForegroundMessage(msg);
} else {
updateUserFeedback("no text area listener on this page", "red");
}
}
});
Doesn't work. I would expect the connect or the postMessage to throw an error I can trap, however the console log is filled with error messages including:
Port: Could not establish connection. Receiving end does not exist.
But I do not end up in the catch statement.
In the end I couldn't do it with connect, I had to use the one shot sendMessage() which has a call-back function when the response comes in. That can then be interrogated for success and the state of lastError. The code now looks like this:
// Called when the user clicks on the browser action.
//
// When clicked we send a message to the current active tab's
// content script. It will then use heuristics to decide which text
// area to spawn an edit request for.
chrome.browserAction.onClicked.addListener(function(tab) {
var find_msg = {
msg: "find_edit"
};
// sometimes there is no content script to talk to which we need to detect
console.log("sending find_edit message");
chrome.tabs.sendMessage(tab.id, find_msg, function(response) {
console.log("sendMessage: "+response);
if (chrome.runtime.lastError && settings.get("enable_foreground")) {
handleForegroundMessage();
} else {
updateUserFeedback("sent request to content script", "green");
}
});
});