Currently it's possible to specify a single query and take the union of terms with the '|'
symbol. However if you want to craft anything more complicated (i.e linux mochitest and
xpcshell, but windows reftest), it becomes really difficult. This allows developers to union
the result of multiple queries.
For example:
./mach try fuzzy -q "'linux 'mochitest | 'xpschell" -q "'windows 'reftest"
Differential Revision: https://phabricator.services.mozilla.com/D1838
Because now we don't try to send the animations on visibility:hidden element.
MozReview-Commit-ID: IFqIc8ewz5T
--HG--
extra : rebase_source : ed031b3a55fd89f74437b71812f90dfc1825e823
Even if we unthrottled the invisbile animations to update the overflow region,
we don't need to send the animations to the compositor since the scroll bar
updates caused by the overflow should have been finished before sending
animations to the compositor.
MozReview-Commit-ID: GtKdPfBSyRB
--HG--
extra : rebase_source : 3b15f4578ed60740c1409304fe35ecd4f53fbd5b
The reason why const_cast is used for nsLayoutUtils::GetNearestScrollableFrame
is that if we changed the function as well, it ends up scattering const_cast
in most call sites of the function. That's because GetNearestScrollableFrame
has a do_QueryFrame call for the given nsIFrame* and returns the queried frame,
so it will be like this;
const nsIScrollableFrame* GetNearestScrollableFrame(const nsIFrame*, ..)
Most call sites of this function are then calls do_QueryFrame for the returned
nsIScrollableFrame*.
MozReview-Commit-ID: EwccKUITL89
--HG--
extra : rebase_source : f3b915fc78c096ca18d0922c764d15d73d552910
Since the test relies on missing keyframes handling.
MozReview-Commit-ID: IfbMvRhIeOh
--HG--
extra : rebase_source : 447bec6c7bc8d8a79f00bb738182e0647ee68ec5
Unknown group semantics are no longer an error but a warning indicating that the lines was skipped.
Made rust unit test test_parse_attribute_group more explicit.
MozReview-Commit-ID: 7adMSzH195H
--HG--
extra : rebase_source : b5edcdd389d5435808cb4faed5b8bf816774d0e4
Added Rid attribute parsing
Added C++/Rust glue code for the rid attribute
Added SdpInternalError for ParseFloatError
Added Rust unit test for parse_rid in Rust
Added U16Vec in C++/Rust glue code.
The C++ glue code no longer parses rid attributes on his own if the rust parser is used.
Reworked Simulcast parsing in rust
Added C++/rust glue code for Simulcast
Enabled CheckSimulcast c++ unit test
Added sanity check, that checks for simulcast rids that have nt been defined
Enabled ParseInvalidSimulcastNoSuchRecvRid C++ unit test
Added comments with bug number to remove redundant parsing functions.
Removed C++ unit test ParseInvalidSimulcastNoSuchPt
Added C++ unit test ParseInvalidRidNoSuchPt
Added sanity check for rid pts.
MozReview-Commit-ID: 7rvsOKIbxVP
--HG--
extra : rebase_source : abfc74e5f57b51158cf9acdf81078e5a4147fb29
When I originally implemented bug 1458161, this is how it was done, but
it was suggested to use a configure-time check. This turned out to not
be great, because the rust compiler changes regularly, and we don't run
the configure tests when the version changes. When people upgraded their
rust compiler to 1.27, the code subsequently failed to build because the
features were still set for the previous version they had installed.
--HG--
extra : rebase_source : 1b5f7a02ad8495d68cd29289f7beea59b8912183
When a binary has a PT_GNU_RELRO segment, the elfhack injected code
uses mprotect to add the writable flag to relocated pages before
applying relocations, removing it afterwards. To do so, the elfhack
program uses the location and size of the PT_GNU_RELRO segment, and
adjusts it to be aligned according to the PT_LOAD alignment.
The problem here is that the PT_LOAD alignment doesn't necessarily match
the actual page alignment, and the resulting mprotect may end up not
covering the full extent of what the dynamic linker has protected
read-only according to the PT_GNU_RELRO segment. In turn, this can lead
to a crash on startup when trying to apply relocations to the still
read-only locations.
Practically speaking, this doesn't end up being a problem on x86, where
the PT_LOAD alignment is usually 4096, which happens to be the page
size, but on Debian armhf, it is 64k, while the run time page size can be
4k.
--HG--
extra : rebase_source : 5ac7356f685d87c1628727e6c84f7615409c57a5
Adding the Places* files into unified sources pushed the
unified sources into a situation that exposed a strangely
large number of errors. This seems to be the minimum set of
changes I could make to resolve all of the issues.
MozReview-Commit-ID: C2H9ce8FmE4
--HG--
extra : rebase_source : 4f8dd2996d820fdb5a07afe544be5e2d6ca6a5c7
Consuming the new 'page-visited' notification was fairly trivial,
since it was already brought over to onVisits. There's not much to
say about this other than that I'm a little bit uncertain about
all the hoops we have to jump through to get a JSContext and
GlobalObject from History.cpp (which is discussed in the earlier
commit in the series).
MozReview-Commit-ID: LHaBWSylyLI
--HG--
extra : rebase_source : fd064e53e8645c3914188c05e71c8800d6f2174b
See the design doc[1] for further info. We would like to redesign
the places observer system to be more performant and more friendly
to consume. WebIDL was recommended as it simplifies creating simple
dictionary payloads while allowing dynamic typing with `any`.
There were some difficulties with WebIDL though, most of which
revolved around allowing consumers to be weakly referenced, from
both C++ and JS. The simplest solution I could come up with was to
create a simple native interface for the C++ case, and a WebIDL
wrapper for a JS callback in the JS case. Suggestions for simpler
alternatives are very welcome though.
[1] https://docs.google.com/document/d/1G45vfd6RXFXwNz7i4FV40lDCU0ao-JX_bZdgJV4tLjk/edit?usp=sharing
MozReview-Commit-ID: ACnAEfa5WxO
--HG--
extra : rebase_source : 6b5101e05d2f0588e831c0a7d1239a3dcb65ddcb
We're well overdue for an upgrade of the rust compiler requirements.
Now that we're building with 1.28 (albeit a beta, due to be bumped when
it's released), we can bump the requirement away from 1.24 which is now
old. 1.27 is too new, though, so settle for the older 1.26.
--HG--
extra : rebase_source : c788ef4f7da9949b81df2f0577af6f6039ea63d8
The sStaticModules list is, practically speaking, a copy of the list
of components we already have in libxul, augmented at runtime with
a few other components for tests (for gtest and xpcshell). We don't
actually need to keep that copy in memory. We can instead just use the
pointers in libxul directly to register them to the component manager,
and use a separate list, only for those extra components when they need
to be registered.
--HG--
extra : rebase_source : 1a32c95312d8577c99823adea8dbc0b022c286b2
Overall, this makes the whole setup less fragile, and make it work with
LTO in more situations.
--HG--
extra : rebase_source : de968c61dc4ef337fdc28745c202334ac41763cd
We perform, on the binaries we build, a series of check, that are
implemented as half-baked make commands, invoked after linking them.
- check libstdc++ symbol versions to ensure binary compatibility with
a baseline.
- check glibc symbol versions to ensure binary compatibility with a
baseline.
- check that target binaries don't contain text relocations.
- check that libmozglue is linked before libc on android.
- on libxul, check that NSModules are laid out correctly.
- on libxul, check that there is more than one PT_LOAD segment.
Those checks happen to work where they matter, but their setup is
unreliable. For example, the checks for symbol versions are supposed to
work for libclang-plugin on cross osx builds, but in fact, don't,
because the readelf path doesn't exist, and the command doesn't fail in
that case.
So move them all to a standalone script, performing the checks more
thoroughly (especially the NSModules one, where we now also check that
they are all adjacent), and more verbosely.
--HG--
extra : rebase_source : 7072e622e95f363d4a6c3a8e272d3445d998b592
At some point, the matching call to reporter.uninit got removed from this test.
The result is that the reporter still exists and is still collecting errors
during the rest of the tasks in the file. In most tasks, this isn't an issue
since we use reporter.handleMessage to test message handling at a per-reporter
level.
But the telemetry measures are shared between multiple reporters, thus they are
susceptible to interference from other running reporter instances.
The error that is being logged when this test fails is from the test add-on
created in testAddonIDMangle. My best guess is that the error logged by the
add-on is being processed during an idle moment in another task, since we
schedule processing to be delayed until the browser is idle. It seems this
scheduling is pretty consistent on certain Linux platforms.
Differential Revision: https://phabricator.services.mozilla.com/D1836
Adding the Places* files into unified sources pushed the
unified sources into a situation that exposed a strangely
large number of errors. This seems to be the minimum set of
changes I could make to resolve all of the issues.
MozReview-Commit-ID: C2H9ce8FmE4
--HG--
extra : rebase_source : b01f47e439a61492ad999ae30677c48535e8cd4c
Consuming the new 'page-visited' notification was fairly trivial,
since it was already brought over to onVisits. There's not much to
say about this other than that I'm a little bit uncertain about
all the hoops we have to jump through to get a JSContext and
GlobalObject from History.cpp (which is discussed in the earlier
commit in the series).
MozReview-Commit-ID: LHaBWSylyLI
--HG--
extra : rebase_source : 1190d4f127453cdcb692deb5982e92a93e236b9e
See the design doc[1] for further info. We would like to redesign
the places observer system to be more performant and more friendly
to consume. WebIDL was recommended as it simplifies creating simple
dictionary payloads while allowing dynamic typing with `any`.
There were some difficulties with WebIDL though, most of which
revolved around allowing consumers to be weakly referenced, from
both C++ and JS. The simplest solution I could come up with was to
create a simple native interface for the C++ case, and a WebIDL
wrapper for a JS callback in the JS case. Suggestions for simpler
alternatives are very welcome though.
[1] https://docs.google.com/document/d/1G45vfd6RXFXwNz7i4FV40lDCU0ao-JX_bZdgJV4tLjk/edit?usp=sharing
MozReview-Commit-ID: ACnAEfa5WxO
--HG--
extra : rebase_source : cb13b24696ee97b611c318b407ea9c31215df3f6
Changing enterprise_only to machine_only will allow these policies outside of the ESR, but not in HKEY_CURRENT_USER.
MozReview-Commit-ID: UAT6CPFOWO
--HG--
extra : rebase_source : e3e49d347241803e6ecd48e037c496ab15b566d5
