`Array.map` triggers a deprecation warnings, and it
turns out we can use `.map` directly on the objects
we were calling `Array.map` on.
Differential Revision: https://phabricator.services.mozilla.com/D25506
--HG--
extra : moz-landing-system : lando
have XHR responseURL use the final channel URL so the expected URLs for substituted protocols like web-extension: are returned
Differential Revision: https://phabricator.services.mozilla.com/D23811
--HG--
extra : moz-landing-system : lando
This depends on https://github.com/eqrion/cbindgen/pull/308. Other than that,
this should be ready to go.
There's still a bit more magic than what I'd like to eventually. I should be
able to make cbindgen not rename types if it doesn't know about them, or
something.
But this removes most of the manual binding function implementations (all but
the ones that are declared via macros, which cbindgen doesn't see across).
I need to give up on the _Drop functions taking an Owned<T> because of
instantiation order fiasco. In order to define DefaultDelete I need Owned to be
complete, but I cannot do it after including the generated file since some
declarations already instantiate the specialization. Oh well.
Differential Revision: https://phabricator.services.mozilla.com/D24798
--HG--
rename : servo/components/style/cbindgen.toml => servo/ports/geckolib/cbindgen.toml
extra : moz-landing-system : lando
This patch marks `EditorBase::InsertNodeTransaction()` **and** its callers as `MOZ_CAN_RUN_SCRIPT`.
Unfortunately, this patch tells us that some `GetSomething()` methods may destroy the editor since `HTMLEditRules::GetNodesForOperation()`, `HTMLEditRules::GetNodesFromPoint()` and `HTMLEditRules::GetNodesFromSelection()` may change the DOM tree. Additionally, initialization methods may destroy the editor since it may insert a bogus `<br>` node.
Note that this patch also removes some unused methods. I.e., they are not result of some cleaning up the code. This patch just avoids marking unused methods as `MOZ_CAN_RUN_SCRIPT`.
Differential Revision: https://phabricator.services.mozilla.com/D25027
--HG--
extra : moz-landing-system : lando
If there's at least 2 content blocking messages displayed
for a given page navigation, we display a warning group
containing the messages, collapsed by default.
This means we need to move or insert those warning messages
at the right position in visibleMessages, either when they're
added, or when we expand a group.
Two mochitest are added to make sure this works as expected,
one for generic warningGroup features (expanding, group per
navigation session, …), and another one specifically for
content blocking warning group, where we check that every
type of content blocking message can be grouped.
The grouping won't occur unless the groupWarnings preferences
is on.
Differential Revision: https://phabricator.services.mozilla.com/D23552
--HG--
extra : moz-landing-system : lando
This component will be used to render warning groups messages.
We also add a `inWarningGroup` prop to the `Message` component
so warnings that will be displayed in such warningGroup can
be styled differently (no warning icon, a different color for
the indent).
Add some utils functions and constants to check if a message
should be a warning group.
Differential Revision: https://phabricator.services.mozilla.com/D23551
--HG--
extra : moz-landing-system : lando
This will be used to enable groups of warning messages (Tracking Protection,
CSP, CORS, …).
Differential Revision: https://phabricator.services.mozilla.com/D23550
--HG--
extra : moz-landing-system : lando
For now, only add the MozMenuPopup base class to MozElements,
and don't define a custom element for it with
`customElements.define`. This is to help avoid conflicts in
de-xbl work. (See the bug for details.)
Includes a function to do 'manual slotting', moving child
elements into place. Dynamically adding, modifying, or
removing child nodes after the element is connected needs
to be handled manually as well.
Differential Revision: https://phabricator.services.mozilla.com/D25467
--HG--
rename : toolkit/content/widgets/popup.xml => toolkit/content/widgets/menupopup.js
extra : moz-landing-system : lando
We apply a local patch while we wait for upstream wine and mingw to review
the changes to widl that are necessary to generate the correct headers. Here we
just grab the generated headers and patch them into MinGW
We can revert this when MinGW updates, but for now we would like to unblock
the ANGLE update
Depends on D25294
Differential Revision: https://phabricator.services.mozilla.com/D25295
--HG--
extra : moz-landing-system : lando
This is needed to bring dispatcherqueue.h in, which is needed for
an ANGLE upgrade. It also ensures that overloads for secure string
functions are always defined and removes redundant --enable-secure-api
configure option and use of MINGW_HAS_SECURE_API
Differential Revision: https://phabricator.services.mozilla.com/D25294
--HG--
extra : moz-landing-system : lando