Restricted nested message loop

[Kentaro Hara]

Hi

While brainstorming strategies for isolating performance of third-party iframes, I started thinking about the idea of running main frame's task in a nested message loop of third-party iframes. Needless to say, we cannot simply use a normal nested message loop for this purpose because it is dangerous. To mitigate the security risk, I'm now thinking about defining safe points and letting the user agent start the nested message loop at the safe points.

I'm only 70% sure if the idea is feasible (or sane) but tried to write a document. Any input is welcome :)

--

Kentaro Hara, Tokyo, Japan

[Kentaro Hara]

tasak@ and I collected some data to understand how much third-party scripts are disturbing the main frame.

- Linux desktop

- Nexus4 low-RAM Android

Each column lists execution times of cross-origin scripts that took >16 ms. We can observe many >100 ms scripts running even on desktops. Some scripts are taking >500 ms. The main frame is blocked during the script execution :/

(Note that some of the websites return different pages for Linux desktop and Nexus4.)

[Elliott Sprehn]

Do we have some traces to show how the work overlaps? I'm curious to know what main frame work we could have done during those scripts of we had a yielding system.

--
You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to platform-architect...@chromium.org.
To post to this group, send email to platform-arc...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CABg10jxXN%2BFcoJUVHtF7_9%2BeRuWEK_NCk6hoStx6GH2%2Bt5QNwQ%40mail.gmail.com.

[Kentaro Hara]

tasak@: Can you upload the traces?

(But I think it would be anyway really problematic that the third-party script blocks the main frame's tasks for >500 ms :-)

[Kentaro Hara]

This is a tracing result when I loaded qq.com on Linux desktop (the first 6 seconds). I also attached a trace file to this email.

​

[Takashi Sakamoto]

The followings are tracing results with blink,blink.console,cc,gpu,renderer.scheduler,toplevel,v8:

​

 http___blog_livedoor_jp_dqnplus_8.html

​​

 http___kakaku_com_pc_note_pc_7.html

​​

 http___www_qq_com_3.html

​​

 https___www_yahoo_com_0.html

​​

 http___portal_nifty_com_9.html

​​

 http___hamusoku_com_6.html

​​

 http___ejje_weblio_jp_4.html

​​

 http___edition_cnn_com_2.html

​​

 http___www_theverge_com_1.html

​​

 http___www_kobe_np_co_jp_5.html

​

[Kentaro Hara]

I tried to prototype the restricted nested message loop and see how it improves UX in real-world websites, but noticed that it's hard to prototype without having the per-iframe scheduler.

To prototype the idea, we need to interrupt a third-party iframe (<-- this is easily doable) and run main frame's task in a nested message loop of the iframe. However, currently there is no way to pick up main frame's task because tasks from various frames are mixed in the default task runner. If we mistakenly run the iframe's task in a nested message loop of the iframe, it will just break the order of task executions :/

So it looks like that we need to tie all tasks and timers with iframes before experimenting with the restricted nested message loop.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CAKp9wxfxk0HOX9Zq1ZtTXxMB1pcgd1eYsTyk6ppdVK2zzXjxeQ%40mail.gmail.com.

[Ojan Vafai]

Makes sense to me.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CABg10jxkaqCxfBWhSoZ00ZH%3D6OBYqfkpHAiBjDVBzBF_Jpegew%40mail.gmail.com.