Straight-forward addition of the --no-install option for reftest, just like
the existing option for mochitest. For gtest, I alos noticed the mach command
help needed some cleanup.
Differential Revision: https://phabricator.services.mozilla.com/D43299
--HG--
extra : moz-landing-system : lando
Now performing a sanity check after grabbing the child at position due to the fact that it can be
null if the position is out of array bounds (this usually happens when all panels are hidden and we request an orientation change).
Differential Revision: https://phabricator.services.mozilla.com/D43236
--HG--
extra : moz-landing-system : lando
With top-level await, we can now have multiple
evaluation results next to each others. Which
means that if they had the same repeatId, we
would only print the first result.
We fix that by not allowing evaluation results to
be repeated.
A mochitest is added to ensure the patch properly
fixes the issue.
Differential Revision: https://phabricator.services.mozilla.com/D43253
--HG--
extra : moz-landing-system : lando
In OnIncomingFrame() we check if the capture has started by calling
CaptureStarted() which holds a lock. If StopCapture() is called on the
control thread after we check CaptureStarted() it is possible that
_captureCapability will be zeroed out prior to frame being delivered because
the lock has been released. This would result in an unknown video type in
CalcBufferSize() and trigger an assertion there. This creates a local copy of
_captureCapability with the lock held to ensure it is not zeroed out when the
frame is delivered.
Differential Revision: https://phabricator.services.mozilla.com/D42338
--HG--
extra : moz-landing-system : lando
Seems we'll update the change hint properly via SetTarget if we get a new
target.
Differential Revision: https://phabricator.services.mozilla.com/D43397
--HG--
extra : moz-landing-system : lando
I've tried hard to find a solution for the clipped window button problem which
does not involve swizzling but could not find one.
The officially ratified ways of moving the window buttons are:
1. Use an NSToolbar in your window, or
2. Make a custom window with your own buttons.
I don't think having an NSToolbar is an option for us. And making our own window frame
implementation would be hard to get right and can easily behave differently from the
native implementation.
I've also tried asking the window to not render any window buttons on its own; then we
could make our own buttons and place them on top of our view. But if I change the
window's styleMask to be just NSTitledWindowMask, it doesn't only make the buttons
disappear, it also makes the window non-resizable. And if I include NSResizableWindowMask,
the buttons come back (only the zoom button is enabled, the other two are grayed out).
This change also stops overriding _wantsFloatingTitlebar when CoreAnimation is
enabled, which is necessary for the window buttons to render.
Depends on D43341
Differential Revision: https://phabricator.services.mozilla.com/D43361
--HG--
extra : moz-landing-system : lando
This gives us two behaviors for free which we were achieving through manual
overrides:
- The content view is sized to cover the entire window frame.
- The window controls are placed on top of the content view (instead of
underneath it in z-order).
It also forces CoreAnimation layers for the window's entire NSView hierarchy, so
we only use it when the CoreAnimation pref is enabled.
NSFullSizeContentViewWindowMask is only available on 10.10 and up, but we still
support 10.9, so we cannot remove the code with the manual overrides just yet.
This change also requires a change to NonDraggableView in order to preserve
window dragging behavior in the titlebar: When NSFullSizeContentViewWindowMask
is used, the method which assembles the window's draggable region takes a
different path. It treats the titlebar specially, and traverses the NSView
hierarchy twice, once for the titlebar area and once for the rest of the window.
Outside the titlebar, it calls _opaqueRect on every visible NSView, but for the
titlebar area, it calls _opaqueRectForWindowMoveWhenInTitlebar instead.
Overriding _opaqueRectForWindowMoveWhenInTitlebar allows us to achieve the old
dragging behavior.
Differential Revision: https://phabricator.services.mozilla.com/D43341
--HG--
extra : moz-landing-system : lando
This makes them only apply in windows with titlebars, which is the only place
where they're needed. The setContentView override can even cause harm for other
windows, such as sheet windows, because it'll move the content view below a
full-window covering solid grey view provided by the system, in builds that
link against the 10.14 SDK and don't override _wantsFloatingTitlebar.
Differential Revision: https://phabricator.services.mozilla.com/D43340
--HG--
extra : moz-landing-system : lando
This makes prefs definition simpler, more consistent, and less error-prone.
Differential Revision: https://phabricator.services.mozilla.com/D41145
--HG--
extra : moz-landing-system : lando
Kartikaya Gupta
Geoff Brown
David Walsh
Andreas Pehrson
Andrei Lazar
alexandru.ionescu
Mirko Brodesser
Tom Ritter
Andreas Farre
ffxbld
tanhengyeow
Cameron McCormack
Nicolas Chevobbe
Dan Minor
Arpit Bharti
Masayuki Nakano
Benjamin Bouvier
Andi-Bogdan Postelnicu
Emilio Cobos Álvarez
Sebastian Hengst
Ed Lee
Markus Stange
Nicholas Nethercote
Brad Werth