Re: [dev-servo] Omar Mozilla Intern Introduction

On Wed, Jun 5, 2019 at 4:16 AM Alan Jeffrey wrote: > We're interested in doing the experiment of how to increase the amount of > determinism in a program like Servo where almost all the nondeterminism > that's observable by Servo has a single cause (in Servo's case selecting on > channels).

Re: [dev-servo] Omar Mozilla Intern Introduction

On Tue, Jun 4, 2019 at 11:49 AM Omar Salvador Navarro Leija < ole...@mozilla.com> wrote: > This summer, I will be looking at taming a small piece of the difficulty > with debugging parallel systems. Specifically, implementing > record-and-replay for Rust channels. This will hopefully make servo a

Re: [dev-servo] Servo testing as part of PhD dissertation

On Thu, Sep 8, 2016 at 4:12 AM, Lars Bergstrom wrote: > Along those lines, it's also worth looking at the very recent awesome > work at the University of Washington formalizing layout (upcoming > paper at OOPSLA): > http://cassius.uwplse.org/ > > I've been in contact with

Re: [dev-servo] Proposal: TLS library for Servo

On Thu, Sep 1, 2016 at 12:57 PM, Diane Hosfelt wrote: > Right now, what I’m working on is updating some TLS statistics using > https://github.com/mozilla/cipherscan cipherscan> (it’s taking a bit longer than I’d originally anticipated). >

Re: [dev-servo] Questions about constellation, sandboxing and multiprocess

On Thu, Aug 4, 2016 at 4:47 AM, Andrew McCreight wrote: > If you do want to think about it, I'd first read over the work that Chrome > people have already put into thinking about this issue: > http://www.chromium.org/developers/design-documents/site-isolation > > I'm not

Re: [dev-servo] Questions about constellation, sandboxing and multiprocess

On Wed, Aug 3, 2016 at 4:10 PM, Michael Howell wrote: > I can think of one advantage right now: by having script and layout in > separate processes, a compromised script thread doesn't automatically give > an attacker the ability to produce malformed display lists

Re: [dev-servo] How to efficiently react to an element changing visibility status from DOM code?

On Tue, Jun 21, 2016 at 9:16 AM, Jack Moffitt wrote: > > The problem is that you want notifications ahead of time that an element > is > > predicted to become visible, so you can decode images/video etc hopefully > > in time to render the element the moment it becomes visible.

Re: [dev-servo] How to efficiently react to an element changing visibility status from DOM code?

On Tue, Jun 21, 2016 at 4:41 AM, Jack Moffitt wrote: > How is this done in Gecko? > Display list analysis in the main thread. We learn something is not visible during one of the various cullings > of WebRender. So I guess the idea would be to have some notification > you send

[dev-servo] MathML

Don't quote me on this, but Mathjax is moving away from MathML which means MathML support in browsers is effectively a lost cause at this point. Don't even think about doing it. Rob -- lbir ye,ea yer.tnietoehr rdn rdsme,anea lurpr edna e hnysnenh hhe uresyf toD selthor stor edna siewaoeodm

Re: [dev-servo] Student Project

On Mon, Jan 11, 2016 at 7:04 AM, Nicolas Silva wrote: > Anyone interested in implementing WebAudio and/or WebRTC (in Gecko > there's some overlap in the underlying infrastructure) should first > spend some time discussing the architecture with Paul Adenot (look for >

Re: [dev-servo] IndexDB project

Jan Varga and others are currently reworking all client-side persistent storage APIs in Gecko so they can all use common quota management. You might want a similar framework in Servo now so you don't have to do a lot of expensive work later. You should talk to him or Kyle Huey or others on the

Re: [dev-servo] IndexDB project

On Tue, Dec 15, 2015 at 12:33 AM, Paul Rouget <p...@mozilla.com> wrote: > On Tue, Dec 15, 2015 at 5:27 AM, Manish Goregaokar > <manishsm...@gmail.com> wrote: > > On Tue, Dec 15, 2015 at 9:39 AM, Robert O'Callahan <rob...@ocallahan.org > > > > wrote: > &

Re: [dev-servo] Stacking order of inline stacking contexts

On Fri, Nov 6, 2015 at 12:53 PM, Martin Robinson wrote: > By way of example: > > > > Line 1 > Line 2 > > > > The two spans are inline, so normally "Line 1" would stack underneath > "Line 2" due to tree order. Since "Line 1" establishes a stacking >

Re: [dev-servo] Meeting notes 11/2 (review carry-over; test coverage; 2016 roadmap; rebase/autosquash; PR queue; debug logging; CSSWG reftests)

On Thu, Nov 5, 2015 at 12:44 AM, James Graham <ja...@hoppipolla.co.uk> wrote: > On 04/11/15 11:41, Robert O'Callahan wrote: > >> The media tests are better than I thought --- I found more. They don't >> test >> the variety of problematic media files that our moch

Re: [dev-servo] Meeting notes 11/2 (review carry-over; test coverage; 2016 roadmap; rebase/autosquash; PR queue; debug logging; CSSWG reftests)

On Thu, Nov 5, 2015 at 12:17 AM, James Graham <ja...@hoppipolla.co.uk> wrote: > On 04/11/15 11:12, Robert O'Callahan wrote: > >> Well sure, I agree that taking mochitests as the input to a test-writing >>> effort is a good idea. I see this as being very differ

Re: [dev-servo] Meeting notes 11/2 (review carry-over; test coverage; 2016 roadmap; rebase/autosquash; PR queue; debug logging; CSSWG reftests)

On Wed, Nov 4, 2015 at 5:14 PM, James Graham <ja...@hoppipolla.co.uk> wrote: > On 03/11/15 22:08, Robert O'Callahan wrote: > > Why not create a Mochitest compatibility layer over testharness.js so >> that tests that only use SimpleTest.waitForExplicitFinish(), >> Simp

Re: [dev-servo] Meeting notes 11/2 (review carry-over; test coverage; 2016 roadmap; rebase/autosquash; PR queue; debug logging; CSSWG reftests)

On Wed, Nov 4, 2015 at 11:50 PM, James Graham <ja...@hoppipolla.co.uk> wrote: > On 04/11/15 10:24, Robert O'Callahan wrote: > >> On Wed, Nov 4, 2015 at 5:14 PM, James Graham <ja...@hoppipolla.co.uk> >> wrote: >> >> On 03/11/15 22:08, Robert O'Callahan

Re: [dev-servo] Meeting notes 11/2 (review carry-over; test coverage; 2016 roadmap; rebase/autosquash; PR queue; debug logging; CSSWG reftests)

On Tue, Nov 3, 2015 at 10:10 PM, James Graham wrote: > On 02/11/15 18:43, Josh Matthews wrote: > >> https://github.com/servo/servo/wiki/Meeting-2015-11-02 >> > > For the record, I'm very against trying to run mochitests in Servo. As I > understand it the additional

Re: [dev-servo] Meeting notes 11/2 (review carry-over; test coverage; 2016 roadmap; rebase/autosquash; PR queue; debug logging; CSSWG reftests)

On Wed, Nov 4, 2015 at 1:48 PM, Manish Goregaokar wrote: > That sounds like a good idea. Perhaps we should do this on the > mozilla-central side; move things out of mochitest into WPT? > > Is there an easy way of identifying browser-agnostic mochitests? > Maybe grepping

[dev-servo] WebRender

This sounds very promising! A question: one of the graphs shows Servo taking 35ms per frame to paint the slide-in animation. What exactly is in this animation that makes it take such a relatively long time to paint? Rob -- lbir ye,ea yer.tnietoehr rdn rdsme,anea lurpr edna e hnysnenh hhe

Re: [dev-servo] Meeting notes 8/10 (retrying PRs; UA string; e10s; WebAudio preliminaries; demos; IndexedDB preliminaries)

On Mon, Aug 10, 2015 at 1:52 PM, Josh Matthews j...@joshmatthews.net wrote: https://github.com/servo/servo/wiki/Meeting-2015-08-10 Before you run ahead and implement WebAudio, I suggest talking to Paul Adenot or me about your design. We learned a lot from our implementation. Rob -- lbir

Re: [dev-servo] Meeting notes 7/27 (critic, e10s, hyper, builders)

Why can't you debug with sandbox enabled? Seems to me Rust needs to be able to build with optimizations and debugging diagnostics both enabled, and that's how you should run Servo tests. C++ can, and we rely on that on mobile for Gecko. Rob -- lbir ye,ea yer.tnietoehr rdn rdsme,anea lurpr

Re: [dev-servo] Per-document event queues

On Fri, Jul 24, 2015 at 10:26 AM, Josh Matthews j...@joshmatthews.net wrote: I don't believe anybody has put thought into addons beyond something like Chrome at this point. FWIW https://bugzilla.mozilla.org/show_bug.cgi?id=1161828 Rob -- lbir ye,ea yer.tnietoehr rdn rdsme,anea lurpr edna

Re: [dev-servo] Meeting notes 7/6 (Reviewable; benchmarking DOM/layout interaction; Rust/Servo training materials)

The layout engine synthesis ideas might pay off for the compute just this metric problem. Rob -- lbir ye,ea yer.tnietoehr rdn rdsme,anea lurpr edna e hnysnenh hhe uresyf toD selthor stor edna siewaoeodm or v sstvr esBa kbvted,t rdsme,aoreseoouoto o l euetiuruewFa kbn e hnystoivateweh

Re: [dev-servo] Multiprocess safety

On Fri, Jun 19, 2015 at 12:45 PM, Patrick Walton pwal...@mozilla.com wrote: It's fine to pass channels over channels as long as those channels don't cross process boundaries. Out of interest, why can't you pass channels over channels across a process boundary? Rob -- oIo otoeololo oyooouo

Re: [dev-servo] Multiprocess safety

On Fri, Jun 19, 2015 at 7:10 PM, Patrick Walton pwal...@mozilla.com wrote: In theory you can use cmsg on POSIX systems to send channels over channels, by treating channels as file descriptors. I tried this first, and I believe it actually worked well on Linux. But on Mac I ran into all sorts

Re: [dev-servo] Meeting notes 4/27 (Reviewable; blog posts; github/BMO; infra issues; Whistler planning)

On Tue, Apr 28, 2015 at 7:32 PM, Manish Goregaokar manishsm...@gmail.com wrote: But I think that as long as the glove still fits, we should use it. Perhaps reevaluate when we start shipping something (Rust-in-Gecko is already being tracked on Bugzilla and we' probably should continue with

Re: [dev-servo] Meeting notes 4/27 (Reviewable; blog posts; github/BMO; infra issues; Whistler planning)

On Tue, Apr 28, 2015 at 4:52 PM, Boris Zbarsky bzbar...@mit.edu wrote: For a layout engine, being able to attach an actual testcase to a bug report is _really_ useful once you get out of just build it mode and into fix all the bugs in this thing you built mode. Github issues simply have no

Re: [dev-servo] Meeting notes 3/16 (Android nightlies; Q2 focus; testing strategies; usability; layout direction; Rust upgrade blocked)

I have concerns about implementing full CSS algorithms in JS. People seem to think that makes it fast by default. It's more that what people are currently doing is crazy slow. Namely, to implement a custom layout today, you typically have to a) identify some DOM elements to measure (typically

Re: [dev-servo] Meeting notes 3/16 (Android nightlies; Q2 focus; testing strategies; usability; layout direction; Rust upgrade blocked)

On Tue, Mar 17, 2015 at 3:12 PM, Patrick Walton pwal...@mozilla.com wrote: Sure, I agree that if you're doing custom layout languages (Cassowary, etc.) Houdini is a win—the comment was more directed toward use of Houdini to reimplement layouts that can already be described with CSS. For those

Re: [dev-servo] WebGL canvas display

On Sun, Mar 15, 2015 at 6:38 AM, Patrick Walton pwal...@mozilla.com wrote: One issue is that we have to unconditionally layerize canvases for this, which violates the spec. What do you mean, it violates the spec? Rob -- oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo

Re: [dev-servo] UI Workers

On Tue, Feb 24, 2015 at 8:56 AM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Feb 23, 2015 at 10:56 AM, Gavin Sharp ga...@gavinsharp.com wrote: What does it mean to save your complex web app for later viewing? In gmail it would mean saving the set of emails that you are currently looking

Re: [dev-servo] UI Workers

On Tue, Feb 24, 2015 at 10:57 AM, Gordon Brander gbran...@mozilla.com wrote: It’s funny: I have come to the opposite conclusion for the same reason. The Good: getting 60fps interactions and animations in web apps using a proven approach (UI and interaction thread). The Ideal: also

Re: [dev-servo] UI Workers

On Tue, Feb 24, 2015 at 12:09 PM, Jonas Sicking jo...@sicking.cc wrote: I think this would fall over more often than not. Most developers will not write their code to be resilient in the face of being suspended for extended periods of time. Upon reopening they would likely display error

Re: [dev-servo] UI Workers

On Fri, Feb 20, 2015 at 10:50 PM, Christopher Lord cl...@mozilla.com wrote: I'd like to see #1 implemented first for two reasons; 1- I know this is easy to do given our platform, and I expect the same for other browser vendors, and 2- behaviour here is 100% predictable. There is nothing

[dev-servo] UI Workers

Last week in Sydney I spent a lot of time talking to Chrome devs about different approaches for 60fps effects in Web pages. There are three different kinds of approaches being discussed (so far): 1) Apple's animation-timeline proposal, which lets CSS animations use scroll position as an input

Re: [dev-servo] Moz2D/Skia (meeting notes)

On Thu, Nov 13, 2014 at 2:03 AM, Nicolas Silva nical.si...@gmail.com wrote: Well, depends on what you call a layer tree. Currently a layer tree is mostly a tree of intermediate surface that you render into, right? It's not a tool describe the content you want to rasterize (with the exception

[dev-servo] Moz2D/Skia (meeting notes)

https://github.com/servo/servo/wiki/Workweek-rasterization We talked about writing our own rasterizer, which makes sense because web pages only render solid colored rectangles, image, and display text. No. SVG, border-radius (rounded borders plus clipping to rounded shapes), complex border

[dev-servo] JS engine (meeting notes)

https://github.com/servo/servo/wiki/Workweek-alt-js I'm pleased with the Table discussion until mid 2015 outcome :-). It might make sense at some point to have a super secure Servo build where you plug in a JS interpreter and simple GC written in Rust, but I can't see a viable general-purpose

Re: [dev-servo] JS engine (meeting notes)

On Wed, Nov 12, 2014 at 11:42 AM, Cameron Zwarich zwar...@mozilla.com wrote: On Nov 11, 2014, at 1:21 PM, Robert O'Callahan rob...@ocallahan.org wrote: https://github.com/servo/servo/wiki/Workweek-alt-js I'm pleased with the Table discussion until mid 2015 outcome :-). It might make

Re: [dev-servo] Moz2D/Skia (meeting notes)

On Wed, Nov 12, 2014 at 2:49 PM, Nicolas Silva nical.si...@gmail.com wrote: If you guys ever have the resource to roll your own rasterizer, I would strongly suggest that you don't build an immediate mode api, and craft a more gpu-friendly scenegraph instead. To be honest I think that there is

Re: [dev-servo] RFC: Making stacking contexts more first-class

On Mon, Nov 10, 2014 at 1:36 PM, Patrick Walton pcwal...@mozilla.com wrote: On 11/9/14 4:31 PM, Josh Matthews wrote: I don't have any experience with these matters, but would this impact our ability to support the will-change CSS property? As I understand it, in Gecko the property basically

Re: [dev-servo] Invalidation test cases?

I still don't understand how your oveflow-based invalidation handles reflows. For example, suppose I have a regular document that's shorter than the whole window and I append some text to the bottom. The height of the body grows. Depending on the styles on the body, e.g. the value of

Re: [dev-servo] Invalidation test cases?

On Wed, Oct 29, 2014 at 10:08 AM, Patrick Walton pcwal...@mozilla.com wrote: On 10/28/14 1:46 PM, Robert O'Callahan wrote: For example, suppose I have a regular document that's shorter than the whole window and I append some text to the bottom. The height of the body grows. Depending

Re: [dev-servo] The current scrolling model

On Wed, Oct 8, 2014 at 10:55 PM, Patrick Walton pcwal...@mozilla.com wrote: On 10/8/14 10:51 PM, Robert O'Callahan wrote: You can get away with that for position:fixed, but I don't think you can get away with that for overflow:auto/scroll. We find in Gecko many real situations where scrolled

Re: [dev-servo] The current scrolling model

On Mon, Oct 6, 2014 at 7:49 PM, Patrick Walton pcwal...@mozilla.com wrote: On 10/6/14 7:44 PM, Boris Zbarsky wrote: Just to check, what's the plan for doing overflow: sticky? And does this model handle position:fixed things that end up both above and below pieces of a single position:static

Re: [dev-servo] Recent Improvements to Functions like getClientBoundingRect

On Fri, Aug 29, 2014 at 2:10 PM, Patrick Walton pwal...@mozilla.com wrote: It might happen if layout is flushed from outside the script task; window resizing/device rotation being what immediately comes to mind, as today in Servo those events go straight from compositor to layout without

[dev-servo] Meeting notes (Q3)

jack: We also had questions about replacing Azure with a thinner layer for disk/memory reasons. We talked to Bas about our options. He has some ideas already about what he wants to build as a new browser-focused graphics API from scratch. But that would be a multi-year, multi-person project

[dev-servo] meeting notes (incremental layout)

- jack: can we avoid width recalc when changing vertical height? pcwalton: that will break with vertical writing modes, among other things. not sure it's a good optimization. I'm not sure what jack had in mind exactly, but one very important incremental layout case is appending

Re: [dev-servo] Meeting notes (Q3)

Sorry, I only just got to the workweek graphics meeting notes :-). Servo will need to support 2D canvas, and it requires something like Moz2D. So I think you're stuck with it or something like it. I'll talk to Bas etc about fixing some of the resource management issues your notes allude to in

