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
Having separate tab stops for every toolbar control results in an unmanageable number of tab stops.
Therefore, we group several buttons under a single tab stop and allow movement between them using left/right arrows.
However, text inputs use the arrow keys for their own purposes, so they need their own tab stop.
There are also groups of buttons before and after the URL bar input which should get their own tab stop.
The subsequent buttons on the toolbar are then another tab stop after that.
Tab stops for groups of buttons are set using the <toolbartabstop/> element.
This element is invisible, but gets included in the tab order.
When one of these gets focus, it redirects focus to the appropriate button.
This avoids the need to continually manage the tabindex of toolbar buttons in response to toolbarchanges.
Navigation to for the View site information button and notification anchors is now managed by this new framework.
As such, they no longer need their own position in the tab order and the CSS has been tweaked accordingly.
For now, this new functionality is behind a pref (browser.toolbars.keyboard_navigation) which is currently disabled by default.
Differential Revision: https://phabricator.services.mozilla.com/D15060
--HG--
extra : moz-landing-system : lando
- makes changes to various configuration files, thanks jmaher
- for the time being, disable tests via `taskcluster/ci/test/test-platforms.yml` to prevent overwhelming the hardware at Bitbar
Differential Revision: https://phabricator.services.mozilla.com/D19581
--HG--
extra : moz-landing-system : lando
This is a preparatory change that can be useful by itself:
- use match on EntryKind to allow safe expansion
- avoid code duplication in get()
- fix some comments
Differential Revision: https://phabricator.services.mozilla.com/D19674
--HG--
extra : moz-landing-system : lando
This is a follow-up to the previous part, which actually changes one of
these callers to use Array<nsIIDRef> instead of [array] nsIIDPtr.
From doing this patch, it seems like we should consider changing
the type `nsIIDRef` to instead simply be `nsIID`, and treat it more like
the `AString` types from the POV of XPIDL. `nsIIDPtr` would then
continue to exist for backwards compatibility, but we can probably
remove almost all current consumers over time.
Depends on D19175
Differential Revision: https://phabricator.services.mozilla.com/D19176
--HG--
extra : moz-landing-system : lando
Currently the [ref] and [ptr] types share the same underlying
implementation. This is unfortunate, and can cause correctness problems
with outparam refs (as an example).
By using the same tools used to allow other larger objects (such as
jsid, nsTArray, and nsString) to be stored directly in the nsXPTCVariant
object, this patch directly stores the nsID in the nsXPTCVariant object
when calling from JS into C++.
Using this new strategy avoids an nsID* allocation every time we pass
one over XPConnect, and should also allow us to simplify callers.
In addition, some special casing is added to xpidl to make it possible
to use the nsid reference type objects directly inside of Array<T>,
which will allow us to remove `[array] nsIIDPtr` callers.
Differential Revision: https://phabricator.services.mozilla.com/D19175
--HG--
extra : moz-landing-system : lando
