When trycatch is used to handle iframe cross-origin exceptions, chrome and safari do not seem to work properly: they directly throw an error without throwing exceptions that can be intercepted by JS. Here is a simple test page: "hello world" is displayed on IE and Firefox, while chrome, safari, and opera are unresponsive.
The following is a short test code (deliberately modifying domain so that the parent page and child page are different domain pages ):
1. Parent Page code:
The Code is as follows:
Script
Document. domain = "nunumick. me ";
Function doTest (){
Alert ('Hello World ');
}
Script
2. subpage code:
The Code is as follows:
Script
Try {
Top. name;
} Catch (e ){
Document. domain = 'nunumick. Me ';
Top. doTest ();
}
Script
The purpose of the above Code is to dynamically modify the domain to achieve smooth access when an access exception occurs. However, the webkit kernel browser reports an error rather than throwing an exception that can be intercepted. other browsers run as scheduled.
Chrome error message:
It is understood that the use of such try catch methods for security feasibility judgment is not just a few phenomena, such as DOJO
The Code is as follows:
Try {
// See if we can access the iframe's location
// Without a permission denied error
Var iframeSearch = _ getSegment (iframeLoc. href ,"? ");
// Good, the iframe is same origin (no thrown exception)
If (document. title! = DocTitle ){
// Sync title of main window with title of iframe.
DocTitle = this.iframe.doc ument. title = document. title;
}
} Catch (e ){
// Permission denied-server cannot be reached.
IfrOffline = true;
Console. error ("dojo. hash: Error adding history
Entry. Server unreachable .");
}
Another example is FCKeditor.
The Code is as follows:
Try {
If (/fcksource = true/I). test (window. top. location. search ))
SFile = 'fckeditor.original.html ';
}
Catch (e) {/* Ignore it. Much probably we are insi
De a FRAME where the "top" is in another domain (security error ).*/}
Feedback from many netizens: chrome bug report
The above code is not applicable to chrome, safari, and opera. I have reviewed some materials and recorded them here:
1.html 5 security location
2. webkit dev lists
According to the discussion from webkit developers, they admitted the problem but were reluctant to correct it, holly shit!