Re: [dev-servo] meeting notes (UTF8)

On Tue, Jul 8, 2014 at 2:51 PM, Cameron Zwarich zwar...@mozilla.com wrote: Are UTF8-backed (as opposed to Latin1-backed) JS strings with random access going to be a real possibility in SpiderMonkey? It’s obviously possible to make random access work with an appropriate indexing data

Re: [dev-servo] meeting notes (COW DOM)

On Tue, Jul 8, 2014 at 2:55 PM, Cameron Zwarich zwar...@mozilla.com wrote: There is this blog post: https://www.webkit.org/blog/3271/webkit-css-selector-jit-compiler/ I’m friends with the author and have anecdotal confirmation that the improvements also occur on real web pages. Good. I

Re: [dev-servo] Compositor Tree Redesign

On Tue, Jul 1, 2014 at 11:46 AM, Patrick Walton pcwal...@mozilla.com wrote: On 6/30/14 4:44 PM, Robert O'Callahan wrote: BTW have you or anyone else working on Servo looked at TextureClient/TextureHost in Gecko? Getting buffer management interfaces correct across many platforms with multi

Re: [dev-servo] Compositor Tree Redesign

On Tue, Jul 1, 2014 at 1:21 PM, Patrick Walton pcwal...@mozilla.com wrote: On 6/30/14 6:20 PM, Robert O'Callahan wrote: Yes. But if you haven't got robust support for D3D10 and Android gralloc and Windows Media Foundation accelerated video decoding and all that sort of thing, you probably

