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
We could keep using ParsedCaseSensitivity::CaseSensitive as a temporary stand-in
for "case-sensitive or maybe not depending on what HTML says" until we check the
attribute list, but it seems better to make that explicit.
Differential Revision: https://phabricator.services.mozilla.com/D14093
--HG--
extra : moz-landing-system : lando
Currently, when `about:debugging` is displaying, even if move to another URL on
Android, its update does not reflect to `about:debugging` page. Because the `DOMTitleChanged` event on message manager comes from only in case of remote browser. In this patch, get the event on even not remote browser, then notify to clients.
Differential Revision: https://phabricator.services.mozilla.com/D12094
--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 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
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
This can happen when we annotate trackers with the strict list but block based on the
basic list, and it is confusing users.
Differential Revision: https://phabricator.services.mozilla.com/D13968
--HG--
extra : moz-landing-system : lando
