Presumably the commit that introduced `aStringOffset` could have removed this,
but overlooked it.
--HG--
extra : rebase_source : 176f14ce01c18ed4c83892d2b7a9e7a54fb5c836
Static atom registration is a bit of a mess. NS_InitAtomTable() calls
nsGkAtoms::RegisterStaticAtoms(), which calls NS_RegisterStaticAtoms(); i.e. we
go from nsAtomTable.cpp to nsGkAtoms.cpp and back.
(And NS_RegisterStaticAtoms() is declared in a .cpp file, not a .h file!)
This commit makes NS_InitAtomTable() a friend of nsGkAtoms, so NS_InitAtomTable
can see nsGkAtoms's atoms array directly, thus removing the need for
NS_RegisterAtomTable() and nsGkAtoms::RegisterStaticAtoms().
This commit also removes an out-of-date part of a comment from XPCOMInit.cpp.
--HG--
extra : rebase_source : 7e1f9aa0a9f7cb5088159fe4c953948b931f6d68
nsGkAtoms.h has a big comment explaining how static atom definitions get
expanded by macros. This comment was very useful when there were multiple
sources of static atoms and their definitions used macros a lot. But bug
1482782 combined all the static atom sources into nsGkAtoms and removed a lot
of macro use. So now the comment is now something of a hindrance, duplicating
quite a bit of the code (and not entirely accurately).
This commit removes the big comment, and moves the still-useful parts inline
with the code. This makes things much easier to follow.
This commit also reformats some of the remaining macros so they are easier to
read.
--HG--
extra : rebase_source : 4377be2fa0edc4ea1f592985ded89acbb76fb104
With libLLVM being a shared library exporting many symbols, all internal
calls using those symbols default to go through the PLT, which is
unnecessary (and costly) overhead. Using -Bsymbolic makes internal calls
go directly to the right place without going through the PLT.
Differential Revision: https://phabricator.services.mozilla.com/D7029
The NEON codepaths could work, but they'd have to be converted to
MSVC-friendly assembly (or separate .asm files) first. Just disable
building them for now.
Replace various custom data-types in JSScript interfaces with
mozilla::Span. This abstracts implementation details and supports
range-based for-loops. Underlying storage is unchanged, but this sets us
up to be able to more easily change it.
MozReview-Commit-ID: FDfIYsAxTA8
This patch adds a few guards to the DOM elements the videocontrols holds as
properties. Any future changes that attempt to access the blacklisted layout
properties of the DOM elements will throw.
Depends on D6725
Differential Revision: https://phabricator.services.mozilla.com/D6726
--HG--
extra : moz-landing-system : lando
Given that the videocontrols UA Widget initializes when the DOM is inserted
(as opposed to the XBL binding only when the element is visible), the code should
not be tapping into layout until it updates.
Differential Revision: https://phabricator.services.mozilla.com/D6725
--HG--
extra : moz-landing-system : lando
When navigating to an about: page that doesn't exist (e.g.
"about:somethingthatdoesnotexist"), the docShell will call
nsSecureBrowserUIImpl::OnLocationChange with a request that is null.
Consequently, we can't use that to QueryInterface to a nsISecurityEventSink to
call OnSecurityChange. The previous implementation would use the prior
request's nsISecurityEventSink, which was a bug but luckily this produced the
correct behavior. Since the original docShell the nsSecureBrowserUIImpl was
initialized with is what needs to be notified, we can just QueryInterface that
to an nsISecurityEventSink and call OnSecurityChange directly instead.
Differential Revision: https://phabricator.services.mozilla.com/D6951
--HG--
rename : browser/base/content/test/siteIdentity/browser_tls_handshake_failure.js => browser/base/content/test/siteIdentity/browser_navigation_failures.js
extra : moz-landing-system : lando
We add several tests and modify the existing one to make sure we handle
top level await correctly in different situation (resolving, rejecting,
when paused in the debugger, when using $_, …).
Depends on D6925
Differential Revision: https://phabricator.services.mozilla.com/D6926
--HG--
extra : moz-landing-system : lando
1. Allow passing a selector to waitForMessage helper function:
This will allow to wait for specific message (warning, error, result, …).
This patch also fixes 2 tests that were already passing an erroneous selector
to waitForMessage.
2. Add an executeAndWaitForMessage function:
This will make a lot of our tests much easier to read. The function takes
an input, an expected output and an optional selector, execute the input
and resolves when a message matching the provided text (and selector
if passed) is displayed in the output.
Depends on D6903
Differential Revision: https://phabricator.services.mozilla.com/D6925
--HG--
extra : moz-landing-system : lando
This patch turns the current top-level handling, which relies on
the console API to print the result of the await expression, into
something natively handled by the server.
First, we don't add a .then handler to the generated async iife by
the mapper. We also removes the case we added in the JsTerm to *not*
print the result for top-level await expression.
In order to make the server capable of handling generated async iife
caused by the mapper, we send to evaluateJsAsync the `mapped` object
that `mapExpression` returns. This way, the server can check if an
expression was originally a top-level await.
If it is the case, we get the promise from the async iife and wait for
it to settle. If it resolves, we simply return the result, as a grip,
to the client. If it rejects, we return a special packet indicating to
not print anything to the client. The error will be reported by the
engine as `uncaught exception: …`.
We add several tests and modify the existing one to make sure we handle
top level await correctly in different situation (resolving, rejecting,
when paused in the debugger, when using $_, …).
Differential Revision: https://phabricator.services.mozilla.com/D6903
--HG--
extra : moz-landing-system : lando
If a class A is derived from a class B, then an instance of A can be
converted to an instance of class B via a static cast, so QI is not
needed. QIs are slower than static casts.
TestCallTemplates seems to be testing that CallQueryInterface compiles
even if the first argument's class is only ambiguously castable to
nsISupports, so I changed the second argument to be a class unrelated
to the concrete class.
I also removed some useless null checks on the return value of new.
Differential Revision: https://phabricator.services.mozilla.com/D6838
--HG--
extra : moz-landing-system : lando
I had to move the tooltip to appear above the help icon to make sure that it cause scrollbars to appear on the address form.
Differential Revision: https://phabricator.services.mozilla.com/D6912
--HG--
extra : moz-landing-system : lando
This changes the serialization of -moz-image-region to be consistent with that
of clip(), but it's an internal property and the specified value is already
serialized by servo so I think it's the right thing to do.
There are also no internal callers of the getter.
Differential Revision: https://phabricator.services.mozilla.com/D7069
We rely on the bit being on the block to restyle them in the right order.
Differential Revision: https://phabricator.services.mozilla.com/D7086
--HG--
extra : moz-landing-system : lando
The patch c1df1c2e46f6 contained a faulty rebase where the coercion
of logging::max_level() changed from the Pref type to a string.
The string representation of geckodriver::logging::Level is given
in upper-case, e.g. "INFO", and the Pref representation is given as
"Info" to be compatible with managing the log level from Log.jsm in Gecko.
This inadvertently caused
https://github.com/web-platform-tests/wpt/issues/12166 to reappear
in almost the same way: before the problem was that Marionette’s
frame script always included all log level entries. This was fixed
with https://bugzilla.mozilla.org/show_bug.cgi?1482829, but then
https://bugzilla.mozilla.org/show_bug.cgi?id=1396821 broke it so
that log entries also from chrome space appeared.
Depends on D7077
Differential Revision: https://phabricator.services.mozilla.com/D7078
--HG--
extra : moz-landing-system : lando
mozprofile gives us an error and we can forward it to the user so
we know what the underlying reason is for not being able to write
the Firefox profile.
Depends on D7075
Differential Revision: https://phabricator.services.mozilla.com/D7076
--HG--
extra : moz-landing-system : lando
Done automatically by running MarionetteHandler through rustfmt(1).
Depends on D7074
Differential Revision: https://phabricator.services.mozilla.com/D7075
--HG--
extra : moz-landing-system : lando
PrefValue implements From<&'static str>, and this makes the calling
code slightly nicer to look at.
Differential Revision: https://phabricator.services.mozilla.com/D7074
--HG--
extra : moz-landing-system : lando
Added trace extra parameters to be printed alongside console.trace() output.
Differential Revision: https://phabricator.services.mozilla.com/D7051
--HG--
extra : moz-landing-system : lando
Error handling for LIRGenerator lets us defer handling until the end of
the instruction but this can result in tripping some sanity checks. Only
report the first error up to caller.
Differential Revision: https://phabricator.services.mozilla.com/D6979
--HG--
extra : moz-landing-system : lando
