Re: [whatwg] keepalive attribute on iframe
I think this only worked for the magic iframe solution because it was cross-document. Talked to Adam offline. It sounded like the problems that didn't stem from cross-document issues had to do with assumptions that rendered iframes are always attach to the DOM. Not sure what we can do about that other than fixing all the bugs. I considered that we could wait until the end of the microtask (task?), and only unload keepalive iframes if they are still detached, but in the presence of sync javascript events, I'm not sure that actually reduces any implementation complexity. Ojan On Mon, Apr 16, 2012 at 4:51 PM, Darin Fisher da...@chromium.org wrote: Can you hide this behind adoptNode just as we did for magic iframe? The nice thing about adoptNode is that the browser gets told both the source and destination parent nodes. This way there is never a disconnected state. So long as we unload when moving between documents, we should be pretty safe as far as the issues which plagued magic iframe are concerned. -Darin On Thu, Apr 12, 2012 at 12:35 PM, Ojan Vafai o...@chromium.org wrote: We should add a keepalive attribute to iframes that prevents iframes from being unloaded/reloaded when removed from or appended to a document. Similarly, a disconnected iframe with keepalive should load. If the keepalive attribute is removed from a disconnected iframe, then it should unload. I'm not terribly happy with the name 'keepalive', but I can't think of anything better at the moment. As iframes increasingly become the standard way of achieving certain tasks (e.g. sandboxing), it's increasingly important to be able to move them around in the DOM. Right now, to achieve this sort of keepalive behavior, you have to keep the iframe always appended to the document and position it absolutely as the document changes. Ojan
Re: [whatwg] keepalive attribute on iframe
Would some sort of a same-origin policy help here? If both the iframe and parent document are same origin, can it be done, at least for the reparenting in the same JS execution block? Most (all?) of the security issues were specifically cross-origin. But yes, there are a lot of assumptions in the code about not only iframes, but most active objects to function only while they are connected all the way through to the valid DOM. There is too many APIs (and new ones are coming all the time) who pick up that assumption. It is not impossible, just a lot of work. Dmitry On Tue, Apr 17, 2012 at 4:06 PM, Ojan Vafai o...@chromium.org wrote: I think this only worked for the magic iframe solution because it was cross-document. Talked to Adam offline. It sounded like the problems that didn't stem from cross-document issues had to do with assumptions that rendered iframes are always attach to the DOM. Not sure what we can do about that other than fixing all the bugs. I considered that we could wait until the end of the microtask (task?), and only unload keepalive iframes if they are still detached, but in the presence of sync javascript events, I'm not sure that actually reduces any implementation complexity. Ojan On Mon, Apr 16, 2012 at 4:51 PM, Darin Fisher da...@chromium.org wrote: Can you hide this behind adoptNode just as we did for magic iframe? The nice thing about adoptNode is that the browser gets told both the source and destination parent nodes. This way there is never a disconnected state. So long as we unload when moving between documents, we should be pretty safe as far as the issues which plagued magic iframe are concerned. -Darin On Thu, Apr 12, 2012 at 12:35 PM, Ojan Vafai o...@chromium.org wrote: We should add a keepalive attribute to iframes that prevents iframes from being unloaded/reloaded when removed from or appended to a document. Similarly, a disconnected iframe with keepalive should load. If the keepalive attribute is removed from a disconnected iframe, then it should unload. I'm not terribly happy with the name 'keepalive', but I can't think of anything better at the moment. As iframes increasingly become the standard way of achieving certain tasks (e.g. sandboxing), it's increasingly important to be able to move them around in the DOM. Right now, to achieve this sort of keepalive behavior, you have to keep the iframe always appended to the document and position it absolutely as the document changes. Ojan
Re: [whatwg] keepalive attribute on iframe
On Tue, Apr 17, 2012 at 8:35 PM, Dmitry Titov dim...@chromium.org wrote: Would some sort of a same-origin policy help here? If both the iframe and parent document are same origin, can it be done, at least for the reparenting in the same JS execution block? Most (all?) of the security issues were specifically cross-origin. If I remember correctly, some of bugs we've had weren't about cross-origin iframes. It was about not being able to infer the correct origin in a detached iframe. So yes, they were cross-origin bugs because we ended up executing scripts we shouldn't be executing but that's not because iframes were cross-origin to begin with. But yes, there are a lot of assumptions in the code about not only iframes, but most active objects to function only while they are connected all the way through to the valid DOM. There is too many APIs (and new ones are coming all the time) who pick up that assumption. It is not impossible, just a lot of work. I would go as far as to say it's practically impossible. - Ryosuke
Re: [whatwg] keepalive attribute on iframe
Can you hide this behind adoptNode just as we did for magic iframe? The nice thing about adoptNode is that the browser gets told both the source and destination parent nodes. This way there is never a disconnected state. So long as we unload when moving between documents, we should be pretty safe as far as the issues which plagued magic iframe are concerned. -Darin On Thu, Apr 12, 2012 at 12:35 PM, Ojan Vafai o...@chromium.org wrote: We should add a keepalive attribute to iframes that prevents iframes from being unloaded/reloaded when removed from or appended to a document. Similarly, a disconnected iframe with keepalive should load. If the keepalive attribute is removed from a disconnected iframe, then it should unload. I'm not terribly happy with the name 'keepalive', but I can't think of anything better at the moment. As iframes increasingly become the standard way of achieving certain tasks (e.g. sandboxing), it's increasingly important to be able to move them around in the DOM. Right now, to achieve this sort of keepalive behavior, you have to keep the iframe always appended to the document and position it absolutely as the document changes. Ojan
Re: [whatwg] keepalive attribute on iframe
FWIW, IE used to not reload iframes when they were moved around in the tree. They changed this behavior in IE9 so maybe there was some compat issues? erik On Mon, Apr 16, 2012 at 16:51, Darin Fisher da...@chromium.org wrote: Can you hide this behind adoptNode just as we did for magic iframe? The nice thing about adoptNode is that the browser gets told both the source and destination parent nodes. This way there is never a disconnected state. So long as we unload when moving between documents, we should be pretty safe as far as the issues which plagued magic iframe are concerned. -Darin On Thu, Apr 12, 2012 at 12:35 PM, Ojan Vafai o...@chromium.org wrote: We should add a keepalive attribute to iframes that prevents iframes from being unloaded/reloaded when removed from or appended to a document. Similarly, a disconnected iframe with keepalive should load. If the keepalive attribute is removed from a disconnected iframe, then it should unload. I'm not terribly happy with the name 'keepalive', but I can't think of anything better at the moment. As iframes increasingly become the standard way of achieving certain tasks (e.g. sandboxing), it's increasingly important to be able to move them around in the DOM. Right now, to achieve this sort of keepalive behavior, you have to keep the iframe always appended to the document and position it absolutely as the document changes. Ojan
[whatwg] keepalive attribute on iframe
We should add a keepalive attribute to iframes that prevents iframes from being unloaded/reloaded when removed from or appended to a document. Similarly, a disconnected iframe with keepalive should load. If the keepalive attribute is removed from a disconnected iframe, then it should unload. I'm not terribly happy with the name 'keepalive', but I can't think of anything better at the moment. As iframes increasingly become the standard way of achieving certain tasks (e.g. sandboxing), it's increasingly important to be able to move them around in the DOM. Right now, to achieve this sort of keepalive behavior, you have to keep the iframe always appended to the document and position it absolutely as the document changes. Ojan
Re: [whatwg] keepalive attribute on iframe
We just got finished removing this feature from WebKit because it caused many security and stability problems. It turns out that there's a lot of code in browsers that can't cope with a disconnected iframe being alive. Adam On Thu, Apr 12, 2012 at 12:35 PM, Ojan Vafai o...@chromium.org wrote: We should add a keepalive attribute to iframes that prevents iframes from being unloaded/reloaded when removed from or appended to a document. Similarly, a disconnected iframe with keepalive should load. If the keepalive attribute is removed from a disconnected iframe, then it should unload. I'm not terribly happy with the name 'keepalive', but I can't think of anything better at the moment. As iframes increasingly become the standard way of achieving certain tasks (e.g. sandboxing), it's increasingly important to be able to move them around in the DOM. Right now, to achieve this sort of keepalive behavior, you have to keep the iframe always appended to the document and position it absolutely as the document changes. Ojan
Re: [whatwg] keepalive attribute on iframe
I thought the issue here was with moving iframes across documents, not with keeping disconnected iframes alive. I'll ping the engineers working on this and see if I can get more information. On Thu, Apr 12, 2012 at 12:37 PM, Adam Barth w...@adambarth.com wrote: We just got finished removing this feature from WebKit because it caused many security and stability problems. It turns out that there's a lot of code in browsers that can't cope with a disconnected iframe being alive. Adam On Thu, Apr 12, 2012 at 12:35 PM, Ojan Vafai o...@chromium.org wrote: We should add a keepalive attribute to iframes that prevents iframes from being unloaded/reloaded when removed from or appended to a document. Similarly, a disconnected iframe with keepalive should load. If the keepalive attribute is removed from a disconnected iframe, then it should unload. I'm not terribly happy with the name 'keepalive', but I can't think of anything better at the moment. As iframes increasingly become the standard way of achieving certain tasks (e.g. sandboxing), it's increasingly important to be able to move them around in the DOM. Right now, to achieve this sort of keepalive behavior, you have to keep the iframe always appended to the document and position it absolutely as the document changes. Ojan
Re: [whatwg] keepalive attribute on iframe
One path we saw in a couple exploits was to trick the code for moving frames between documents into keeping the frame alive outside of the DOM. Having a live frame outside of the DOM caused all kinds of madness. The underlying problem is that it's a strange, uncommon situation that affects many code paths. When folks write those code paths, they don't think about the live-frame-outside-the-DOM case and that situation doesn't get hardly any testing. Adam On Thu, Apr 12, 2012 at 12:41 PM, Ojan Vafai o...@chromium.org wrote: I thought the issue here was with moving iframes across documents, not with keeping disconnected iframes alive. I'll ping the engineers working on this and see if I can get more information. On Thu, Apr 12, 2012 at 12:37 PM, Adam Barth w...@adambarth.com wrote: We just got finished removing this feature from WebKit because it caused many security and stability problems. It turns out that there's a lot of code in browsers that can't cope with a disconnected iframe being alive. Adam On Thu, Apr 12, 2012 at 12:35 PM, Ojan Vafai o...@chromium.org wrote: We should add a keepalive attribute to iframes that prevents iframes from being unloaded/reloaded when removed from or appended to a document. Similarly, a disconnected iframe with keepalive should load. If the keepalive attribute is removed from a disconnected iframe, then it should unload. I'm not terribly happy with the name 'keepalive', but I can't think of anything better at the moment. As iframes increasingly become the standard way of achieving certain tasks (e.g. sandboxing), it's increasingly important to be able to move them around in the DOM. Right now, to achieve this sort of keepalive behavior, you have to keep the iframe always appended to the document and position it absolutely as the document changes. Ojan
Re: [whatwg] keepalive attribute on iframe
Quoting from the webkit-dev email killing this feature for cross-document iframe loads: We did have quite a few issues with this mechanism. The root of the problem seems to be that traditionally, multiple 'permissions' and 'live objects' are associated with a top-level page, or a top frame of some kind, instead of being associated with each Frame. Even HTML specifications often formulate the scope of things like permissions in terms of a page - for example, geo permissions are computed based on the origin of the page. When an iframe is transferred from one page to another, it may enter a different set of permissions while already performing operations authorized before. Association with the top-level page is also used to determine which one should show modal UI for HTTP Auth, per-origin permissions, or certificate issues for example. On Thu, Apr 12, 2012 at 12:45 PM, Adam Barth w...@adambarth.com wrote: One path we saw in a couple exploits was to trick the code for moving frames between documents into keeping the frame alive outside of the DOM. Having a live frame outside of the DOM caused all kinds of madness. The underlying problem is that it's a strange, uncommon situation that affects many code paths. When folks write those code paths, they don't think about the live-frame-outside-the-DOM case and that situation doesn't get hardly any testing. I feel like these are just implementation problems we need to address. We can't keep pushing more and more core functionality into iframes and not even be able to move them around in the DOM. It's OK to me, at least in the short term, if we disallow keepalive for cross-document moves given the problems WebKit had. Adam On Thu, Apr 12, 2012 at 12:41 PM, Ojan Vafai o...@chromium.org wrote: I thought the issue here was with moving iframes across documents, not with keeping disconnected iframes alive. I'll ping the engineers working on this and see if I can get more information. On Thu, Apr 12, 2012 at 12:37 PM, Adam Barth w...@adambarth.com wrote: We just got finished removing this feature from WebKit because it caused many security and stability problems. It turns out that there's a lot of code in browsers that can't cope with a disconnected iframe being alive. Adam On Thu, Apr 12, 2012 at 12:35 PM, Ojan Vafai o...@chromium.org wrote: We should add a keepalive attribute to iframes that prevents iframes from being unloaded/reloaded when removed from or appended to a document. Similarly, a disconnected iframe with keepalive should load. If the keepalive attribute is removed from a disconnected iframe, then it should unload. I'm not terribly happy with the name 'keepalive', but I can't think of anything better at the moment. As iframes increasingly become the standard way of achieving certain tasks (e.g. sandboxing), it's increasingly important to be able to move them around in the DOM. Right now, to achieve this sort of keepalive behavior, you have to keep the iframe always appended to the document and position it absolutely as the document changes. Ojan
