I did a bunch of manual testing with this, the biggest uncertainties lie around beta and central/nightly.
We are adding shippable-qr to beta because of replacing nightly too.
Autoland and inbound should have the same sets of tasks.
beta -
- adds mochitest-plain-headless-{1..4} to beta (not currently run)
- adds raptor to run on shippable for beta
- currently runs on opt on beta, and for nightly tasks on beta only webaudio-chrome runs.
- adds talos to shippable tasks, on beta talos only runs against opt.
central -
- adds browser-screenshots to nightly graph
- adds mochitest-plain-headless-{1..4} to nightly graph
- adds browser-instrumentation to shippable
Differential Revision: https://phabricator.services.mozilla.com/D23122
--HG--
extra : moz-landing-system : lando
Effectively back out much of the run on projects from D22710
This also has the added affect of scheduling the shippable builds to run because of dependencies.
Differential Revision: https://phabricator.services.mozilla.com/D22833
--HG--
extra : moz-landing-system : lando
raptor-chrome is Google Chrome and only needs to run once per day, so mozilla-central pushes and try.
raptor-profiling is primarily for devs to have up to date profile information and it too only needs to run once per day.
TODO is to try and find a clean way to make them only run when we trigger Nightlies rather than every m-c push.
Differential Revision: https://phabricator.services.mozilla.com/D22832
--HG--
extra : moz-landing-system : lando
I kept it building the most straight-forward way possible (pub use) because it
seems to me that bindings is not a bad name, and we should probably move
structs.rs to be bindings.rs rather than the other way around.
But that's a different bug in any case, need to think more about it.
Differential Revision: https://phabricator.services.mozilla.com/D24713
--HG--
extra : moz-landing-system : lando
And make them actually sound. We're defining functions on Rust-land that get
structs as arguments, but declaring them in C++ as getting pointers.
This is another step in order to be able to autogenerate ServoBindings.h and
remove bindings.rs altogether.
We remove FooOwned in favor of Owned<Foo>, which is generated via cbindgen.
It'd be good to actually mark Owned and such as MOZ_MUST_USE_TYPE, so I sent
https://github.com/eqrion/cbindgen/pull/307 for that.
Differential Revision: https://phabricator.services.mozilla.com/D24681
--HG--
extra : moz-landing-system : lando
This ensures test stability, and avoids leaking browser windows when we're closing the private browsing window in the test.
Differential Revision: https://phabricator.services.mozilla.com/D24530
--HG--
extra : moz-landing-system : lando
This is more of a feedback request, I have not really written component unit tests before.
Differential Revision: https://phabricator.services.mozilla.com/D24145
--HG--
extra : moz-landing-system : lando
This is now necessary, because it's possible to effectively create new
AudioNodes on during shutdown, when the global is not available anymore.
It is unnecessary to null-check in the AudioNodeEngine methods, because they
will not run in this scenario.
This also renames the function because it can now return nullptr.
Differential Revision: https://phabricator.services.mozilla.com/D24688
--HG--
extra : moz-landing-system : lando
- Use Bengali (bn-BD) as base
- Keep amazon-in on Desktop (from bn-IN)
- Remove rediff (from bn-IN)
Differential Revision: https://phabricator.services.mozilla.com/D23480
--HG--
extra : moz-landing-system : lando
Without this patch, content-length getter returns 0 if we have an available
alt-data because we don't distinguish between having and using it.
Differential Revision: https://phabricator.services.mozilla.com/D24875
--HG--
extra : moz-landing-system : lando
PanelMultiView adds the keydown handler on the window so that it handles key presses when a panel appears but doesn't get focus, as happens when a button to open a panel is clicked with the mouse.
However, this means the listener is on an ancestor of the panel, which means that handlers such as ToolbarKeyboardNavigator are deeper in the tree.
Previously, PanelMultiView used a bubbling (default) listener.
This meant that ToolbarKeyboardNavigator handled the event first, causing it to interfere when a panel opened within the toolbar; e.g. the Library menu.
To fix this, use a capturing listener for PanelMultiView so it gets the event first.
Differential Revision: https://phabricator.services.mozilla.com/D24848
--HG--
extra : moz-landing-system : lando
Move addEventhandler to top of appPickerLoad() to avoid not reaching it when errors occur later in the function.
Differential Revision: https://phabricator.services.mozilla.com/D24866
--HG--
extra : moz-landing-system : lando
When adding an range via `Selection::AddItem()` and only when it's caused by
user's operation, the range may be split at non-selectable content. This is
done in `nsRange::ExcludeNonSelectableNodes()` but it modifies the given range
as the first range. Then, [`Selection::AddRangeInternal()` calls
`Selection::SelectFrames()` with the range which may have been modified by
`nsRange::ExcludeNonSelectableNodes()`](https://searchfox.org/mozilla-central/rev/358f816f63da072145c593e9e2ac36b7250ecd25/dom/base/Selection.cpp#2030,2049).
Therefore, only the frames between first child of `<body>` element and
previous element of first non-selectable content are painted as selection
after user does "Select All".
[`Selection::Extend()` calls `Selection::SelectFrames()` by itself for all
existing ranges](https://searchfox.org/mozilla-central/rev/358f816f63da072145c593e9e2ac36b7250ecd25/dom/base/Selection.cpp#2718-2724). Therefore, this patch creates new method and makes both
`Selection::Extend()` and `Selection::SetStartAndEndInternal()` call it only
when the result is not only one range.
Differential Revision: https://phabricator.services.mozilla.com/D24871
--HG--
extra : moz-landing-system : lando
`Selection::Extend()` is too slow but editor and ContentEventHandler use it in
some places. We should make them use `Selection::SetStartAndEndInLimiter()` or
`Selection::SetBaseAndExtentInLimiter()`. The former is usable only when caller
guarantees the start point is prior to the end point in the DOM tree.
Otherwise, we need to use the latter even though it's slower than the former.
Differential Revision: https://phabricator.services.mozilla.com/D23462
--HG--
extra : moz-landing-system : lando
`EditorBase::SelectEntierDocument()` uses `Selection::Extend()` but it's too
slow. It should use `Selection::SetStartAndEndInLimiter()` instead.
Additionally, `TextEditor::SelectEntierDocument()` shrink the result of
`EditorBase::SelectEntierDocument()` with `Selection::Extend()` if there is
a `moz-<br>` element. So, `TextEditor::SelectEntinerDocument()` should set
its expected selection with a call for saving the runtime cost.
Then, we don't need to make `EditorBase::SelectEntierDocument()` as non-pure
virtual method. So, this patch makes each its callers call
`Selection->SelectAllChildren()` directly.
Differential Revision: https://phabricator.services.mozilla.com/D23461
--HG--
extra : moz-landing-system : lando
`Selection::Extend()` is too slow because:
- it may create some `nsRange` instances.
- it users `nsContentUtils::ComparePoints()` multiple times.
Therefore, we can improve the performance if we can stop using it in some
places. First, this patch creates `Selection::SetStartAndEnd()` and
`Selection::SetStartAndEndInLimiter()` for internal use. They remove
current ranges, reuse `nsRange` instance as far as possible and add new
range which is set by their arguments. Then, this patch makes
`Selection::SelectAllChildren()` stop using `Selection::Extend()`. At this
time, this fixes a web-compat issue. `Selection::Expand()` cannot cross the
selection limiter boundary when there is a limiter (e.g., when an editing host
has focus). But we can now fix this with using the new internal API.
Note that methods in editor shouldn't move selection to outside of active
editing host. Therefore, this patch adds `Selection::SetStartAndEndInLimiter()`
and `Selection::SetBaseAndExtentInLimiter()` for them.
Differential Revision: https://phabricator.services.mozilla.com/D23459
--HG--
extra : moz-landing-system : lando
`nsRange::SetSelection()` may be called during unlinking. Therefore,
`mRegisteredCommonAncestor` may have already been unlinked. This patch
makes it check whether it's nullptr or not before using it to call
`UnregisterCommonAncestor()`.
Differential Revision: https://phabricator.services.mozilla.com/D24872
--HG--
extra : moz-landing-system : lando
In normal cases, `PresShell::EventHandler` won't receive untrusted event.
However, only `nsIDOMWindowUtils.dispatchDOMEventViaPresShell()` may send
untrusted event if its `aTrusted` is false. Currently, this is not used by
chrome so that we don't need to keep supporting it for dispatching untrusted
events.
This patch removes `aTrusted` argument from it.
Differential Revision: https://phabricator.services.mozilla.com/D24870
--HG--
extra : moz-landing-system : lando
`PresShell::EventHandler::PrepareToDispatchEvent()` checked whether the
given event is a trusted event or an untrusted event, but
`PresShell::EventHandler::PrepareToDispatchOntextMenuEvent()` didn't so.
However, now, both of them don't need to check it. Therefore, we can merge
them.
Differential Revision: https://phabricator.services.mozilla.com/D24132
--HG--
extra : moz-landing-system : lando
`PresShell::EventHandler` shouldn't be used to dispatch untrusted event.
However, it checks whether the given event is trusted or untrusted somewhere
and that makes the code harder to understand. So, it should check each event
only with `MOZ_ASSERT()` or `MOZ_DIAGNOSTIC_ASSERT()` instead. Then,
developers can trust the event is always a trusted event.
Differential Revision: https://phabricator.services.mozilla.com/D24131
--HG--
extra : moz-landing-system : lando
realigning the RTP stats types to match spec. This involves breaking out the remote dictionary types. This shouldn't create user space visible changes.
Differential Revision: https://phabricator.services.mozilla.com/D20432
--HG--
extra : moz-landing-system : lando
If the frame supports it (stacking context + containing block for fixed), and a descendant was
modified, we would have created an override dirty region with just the area of that descendant.
In the case where no descendants are modified, we should use an empty rect, rather than
the area inherited from our parent.
This fixes the case where we forcibly build position:fixed frames (since they might async
scroll differently to the rest of the page), but we only need to build the container item,
not the whole frame subtree within it.
Added a test that shows us building the non-intersecting position:fixed, but not items within it.
Differential Revision: https://phabricator.services.mozilla.com/D23610
--HG--
extra : moz-landing-system : lando
Justin Wood
Adam Gashlin
vladikoff
Emilio Cobos Álvarez
Mark Banner
Marco Bonardo
Christoph Kerschbaumer
Cosmin Sabou
Csoregi Natalia
Julian Descottes
Mihir
Jeff Walden
Paul Adenot
Luca Greco
Francesco Lodolo (:flod)
Andrea Marchesini
Johann Hofmann
monikamaheshwari
James Teh
Jonas Allmann
Masayuki Nakano
Andi-Bogdan Postelnicu
Gurzau Raul
Alex Chronopoulos
Nico Grunbaum
Matt Woodrow
Oriol Brufau