This patch make nsCSSFrameConstructor::CreateGeneratedContentItem() early
returns if the originating element contains an UA Widget shadow root.
Differential Revision: https://phabricator.services.mozilla.com/D6828
--HG--
extra : moz-landing-system : lando
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.
This incorporates some fixes for ccache, icecream, and a better display
output (decreasing count instead of an increasing count). It may also
let us experiment with incremental rust support, though I think that
feature still needs some more work.
MozReview-Commit-ID: 7zPGiL9Ob6N
Differential Revision: https://phabricator.services.mozilla.com/D7152
--HG--
extra : moz-landing-system : lando
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
These are identical to the 32 bit versions and so are no longer necessary to correctly
generate moz.build files for windows.
Depends on D7101
Differential Revision: https://phabricator.services.mozilla.com/D7102
--HG--
extra : moz-landing-system : lando
Markers are taking so much time(~10%) to allocate and in a website
like Speedometer, it takes ages to load the profile data since
there are so many frame construction markers.
Differential Revision: https://phabricator.services.mozilla.com/D7064
--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