Re: [dev-servo] Compositor Tree Redesign

On Tue, Jul 1, 2014 at 3:27 PM, Cameron Zwarich zwar...@mozilla.com wrote: How much of that changed the basic nature of the abstraction and how much of it was just difficult platform-specific implementation work? Depends on the level of abstraction you're talking about, but we had to

Re: [dev-servo] 3/24 meeting notes (greetings; android; acid2; rust upgrade)

We have multiple layers support. I reworked because it was bogus, but it's a hard problem with iframes in multiple threads Would it be helpful to explain how multiprocess layer trees work in Gecko? Very different than it was before because they're doing it without false DOM nodes - all

Re: [dev-servo] 3/24 meeting notes (greetings; android; acid2; rust upgrade)

On Tue, Mar 25, 2014 at 9:41 AM, Patrick Walton pcwal...@mozilla.comwrote: On 3/24/14 1:40 PM, Robert O'Callahan wrote: We have multiple layers support. I reworked because it was bogus, but it's a hard problem with iframes in multiple threads Would it be helpful to explain how

Re: [dev-servo] JST guide

On Wed, Mar 5, 2014 at 11:33 AM, Josh Matthews j...@joshmatthews.netwrote: I know that some contributors have expressed confusion about the new JST types that are all over the DOM. I've started a guide to try and clear up how to use them; please feel free to suggest further topics or make

