For now, always pass null, except when passing it through from one
overload to another.
Differential Revision: https://phabricator.services.mozilla.com/D38389
--HG--
extra : moz-landing-system : lando
Also move the duplicate logic for reframing MathML in ContentAppended()
and ContentRangeInserted() into WipeInsertionParent().
Differential Revision: https://phabricator.services.mozilla.com/D38417
--HG--
extra : moz-landing-system : lando
Tab in an open menulist should close the menulist.
Previously, we were overriding the tab key in this case, which meant that the menulist remained open while focus moved elsewhere.
Differential Revision: https://phabricator.services.mozilla.com/D37835
--HG--
extra : moz-landing-system : lando
In bug 1525101, autocomplete-richlistbox-popup was converted to a Custom Element.
This means we can no longer use do_QueryInterface to get nsIAutoCompletePopup.
Instead, we must use Element::AsAutoCompletePopup.
This fixes accessibility focus for these autocompletes.
Differential Revision: https://phabricator.services.mozilla.com/D38158
--HG--
extra : moz-landing-system : lando
Until now we asserted that EnsureMTA was being called from the main thread
unless the current thread was already in the MTA.
This patch makes MTA thread initialization thread-safe by using a C++11
"magic static," thus allowing EnsureMTA to be safely invoked from any thread.
Differential Revision: https://phabricator.services.mozilla.com/D38422
--HG--
extra : moz-landing-system : lando
A test is added to ensure this is fixed properly.
We also fix the Array previewer to properly return
undefined for unknown array properties, rather than null.
Differential Revision: https://phabricator.services.mozilla.com/D38467
--HG--
extra : moz-landing-system : lando
The file was included in the index.html and was used
to create the WebConsoleWrapper.
We can directly create it from webconsole-ui.js and
not have this unusual mechanism.
Differential Revision: https://phabricator.services.mozilla.com/D38456
--HG--
extra : moz-landing-system : lando
If user clicks gutter to add a breakpoint in tab of a blackboxed file, the file should be un-blackboxed.
Differential Revision: https://phabricator.services.mozilla.com/D38198
--HG--
extra : moz-landing-system : lando
JS_TransplantObject is a very powerful API that results in the JITs
having to worry about the type of objects changing in surprising ways.
In practice though, there are very limited uses of this API so we can
add an API to determine which objects have to worry about transplanting.
This can then by asserted in JITs to document places that optimize
performance by expecting not to deal with transplants.
Differential Revision: https://phabricator.services.mozilla.com/D27975
--HG--
extra : moz-landing-system : lando
Extend js::Handler, the base class for Debugger API handler functions, with a
`hold` method, to act as a pair with the `drop` method. Clarify comments
explaining how they're to be used, with a more explicit explanation of how
reference-counted handlers could be implemented.
Following the new rules:
- Change `ScriptedOnStepHandler` and `ScriptedOnPopHandler` to report the
handler's ownership.
- Change `DebuggerFrame::setOnStepHandler` and `DebuggerFrame::setOnPopHandler`
to let the handler deal with that.
Change the `owner` argument type from `DebuggerFrame` to the looser `JSObject`;
the `Handler` base class isn't specific to stack frames at all, but is meant to
eventually be used for `onNewScript` and `onEnterFrame` as well.
Differential Revision: https://phabricator.services.mozilla.com/D37940
--HG--
extra : moz-landing-system : lando
This patch adds an assertion that documents the invariant that this code
needs to maintain to manage the line iterator correctly. Failing to
meet that invariant would also cause additional assertions in my
work-in-progress on bug 1300293.
It then adds two assignments of mPrevFrame to null that make that
assertion hold.
The first assignment to null is tested by a number of tests already in
our test suite, including
layout/reftests/w3c-css/received/css-writing-modes/block-plaintext-004.html
and layout/reftests/bidi/unicode-bidi-plaintext.html , which would hit
the added assertion if that assignment to null were not present.
The second assignment to null was untested in our test suite (though it
showed up when doing view-source: of https://html.spec.whatwg.org/ ), so
I've added a reftest (1567036-1.html) that hits the added assertion if
that second assignment to null is not present.
Differential Revision: https://phabricator.services.mozilla.com/D38438
--HG--
extra : moz-landing-system : lando
Minor things to ease the transition to StaticPrefList.yaml.
- Rename apz_touch_drag_enabled() to the correct apz_drag_touch_enabled(), and
media_mwf_low_latency_force_disabled() to the correct
media_wmf_low_latency_force_disabled().
- Change some trailing C-style comments to C++-style comments. This makes life
easier for the script I wrote to convert StaticPrefList.h to
StaticPrefList.yaml, which will be used for the next patch.
- Avoid comments on #define lines, because they aren't handled in the YAML
input.
- Convert a multi-line `#if` condition to a single line, because
Preprocessor.py doesn't handle multi-line conditions.
- Remove one unnecessary `#undef PREF_VALUE` directive.
- Move intl.charset.detector.iso2022jp.allowed to the correct section, so the
YAML processing script won't complain.
- Change an `int` pref to `int32_t`, again so the YAML processing script won't
complain.
- Change OS_OPENBSD to XP_OPENBSD, because the former isn't defined for
preprocessor.py. (It's also only defined in C/C++ when chromium-config.h is
included, which isn't always the case.)
Differential Revision: https://phabricator.services.mozilla.com/D37815
--HG--
extra : moz-landing-system : lando
This is the safer assumption, since we normally skip setting isTopFrame
explicitly if no BrowsingContext exists (which is the case if, for example,
the crash is due to the fact that creating the top-level browser failed).
Differential Revision: https://phabricator.services.mozilla.com/D38119
--HG--
extra : moz-landing-system : lando
When a BrowsingContext changes from being local to remote, we have to
change all window proxies from being local to remote, using
transplanting. The actual window proxy becomes a remote window
proxy. Cross compartment wrappers (CCWs) to the window proxy also
become remote window proxies in their respective compartments, rather
than CCWs to a remote proxy in the old compartment of the window
proxy, because the window is no longer actually in that
compartment. This also avoids having to figure out what Xray behavior
for remote window proxies should be.
This patch uses the transplanting support I added to
GetRemoteOuterWindowProxy() in the previous patch to ensure that the
remote proxy map holds the correct value after transplanting finishes.
It drops the requirement that both arguments to JS_TransplantObject
have the same class, because we need to transplant a window proxy with
a remote window proxy. It also deals with this by not adding origobj
to the wrapper map unless it is a CCW, to handle transplanting to a
remote proxy.
The core design here, with the remote window proxies in every
compartment, is taken from a patch by peterv.
Differential Revision: https://phabricator.services.mozilla.com/D35730
--HG--
extra : moz-landing-system : lando
When we call GetRemoteOuterWindowProxy in the middle of a transplant,
the remote proxy that the function returns will be almost immediately
swapped with some other object. Rather than trying to fix up the
remote proxy map when that happens, this patch adds a new argument
that is a pointer to the object, if any, that the remote proxy is
going to be swapped to. This will be used in the remote proxy map.
Having a value in the remote proxy map that is not a remote proxy
could cause issues if somebody ends up calling
GetRemoteOuterWindowProxy() a second time before the transplant has
finished. To avoid that, my patch asserts that we are returning an
object with the appropriate class.
Differential Revision: https://phabricator.services.mozilla.com/D37598
--HG--
extra : moz-landing-system : lando
In a later patch, the prewrap hook will need to know the address of
the object we are eventually going to transplant into. In the
non-transplant case, the value will be null.
Differential Revision: https://phabricator.services.mozilla.com/D37597
--HG--
extra : moz-landing-system : lando