What we actually care about here is whether itemRect is empty bceause that's
the what we'll use for the actual surface size.
Differential Revision: https://phabricator.services.mozilla.com/D48548
--HG--
extra : moz-landing-system : lando
This should fix the doc builds on Windows, as sphinx-js added Windows support in 2.3.1 and 2.4. We also now get support for variadic args, @deprecated, and @see, along with other features.
sphinx-js 2.7.1 changed the default cwd to be the one containing conf.py, so I also had to twiddle `jsdoc_config_path`.
Let some other pipenv pinnings update themselves as well, as, if I don't, they'll just update themselves the next time somebody runs `mach doc`, dirtying their tree.
I suspect this also fixes bug 1556460, whose equivalent bug in sphinx-js is https://github.com/mozilla/sphinx-js/issues/106. IOW, it should no longer break with versions of jsdoc >= 3.6.
Differential Revision: https://phabricator.services.mozilla.com/D48122
--HG--
extra : moz-landing-system : lando
With fission, we most likely have a process switch and the existing worker
target isn't properly detached. We should ensure releasing the SW whenever
the connection to the server drops
Differential Revision: https://phabricator.services.mozilla.com/D48061
--HG--
extra : moz-landing-system : lando
The original plan for the node-picker to work with multiple targets was introduced in D41598 (in bug 1568825). The idea was that, because we can have multiple independent inspectable targets, and because the client is the one doing the orchestration between them, to let the client start the node picker in all targets at once.
At the time of this first change, the code was create with this in mind, but there was really just one target (the top-level one).
So, this revision introduces the real code for this. First of all, I removed the now obsolete `getAllInspectorFronts` in `node-picker.js` because we now have a similar function on the inspector front directly.
Then the main code changes to look for are on the actor side, in the `HighlighterActor`. This is where the picking actually happens.
You have to remember that several targets will be picking at the same time, and therefore several `HighlighterActor` instances will be in pick mode at the same time.
The way they allow users to pick is by listening to mouse events (mousemove and clicks essentially).
Because these actors can't see or talk to each other, one can't tell the others that the mouse is now over its content and the other pickers should pause somewhat.
So, when one of them sees that the mouse event is happening on a remote frame, then it bails out and lets events through without handling them. This is so that the embedded document (which also has a picker running) can get a chance to receive the mouse events too.
The other aspect is that each `HighlighterActor`, when picking, does its own highlighting. So if there are 3 remote frames, then there really are 3 highlighters.
So the trick is to make sure only one of them ever appears at any given time. Again, these actors can't talk to each other directly, so the client is responsible for doing this when receiving events that a node was hovered.
This is not perfect, but should normally get far better when the new fission-compatible highlighter is in place. Indeed, when that happens, we won't have to care about this anymore, there will be only one `HighlighterRenderer` for the entire tab. So even if there are multiple `HighlighterActor` instances picking, they will all be sending events to the same renderer.
The only exception is in the browser toolbox where you can inspect both the browser UI and the content UI. In this case, there will be 2 renderers: one over the entire browser window, and one over the <browser> area. So we'll still have to do the dance of hiding one when the other is shown.
Differential Revision: https://phabricator.services.mozilla.com/D42640
--HG--
extra : moz-landing-system : lando
In that case, the flat tree cannot possibly be changing, so we don't really need
to invalidate anything. This, in theory, is just a really minor optimization.
In practice however, the browser chrome needs it, at least for now, because XUL
elements get frames really early (because we don't have lazy frame construction
for XUL, bug 1584935), and because destroying some kinds of frames (like panels)
does have side effects (they're popups), even though ideally they shouldn't.
Differential Revision: https://phabricator.services.mozilla.com/D48428
--HG--
extra : moz-landing-system : lando
Kernel can drop routes, addresses and neighbors without notification via netlink. So we update information in our structures as follows:
- when a link is removed all associated routes, addresses and neighbors are removed too
- when a link is disabled all associated routes and neighbors are removed
- when an address on a link is removed all routes and neighbors from this network are removed
All routes, neighbors and addresses always belong to some link, so a new class LinkInfo was created and it holds all information related to a single link. This makes finding information related to a specific link much easier.
Differential Revision: https://phabricator.services.mozilla.com/D48360
--HG--
extra : moz-landing-system : lando
Kernel can drop routes, addresses and neighbors without notification via netlink. So we update information in our structures as follows:
- when a link is removed all associated routes, addresses and neighbors are removed too
- when a link is disabled all associated routes and neighbors are removed
- when an address on a link is removed all routes and neighbors from this network are removed
All routes, neighbors and addresses always belong to some link, so a new class LinkInfo was created and it holds all information related to a single link. This makes finding information related to a specific link much easier.
Differential Revision: https://phabricator.services.mozilla.com/D48360
--HG--
extra : moz-landing-system : lando
