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? On Thursday, September 14, 2017 at 1:21:48 PM UTC+2, Thomas Broyer wrote: > > > > 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. > > >> 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 :-) >> >> On Thursday, September 3, 2009 at 12:51:09 AM UTC+2, 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 ?? >>> more over is the limit of 2 open http request apply on 2 diffrent >>> modules running in diffrent iframes ?? >> >> -- You received this message because you are subscribed to the Google Groups "GWT Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at https://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
