Instead of having the various positions and sizes of elements of the timeline
defined in pixels, this defines them in % of the total width.
This way the animations, scrubber, etc... adapt as you resize the panel.
The only complex thing here is resizing the header and background. Both of
them are generated via javascript. To do this, they are now positioned and sized
in % too, so they resize when the window is resized, and after a debounced
delay, they get re-generated too.
1 - Make the LayoutChangesObserver also send "resize" events; r=bgrins
The LayoutChangesObserver was originally made to observe all kinds of
layout-related events. So far, it was only observing reflows though.
This adds the capability to also observe resize events on the content
window.
2 - Removed the non-e10s rule/computed-views refreshing mechanism; r=bgrins
When the window is resized, the styles shown in the rule-view and
computed-view need to be updated (media-queries may be at play).
This was done before using a local-only, non-e10s solution. The
inspector-panel would listen to the resize event on the linkedBrowser
in the current tab.
This, obviously, did not work with e10s or across a remote connection.
This change just removes all of the code involved with this.
This won't cause any regression or backwards-compatibility problems as
a new server-driven resize observer is being put in place in this bug.
Even if you connected to an older server, you wouldn't see a difference
because the refresh-on-resize didn't work over remote connections already.
3 - Refresh the style-inspector when the LayoutChangesObserver detects resize
The implementation is simple, the inspector actor uses the
LayoutChangesObserver to detect window resize, and when it does, it
forwards the event to its front.
This is similar to how we deal with reflow events, except that for
reflows, the inspector actor (walker in this case), first filters on
the server to see if the reflow would indeed impact known nodes.
For resize events, it seemed more complex to do this kind of server
side filtering as this would involve remembering which node is currently
selected and which style were applied, and then compare that with the
new styles.
4 - Tests for the style-inspector refresh on window resize
Waiting for 50ms and checking if the scrollTop has changed does not
necessarily mean that the scrolling has stopped (or even started). It
might also mean that a GC has blocked the autoscroll interval from
running and the scrolling will happen in a few moments. If the view
hasn't even started to scroll, the assertion that the view has scrolled
fails. If the view has started to scroll, the next call to
waitForViewScroll() might resolve when before the direction of the
scrolling is reversed causing the assertions that the direction has
changed to fail.
Instead of relying on intervals to detect if scrolling has stopped, the
test could wait for a certain number of frames during which the view
has not scrolled to determine if the scrolling has ended. This method has
successfully been used in layout/base/tests/test_scroll_snapping.html
to detect when scrolling has stopped.
These changes make browser_markupview_dragdrop_autoscroll.js to use the
previously presented method to detect the end of markup-view autoscroll.
The code used in the layout test has been included in the test and
modified to yield and use promises when waiting for a frame.
This commit adds the `getImmediateDominator` method to `DominatorTree` which
returns the id of the immediate dominator of the node associated with the given
id. This enables walking the dominator tree from leaves up parents all the way
to the root of the tree.
This adds the `getImmediatelyDominated` method to `DominatorTree` which takes a
node id and returns the set of each node ids for every node that is immediately
dominated by the node with the given id. The results are sorted by greatest to
least retained size. In conjunction with the `root` attribute, this can be used
to traverse the whole dominator tree.
