Depends on D18236
Worker updates are very hard to predict and we have many intermittents caused by pending requests
for workers while we destroy the client.
Discussed with @ochameau about the potential solutions, and disabling worker updates in tests that don't need them seems a good option. A complementary solution can be to wait for debugger-client waitForRequestsToSettle (different from our current helper in head.js).
Differential Revision: https://phabricator.services.mozilla.com/D18237
--HG--
extra : moz-landing-system : lando
Depends on D18235
The two parameters in the openAboutDebugging are a leftover from the original helper of the old about:debugging.
Differential Revision: https://phabricator.services.mozilla.com/D18236
--HG--
extra : moz-landing-system : lando
Depends on D18234
Most tests will now need to use the mocks helper to avoid loading the regular client-wrapper.
Differential Revision: https://phabricator.services.mozilla.com/D18235
--HG--
extra : moz-landing-system : lando
Environment shapes always use the max number of fixed slots before using
dynamic slots (see EmptyEnvironmentShape). We can take advantage of this in
the JITs and eliminate the calls to EnvironmentCoordinateToEnvironmentShape.
Differential Revision: https://phabricator.services.mozilla.com/D19361
--HG--
extra : moz-landing-system : lando
Bug 1526508 - add profiler markers for importing a JS module, loading a JS XPCOM component or a subscript
Differential Revision: https://phabricator.services.mozilla.com/D19228
--HG--
extra : moz-landing-system : lando
The mIndexInInserted keeps pointing to the last assigned node of a slot parent
when we are at the end of child list. So when we calles GetPreviousChild when we
are at the end of child list, ExplicitChildIterator will skip last assigned node.
Differential Revision: https://phabricator.services.mozilla.com/D19651
--HG--
extra : moz-landing-system : lando
This is for the scrollable frame, because nsIFrame::IsFocusable of a scrollable
frame returns true with tabIndex = 0 even if the content has no tabIndex
attribute.
Differential Revision: https://phabricator.services.mozilla.com/D19646
--HG--
extra : moz-landing-system : lando
Add the origin ContentParent to a CanonicalBrowsingContext's group
when a CanonicalBrowsingContext is created from IPC. With this it is
possible to keep track of all child processes associated with a
BrowsingContextGroup.
Differential Revision: https://phabricator.services.mozilla.com/D19004
--HG--
extra : moz-landing-system : lando
Depends on D18236
Worker updates are very hard to predict and we have many intermittents caused by pending requests
for workers while we destroy the client.
Discussed with @ochameau about the potential solutions, and disabling worker updates in tests that don't need them seems a good option. A complementary solution can be to wait for debugger-client waitForRequestsToSettle (different from our current helper in head.js).
Differential Revision: https://phabricator.services.mozilla.com/D18237
--HG--
extra : moz-landing-system : lando
Depends on D18235
The two parameters in the openAboutDebugging are a leftover from the original helper of the old about:debugging.
Differential Revision: https://phabricator.services.mozilla.com/D18236
--HG--
extra : moz-landing-system : lando
Depends on D18234
Most tests will now need to use the mocks helper to avoid loading the regular client-wrapper.
Differential Revision: https://phabricator.services.mozilla.com/D18235
--HG--
extra : moz-landing-system : lando
This is what Chrome does.
documentElement-clientWidth-on-minimum-scale-size.tentative.html was the test
case for this but unfortunately it was disabled in bug 1515043. And it seems
that the test case failed on Android in the first place.
Differential Revision: https://phabricator.services.mozilla.com/D19461
--HG--
extra : moz-landing-system : lando
This is a clearer implementation that achieves the same thing.
Moreover, disabling the clearing by overriding drawRect wouldn't work in
CoreAnimation windows because in CoreAnimation windows, the clearing happens
through a property of the NSVisualEffectView's CALayer, and not through the
view's drawRect implementation - drawRect probably isn't even called in that
context.
Differential Revision: https://phabricator.services.mozilla.com/D19601
--HG--
extra : moz-landing-system : lando
This has two advantages:
- The drawing will now correctly be placed "on top" of the vibrancy views.
- We can turn this new view into a layer-hosting view. Layer-hosting views are
supposed to be leaf NSViews; they shouldn't have any children.
Differential Revision: https://phabricator.services.mozilla.com/D19600
--HG--
extra : moz-landing-system : lando
Otherwise, any views inside the contentView are imbued with a vibrant effect, and
even non-NSVisualEffectView NSViews subtract from the vibrant region of any actual
vibrant views they overlap. This would cause the PixelHostingView to 'erase' the
blue context menu item highlighting.
This behavior is documented on NSVisualEffectView:
> It is recommended that you enable vibrancy only in the leaf views of your view
> hierarchy. Subviews inherit the vibrancy of their parent. Once enabled in a
> parent view, a subview cannot turn off vibrancy. As a result, enabling
> vibrancy in a parent view can lead to subviews that look incorrect if they are
> not designed to take advantage of the vibrancy effect.
Differential Revision: https://phabricator.services.mozilla.com/D19599
--HG--
extra : moz-landing-system : lando
NSView hierarchy before:
- window contentView
- ChildView
- NonDraggableView 1
- NonDraggableView 2
- EffectViewWithoutForegroundVibrancy 1
- EffectViewWithoutForegroundVibrancy 2
NSView hierarchy after:
- window contentView
- ChildView
- ViewRegionContainerView
- NonDraggableView 1
- NonDraggableView 2
- ViewRegionContainerView
- EffectViewWithoutForegroundVibrancy 1
- EffectViewWithoutForegroundVibrancy 2
This allows us to give those container views a new sibling view which stays
fixed in z-order with respect to the NSViews that get created by
mNonDraggableRegion and mVibrancyManager. More specifically, I'm going to add a
view for the drawing of our ChildView ("PixelHostingView") which is going to be
a direct child of the Gecko "ChildView" and a sibling of the
ViewRegionContainerViews; the PixelHostingView needs to always stay on top of
the vibrancy views.
Without the wrapper around the vibrancy views, whenever the vibrant region
changes, a vibrant view would be placed on top of the PixelHostingView and the
order would be wrong.
Differential Revision: https://phabricator.services.mozilla.com/D19598
--HG--
extra : moz-landing-system : lando
