> 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
On Thu, Sep 1, 2016 at 10:43 AM, Jack Moffitt wrote:
> mozpkix was the proposal, which Brian is also an author of. Brian, why
> exactly is mozpkix hard to wrap? Specific examples may help us
> understand Rust / C++ limitations. If that library is hard enough to
> wrap, then it
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.
> NSS doesn’t currently support building as static libraries. Do you think it
> would be better to try to use the system NSS or ship the libraries?
Depending on the system one exclusively is one reason why our OpenSSL
bindings suck. So we have to have it built by Cargo as a fallback.
jack.
On Tue, Sep 6, 2016 at 4:35 AM, Boris Zbarsky 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
NSS doesn’t currently support building as static libraries. Do you think it
would be better to try to use the system NSS or ship the libraries?
Diane
> On Sep 5, 2016, at 10:16, Ms2ger wrote:
>
> On 26/08/16 02:13, Diane Hosfelt wrote:
>> Proposed Development
>>
>> I
6 matches
Mail list logo