> More generally, tabs, iframes, workers, etc. all make up a set of browsing contexts. The question then becomes: what set of browsing contexts should be the unit of debugging? Or put differently: what set of browsing contexts should be under control of the debugger, so that pausing the debugger pauses every browsing context in that set?
To summarise our IRC discussion, In Servo, that should be all the script threads of current (as in, not frozen) pipelines under a top level Constellation::Frame. We don't have a notion of top level frame at the moment, so I recommend to track the pipelines of the root frame for now, but without assuming it is the parent of the existing pipelines; and once we support top level browsing context, you would switch from targeting root frame to top level frame. On Tue, Sep 6, 2016 at 10:17 PM, Jim Blandy <jbla...@mozilla.com> wrote: > This sounds right to me. Isn't this pretty much a ScriptThread? > > There are a lot of different ways to present the big picture. Sometimes you > want workers to stop and be paused along with the main thread; at other > times, you'd like the worker to continue running. (GDB took a > stop-the-world approach, but then later people paid big money to make it > support a one-thread-paused model too.) > > Ideally, the server should be free to focus on conveying the state of the > debuggee in an accurate and robust way, and the front ends should be able > to experiment rapidly with different ways of presenting that to the > developer. > > In a sense, the boundary of debugging is already fixed, in that it needs to > match what the Chrome protocol expects. I'd be very surprised if it weren't > a same-origin related browsing context, though. > > On Tue, Sep 6, 2016 at 9:58 AM, Nick Fitzgerald <nfitzger...@mozilla.com> > wrote: > >> I think that each unit of sequential execution should get its own debugger >> server (so a (same origin?) related browsing context). Then if we want to >> present a unified interface, we can race-ily pause workers (and cross >> origin iframes?) and coalesce these things in the UI or via a supervisor >> task. >> >> Basically, nothing really different from Gecko except that we can >> /actually/ pause event queues for different contexts and can talk about >> related browsing contexts directly instead of via guesswork. >> >> On Tue, Sep 6, 2016 at 5:40 AM, Till Schneidereit < >> t...@tillschneidereit.net >> > wrote: >> >> > On Tue, Sep 6, 2016 at 4:35 AM, Boris Zbarsky <bzbar...@mit.edu> wrote: >> > >> > > On 9/5/16 8:17 AM, Till Schneidereit wrote: >> > > >> > >> I don't think it makes too much sense to be able to pause completely >> > >> independent browsing contexts that can't possibly interact with each >> > >> other. >> > >> >> > > >> > > There is no such thing. They can always interact, just async. >> > > >> > >> > That is indeed an important point. While I meant sync interactions, that >> > doesn't cover worker threads, so it can't be the whole story. >> > _______________________________________________ >> > 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 >> > _______________________________________________ > 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
