I'm pretty sure the FIXME I left in the outline-style code is a bug,
but I want to clean this up further and I didn't want to fix it without adding
a test.
Differential Revision: https://phabricator.services.mozilla.com/D12859
--HG--
extra : moz-landing-system : lando
This also adds a telemetry count for the grid highlighter being turned on by the
markup view, which was not in place when we added the telemetry for the grid
highlighter.
ICEntries and the fallback stub space are now stored in ICScript. The ICScript*
is stored in TypeScript to not increase sizeof(JSScript).
We need this for bug 1499324 but it also lets us greatly simplify the
BaselineDebugModeOSR code as this patch shows.
Note: some ICScript method definitions are still in BaselineJIT.cpp instead of
BaselineIC.cpp to make this patch easier to review. We could move them to
BaselineIC.cpp as a follow-up change.
Differential Revision: https://phabricator.services.mozilla.com/D11746
--HG--
extra : moz-landing-system : lando
Without knownTracksTime, StreamTracks::GetFirstTrackEnd() returns
STREAM_TIME_MAX for an empty StreamTracks, so PullNewData() thinks no new data
is needed.
This circumvents that by always checking whether tracks need data.
Differential Revision: https://phabricator.services.mozilla.com/D12928
--HG--
extra : moz-landing-system : lando
If zero tests are selected to run while --repeat-until-unexpected is specified, wptrunner can get into a fast infinite loop of running nothing until killed by the user.
This patch should stop that from happening by breaking the loop after the first iteration of nothing finishes.
Differential Revision: https://phabricator.services.mozilla.com/D13204
--HG--
extra : moz-landing-system : lando
This is all the style-system work needed for this.
This implements the concept of legacy shorthands, teaches tests to understand
it, and adds a few more tests for these properties in particular.
The WPT even caught a few WebKit / Blink bugs:
https://bugs.chromium.org/p/chromium/issues/detail?id=906336https://bugs.webkit.org/show_bug.cgi?id=191803
This doesn't change the layout behavior for page-break-before: always, since
it'd stop breaking in multicol and such. Similarly, break-before / break-after:
column and page still behave the same, I'll file followups for those given
comment 22.
Differential Revision: https://phabricator.services.mozilla.com/D12211
--HG--
extra : moz-landing-system : lando
This patch replace the LWT aliases with their related non-deprecated alias in all the theme API tests
that don't seem to be specifically testing the LWT aliases (e.g. browser_ext_themes_lwtsupport.js is
leaved unmodified for this reason).
The main reason to replace them in the "not stricly LWT-related" tests before their final removal
(currently planned for Firefox 69) is that the deprecation warnings will make these tests more
noisy (and so they may be making harder to investigate failures, without any actual gain in terms
of coverage).
Depends on D12297
Differential Revision: https://phabricator.services.mozilla.com/D12783
--HG--
extra : moz-landing-system : lando
The addon manager has a bunch of handling for "strict compatibility" --
an option for individual profiles and addons to control exactly how
compatibility is handled. However, WebExtensions don't use or expose
this feature. We want to retain this capability for other projects that
use the addon manager but since it cannot be tested with WebExtensions,
this patch converts its tests to use the new extension loading hook added
in the previous patch.
--HG--
extra : rebase_source : 023ef88b35d02f02976681894e9f052146f8b66c
extra : histedit_source : e6ff774d3639fe580f97bc7aa6df6f15a42d1a61
This patch doesn't currently prevent a static theme which uses the LWT aliases from
being installed successfully but, as the first step for their deprecation and removal,
it starts to log a warning message when these aliases are being used (e.g. when
installing the static theme extension from "about:debugging", these warnings are being
shown to the theme author).
A similar linting warning is going to be emitted on AMO submissions
(See https://github.com/mozilla/addons-linter/issues/2259), and it will
be turned it into a linting error once AMO should start to prevent new static
theme submittions from using the LWT aliases.
Differential Revision: https://phabricator.services.mozilla.com/D12297
--HG--
extra : moz-landing-system : lando
This spewer design has two goals:
1. Provide a spew mechanism that has first-class support for slicing and
dicing output. This means that filtering by script and channel should be
the dominant output mechanism.
2. Provide a simple powerful mechanism for getting information out of the
compiler and into tools. I'm inspired by tools like CacheIR analyzer,
IR Hydra, and the upcoming tracelogger integration into perf.html.
Differential Revision: https://phabricator.services.mozilla.com/D11787
--HG--
extra : moz-landing-system : lando
In mozTXTToHTMLConv, FindURL is not able to correctly calculate replaceBefore for nested email addresses/URLs such as john@doe.org}john@doe.org. As a workaround, we keep track of the end of the last URL HTML markup in the output string and skip any subsequent URLs whose replaceBefore would cut into this markup.
Differential Revision: https://phabricator.services.mozilla.com/D13391
--HG--
extra : moz-landing-system : lando
Port restriction is delegated to the io service. Port 0 is explicitly
unrestricted.
NS_CheckPortSafety emits a warning which pollutes the gtests a bit. It is only
tested if the port is not 0.
Differential Revision: https://phabricator.services.mozilla.com/D13187
--HG--
extra : moz-landing-system : lando
In Bug 1462394, we moved the autocomplete data handling
out of the JsTerm to the Redux store. In the process, we
regress some cases like `await n`, which should display
`navigator`, but isn't anymore when the user types the
whole sequence. Ctrl+Space would still show the popup,
which indicates that the issue is not on the server-side.
This issue is caused because our new code decides that
we should hit the cache when typing the `n`, and there's
nothing in the cache.
Previously, we were clearing the cache as soon as the input
last string wasn't alphanumeric, which we don't anymore.
To fix that, instead of relying on the last string of the
input (which could be wrong in cases like `x.["hello `), we
clear the cache when the autocomplete service returns a null
`matches` property.
In the JsPropertyProvider, we use to return null whenever
there isn't any search done (incorrect input, empty match prop, …).
So it seems like a good idea to bust the cache when the
server returns null.
This requires some changes to the autocomplete service, as well
as some in jsPropertyProvider (e.g. to handle `await `).
Tests are added both on the client and the frontend to make sure
we don't regress this (those tests fail without the actual fix).
Differential Revision: https://phabricator.services.mozilla.com/D13231
--HG--
extra : moz-landing-system : lando
