1. Add successorTabId to the Tab type, so that it will be returned in, e.g.,
browser.tabs.get calls
2. Extend or create the following methods on the browser.tabs API:
- update: add successorTabId as an optional property on the provided
updateProperties object
- moveInSuccession: new method that manipulates tab successors in bulk
Differential Revision: https://phabricator.services.mozilla.com/D9272
--HG--
extra : moz-landing-system : lando
Remove the intermediate <html:iframe> as it makes support of detaching impossible since we would need
to swap both the <browser> and <html:iframe> contents during a tab detach.
Since a docshell swap requires both docshells to have a frame and document loaded and the move of the
tab won't wait on payments code to do async work to get frames and documents ready for swapping, I
couldn't see a way to get detaching to work with the nested frames.
* Swapping the docshell of only the outer <html:iframe> still caused a reload of the inner <browser>.
Differential Revision: https://phabricator.services.mozilla.com/D10180
--HG--
extra : moz-landing-system : lando
This patch removes the dom.webcomponents.shadowdom.enabled pref and all its
references, including the following functions:
* nsContentUtils::IsShadowDOMEnabled()
* nsIDocument::IsShadowDOMEnabled()
* nsDocument::IsShadowDOMEnabled(JSContext* aCx, JSObject* aGlobal)
* nsDocument::IsShadowDOMEnabled(const nsINode* aNode)
* nsTextNode::IsShadowDOMEnabled(JSContext* aCx, JSObject* aObject)
This function is renamed and updated to nsDocument::IsCallerChromeOrAddon():
* nsDocument::IsShadowDOMEnabledAndCallerIsChromeOrAddon(JSContext* aCx, JSObject* aObject)
I didn't change the tests that load Shadow DOM tests in an iframe, in the interest of keeping hg annotation history.
Differential Revision: https://phabricator.services.mozilla.com/D11183
--HG--
extra : moz-landing-system : lando
This patch modifies UAWidgetsChild so that when the call into the UA Widget
script throws, it could correctly clean up the Shadow DOM, to avoid leaving
the DOM in a half-broken state.
This is needed because of bug 1506300 will cause the constructor of the videocontrols
UA Widget to throw, in our specific test case.
This exception also happens when the videocontrols XBL binding initializes,
but the way the XBL service calls into the XBL binding allow it to reach a usable
but a half-broken state, while our current approach will cause the UA Widget DOM
to be inserted twice, and layout to assert.
The new clean-up approach here will make UA Widget completely absent when the
constructor throws until the cause of the exception is fixed.
Differential Revision: https://phabricator.services.mozilla.com/D11542
--HG--
extra : moz-landing-system : lando
This patch modifies UAWidgetsChild so that when the call into the UA Widget
script throws, it could correctly clean up the Shadow DOM, to avoid leaving
the DOM in a half-broken state.
This is needed because of bug 1506300 will cause the constructor of the videocontrols
UA Widget to throw, in our specific test case.
This exception also happens when the videocontrols XBL binding initializes,
but the way the XBL service calls into the XBL binding allow it to reach a usable
but a half-broken state, while our current approach will cause the UA Widget DOM
to be inserted twice, and layout to assert.
The new clean-up approach here will make UA Widget completely absent when the
constructor throws until the cause of the exception is fixed.
Differential Revision: https://phabricator.services.mozilla.com/D11542
--HG--
extra : moz-landing-system : lando
--enable-default-toolkit=cairo-gtk3-wayland is left to _force_ wayland
support being built in, while --enable-default-toolkit=cairo-gtk3 still
allows to build against a Gtk+ version that doesn't support wayland.
Differential Revision: https://phabricator.services.mozilla.com/D11433
--HG--
extra : moz-landing-system : lando
The FX_PAGE_LOAD_MS histogram, implemented in Bug 790213, measures the time it takes
Firefox to load a page's static content. Unfortunately, it uses only 20 buckets to cover
a 10,000ms range, so resolution is quite poor. The modal bucket is 860ms wide. There is
at least anecdotal evidence that increasing page load times by increments as small as 100 ms
can alter user behavior, so much better resolution is required to have confidence in changes
we expect to alter page load times. Also fixes Bug 1364957.
Differential Revision: https://phabricator.services.mozilla.com/D11198
--HG--
extra : moz-landing-system : lando
Previously, our panic hook was only really useful when the crash
reporter is used, because all it did apart from calling rust's default
panic handler was to keep a pointer to the panic message for the crash
reporter.
Now that it just redirects to the Gecko crash code, it doesn't need to
be tied to the crash reporter. In fact, to ensure it's consistently used
in all cases, we ought to install it early on. Use a static initializer
for that.
Depends on D11720
Depends on D11720
Differential Revision: https://phabricator.services.mozilla.com/D11721
--HG--
extra : moz-landing-system : lando
The current rust panic hook keeps a string for the crash reporter, and
goes on calling the default rust panic hook, which prints out a crash
stack... when RUST_BOOTSTRAP is set *and* when that works. Notably, on
both mac and Windows, it only really works for local builds, but fails
for debug builds from automation, although on automation itself, we also
do stackwalk from crash minidumps, which alleviates the problem.
Artifact debug builds are affected, though.
More importantly, C++ calls to e.g. MOZ_CRASH have a similar but
different behavior, in that they dump a stack trace on debug builds, by
default (with exceptions, see below for one). The format of those stack
traces is understood by the various fix*stack*py scripts under
tools/rb/, that are used by the various test harnesses both on
automation and locally.
Additionally, the current rust panic hook, as it calls the default rust
panic hook, ends up calling abort() on non-Windows platforms, which ends
up being verbosely redirected to mozalloc_abort per
https://dxr.mozilla.org/mozilla-central/rev/237e4c0633fda8e227b2ab3ab57e417c980a2811/memory/mozalloc/mozalloc_abort.cpp#79
which then calls MOZ_CRASH. Theoretically, /that/ would also print a
stack trace, but doesn't because currently the stack trace printing code
lives in libxul, and MOZ_CRASH only calls it when compiled from
libxul-code, which mozalloc_abort is not part of.
With this change, we make the rust panic handler call back into
MOZ_CRASH directly. This has multiple advantages:
- This is more consistent cross-platforms (Windows is not special
anymore).
- This is more consistent between C++ and rust (stack traces all look
the same, and can all be post-processed by fix*stack*py if need be)
- This is more consistent in behavior, where debug builds will show
those stack traces without caring about environment variables.
- It demangles C++ symbols in rust-initiated stack traces (for some
reason that didn't happen with the rust panic handler)
A few downsides:
- the loss of demangling for some rust symbols.
- the loss of addresses in the stacks, although they're not entirely
useful
- extra empty lines.
The first should be fixable later one. The latter two are arguably
something that should be consistent across C++ and rust, and should be
changed if necessary, independently of this patch.
Depends on D11719
Depends on D11719
Differential Revision: https://phabricator.services.mozilla.com/D11720
--HG--
extra : moz-landing-system : lando
nsIPrefBranch.deleteBranch doesn't work as documented when the preference's
default value was set very early after Firefox has started, such as when
Normandy sets startup branches. This is filed as bug 1505941. In order to work
around this problem, this patch makes Normandy never use deleteBranch, except
in tests where it is safe to do so.
With this patch, an experiment that is run on the default branch for a
preference that does not have a default value in the tree cannot be promptly
unenrolled, instead we must wait until the preference is naturally cleared when
Firefox restarts. This is better than never unenrolling though.
Differential Revision: https://phabricator.services.mozilla.com/D11383
--HG--
extra : moz-landing-system : lando
1. Add successorId to the Tab type, so that it will be returned in, e.g.,
browser.tabs.get calls
2. Extend or create the following methods on the browser.tabs API:
- update: add successorTabId as an optional property on the provided
updateProperties object
- moveInSuccession: new method that manipulates tab successors in bulk
Depends on D4731
Differential Revision: https://phabricator.services.mozilla.com/D9272
--HG--
extra : moz-landing-system : lando
"text" event is Mozilla specific event, not in any standards. The event follows
"compositionupdate" event and editor modifies composition string when receives
the event in the system group.
So, we'd like to stop dispatching this unnecessary event but we need to get
actual usage in the web.
Differential Revision: https://phabricator.services.mozilla.com/D11600
--HG--
extra : moz-landing-system : lando
Previously, our panic hook was only really useful when the crash
reporter is used, because all it did apart from calling rust's default
panic handler was to keep a pointer to the panic message for the crash
reporter.
Now that it just redirects to the Gecko crash code, it doesn't need to
be tied to the crash reporter. In fact, to ensure it's consistently used
in all cases, we ought to install it early on. Use a static initializer
for that.
Depends on D11720
Differential Revision: https://phabricator.services.mozilla.com/D11721
--HG--
extra : moz-landing-system : lando
The current rust panic hook keeps a string for the crash reporter, and
goes on calling the default rust panic hook, which prints out a crash
stack... when RUST_BOOTSTRAP is set *and* when that works. Notably, on
both mac and Windows, it only really works for local builds, but fails
for debug builds from automation, although on automation itself, we also
do stackwalk from crash minidumps, which alleviates the problem.
Artifact debug builds are affected, though.
More importantly, C++ calls to e.g. MOZ_CRASH have a similar but
different behavior, in that they dump a stack trace on debug builds, by
default (with exceptions, see below for one). The format of those stack
traces is understood by the various fix*stack*py scripts under
tools/rb/, that are used by the various test harnesses both on
automation and locally.
Additionally, the current rust panic hook, as it calls the default rust
panic hook, ends up calling abort() on non-Windows platforms, which ends
up being verbosely redirected to mozalloc_abort per
https://dxr.mozilla.org/mozilla-central/rev/237e4c0633fda8e227b2ab3ab57e417c980a2811/memory/mozalloc/mozalloc_abort.cpp#79
which then calls MOZ_CRASH. Theoretically, /that/ would also print a
stack trace, but doesn't because currently the stack trace printing code
lives in libxul, and MOZ_CRASH only calls it when compiled from
libxul-code, which mozalloc_abort is not part of.
With this change, we make the rust panic handler call back into
MOZ_CRASH directly. This has multiple advantages:
- This is more consistent cross-platforms (Windows is not special
anymore).
- This is more consistent between C++ and rust (stack traces all look
the same, and can all be post-processed by fix*stack*py if need be)
- This is more consistent in behavior, where debug builds will show
those stack traces without caring about environment variables.
- It demangles C++ symbols in rust-initiated stack traces (for some
reason that didn't happen with the rust panic handler)
A few downsides:
- the loss of demangling for some rust symbols.
- the loss of addresses in the stacks, although they're not entirely
useful
- extra empty lines.
The first should be fixable later one. The latter two are arguably
something that should be consistent across C++ and rust, and should be
changed if necessary, independently of this patch.
Depends on D11719
Differential Revision: https://phabricator.services.mozilla.com/D11720
--HG--
extra : moz-landing-system : lando
This patch removes the dom.webcomponents.shadowdom.enabled pref and all its
references, including the following functions:
* nsContentUtils::IsShadowDOMEnabled()
* nsIDocument::IsShadowDOMEnabled()
* nsDocument::IsShadowDOMEnabled(JSContext* aCx, JSObject* aGlobal)
* nsDocument::IsShadowDOMEnabled(const nsINode* aNode)
* nsTextNode::IsShadowDOMEnabled(JSContext* aCx, JSObject* aObject)
This function is renamed and updated to nsDocument::IsCallerChromeOrAddon():
* nsDocument::IsShadowDOMEnabledAndCallerIsChromeOrAddon(JSContext* aCx, JSObject* aObject)
I didn't change the tests that load Shadow DOM tests in an iframe, in the interest of keeping hg annotation history.
Differential Revision: https://phabricator.services.mozilla.com/D11183
--HG--
extra : moz-landing-system : lando
Previously, our panic hook was only really useful when the crash
reporter is used, because all it did apart from calling rust's default
panic handler was to keep a pointer to the panic message for the crash
reporter.
Now that it just redirects to the Gecko crash code, it doesn't need to
be tied to the crash reporter. In fact, to ensure it's consistently used
in all cases, we ought to install it early on. Use a static initializer
for that.
Depends on D11720
Differential Revision: https://phabricator.services.mozilla.com/D11721
--HG--
extra : moz-landing-system : lando
The current rust panic hook keeps a string for the crash reporter, and
goes on calling the default rust panic hook, which prints out a crash
stack... when RUST_BOOTSTRAP is set *and* when that works. Notably, on
both mac and Windows, it only really works for local builds, but fails
for debug builds from automation, although on automation itself, we also
do stackwalk from crash minidumps, which alleviates the problem.
Artifact debug builds are affected, though.
More importantly, C++ calls to e.g. MOZ_CRASH have a similar but
different behavior, in that they dump a stack trace on debug builds, by
default (with exceptions, see below for one). The format of those stack
traces is understood by the various fix*stack*py scripts under
tools/rb/, that are used by the various test harnesses both on
automation and locally.
Additionally, the current rust panic hook, as it calls the default rust
panic hook, ends up calling abort() on non-Windows platforms, which ends
up being verbosely redirected to mozalloc_abort per
https://dxr.mozilla.org/mozilla-central/rev/237e4c0633fda8e227b2ab3ab57e417c980a2811/memory/mozalloc/mozalloc_abort.cpp#79
which then calls MOZ_CRASH. Theoretically, /that/ would also print a
stack trace, but doesn't because currently the stack trace printing code
lives in libxul, and MOZ_CRASH only calls it when compiled from
libxul-code, which mozalloc_abort is not part of.
With this change, we make the rust panic handler call back into
MOZ_CRASH directly. This has multiple advantages:
- This is more consistent cross-platforms (Windows is not special
anymore).
- This is more consistent between C++ and rust (stack traces all look
the same, and can all be post-processed by fix*stack*py if need be)
- This is more consistent in behavior, where debug builds will show
those stack traces without caring about environment variables.
- It demangles C++ symbols in rust-initiated stack traces (for some
reason that didn't happen with the rust panic handler)
A few downsides:
- the loss of demangling for some rust symbols.
- the loss of addresses in the stacks, although they're not entirely
useful
- extra empty lines.
The first should be fixable later one. The latter two are arguably
something that should be consistent across C++ and rust, and should be
changed if necessary, independently of this patch.
Depends on D11719
Differential Revision: https://phabricator.services.mozilla.com/D11720
--HG--
extra : moz-landing-system : lando
This is based on the patch in bug 1504552. I'm calling the @engine aliases -- as opposed to aliases without @ -- "token" aliases since I need to refer to them somehow.
Differential Revision: https://phabricator.services.mozilla.com/D11546
--HG--
extra : moz-landing-system : lando
--enable-default-toolkit=cairo-gtk3-wayland is left to _force_ wayland
support being built in, while --enable-default-toolkit=cairo-gtk3 still
allows to build against a Gtk+ version that doesn't support wayland.
Differential Revision: https://phabricator.services.mozilla.com/D11433
--HG--
extra : moz-landing-system : lando