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?
-Boris
___
On 10/19/12 1:55 PM, Boris Zbarsky 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 implementa
On 10/21/12 1:49 AM, Patrick Walton wrote:
I'm not entirely clear on the semantics of adoptNode. Is it possible
that the node could come from a different origin?
On the web, no. As far as what browser UI and extensions can do... up
to us, I guess.
If the node can't come from a different or
Boris Zbarsky wrote:
On 10/21/12 1:49 AM, Patrick Walton wrote:
I'm not entirely clear on the semantics of adoptNode. Is it possible
that the node could come from a different origin?
On the web, no. As far as what browser UI and extensions can do... up
to us, I guess.
I think the right ans
On 10/21/12 1:34 PM, Brendan Eich wrote:
Ah, ok. We'd need to find all the places in the old document that
reference the node, but that might be feasible.
By tracking all the time, or scanning only upon an adoptNode? Hrm.
We'd only need the Rust references, since the JS ones would be handled
Boris Zbarsky wrote:
On 10/21/12 1:34 PM, Brendan Eich wrote:
Ah, ok. We'd need to find all the places in the old document that
reference the node, but that might be feasible.
By tracking all the time, or scanning only upon an adoptNode? Hrm.
We'd only need the Rust references, since the JS
Le 22/10/2012 12:58, Brendan Eich a écrit :
> Boris Zbarsky wrote:
>> So we'd only need to worry about places in the Rust code on the DOM
>> side that hold references to nodes that are not in the DOM tree.
>> There shouldn't be that many (e.g. the -moz-element stuff would have
>> that, perhaps, an
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 d
On 10/22/12 6:58 AM, Brendan Eich wrote:
Is adoptNode an important API?
Define important?
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
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.
On 10/22/12 7:59 AM, David Bruant wrote:
As a web developer, I've never used adoptNode
I will bet $100 that you have, and never even realized it, what with
implicit adoption. Again, unless you're narrowly defining "use" as
"call adoptNode" as opposed to "adopt a node".
Specifically, compar
On 10/22/12 10:15 AM, Brendan Eich wrote:
Defined in terms of "not important" == "can put in perf penalty box" of
some non-trivial penalty-size.
This is always true. It only takes one benchmark that takes off that
exercises something you assumed was rare for you to be screwed.
That said, I w
Boris Zbarsky wrote:
On 10/22/12 10:15 AM, Brendan Eich wrote:
Defined in terms of "not important" == "can put in perf penalty box" of
some non-trivial penalty-size.
This is always true. It only takes one benchmark that takes off that
exercises something you assumed was rare for you to be scr
On 10/22/12 10:29 AM, Brendan Eich wrote:
We know document.write has to be fast
(http://www.youtube.com/watch?v=3NVpFj64MQU).
1) document.write is not fast (though of course "fast" is a relative
concept).
2) How slow it is depends on what's passed to the call.
Just fyi.
This has nothing t
On Sun, Oct 21, 2012 at 6:50 PM, Patrick Walton 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, eve
On Sat, Oct 20, 2012 at 9:55 AM, Boris Zbarsky 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 pointe
On 10/24/2012 4:04 PM, Robert O'Callahan wrote:
> On Sat, Oct 20, 2012 at 9:55 AM, Boris Zbarsky 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
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 mai
18 matches
Mail list logo
