We must fail if server responds with HTTP/1.0 because HTTP upgrade requires at least HTTP/1.1 and nsHttpChannel correctly won't perform the upgrade, i.e WebSocketChannel::OnTransportAvailable won't be called.
--HG--
extra : rebase_source : a5af566c8a8dfc5e50aa74fcc1f0e552937e4b4e
By retaining a global GPU cache handle for a dummy image block, we
can reduce the per-frame GPU cache uploads quite a bit, which
helps with compositor time.
Differential Revision: https://phabricator.services.mozilla.com/D19326
--HG--
extra : moz-landing-system : lando
Chromium does workaround for scrolling with touch and avoid bitmap allocation when child window is used for DirectComposition. It improves performance of WebRender.
Differential Revision: https://phabricator.services.mozilla.com/D18659
The WR double style border shader has a condition to check if the
widths of the edges are too small to apply the style, in which case
it draws the border segment as solid. However, the check was
incorrectly skipping when the width of the inner / outer edge
was exactly one pixel.
Differential Revision: https://phabricator.services.mozilla.com/D19440
--HG--
extra : moz-landing-system : lando
When preceding mouse event is handled, that may cause changing style of the
target. Therefore, when an eMouseDown or eMouseUp event is handled, handlers
require the latest layout. Currently, nsViewManager::DispatchEvent() tries
to guarantee that with calling nsIPresShell::FlushPendingNotifications()
with FlushType::Layout. However, this just flushes the pending layout in
the PresShell associated with the nsViewManager instance. I.e., if the
target is in a child PresShell, its layout hasn't been flushed.
This patch makes PresShell::EventHandler::HandleEvent() flush pending
notifications at first of handling events using coordinates (only when
eMouseDown or eMouseUp, though). Then, when it realizes that the event
should be handled in a child PresShell, makes it flush its pending
notifications and then, recompute event target with the latest layout if
the layout is actually changed.
Differential Revision: https://phabricator.services.mozilla.com/D13720
--HG--
extra : moz-landing-system : lando
This patch defines a new xpcshell test which loads all the WebExtensions API modules twice,
first in alphabetic order and then again in reversed order.
The goal of this new test is to make it easier to detect issues with API module loading,
because all these API modules are loaded lazily in a shared global and it can fail
if multiple API modules defines the same global in incompatible ways (e.g. something which
is defined as a `const` in one module, and then as a `var` in a different one).
Depends on D18683
Differential Revision: https://phabricator.services.mozilla.com/D19160
--HG--
extra : moz-landing-system : lando
Some functions or properties are not used anymore in the
codebase, so we can safely delete them.
Other ones are only used in Scratchpad or VariableView,
which we want to get rid off in the next months. We move
those functions directly in Scratchpad/VariableView.
Differential Revision: https://phabricator.services.mozilla.com/D19377
--HG--
extra : moz-landing-system : lando
This manifests as silent child process crashes; let's try to avoid
that when we can.
Differential Revision: https://phabricator.services.mozilla.com/D19089
--HG--
extra : moz-landing-system : lando
No one uses CheckCurrentWordNoSuggest. So I would like to get a rid of this
method. And this method is only user of mozSpellChecker::CheckWord. So
mozSpellChecker::CheckWord shouldn't allow that aSuggestions is nullptr on
content process since we already have async API as mozSpellChecker::CheckWords.
Differential Revision: https://phabricator.services.mozilla.com/D19303
--HG--
extra : moz-landing-system : lando
This patch splits the part handling event when there is pointer capturing
content but it does not have frame.
Differential Revision: https://phabricator.services.mozilla.com/D19300
--HG--
extra : moz-landing-system : lando
When we mark call expressions as breakpoints, we want to make it as likely
as possible that the call has its own unique positon. The existing logic
means that it is more likely that the beginning of a call will align
with the start of an expression statement or other debuggable step point.
By using the property-access location, we're less likely to collide.
Thid also adds a new bytecodes that were missed in the original code that
added this position handling logic.
Differential Revision: https://phabricator.services.mozilla.com/D17661
--HG--
extra : moz-landing-system : lando
Making changes to this test is kind of annoying because the count and
the array items need to be kept in sync. This just avoids that.
Differential Revision: https://phabricator.services.mozilla.com/D17660
--HG--
extra : moz-landing-system : lando
This is just a bit of cleanup I'd noticed while writing new implementations of these.
Differential Revision: https://phabricator.services.mozilla.com/D17659
--HG--
extra : moz-landing-system : lando
lib32-libstdc++5 moved from multilib to AUR, but it seems like we don't
need this anymore anyway.
Differential Revision: https://phabricator.services.mozilla.com/D19276
--HG--
extra : moz-landing-system : lando
This patch changes ext-history.js and ext-browsingData.js to ensure that these API modules are importing PlacesUtils in the same way as ext-bookmarks.js, because mixing CU.defineModuleGetter and CU.import would raise an error and it would break those two WebExtensions APIs if the ext-bookmarks.js gets loaded first.
Differential Revision: https://phabricator.services.mozilla.com/D18683
--HG--
extra : moz-landing-system : lando
Functionally, we want Marionette to be enabled whenever remote
debugging enabled and disabled whenever remote debugging is enabled.
That's not particularly well supported by Gecko prefs, so we don't try
to handle all situations. We force the Marionette pref whenever the
remote debugging pref changes; if consumers get themselves into a bad
state by fiddling the Marionette pref independently, that's fine:
GeckoView will take back control eventually.
There are a couple of wrinkles here. The first is that GeckoView and
Marionette race to set themselves up in "profile-after-change". We
ensure that both are configured before GeckoView notifies
"marionette-startup-requested". The second is that the initial value
of the Marionette pref is taken from the environment variable
MOZ_MARIONETTE; therefore, we set that variable when starting the
Gecko thread.
Differential Revision: https://phabricator.services.mozilla.com/D17580
--HG--
extra : moz-landing-system : lando
This is just a testing convenience. Remote debugging is engine-wide,
not session-wide, so it doesn't fit the other actions _exactly_; but
the "multiprocess" option is also somewhat engine-wide, so it doesn't
seem wildly out of place.
Differential Revision: https://phabricator.services.mozilla.com/D18616
--HG--
extra : moz-landing-system : lando
This implements support for adding generic-worker caches. As a consequence this
also turns on caching for the gecko checkout if present.
Differential Revision: https://phabricator.services.mozilla.com/D17690
--HG--
extra : moz-landing-system : lando
We add caches at various places in common.py. This consolidates the logic into
a re-useable function. This is in preparation for adding generic-worker cache
support.
This also adds a test. The test is not terribly useful, but I've been looking
for an excuse to lay some groundwork for further tests in the 'job' submodule.
This will do.
Differential Revision: https://phabricator.services.mozilla.com/D17689
--HG--
extra : moz-landing-system : lando
When the build system compiler is clang, and bindgen autodetection
actually finds a different clang via llvm-config, or a different clang
was given with --with-clang-path, we do want the proper flags to be
used for that clang, so we always get the right flags for that clang
instead of trying to shortcut.
Bug 1526857 will take care of making things more proper, while this is a
quick fix to unbreak builds in some unfortunately common kind of local
setups.
Differential Revision: https://phabricator.services.mozilla.com/D19328
--HG--
extra : moz-landing-system : lando