Most test modifications deal with listening to the proper events.
As mentioned in the parent commit, the keyboard navigation for the
inspector-search changed a bit with this change, so the related test
case is using a slightly different scenario.
MozReview-Commit-ID: BgSa69bSSFB
--HG--
extra : rebase_source : a1b565f6b54f2c8e3d641794aaa6aa43a2c75134
Modify the devtools autocomplete-popup to rely on a HTMLTooltip instance
instead of a XUL panel.
Other than the straightforward migration to HTML, the main difference with
the new implementation is that the richlistbox has now been replace with a
simple HTML list element. The former XUL widget used to be able to take the
focus from the input it was linked to.
This is no longer the case. Most autocomplete users were always keeping the
focus in the input, except for the inspector-search, which was moving the
focus back and forth between the input and the autocomplete's richlistbox.
Now the focus is always in the input. A practical example to illustrate how
this changes the UX: before when the user had the focus on the first element
of the list, pressing "DOWN" would keep the element selected but visually move
the focus in the input. Now the selection simply cycles to the next item.
Even though this introduces a difference in behaviour compared to the previous
implementation, it makes the inspector search UX consistent with the other
autocomplete widgets used in devtools.
Another difference is about the display for the inspector-search. The position
of the autocomplete popup used to be above the input. This is now impossible to
achieve because the search input is at the top of the toolbox and the HTML tooltip
can not exceed the limits of the toolbox.
For this #2 issue, either we manage to use XUL panel wrappers, in which case, the
autocomplete will be displayed as it used to. Or we can invert the order in which
items are inserted and explicitly ask for the autocomplete to be displayed below the
input. I prefered not to change this here in order to make the code change easier to
understand, but it should be addressed in a follow-up.
MozReview-Commit-ID: jH9aXm9Jvz
--HG--
extra : rebase_source : 57267be0d214ed807f3152838c4123400ab7b7e3
There are two leaks addressed in this commit:
1. The thread actor's `_debuggerSourcesSeen` set was never cleared. This set
exists only as a performance optimization to speed up `_addSource` in cases
where we've already added the source. Unfortunately, this set wasn't getting
cleared when we cleared debuggees out and it ended up keeping the
`Debugger.Source`, its referent, and transitively its referent's global alive. I
figured it was simpler to make it a `WeakSet` than to add it as a special case
in `ThreadActor.prototype._clearDebuggees` and manage the lifetimes by hand. I
think this fits well with its intended use as an ephemeral performance
optimization.
2. Due to a logic error, we were not clearing debuggees in the memory actor's
`Debugger` instance on navigations. This isn't really a "proper" leak, in that
if you forced a GC, the old debuggees would go away as `Debugger` holds them
weakly, however if there was no GC between navigations, then you could still see
the old windows (and everything they "retained") as roots in the snapshot. This
issue is straightforward to fix once identified: ensure that `_clearDebuggees`
is actually called on navigation.
Finally, this commit adds a test that we don't leak Window objects when devtools
are open and we keep refreshing a tab. When it fails, it prints out the leaking
window's retaining paths.
The HTMLTooltip supports an additional configuration parameter "useXulWrapper".
When set to true, if the tooltip is displayed in a XUL document, a XUL panel
will be used as an additional container for the tooltip.
This allows the tooltip to be displayed anywhere on the screen and can be
useful when displayed in small toolboxes.
MozReview-Commit-ID: 63kv4vAeW5R
--HG--
extra : source : fc4d902ff01ee92a5b6742d44286e5feaaba1500
extra : intermediate-source : 126f43ff3be5505920946a77ad82401c6bbaebef
extra : histedit_source : 863888c014723f7e95742079395497ba1a30aa36%2C13ba9aaf80acb96c587739c767c20a8f0f6a9a5a