Re: [dev-servo] JST guide

On Wed, Mar 5, 2014 at 12:55 PM, Josh Matthews j...@joshmatthews.netwrote: It can be, but there are cases when that would be wasted effort. I'm open either way. In XPCOM terms, the vast majority of QueryInterface calls do more with the returned pointer than a null check. So I think you'll

Re: [dev-servo] Roadmap Q2 goal : Pass Acid3

On Wed, Feb 26, 2014 at 7:02 AM, Patrick Walton pcwal...@mozilla.comwrote: So I agree that we must not make architectural decisions that make it difficult to implement Web features. But I do think that Web compat is useful, because it helps us to identify the parallel hazards and know where

[dev-servo] Display list stuff

On Thu, Feb 6, 2014 at 5:09 AM, Josh Matthews j...@joshmatthews.net wrote: https://github.com/mozilla/servo/wiki/Meeting-2014-02-03 - pcwalton: that's how gecko does it, but the FrameLayerBuilder is really complicated. Roc is the only one who understands how that works, so should

Re: [dev-servo] Meeting 2013-11-04: mac builder failure, priorities (C++, layout, parallelism, rustpkg, embedding, graphics)

I had a discussion with pcwalton and kmc yesterday about string interning. The concurrent cuckoo hash table is cool but maybe not the right fit for the browser workload for a couple of reasons: a) interning lookups are mostly not on the hottest paths. They will occur during parsing, and that can

