This issue is e10s only.
Even if calling SetSelection, it doesn't reset selection cache in
TextInputHandler. Since selection cache is updated by OnSelectionChange
asynchronous, we should set temporary range when having replacement range.
Also, even if marking dirty doesn't fix this issue. Content cache may return
other range such as caret position instead of replacement range by SetSelection.
Differential Revision: https://phabricator.services.mozilla.com/D14002
--HG--
extra : moz-landing-system : lando
Bug 1505887 changed the behavior here from content calling into nsFind via
window.find(), by making the SetStart and SetEnd calls here fail instead of
succeed for NAC (like the text in textareas).
This patch makes us handle that error gracefully moving on to the next match,
instead of trying to preserve the previous behavior.
This means that we'll fail to highlight textarea content and such from
window.find, which Chromium does, looks like. Though Chromium doesn't expose
the ranges as selection either. In any case I don't think that this is a very
common thing given bugs like bug 1442466, which this bug fixes.
I haven't found anything close to a spec for what window.find() should do... If
we decide to go with this patch then I'll add a crashtest for this and a test
for bug 1442466 as well. Otherwise I'll add a way to skip the security check in
nsFind somehow for NAC, or relax the security restrictions in SetStart /
SetEnd, I guess.
Differential Revision: https://phabricator.services.mozilla.com/D14013
--HG--
extra : moz-landing-system : lando
This allows to experiment with other hash maps easily rather than
depending on what hashglobe::fake::HashMap dereferences to.
In particular I wrote it while trying to get a build working with hashbrown.
Differential Revision: https://phabricator.services.mozilla.com/D14098
--HG--
extra : moz-landing-system : lando
The minidump_stackwalk used for tests ifs picked up from tooltool, and
it looks like the tooltool manifests haven't been updated in 2 years.
As it turns out, this old version is not capable of, at least, stack
walk over crashes originated in LTOed rust code on Windows, while
breakpad trunk, as well as the slightly oldest version we have in-tree
do.
While ideally, we'd go with building minidump_stackwalk as a taskcluster
toolchain artifact, or during the build, but that involves significantly
more work, while we should fix the stack traces of crashes that people
_do_ get as early as possible.
The tooltool artifacts linked in the updated manifests were generated
the following way:
- Revert the last two changes that happened to minidump_stackwalk.cc
between 2016 and now (they don't matter for functionality and get in
the way of the rest below).
- Apply the changes betwen the version of minidump_stackwalk.cc from
2016 and
https://hg.mozilla.org/users/tmielczarek_mozilla.com/stackwalk-http/raw-file/51e4725ffad4/stackwalk.cc
- Pick the http_symbol_supplier.cc and http_symbol_supplier.h files from
the same repo as stackwalk.cc above.
- Add the necessary build system bits to build it off the Gecko tree,
along with the in-tree breakpad code.
- Build it for linux, linux64, macosx64, win32-mingw.
The patch doing all the above is:
https://hg.mozilla.org/try/rev/64491336dc7fca7a1c00ae8c66619b01563bbe4e
The push to build it on the aforementioned platforms:
https://hg.mozilla.org/try/rev/4b621a67ca0bd6cf8954566e180d23e1ba8a9f83
A win64-mingw variant was also built, but is not being used, keeping
things in line with what we currently are using. We may want to follow
up with an update to use that win64 variant on 64-bits testers.
Differential Revision: https://phabricator.services.mozilla.com/D14005
--HG--
extra : moz-landing-system : lando
The gfx pref machinery asserts when user-level values are set that
environment and runtime prefs have not been set. This effectively means
we need to make all user-level decisions before calls to ForceDisable(),
and the code in question here violates that contract.
This branch is not necessary for correctness, since the pref basically
means "enable WR on qualified hardware", and we can just ignore that
request if the hardware is not qualified. It does provide extra
about:support information, but we also get that information from the
recording in WebRenderHardwareQualificationStatus, which creates a
separate decision log for WEBRENDER_QUALIFIED. In this case, it will
report something like:
"WEBRENDER_QUALIFIED: blocked by env: No qualified hardware"
which should be enough here.
Differential Revision: https://phabricator.services.mozilla.com/D14082
Moves bspatch.h and bspatch.cpp into new folder
Adds LICENSE, moz.yaml, and moz.build for bspatch
Alters bsdiff and updater build files to account for the new location of bspatch
Renames toolkit/mozapps/update/common/errors.h to toolkit/mozapps/update/common/updatererrors.h for
breaking windows builds. It collided with MSVCRT's exported errors.h after being added to the export list for
the 'updatercommon' library
Differential Revision: https://phabricator.services.mozilla.com/D13735
--HG--
rename : toolkit/mozapps/update/common/errors.h => toolkit/mozapps/update/common/updatererrors.h
rename : toolkit/mozapps/update/updater/bspatch.cpp => toolkit/mozapps/update/updater/bspatch/bspatch.cpp
rename : toolkit/mozapps/update/updater/bspatch.h => toolkit/mozapps/update/updater/bspatch/bspatch.h
extra : moz-landing-system : lando
When wpt is used by developers they often want to reload a test that's
running to allow iterative development (or running under devtools,
etc.). The recent switch to target marionette commands at the test
window rather than the opener window broke this as waiting is
implemented as an async script that never returns (i.e. a promise that
never resolves) and when this is in the test window navigating that
window causes the script to return.
A simple, but not particuarly elegant, solution here is to simply
rerun the script in the new window.
Differential Revision: https://phabricator.services.mozilla.com/D14087
--HG--
extra : moz-landing-system : lando
In Bug 919979 we added 100 bytes to the size returned by CalcBufferSize
to work around an error with the calculated buffer size with small
resolutions. I verified that this extra buffer is no longer required with
a modified mochitest. Given the age of the bug this was working around,
I don't think a permanent test is required to prevent regressions from
upstream.
Differential Revision: https://phabricator.services.mozilla.com/D14076
--HG--
extra : moz-landing-system : lando
- Unified openContainerNodeInTabs and openURINodesInTabs in PlacesUIUtils into openMultipleLinksInTabs
- Users are now warned when the amount of links to be opened is equal to or exceeds browser.tabs.maxOpenBeforeWarn
Differential Revision: https://phabricator.services.mozilla.com/D12983
--HG--
extra : moz-landing-system : lando
Whilst we do set the Keep-Alive HTTP header to request the HTTPD to
use a persistent connection, we throw away the httplib.HTTPConnection
object after each request. This will causes the HTTPD to serve us
a persistent connection, only to throw it away after the first request.
When the connection timeout is reached, httplib closes the connection
for us. Unfortunately httplib does not reconnect for the next
request, so we need to manually check if the underlying socket
connection to the server is alive.
We check whether the connection has dropped or if it has unread,
buffered data using select() as a poller. We could use poll() here
on available systems, which might give a theoretical performance
improvement since it gives O(number of file descriptors), but since
we only deal with one connection select() will probably be good enough.
Differential Revision: https://phabricator.services.mozilla.com/D13845
--HG--
extra : moz-landing-system : lando
Implemented cache sanitizing for files generated by handling the content:// scheme.
Differential Revision: https://phabricator.services.mozilla.com/D11779
--HG--
extra : moz-landing-system : lando
This prevents an infinite loop where we go into a child only to find the
nearest hypertext accessible being its parent.
Differential Revision: https://phabricator.services.mozilla.com/D13998
--HG--
extra : moz-landing-system : lando
This is an egregious hack. The web-platform-tests were not meant to run in the shell.
The eight tests that are included are the ones that we pass with flying colors.
In most of the others, we still have a failure or two.
Differential Revision: https://phabricator.services.mozilla.com/D11533
--HG--
rename : dom/imptests/testharness.js => js/src/jit-test/lib/w3c-testharness.js
extra : moz-landing-system : lando
Uploading both versions will hopefully make this easier to uplift. Once old pushes and artifacts expire, we can stop uploading the gzipped version.
Differential Revision: https://phabricator.services.mozilla.com/D13601
--HG--
extra : moz-landing-system : lando
WR Updater Bot
Makoto Kato
Mike Hommey
Emilio Cobos Álvarez
Brindusan Cristian
Logan Smyth
Dave Townsend
Tim Nguyen
Wes Kocher
Cameron McCormack
Dão Gottwald
Bobby Holley
Boris Zbarsky
June Wilde
James Graham
Dan Minor
Sebastian Hengst
Yura Zenevich
Toby Ward
Florens Verschelde
Cosmin Sabou
Andreas Tolfsen
Patrick Brosset
ffxbld
Andrei Lazar
Eitan Isaacson
Jason Orendorff
Ciure Andrei
Andrea Marchesini