Re: [dev-servo] Handling adoptNode
On Sun, Oct 21, 2012 at 6:50 PM, Patrick Walton pwal...@mozilla.com wrote: It seems to me that Google Chrome would have the same problems here, since it runs different origins in different processes. AFAIK, in Chrome, if two JS documents can reference each other's heaps, it puts them in the same process, even if they're different origins. Rob -- “You have heard that it was said, ‘Love your neighbor and hate your enemy.’ But I tell you, love your enemies and pray for those who persecute you, that you may be children of your Father in heaven. ... If you love those who love you, what reward will you get? Are not even the tax collectors doing that? And if you greet only your own people, what are you doing more than others? [Matthew 5:43-47] ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Handling adoptNode
On Sat, Oct 20, 2012 at 9:55 AM, Boris Zbarsky bzbar...@mit.edu wrote: Do we have a plan for adoptNode? If we're allocating nodes out of the JS heap, presumably we'll need to brain-transplant the JSObject and then copy over the implementation into the new compartment... and make sure we update any pointers to the implementation, right? Couldn't we replace the original with a proxy that forwards to the new object? It would get a bit complex if the node is adopted many times, but seems like it ought to work. Rob -- “You have heard that it was said, ‘Love your neighbor and hate your enemy.’ But I tell you, love your enemies and pray for those who persecute you, that you may be children of your Father in heaven. ... If you love those who love you, what reward will you get? Are not even the tax collectors doing that? And if you greet only your own people, what are you doing more than others? [Matthew 5:43-47] ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Handling adoptNode
On 10/24/12 7:04 PM, Robert O'Callahan wrote: Couldn't we replace the original with a proxy that forwards to the new object? For access from JS that's exactly what we'll do. The question is what happens for access from Rust. -Boris ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Handling adoptNode
On 10/22/2012 7:59 AM, David Bruant wrote: Is adoptNode an important API? It's not a good design in my view, but I'm in a glass house when it comes to criticizing DOM APIs :-P. Perhaps it's ok for performance to be in a penalty box for adoptNode. As a web developer, I've never used adoptNode, I don't even recall having seen it in an actual website while view-sourcing. So if there is a trade-off to be made in which the downside is adoptNode being slow, I personnally think it's a worthwhile trade-off. It's definitely used on some high-visibility websites; we had a bug where some framework was calling .adoptNode on a plugin element and it showed up on several sites including a German transit site and several Chinese video sites. So I'd treat our assumptions with some caution. I thought that using XHR to parse into a document and then adopting those nodes into the current document is a fairly common occurrence, but I might be wrong about that. --BDS ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Handling adoptNode
Boris Zbarsky wrote: On 10/22/12 6:58 AM, Brendan Eich wrote: Is adoptNode an important API? Define important? Defined in terms of not important == can put in perf penalty box of some non-trivial penalty-size. Still could have too high a penalty, but we can roll the dice with Servo. /be Not implementing adoption breaks the web. That includes both explicit adoption via adoptNode and implicit adoption via simply inserting the node into a different document. Both pose identical problems for our design, so I wasn't bothering to draw a distinction between them. Perhaps it's ok for performance to be in a penalty box for adoptNode. Yes. There already is in Gecko, btw: we have to go through and brain-transplant everything in the subtree and whatnot. -Boris ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
