As discussed with @mbalfanz, we want to flip the pref so Inactive CSS is enabled and rides the trains.
This will enable the feature on Firefox 70 Beta/DevEdition allowing us to collect early user feedback and issues.
If all goes well during Beta/DevEdition, the feature will ride the trains to Release.
If there is a major blocker, we will uplift a patch to disable the pref so it doesn't proceed to Release.
Differential Revision: https://phabricator.services.mozilla.com/D43265
--HG--
extra : moz-landing-system : lando
At some point we can think about triggering incremental slices here the way we do for the GC heap allocations but for now it's simplest to just not trigger any more slices if we're already allocating.
Differential Revision: https://phabricator.services.mozilla.com/D43099
--HG--
extra : moz-landing-system : lando
I missed changing this when I changed the threshold to be the incremental trigger rather than the non-incremental one. I'm not entirely sure we need this chech at all - I think it will only happen in the case where we've requested a non-incremental GC but the interrupt hasn't caused one to run yet.
Differential Revision: https://phabricator.services.mozilla.com/D43035
--HG--
extra : moz-landing-system : lando
This was already transferring ownership to caller so use appropriate
types instead.
Depends on D43182
Differential Revision: https://phabricator.services.mozilla.com/D43183
--HG--
extra : moz-landing-system : lando
- This creates a mock for fluent-l10n module, so we can use `l10n.getString()` in our code and test for it.
- This patch also removes unused files `test/fixtures/l10n.js` and `test/fixtures/PluralForm.js`
In order to double check the mock works, these two lines can be added to any test:
```
const { l10n } = require("devtools/client/application/src/modules/l10n");
expect(l10n.getString("foo")).toBe("foo");
```
Differential Revision: https://phabricator.services.mozilla.com/D43050
--HG--
rename : devtools/client/application/test/components/fixtures/l10n.js => devtools/client/application/test/components/fixtures/fluent-l10n.js
extra : moz-landing-system : lando
It just collects all children of given node so that it can be a static method
in `HTMLEditor`.
Differential Revision: https://phabricator.services.mozilla.com/D43022
--HG--
extra : moz-landing-system : lando
This patch fixes the issue by updating the allow list as soon as the
switch been toggled. And the reload still happens after the 500ms delay.
We cache the target tab in order to reload the correct tab in case tabs
change and reload the target tab after the delay. In additon, we won't
reload the tab if is has been closed since it is totally unnecessary.
We also add a test for this.
Differential Revision: https://phabricator.services.mozilla.com/D43139
--HG--
extra : moz-landing-system : lando
It's called only from `HTMLEditRules::MoveBlock()`. Even though it has 4
patters to call different methods, we need only one of them. Therefore,
this patch moves it into `HTMLEditor.h` as
`SplitInlinesAndCollectEditTargetNodesInOneHardLine()`.
Differential Revision: https://phabricator.services.mozilla.com/D43021
--HG--
extra : moz-landing-system : lando
`HTMLEditRules::GetNodesFromSelection()` has a patch to call
`HTMLEditor::GetSelectionRangesExtendedToIncludeAdjuscentWhiteSpaces()`.
However, nobody uses this path so that we can get rid of this path.
Then, it becomes just calling `SplitInlinesAndCollectEditTargetNodes()` or
`CollectEditTargetNodes()` with result of
`GetSelectionRangesExtendedToHardLineStartAndEnd()`. Therefore, we can split
it to `SplitInlinesAndCollectEditTargetNodesInExtendedSelectionRanges()` and
`CollectEditTargetNodesInExtendedSelectionRanges()`. Then, we can mark
only the former as `MOZ_CAN_RUN_SCRIPT`.
Differential Revision: https://phabricator.services.mozilla.com/D43020
--HG--
extra : moz-landing-system : lando
`HTMLEditRules::GetPromotedRanges()` does 2 things. Calling
`CreateRangeIncludingAdjuscentWhiteSpaces()` or
`CreateRangeExtendedToHardLineStartAndEnd()` with each range of `Selection`.
The difference is considered with current edit sub-action. Therefore, we cal
split it to `GetSelectionRangesExtendedToIncludeAdjuscentWhiteSpaces()` and
`GetSelectionRangesExtendedToHardLineStartAndEnd()`. Then, we got clearer code
at each caller.
Differential Revision: https://phabricator.services.mozilla.com/D43018
--HG--
extra : moz-landing-system : lando
Bug 1454613 enabled binast (binsource back then) so that automation
would catch trivial build errors. The caveat is that it incurs build
times for everyone, while the tool is not even used during the build:
the result of running it is checked into the tree.
Ideally, it would be built in entirely separate tasks, but the overhead
of setting up a task (checking out the repository, downloading
toolchains, etc.) is actually large enough that it's overkill to build
completely separately.
However, it makes sense to limit to spidermonkey standalone builds.
Differential Revision: https://phabricator.services.mozilla.com/D43208
--HG--
extra : moz-landing-system : lando
The discrepancy of features used for syn between jsrust and gkrust
triggered syn and its reverse dependencies up to cranelift to be
built once for jsrust and once for gkrust, while they are time consuming
to build.
Differential Revision: https://phabricator.services.mozilla.com/D43209
--HG--
extra : moz-landing-system : lando
This time, existing config.status trying to import it will throw an exception
that will trigger a re-configure.
Differential Revision: https://phabricator.services.mozilla.com/D43215
--HG--
extra : moz-landing-system : lando
As seen in bug 1575774/1575959, things can go badly when config.status
doesn't match expectations, especially when most mach commands try to
read it, starting with mach clobber, which is supposed to be the one
commant to get away from most problems.
The idea here is to throw a recognizable exception so that callers can
react accordingly. While not obvious from the patch, the result is that
running e.g. mach build with a broken config.status will automatically
run configure (because the relevant caller actually handles the rethrown
exception that way).
There are other calls to from_config_status in the mozbuild reader, but
that can't be reached before MozbuildObject.config_environment.
Differential Revision: https://phabricator.services.mozilla.com/D43214
--HG--
extra : moz-landing-system : lando
The method name is really unclear what's done. The method does 3 things.
One is try to select a `<br>` element in empty block if given range is
collapsed in the block. This is moved as
`HTMLEditor::SelectBRElementIfCollapsedInEmptyBlock()`. Next, it extends the
given range to include adjuscent whitespaces only when edit sub-action is
inserting or deleting text. This is moved as
`HTMLEditor::CreateRangeIncludingAdjuscentWhiteSpaces()`. Finally, when
handling the other edit sub-actions, extends the given range to start/end
of line at both edges. This is moved as
`HTMLEditor::CreateRangeExtendedToHardLineStartAndEnd()`.
And also this patch makes each caller of `PromoteRange()` to check edit
sub-action by themselves. Unfortunately, this duplicates same logic to
multiple places, but makes what they do clearer. I think that the duplication
issue should be fixed later if necessary. Instead, we should shine the
blackbox of `HTMLEditRules` right now.
Differential Revision: https://phabricator.services.mozilla.com/D43017
--HG--
extra : moz-landing-system : lando
2019-08-23 Kevin Jacobs <kjacobs@mozilla.com>
* tests/common/cleanup.sh:
Bug 1560593 - Check that BUILD_OPT is defined before testing its
value. r=jcj
[44aa330de2aa] [NSS_3_46_BETA1]
* cmd/strsclnt/strsclnt.c:
Bug 1575968 - Add strsclnt option to enforce the use of either IPv4
or IPv6 r=jcj
[da284d8993ea]
2019-08-23 Marcus Burghardt <mburghardt@mozilla.com>
* gtests/softoken_gtest/softoken_gtest.cc:
Bug 1573942 - Gtest for pkcs11.txt with different breaking line
formats. r=kjacobs
[d07a07eb0e40]
2019-08-21 Kevin Jacobs <kjacobs@mozilla.com>
* lib/util/utilmod.c:
Bug 1564284: Added check for CR + LF, r=marcusburghardt,kjacobs
Looks good and it was already tested locally with this gtest patch:
[d1d2e1e320cd]
2019-08-22 Martin Thomson <mt@lowentropy.net>
* lib/ssl/ssl3con.c:
Bug 1528666 - Formatting, a=bustage
[60eeac76c8ec]
2019-08-20 Martin Thomson <martin.thomson@gmail.com>
* gtests/ssl_gtest/ssl_0rtt_unittest.cc,
gtests/ssl_gtest/ssl_resumption_unittest.cc, lib/ssl/ssl3con.c:
Bug 1528666 - Correct resumption validation checks, r=jcj
We allowed cross-suite resumption before, but it didn't work. This
enables that for clients.
As a secondary minor tweak, clients will no longer validate the
availability of a cipher suite based on their configured version
range when attempting resumption. Instead, they will check whether
the suite works for the version in the session that they are
attempting to resume. In theory, this doesn't change anything
because the previous session should not have selected an
incompatible combination of version and cipher suite, but it's worth
being extra precise.
[cab2c8905214]
2019-08-22 Martin Thomson <mt@lowentropy.net>
* gtests/ssl_gtest/ssl_auth_unittest.cc,
gtests/ssl_gtest/ssl_resumption_unittest.cc, lib/ssl/ssl3con.c:
Bug 1568803 - More tests for client certificate authentication,
r=kjacobs
These were previously disabled because of difficulties (at the time)
in writing these tests for TLS 1.3. The framework, and my
understanding of it, has since improved, so these tests can be
restored and expanded. This exposed a minor correctness issue that
is also corrected.
[95f97d31c313]
Differential Revision: https://phabricator.services.mozilla.com/D43308
--HG--
extra : moz-landing-system : lando
