The assert was overzealous and should just be removed. Other return
addresses reported by iterator are just sampled by stack and don't
indicate if stack is synced or not.
Also, fix up an out-of-date comment here.
Differential Revision: https://phabricator.services.mozilla.com/D14108
--HG--
extra : moz-landing-system : lando
loadSubScript throws a string, without any stack/location.
Consider all string exceptions as coming from loadSubScript and re-throw a real error
object, coming with the stack of the require call.
Also handle wrong require path with a more explicit error message.
Differential Revision: https://phabricator.services.mozilla.com/D14139
--HG--
extra : moz-landing-system : lando
1-line fix to hero element timing: the performance entry would show up as 'undefined' in profiles because the variable was defined later.
Differential Revision: https://phabricator.services.mozilla.com/D14746
--HG--
extra : moz-landing-system : lando
IMMHandler and TSFTextStore are good class to put native caret when they have
enough information. However, for example, IMMHandler may not have its singleton
instance until first composition of IMM-IME starts. Therefore, typically,
IMEHandler is a good class to put native caret without composition.
This patch adds IMEHandler::MaybeCreateNativeCaret(), and if it won't create
native caret because not yet received WM_GETOBJCT for OBJID_CARET, we should
fire window event for MSAA applications. If there is new MSAA application
retrieves OBJID_CARET, we'll receive WM_GETOBJECT for OBJID_CARET
asynchronously. Then, we should start to put native caret for such
applications.
Note that if we create native caret, some versions of ATOK refers the native
caret and the behavior becomes worse than usual. Therefore, we need to
keep not using native caret as far as possible.
Differential Revision: https://phabricator.services.mozilla.com/D13962
--HG--
extra : moz-landing-system : lando
If WM_GETOBJECT for OBJID_CARET is received but a11y module is not active,
IME module should create native caret over our caret because Windows will
handle the request with native caret automatically and we don't need to
enable a11y module only for it.
This patch makes IMEHandler store whether such message has been received and
makes TSFTextStore create native caret when composition, selection or layout
is changed because especially when there is composition, only TSFTextStore
knows correct position to put caret if there is composition or some dispatched
events have not been handled by content process yet.
Note that IMMHandler already does that since some legacy IMEs require native
caret to show its UI and we cannot check active IME strictly. Therefore, this
patch does not touch IMMHandler.
Differential Revision: https://phabricator.services.mozilla.com/D13961
--HG--
extra : moz-landing-system : lando
IMEHandler needs to create native caret later (when there is no composition).
Therefore, IMEHandler should manage whether it creates native caret or not
and IMMHandler and TSFTextStore should create/destroy native caret via
IMEHandler.
Note that this patch makes IMMHandler stops managing whether native caret
is created for plugin or not because native caret is created only one instance
and anyway IME handlers should stop managing native caret when they loses
focus.
Differential Revision: https://phabricator.services.mozilla.com/D13960
--HG--
extra : moz-landing-system : lando
If a11y module is active, it observers caret position and size, and when caret
position or size is changed, it creates/moves native caret to overlap with
our caret.
On the other hand, IME module also creates native caret if active IME requires
it. Therefore, both of them conflicts each other.
This patch makes IME module stop touching native caret if a11y module is active.
Although, a11y module with Flush Player does not work well for IME. Therefore,
this patch keeps the conflict between them as-is for now.
Differential Revision: https://phabricator.services.mozilla.com/D13959
--HG--
extra : moz-landing-system : lando
The test intermittently fails on OSX. For some reason start(PORT) doesn't always fail when PORT is in use, so we timeout because the handler is never called. I suspect it's because of how SO_REUSEADDR and SO_REUSEPORT are handled on sockets sever-side on OSX. Since httpd is used for unit tests, there is little risk in disabling the test on OSX.
The alternative is to check for a timeout, and in that case switch to another port - which is cumbersome, and not the purpose of the test.
Differential Revision: https://phabricator.services.mozilla.com/D14756
--HG--
extra : moz-landing-system : lando
This collects SSL_TIME_UNTIL_HANDSHAKE_FINISHED dependent on the key group used. This is nice to have in general and especially for the ecdhe-sidh thing.
Differential Revision: https://phabricator.services.mozilla.com/D13524
--HG--
extra : moz-landing-system : lando
* Make the probes available on the release channel.
* Migrate the probes to newer probe types.
* Rename the probes.
* Set email.
* Set expiry.
Differential Revision: https://phabricator.services.mozilla.com/D14237
--HG--
extra : moz-landing-system : lando
We don't care anymore: the Gradle build fetches an appropriate version
of the build-tools package, and the one build-tool we actually use --
zipalign -- isn't version sensitive.
Differential Revision: https://phabricator.services.mozilla.com/D14290
--HG--
extra : moz-landing-system : lando
There's no need -- it will be fetched by Gradle when needed. The only
wrinkle is that the user might be asked to confirm license agreements,
which could be a hassle (and could cause problems in CI, but there we
install relevant platforms in advance).
Differential Revision: https://phabricator.services.mozilla.com/D14288
--HG--
extra : moz-landing-system : lando
The build system no longer invokes these directly: they're all fetched
and invoked by Gradle and its plugins.
Differential Revision: https://phabricator.services.mozilla.com/D14287
--HG--
extra : moz-landing-system : lando
This assumes that all of the notifications for a given origin must be in the
same process. With this patch, we'll always go back to the parent process to
get the notifications. Up next is limiting our search in the parent process to
only the notifications we're looking for.
Differential Revision: https://phabricator.services.mozilla.com/D14774
--HG--
extra : moz-landing-system : lando
The current code assumes that it can get the ServiceWorkerManager in the child
process to send a message to the proper service worker. That isn't true, we
need to ask the parent to do it for us.
Differential Revision: https://phabricator.services.mozilla.com/D14773
--HG--
extra : moz-landing-system : lando
Adds hiddenFocus() and removeHiddenFocus() methods and some CSS selector tweaking to enable focusing without visible changes.
MozReview-Commit-ID: Dq66TET4AVR
Differential Revision: https://phabricator.services.mozilla.com/D14733
--HG--
extra : moz-landing-system : lando
This might just push the crash to one of the other methods. If it does,
that will confirm that this is the right thing to be guarding against,
and we can extend the guard to any other methods that need it. If the
crash goes away entirely, that's good too and might be because
UpdateZoomConstraints is somehow "special" (it has been found to be
special in the past because at one point it was the first IPDL message
to get sent over some channel).
Depends on D14787
Differential Revision: https://phabricator.services.mozilla.com/D14788
--HG--
extra : moz-landing-system : lando
Move js/src/jsapi.h declarations related to promises and job queues into their
own public header file, js/public/Promise.h. Change the compilation units that
need these declarations to #include the new header.
There should be no changes to the actual functionality here, simply moving the
code to a new file, and removing the "JS" prefix from some typedefs which are
now in the JS namespace.
Differential Revision: https://phabricator.services.mozilla.com/D13345
--HG--
extra : moz-landing-system : lando
This makes it so that apilints lints with "GV" codes are enforced and will fail
the build.
Depends on D13882
Differential Revision: https://phabricator.services.mozilla.com/D13883
--HG--
extra : moz-landing-system : lando
