Iframe = multithreading ???

[ben fenster]

i was wondering that if by opening another module in an iframe tag the
code of that module runs in another thread ??
more over is the limit of 2 open http request apply on 2 diffrent
modules running in diffrent iframes ??

[David Given]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

ben fenster wrote:
> i was wondering that if by opening another module in an iframe tag the
> code of that module runs in another thread ??

Nope. There is no way of getting access to multiple Javascript threads
from a web browser, unless you use some sort of extension like Google
Gears or HTML5 web workers. Every part of the Javascript VM that your
code can see is part of the same event loop.

> more over is the limit of 2 open http request apply on 2 diffrent
> modules running in diffrent iframes ??

Don't know about this one.

- --
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ─────
│
│ "People who think they know everything really annoy those of us who
│ know we don't." --- Bjarne Stroustrup
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iD8DBQFKnxH6f9E0noFvlzgRApqiAKC/xF4z1x0t7s+8kAsTVoSxYFRFmQCfaUcx
7F+QaH0Fdc9baW9Wcgl3swM=
=ukVk
-----END PGP SIGNATURE-----

[ben fenster]

your answear is based on your knolage in js but i need an answear
based on actual in depth knowlage in how browser work since each
iframe act as an independed wep page and loaded sepertly then the
containing page made me wonder about how its being done without a
diffrent thread ?
and if another thread is envolved in loading then maybe the new thread
is also responsible on running the js code contained in the page of
the iframe ?

On Sep 2, 5:46 pm, David Given <d...@cowlark.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> ben fenster wrote:
> > i was wondering that if by opening another module in an iframe tag the
> > code of that module runs in another thread ??
>
> Nope. There is no way of getting access to multiple Javascript threads
> from a web browser, unless you use some sort of extension like Google
> Gears or HTML5 web workers. Every part of the Javascript VM that your
> code can see is part of the same event loop.
>
> > more over is the limit of 2 open http request apply on 2 diffrent
> > modules running in diffrent iframes ??
>
> Don't know about this one.
>
> - --
> ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─────http://www.cowlark.com─────
> │
> │ "People who think they know everything really annoy those of us who
> │ know we don't." --- Bjarne Stroustrup
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)

> Comment: Using GnuPG with Mozilla -http://enigmail.mozdev.org/

[ben fenster]

another thing about the http request limitation most browsers rejects
more then 2 simultinus requests to a spacific url and i wondered i
its aplays to 2 diffrent browser windows (diffrent process in new
browsers) and if iframe acts as new web page maybe the limitation
grows by 2 for each iframe

[David Given]

ben fenster wrote:
> your answear is based on your knolage in js but i need an answear
> based on actual in depth knowlage in how browser work since each
> iframe act as an independed wep page and loaded sepertly

No, you misunderstand --- if your code can see an iframe, that iframe
must be part of the same Javascript VM as your code, and therefore must
be part of the same thread. The spec requires it.

Iframes aren't as independent as you think.

--
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ─────
│

│ "They laughed at Newton. They laughed at Einstein. Of course, they
│ also laughed at Bozo the Clown." --- Carl Sagan

[ben fenster]

ok thats sounds right but if thats true can i access static classes
in the entrypoint module from a seperate module loaded in an iframe
(that ofcours exists in the first module) ?

[David Given]

ben fenster wrote:
> ok thats sounds right but if thats true can i access static classes
> in the entrypoint module from a seperate module loaded in an iframe
> (that ofcours exists in the first module) ?

Javascript will let you do it, provided the security rules let you (the
page in the iframe must come from the same domain that your script
does). I don't know whether it's possible to make GWT give you seamless
access from Java, though --- you'd probably have to use Javascript
trampolines. (Where one module explicitly exports stuff to the parent
window, and then another module explicitly imports it again.)

[David]

There is just 1 JS thread. Regardless of URL or IFrame.
The limit of max 2 connections is purely based on URL, not on per
IFrame basis. IE8 allows more than 2, I forgot the exact number.
To work around the connections limit you can spread web resources over
different hosts in the same domain.

Getting access to static classes in different IFrames can works but:
1) security restrictions might stop you from calling from one IFrame to another.
2) GWT code is obfuscated and can be totally different with every
change you make. So in order to get access to some static classes, you
will need to expose them through JSNI.

[Paul Porombka]

Hi Ben,

I see the time when you've posted the message and see the answers here, so I codn;t stop to write something here.

I will answer YES to your question, but it depends.

Generally, IFrame under the same domain is using the same thread. I don't know how it was at the time You've been asking, but now if you use IFrame with different origin (domain/host) it will use its own context, own event loop, so also ot will be separate thread.

Currently a Web Workers concept is using this behavior. The problem was always with communication between those two frames, so it was also solved by "Messages". You are able to post a message to different ORIGIN and addEventListener to "message" event to receive such messages, and voila! You have two way communication between threads :-)

So if you create a code that can be executed separately in different IFrame, and exeute it in different ORIGIN, then YES you will get REAL multithreading, not single event loop, real muti-event-loop :-)

[Thomas Broyer]

On Thursday, September 14, 2017 at 12:09:37 PM UTC+2, Paul Porombka wrote:

Hi Ben,

I see the time when you've posted the message and see the answers here, so I codn;t stop to write something here.

I will answer YES to your question, but it depends.

Generally, IFrame under the same domain is using the same thread. I don't know how it was at the time You've been asking, but now if you use IFrame with different origin (domain/host) it will use its own context, own event loop, so also ot will be separate thread.

It's actually a bit more complicated: https://html.spec.whatwg.org/multipage/webappapis.html#event-loops

While browsers are *allowed* to use different event loops for those "units of related similar-origin browsing contexts", it adds complications (see note in spec)

A quick test in my Chrome 61 on Linux shows that the same event loop is used for the iframe and parent browsing contexts loaded from totally different origins (I do heavy DOM manipulations in the iframe on the click of a button, and use a tight setTimeout loop on the parent that updates an element; when I click on the button in the iframe, I clearly see the parent "pause"; there are no communication by any mean between the pages; using 127.0.0.1.xip.io and devd.io to have distinct origins for the same local server).

Same in Firefox 55.

So while it theorically *can* happen (is allowed by spec), it's not the case in practice.

Web Workers are the only (guaranteed, effective) way of "multithreading" in the browser. 

[Paul Porombka]

YES, totally agree. This is probably because Web Workers don't use any UI there. So they are probably better scheduled and "lighter", so works much better than forcing multithreading with IFrames :-)

But the concept is pretty nice, don't you think :-)

And to clarify. I was rather also considering a situation where I have a blank page in IFrame, without any UI elements, probably hidden frame, that will handle heavy operations, sent there from parent using postMessage. Because user interactions on UI can cause the behavior you observed. Then I would be closer to Web Workers. But definitely Web Workers are the right way in such situations. 

PS: Did you try your test using Web Workers for comparison?

[Paul Porombka]

And one more thing, UI thread is only one for windowed / process application. So the clicks and generally Browser can be blocked when you will use time consuming operation on UI. If you will use e.g. setTimeout, no clicking etc, then it could work much better. Because this single UI thread must be "shared" by renderer of all frames / windows / documents visible to the user :-)