I took the opportunity to move away from the NonNull<nsAString> hack
we had for string arguments, since just passing in a
FakeDependentString works fine and callees are now less likely to
declare their arg as being of that type.
In the process of doing that, I ran into what looks like a substantive
bug in the "owning union with string default value" case: We were
doing mValue.mString.Value() without ever having constructed
mValue.mString!
Note that we can't name this namespace "detail", because then we'd
have both ::mozilla::detail and ::mozilla::dom::detail namespaces in
the tree and various template name lookups that look for "detail::Foo"
would get confused, and the code would not compile. C++ strikes
again.
I took the opportunity to move away from the NonNull<nsAString> hack
we had for string arguments, since just passing in a
FakeDependentString works fine and callees are now less likely to
declare their arg as being of that type.
In the process of doing that, I ran into what looks like a substantive
bug in the "owning union with string default value" case: We were
doing mValue.mString.Value() without ever having constructed
mValue.mString!
Note that we can't name this namespace "detail", because then we'd
have both ::mozilla::detail and ::mozilla::dom::detail namespaces in
the tree and various template name lookups that look for "detail::Foo"
would get confused, and the code would not compile. C++ strikes
again.
The iteration used to look up the current window's server-assigned
unique identifier in Marionette continues after the response has been
sent. This is unnecessary and a potential synchronization problem
because the client only expects a single response.
* Made the DebuggerClient, which is actually the RootActor front, not consider one of the attached child fronts as "active". Since a single DebuggerClient (or RootFront) is kept around for the App Manager's lifetime, it makes sense to move the notion of "active" tab to the toolbox's target. As each toolbox gets destroyed, the fronts should be detaching from their actors (if they are stateful) so that the app is no longer in a debugging state. Debugging a new app (or reconnecting to a previous one) will create new fronts anyway.
* Slightly refactored the TabClient, ThreadClient, SourceClient and TracerClient towards a protocol.js-based architecture, by adding parent-child references and lifecycle management. Now a tab-scoped thread actor for instance has the tab as its parent, while a global-scoped thread actor (chrome debugger) has the DebuggerCLient (RootFront) as its parent. This lets parents reference their children, so that caching in the target object can work. It also allowed me to move some methods from the DebuggerClient to the actual front that should be responsible, like reconfigureTab, reconfigureThread and attachThread. These methods now use DebuggerClient.requester, too.
* Added some error handling in the debugger client requester around "before" and "after" callbacks, which exposed some errors in tests that are now fixed.
* Fixed the state handling in the thread actor so that merely detaching from a thread doesn't put it in the exited state. This is the part that what was necessary for Firebug's use case.
* Properly loading tracer and webgl actors now on b2g.
