Do web browsers use separate executional threads for JavaScript in iframes?
I believe Chrome uses separate threads for each tab, so I am guessing that JavaScript in an iframe would share the same thread as its parent window, however, that seems like a security risk too.
Recently tested if JavaScript running in a iFrame would block JavaScript from running in the parent window.
iFrame on same domain as parent:
Chrome 68.0.3440.84: Blocks
Safari 11.0.2 (13604.4.7.1.3): Blocks
Safari 15.1 on iOS: Blocks
Firefox 96: Blocks
iFrame on different domain as parent
Chrome 68.0.3440.84: Doesn't block
Safari 11.0.2 (13604.4.7.1.3): Blocks (outdated, but I don't have a macbook)
Safari 15.1 on iOS: Doesn't block
Firefox 96: Doesn't block
Chrome for Android 96: sometimes Blocks and sometimes Doesn't block (There are some complex rules in Chrome for Android that determine when Chrome for Android does and doesn't isolate a process, see chrome://process-internals and chrome://flags)
parent.html:
<body>
<div id="count"></div>
<iframe src="./spin.html"></iframe>
<script>
let i = 0;
let div = document.getElementById("count");
setInterval(() => {
div.innerText = i++;
}, 100);
</script>
</body>
spin.html:
<body>
<button id="spin">spin</button>
<script>
const spin = document.getElementById("spin");
spin.addEventListener('click', () => {
const start = Date.now();
while (Date.now() - start < 1000) { }
})
</script>
</body>
Before chrome came along, all tabs of any browser shared the same single thread of JavaScript. Chrome upped the game here, and some others have since followed suit.
This is a browser implementation detail, so there is no solid answer. Older browsers definitely don't. I don't know of any browser that definitely uses another thread for iframes, but to be honest I've never really looked into it.
It isn't a security risk, as no objects are brought along with the thread execution.
To sum up the other answers: No, iFrames usually run in the same thread/process as the main page.
However, it appears the Chromium team are working on further isolation in this area:
Chromium Issue 99379: Out of process iframes [sorry, link not working - if you can find a link to the issue that works, please let me know]
Design Plans for Out-of-Process iframes
I've had the same question myself this night, before checking for any existing answers. In the project I'm currently working we have to load an iFrame that uses a different framework and I was curios if that iFrame could somehow block the thread and affect my app. The answer is yes, it can.
My test was done in Chrome. In the parent I've loaded a child iFrame. In the parent I've set an interval to console.log a text every amount time. Then in the iFrame I've used a timeout to launch a 'while' that blocks the thread. The answer: the iFrame uses the same thread.
Example:
In the parent:
setInterval(() => {
console.log('iFrame still using the thread');
}, 3000)
In the iFrame:
setTimeout(() => {
console.log('now the thread is not working in the iFrame anymore');
while (true) {
}
}, 10000)
2021 Update:
There is now the Origin-Agent-Cluster header which allows you to request dedicated resources for an iframe. It is currently supported on Chrome (88+) with positive reception from Mozilla and Safari.
Origin-Agent-Cluster is a new HTTP response header that instructs the browser to prevent synchronous scripting access between same-site cross-origin pages. Browsers may also use Origin-Agent-Cluster as a hint that your origin should get its own, separate resources, such as a dedicated process.
[...] For example, if https://customerservicewidget.example.com expects to use lots of resources for video chat, and will be embedded on various origins throughout https://*.example.com, the team maintaining that widget could use the Origin-Agent-Cluster header to try to decrease their performance impact on embedders.
To use the Origin-Agent-Cluster header, configure your web server to send the following HTTP response header: Origin-Agent-Cluster: ?1 The value of ?1 is the structured header syntax for a boolean true value.
More details here: https://web.dev/origin-agent-cluster/
Only chrome & firefox on desktop (no, not mobile) is separating threads.
I've created a small page that run long loop in interval in the main page, and shows an animation both in the main page and in the iframe.
You can go to the site from the browser you wish to check.
If the lower animation (under 'crossorigin') runs without stopping, it's have a separate thread.
https://eylonsu.github.io/browser_thread/
Late on this but... good point, cause iframe js seems to be concurrent in Firefox 16.
Try with alert function (blocking), you'll see dialogs opening together.
You won't see that in Chrome or IE.
iframe js may access the parent window in Firefox 16 as usual, so I can think of possible race conditions arising.
Did some experimenting with this today in Chrome 28 in Ubuntu. Used this command to see Chrome's threads and processes
ps axo pid,nlwp,cmd | grep "chrome"
It looks like Chrome does not spawn new threads or processes for iframes. An interesting note is that it does spawn a new process for the dev tools pane.
2022 Update (Experimental)
Iframes can now be run in parallel in at least Chrome Canary on desktop computers, but this is still experimental.
Download Chrome Canary (https://www.google.com/chrome/canary/).
Navigate to "chrome://flags/".
Enable "Isolated sandboxed iframes".
Create "index.html" with the following content:
<h1>index.html</h1>
<iframe src="index-child.html" sandbox="allow-scripts"></iframe>
<script>
setInterval(() => {
console.log("index.html executed one iteration");
}, 1000)
</script>
Create "index-child.html" with the following content:
<h1>index-child.html</h1>
<script>
setTimeout(() => {
console.log("index-child.html started continuous execution");
while (true) {
}
}, 3000)
</script>
Open "index.html" in the browser.
Verify that the console is consistently logging "index.html executed one iteration". Thus, the iframe is executed in parallel.
Disable "Isolated sandboxed iframes" (or just use another browser) and open "index.html" again. The console is no longer consistently logging "index.html executed one iteration". Thus, the iframe is no longer executed in parallel.
Note: The sandbox attribute on the iframe tag must be correctly set for this to work. Additionally, only one extra process per site is currently supported, which means that multiple iframes will not all run in parallel.
The specific instructions from "chrome://flags/":
Isolated sandboxed iframes
When enabled, applies process isolation to iframes with the 'sandbox' attribute and without the 'allow-same-origin' permission set on that attribute. The current isolation model is that all sandboxed iframes from a given site will be placed into the same process, but alternative models may be introduced in future experiments. – Mac, Windows, Linux, Chrome OS, Fuchsia
For iFrames, no. However if you want to use threads in JavaScript you can use Web Workers, a working html5 draft supported by the new browsers. http://www.w3.org/TR/2009/WD-workers-20091029/
Related
Apologies that this is a long question, I wanted to make sure it was clear what the problem is and, just as importantly, what it isn't - because I know there are a lot of questions that seem related but they don't seem to be about quite the same issue:
The web application we're developing at work needs to open a URL in a new tab when the user presses a particular button, after an API request has completed. The URL in question happens to open a PDF document.
We're aware of the issue with popup blockers, so are opening a blank tab straight away when the button is pressed, then setting the location to the URL a short time later after the API request completes. And this is working fine on desktop browsers as well as on Safari on iPad.
But there is a peculiar problem with Chrome on Android - at least we have observed the problem on Galaxy tablet versions 6 and 7. I'm aware that for some reason Chrome on Android does not have a built-in PDF viewer - however, it seems that accessing the PDF should trigger the OS to ask the user which app they want to use to view the PDF, and we are OK with that. What we do not want - but what is happening at the moment - is the PDF simply getting downloaded in the background, and the user not being given the option of viewing it directly.
From my research on how browsers handle PDFs, it seems this behaviour is dependent on various response headers - notably Content-Type and Content-Disposition. But we are doing this correctly as far as I know - the Content-Type is application/pdf and there is no Content-Disposition header so it should default to "inline", ie opening up to view rather than downloading. And I have tried adjusting the backend to send this header explicitly, both with and without a filename parameter - with no change in observed behaviour.
I strongly suspect this is a bug with Chrome and/or Android, but I cannot find it clearly reported anywhere. The key thing is that there is a delay in setting the URL - because if I put this directly into the console (which I can do when running browserstack from my desktop; not sure if there's any way to input it into a real device directly):
function test1() {
window.open("url/for/my/pdf");
}
this works fine (the device prompts you with a choice of how to open the PDF)
but not with either
function test2() {
const newTab = window.open();
setTimeout(() => {
newTab.location = "url/for/my/pdf";
}, 1000);
}
or even with this, non-asynchronous, version:
function test3() {
const newTab = window.open();
newTab.location = "url/for/my/pdf";
}
Both test2 and test3 above, when called from the console, result in the PDF being downloaded rather than viewed. And this isn't specific to our endpoints - I've tested it with URLs to various random PDF documents I've found online, and the same behaviour occurs.
So my questions are:
is this a known bug with Chrome or Android?
whatever the answer to 1) above, is there any straightforward workaround which will ensure the user is always prompted to open an application to view the PDF, rather than simply downloading it? (Bearing in mind that we can't avoid the delay between opening the tab and setting the location - or at least this is our preferred way.)
Thanks in advance!
Situation
In our Android app (Xamarin), we open a web page using an ActionView intent. The code looks like this:
Intent intent = new Intent((string)Intent.ActionView, Android.Net.Uri.Parse(args.url));
intent.AddFlags(ActivityFlags.NewTask);
The opened page at some point does a JS redirect, with a line like this:
window.location = '...';
We tried many different variations of that line, including window.location.href = '...', window.location.assign('...'); and some more. All show the same behavior.
Problem
This has worked fine for years now, in all browsers - but now we ran into a problem, when the browser on the android device is the Edge browser:
When the browser tab is initially opened by the intent, the window.location = '...' line in Javascript is just ignored by the browser. No error message - just ignored.
However, if that same browser tab with exactly the same URL is opened manually (either by reloading or by copying and pasting the URL), the JS redirect is executed just fine.
Question
How do we fix this, how do we make the JS redirect reliably work?
My guess is that we are running into a security feature, which prevents JS redirects in browser tabs that the user has never interacted with.
Is there something (maybe an intent flag?) to circumvent this? We already tried the flag GrantWriteUriPermission, but it did not help.
Possible duplicates
Android Browser Facebook Redirect Does Not Always Trigger Intent for URL :
The proposed situation of setting the URL on a link and faking a click on it did not work.
Microsoft Edge security
Microsoft Edge recently fixed an issue regarding XSS Targeting Non-Script Elements (June 24, 2021).
The vulnerability was found by two researcher when they visited a website in another language via the Microsoft Edge browser and attempted to translate the page. The goal of the recent fix by Microsoft is to avoid vulnerability regarding accessing dynamically to a content from a third party application and specifically in the case of browser redirection. They need to act quickly because the vulnerability is quite huge.
In order to mitigate a large class of potential cross-site scripting issues, the Microsoft Edge Extension system has incorporated the general concept of Content Security Policy (CSP)
Ok, but ... is there any solution?
Maybe you can find a solution to solve your issue here, in particular the part concerning the <button onclick="...">.
Inline code is considered harmful in concept of CSP and microsoft recommend some good practices :
1 - The clickHandler definition must be moved into an external JavaScript
2 - The inline event handler definitions must be rewritten in terms of addEventListener and extracted into your external js file. If you are currently starting your program using code like <body onload="main();">, consider replacing it by hooking into the DOMContentLoaded event of the document, or the load event of the window, depending on your requirements. Use the former, since it generally triggers more quickly.
3 - Function inside onclick call must be rewritten to avoid converting the string of function into JavaScript for running.
The code exemple of the external .js file cited in the documentation look like this :
function awesome() {
// Do something awesome!
}
function totallyAwesome() {
// do something TOTALLY awesome!
}
function awesomeTask() {
awesome();
totallyAwesome();
}
function clickHandler(e) {
setTimeout(awesomeTask, 1000);
}
function main() {
// Initialization work goes here.
}
// Add event listeners once the DOM has fully loaded by listening for the
// `DOMContentLoaded` event on the document, and adding your listeners to
// specific elements when it triggers.
document.addEventListener('DOMContentLoaded', function () {
document.querySelector('button').addEventListener('click',
clickHandler);
main();
});
Hope it's helps
Safari 12.1 seems to have stopped remembering getUserMedia (microphone in this case) permissions for cross domain iframes.
Given a simplified example of two sites:
Domain A:
<!DOCTYPE html>
<html>
<head></head>
<body>
<button onclick="triggerUserMedia()">Get User Media</button>
<script>
function triggerUserMedia(){
const constraints = { audio: true, video: false };
navigator.mediaDevices.getUserMedia(constraints)
.then(function(stream) {
console.log('got stream');
})
.catch(function(err) {
console.log('couldn\'t get the stream');
});
}
</script>
</body>
</html>
Domain B:
<!DOCTYPE html>
<html style="height:100%">
<head></head>
<body>
<iframe src="https://domain-a/index.html" allow="microphone"></iframe>
</body>
</html>
In Safari pre 12.1, and in the current build of Chrome etc., pressing the button multiple times when embedded in Domain B would result in one single "Allow “Domain A” to use your microphone?", just on the first press.
However, it now results in a permission popup every time the button is pressed.
Does anyone know what specifically changed in Safari 12.1 which is caused this behaviour to change? (Is this a new webkit security restriction?)
What can be done to ensure the permission is only asked for once, as it was before?
(We call getUserMedia multiple times in a project intended to be embedded in different sites, so this is causing a significant user experience impact)
I can't answer as to what specifically is going on with browser vendors making iframe getUserMedia requests reprompt for permission every time a media stream is requested, but we found the solution to be to use the parents mediaDevices singleton to request for a stream.
function getRootWindow(window) {
if (window.parent === window) {
return window;
}
return getRootWindow(window.parent);
}
getRootWindow(window).navigator.mediaDevices.getUserMedia().then(...);
We have tested this on iOS, FF, Chrome, Safari and it works fine, once permissions have been granted subsequent requests for a media device work fine. Something about calling this from the iFrames DOM causes it to issue prompts every request.
I'm seeing the same issue even for the same domain iframe - simply asking for getUserMedia from inside iframe always asks for permission.
I figured out an ugly workaround even for cross-domain: if you at least once ask for permission on "host" page, it'll start working inside iframe. It requires you to have some "host page" script that'll communicate with iframe (via window messages to avoid cross-domain issues) but it works.
Another weird behavior even using my workaround is that enumerateDevices do not return valid device names if you first ask a permission on host page and then inside iframe. So a full workaround (if you need enumeration) would be to have 2 permission prompts:
first ask inside iframe (this will make sure enumeration works)
and then on host page (this will ensure Safari will remember permission and won't show prompt for next getUserMedia invokes)
I have a site that renders nearly everything through javascript (not my design), and this has caused a lot of issues in Internet Explorer, of course. The recurring issue is that when the user has security set to High, the necessary javascript files get blocked, I believe because they are from another domain. This has something to do with the Drupal setup, I'm not entirely sure, but the important thing to know is that the files are served from a different domain and there's nothing I can do about that.
What my client wants is for an alert to pop up whenever these scripts are getting blocked that tells their users how to change their security settings.
1) If I add a javascript file on the same domain, it shouldn't get blocked, right?
2) Is there a way I can detect what the user's security settings are, or detect if scripts are being blocked using javascript?
There is another way to detecting whether a js script was loaded or not; there could be so many things, it can be their network firewall, os level firewall, browser security settings, the list continues with possibilities.
You can have:
<script src="http://yourdomain.com/the_js_script.js"></script>
<script>if (typeof foo == "undefined") {alert ('error loading script');}</script>
Make sure in the_js_script.js, you'd have
var foo = 'Script loaded successfully';
You can do that for all the js scripts, and alert distinct messages so the user at least knows which scripts were blocked or if they came through.
Setting your IE security set to High, disables all scripts from running in the browser.
The only workaround available is to place a warning message using the noscript html tag.
<noscript>Your browser does not support JavaScript!</noscript>
I would have liked to comment on #unixmiah's answer, but I don't have enough reputation, and I believe this is an answer as well. Unixmiah's solution won't work to alert blocked clients, I think since the alert needs a script to be generated.However, I believe this would work (wouldn't it?):
jQuery(function($) {
$(document).ready(function() {
$("p#jstrap").hide();
});
});
<script src="https://ajax.googleapis.com/ajax/libs/jquery/2.1.1/jquery.min.js"></script>
<p id="jstrap">You seem to have switched Javascript off.</p>
I'm using IE9 to debug a web app. I made some changes to the javascript after loading the page. I'm not able to get IE9 to stop on the new code. The message is "The code in the document is not loaded". I can set breakpoints when I'm not debugging, but they won't be valid when I start debugging. I'm using IE7 Browswer Mode, IE7 Document Mode.
Things I've tried:
close dev tools window, re-open
stop debugging, start debugging
Ctrl R in dev tools window (same as Clear Browser Cache button)
Ctrl R on the IE9 web page
Ctrl F5 on the Ie9 web page
Clear browser cache for this domain
Check (set) Always refresh cache from server
Next thing to try (I guess) would be closing IE completely. Is that the fix for this? If so, yuck. It takes me a couple of minutes to set the page up so doing that after every JS change really stinks. I can use FF4 to develop the JS, but the JS issue I'm seeing is specific to IE7 so I have to do it this way.
>> How can I get IE9 (running in IE7 mode) to reliably debug the most current JS from the server?
This issue wasn't related to caching etc. IE9 was hitting a script error (missing closing paren) in the new code and not allowing breakpoints anywhere in the script. IE seemed very quiet about the script error though. Anyway, fixing the script error fixed the issues with breakpoints / caching.
If you have access to the code:
In you javascript file reference add a query string, something like this:
<script src="Scripts/main.js?v=1" type="text/javascript"></script>
And every time you change in the js file change the v value to something else, like that the browser will feel that this is a new file and will get it.
Add this:
window.applicationCache.addEventListener('updateready', function (e)
{
if (window.applicationCache.status == window.applicationCache.UPDATEREADY)
{
window.applicationCache.swapCache();
if (confirm('A new version of this site is available. Load it?'))
window.location.reload();
}
}, false);
I found this solution somwhere in the Net. Sorry, but I don't remember the author. It works for me when I debug Web App with JavaScript in Visual Studio and use IE.
I found this question based on the "the code in the document is not loaded" error message. I'm not using IE7 document mode or any of that, just IE9.
Like jcollum, my issue wasn't related to caching.
I'm using MVC.Net, and someone had set up a piece of javascript to rely on a string in the ViewBag. I changed a couple things, and that ViewBag string disappeared, so the resulting javascript looked something like this:
if(!()) {
// Some code
}
Javascript died right here, and wouldn't process the rest of the code in the block. This was confusing, as it was still trying to execute javascript in a different set of script tags, but which relied on a variable set in the other block it wouldn't load.
So, basically, a syntax error was introduced via strange means, and the debugger refused to load some of the code which came after it. Another lesson on the dangers of ViewBag.