Re: [dev-servo] 9/23 meeting - leaks, crashes, reflow performance, demos

nsBlockReflow, and most layout code, is indeed inefficient. Some amount of that is because we support a lot of features and we've fixed a lot of bugs. Fixing bugs tends to add code, and even if you try to keep things off commonly taken paths, even not-taken conditionals add up. I guess I'm saying

Re: [dev-servo] Meeting notes - further discussion of selected topics from Unanswered questions thread

people like roc say we must be at least as fast as Gecko for everything To be clear: I think Servo's architecture must not prevent Servo from being as fast as Gecko for everything. I push for microbenchmarks targeting the risky parts of Servo's architecture because we must avoid discovering much

Re: [dev-servo] Meeting notes - further discussion of selected topics from Unanswered questions thread

For compositing with IFRAMEs, you might want to consider what we do for multi-process compositing in Gecko. It's somewhat obvious but it seems like it works well. Each process publishes a layer tree to the compositor. A layer tree can contain RefLayers, each with a unique ID. A layer tree root can

Re: [dev-servo] Unanswered questions from a QA about Servo

On Fri, Jul 12, 2013 at 11:33 AM, Patrick Walton pwal...@mozilla.comwrote: * Do we have data showing how many security bugs we could be avoiding in Servo in comparison to Gecko? Is the security benefit truly as valuable if expected performance benefits don't pan out? We've been talking to

Re: [dev-servo] Unanswered questions from a QA about Servo

On Fri, Jul 12, 2013 at 6:00 PM, Patrick Walton pwal...@mozilla.com wrote: In general the overhead for writes and borrows will probably be only a couple of instructions over a dereference operation. Reads should be unbarriered, although I think we need a little more design to make that happen

Re: [dev-servo] Unanswered questions from a QA about Servo

On Fri, Jul 12, 2013 at 5:55 PM, Robert O'Callahan rob...@ocallahan.orgwrote: A quick scan suggests that all 34 sec-critical bugs filed against Web Audio so far are either buffer overflows (array-access-out-of-bounds, basically) or use-after-free. In many cases the underlying bug is something

Re: [dev-servo] More planning

On Thu, Feb 14, 2013 at 7:19 PM, Luke Wagner l...@mozilla.com wrote: Eventually I can imagine writing the JIT in Rust and using some kind of certified compilation to guard against compiler bugs. I haven't really followed this topic; do you really think this would be a feasible approach to

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

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