`HTMLEditRules::GetListActionNodes()` removes non-editable element. However,
this should've been done by collector methods.
Differential Revision: https://phabricator.services.mozilla.com/D43026
--HG--
extra : moz-landing-system : lando
First half of `HTMLEditoRules::GetListActionNodes()` does 2 things. One is
trying to get parent list element of `Selection` ranges if `aEntireList` is
`EntireList::yes`. If it found a list element, it does nothing anymore.
Otherwise, falls backs to `EntireList::no` case. So, if each caller which
calls it with `EntireList::yes`, `GetListActionNodes()` does not need the
argument. Therefore, this patch does it first.
Then, `GetListActionNodes()` calls
`CollectEditTargetNodesInExtendedSelectionRanges()` or
`SplitInlinesAndCollectEditTargetNodesInExtendedSelectionRanges()`. It's
considered with `aTouchContent` is `yes` or `no`. So, this should be done
by each caller for making it clearer.
Differential Revision: https://phabricator.services.mozilla.com/D43024
--HG--
extra : moz-landing-system : lando
`HTMLEditRules::LookInsideDivBQandList()` does complicated things and I cannot
explain with a method name what it does. Fortunately, there are only 2 callers.
Therefore, this patch duplicates the part of modifying the range and creates
a method to retrieve "deepest and only editable child of `<div>`, `<blockquote>`
and one of list items".
Differential Revision: https://phabricator.services.mozilla.com/D43023
--HG--
extra : moz-landing-system : lando
This patch adds support for quota cache invalidation if the profile is loaded in different builds.
Differential Revision: https://phabricator.services.mozilla.com/D39673
--HG--
extra : moz-landing-system : lando
MANUAL PUSH: Backout and comment change that don't require a review and are somewhat time-critical: the backout fixes breakage in some local build scenarios.
--HG--
extra : rebase_source : 5230000ce88395794c272f0133e09979c70d526d
extra : amend_source : df014e518d27480c5b149acb8acaa0433565d483
The source of the trouble is our setContents override, which makes sure the window's
content view is the bottommost view in the window, and its interaction with a change
in behavior on 10.14, where windows that return YES from _wantsFloatingTitlebar will
contain an additional NSView for the window background. Our setContents override
moves the content view behind that window background view, which covers it with a
solid gray color.
--HG--
extra : amend_source : cd11d5c805de7054c3dfa3a1d5ae0f504f07116d
We need this change so that the newly-built clang will have
C++17-compatible libstdc++ headers installed. I believe this change
also means that the newly-built clang (and associated tools) links
against GCC 7's libstdc++, but we set RPATH or similar appropriately, so
there shouldn't be issues stemming from that.
Differential Revision: https://phabricator.services.mozilla.com/D41251
--HG--
extra : moz-landing-system : lando
1. Unsticky connection from a transaction we disable SPDY on to restart
2. Call OnReadSegment from TLSFilterTransaction;FilterOutput to push written data out (renegotiation)
3. Break indefinite loop that may occur during renegotiation by propagating WOULD_BLOCK via mFilterReadCode
Differential Revision; https;\\phabricator.services.mozilla.com\D40409
Differential Revision: https://phabricator.services.mozilla.com/D42310
--HG--
extra : moz-landing-system : lando
performAction, performActionOnRow and performActionOnCell are methods of the
nsITreeView interface that are never called. This is to remove these methods.
A comm-central patch will be along shortly.
Differential Revision: https://phabricator.services.mozilla.com/D39273
See https://github.com/w3c/csswg-drafts/issues/4239
This fixes what is in my opinion one of the biggest issues of scroll anchoring
as specified / currently implemented.
It's trivial to flush layout on a scroll handler and create scroll adjustments,
which in turn would trigger other scroll events to be fired. This situation,
which is what has happened in most of the scroll anchoring regressions I've
fixed, at best gets pages to get stuck in an infinite CPU loop. At worst, it
causes scrolling to be unusable because the page keeps reacting to scroll
events.
An alternative, slightly more elegant but not clear to me if 100% implementable
approach would be bug 1529702.
This should enormously reduce the need for scroll anchoring suppression
triggers[1], I'd think, which in turn would allow me to investigate removing
some of that complexity.
https://drafts.csswg.org/css-scroll-anchoring/#suppression-triggers
The setup to set / unset the boolean is a bit awkward but I couldn't come up
with anything better.
Differential Revision: https://phabricator.services.mozilla.com/D43233
--HG--
extra : moz-landing-system : lando
Changes:
- when specifying `fail-if` condition for linux platform, narrow down the scope using Ubuntu version `16.04` since some tests are passing on Debian 10
Differential Revision: https://phabricator.services.mozilla.com/D43172
--HG--
extra : moz-landing-system : lando
Automatic update from web-platform-tests
[Azure Pipelines] Differentiate manual triggers for Edge Dev/Canary (#18445)
As it is, it's only possible to run both of them:
https://github.com/web-platform-tests/wpt/issues/17342#issuecomment-521534275
This also renames the Edge Dev job and artifacts so that Edge stable can
later be added without further renaming.
--
wpt-commits: c1e89362cb351be0ea9239e38cf5830e104ba1f4
wpt-pr: 18445
Automatic update from web-platform-tests
Create new list for paced animation values
SVGAnimationElement::calculateKeyTimesForCalcModePaced() used to
overwrite the data passed in by the user. This commit fixes the
issue and there are now two lists stored, one with the user data
and one with the key times for paced.
This is a bug fix and should only affect SVGAnimationElements,
there will be an increase in memory usage, especially for animation
intensive scenes. Can be avoided by changing to a CPU heavy approach,
but this will probably be more energy efficient for mobile devices.
Bug: 231525
Change-Id: Ief9bbb8c6d1133d0041ad2c8f5a3d63f9ddcde90
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1757825
Reviewed-by: Fredrik Söderquist <fs@opera.com>
Commit-Queue: Edvard Thörnros <edvardt@opera.com>
Cr-Commit-Position: refs/heads/master@{#687651}
--
wpt-commits: 6ee27431c3352f158b198de70c0816bf1b485a05
wpt-pr: 18491
Automatic update from web-platform-tests
[css-transitions-2] Make null-effect test properly wait for the transition to start (#18457)
Previously this test would just rAF a single frame and assume that the
transition had started and that the 'left' had changed. Instead, this PR
changes the test to explicitly wait for 'left' to change, so that we can
be sure the transition has started before we interrupt it.
--
wpt-commits: 386d028948caf18c09ba67a68fc5b5667a6b8961
wpt-pr: 18457
Automatic update from web-platform-tests
Add a test for document.fonts.ready timing assumptions (#18489)
In https://github.com/web-platform-tests/wpt/pull/17219#issuecomment-521905202
a number of tests were found to depend on document.fonts.ready in this
way, and it turns out it doesn't work in Safari with web fonts. Add a
test to surface this problem more clearly.
--
wpt-commits: 29e72c566832e86e0180982400a1d77d4773e5d2
wpt-pr: 18489
Automatic update from web-platform-tests
Use StyleEngine::InRebuildLayoutTree() to check if we are rebuilding.
We used ChildNeedsReattachLayoutTree() on documentElement() to check
after [1], but that is false if it's only the root element which is
marked for re-attachment.
[1] https://crrev.com/df2ed4afdfaf3b30adc3d4d80cc7559965eb8519
Bug: 993764
Change-Id: If4656e1c478ee74d26e6e1a39dcef601837020e2
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1755990
Commit-Queue: Morten Stenshorne <mstensho@chromium.org>
Reviewed-by: Morten Stenshorne <mstensho@chromium.org>
Cr-Commit-Position: refs/heads/master@{#687607}
--
wpt-commits: 936827a6527f1c53051d3bc5bc79304c88c0737f
wpt-pr: 18490
Automatic update from web-platform-tests
Translate svg/animation tests to WPT (Commit 6)
This is the sixth commit in the series of updating all the old svg
animation tests.
The usage of testharness has replaced the older SVGAnimationTest.js
for all where it's suitable. No functionality should have changed
and the tests should cover almost the same.
In all of the animations where there is a sampling at T=0, where
it was assumed that no animations had started. Which didn't work
flawlessly when moved to the new system, it has thus been removed.
Bug: 985335
Change-Id: I43342eb1f4ee50aa5c14ec6035b4a45fee82d5f0
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1755902
Commit-Queue: Edvard Thörnros <edvardt@opera.com>
Auto-Submit: Edvard Thörnros <edvardt@opera.com>
Reviewed-by: Stephen Chenney <schenney@chromium.org>
Cr-Commit-Position: refs/heads/master@{#687594}
--
wpt-commits: 78a9dd6f2b8ef40c9e296ea493d6d04b86816055
wpt-pr: 18456
