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.
