If selection range is not in **one** text node, `RemoveInlinePropertyInternal()`
collects target nodes with `SubtreeContentIterator`. It only collects topmost
nodes which are **entirely** contained in the range (it's enough because their
descendants will be handled by `RemoveStyleInside()` recursively).
The reasons why it uses `SubtreeContentIterator` rather than
`PreContentIterator` must be:
1. Performance reason.
2. Assuming there are no multiple text nodes.
3. Not expects that user removes text node styles come from parent block.
The reason 2 is wrong because when removing a style, all browsers don't
join text nodes which was in removing element with adjacent text nodes.
(I.e., we cannot change this behavior for compatibility.)
The reason 3 is of course wrong we're struggling with this scenario.
Therefore, `RemoveInlinePropertyInternal()` needs to collect partially
selected text nodes by itself (if there are). Then, we can merge the
single text node selected case with the `for` loop.
Differential Revision: https://phabricator.services.mozilla.com/D47864
--HG--
extra : moz-landing-system : lando
I want to add this option to the gc() shell builtin to write a test case for
this bug.
Differential Revision: https://phabricator.services.mozilla.com/D48291
--HG--
extra : moz-landing-system : lando
This test sets the minimum nursery size to 16MB. But on some configurations
the nursery's maximum is 4MB (16 * 256KB chunks, eg on mobile). Setting the
minimum greater than the maximum is forbidden. This patch sets the maximum
and minimum nursery sizes in the test to avoid this problem.
Differential Revision: https://phabricator.services.mozilla.com/D48288
--HG--
extra : moz-landing-system : lando
The only thing it does is asserting a bit and posting more async work to the
text frame. It seems we can just post all the async work early instead, and
remove the change hint.
This was only introduced to fix bug 779971, where a <textPath> element
references its parent SVG, which is obviously unsound if we allowed to render
it.
What we're doing right now is a bit silly... We're observing the <svg>, so when
we finish reflowing it and store its overflow, we invalidate its rendering
observers, but that invalidates a _descendant_, which makes no sense.
Fortunately we don't let the element affect its rendering, as it fails this
check:
* https://searchfox.org/mozilla-central/rev/35cc00a25c4471993fdaa5761952bd3afd4f1731/layout/svg/SVGObserverUtils.cpp#1390
But we still request reflow of the outer <text>, which is not amazing. We
shouldn't invalidate anything if the textpath doesn't reference a valid element
and that didn't change. This is roughly what the code tried to do when checking
mValid, except we always initialize mValid to true and thus always trigger at
least one bogus reflow call.
Differential Revision: https://phabricator.services.mozilla.com/D48008
--HG--
extra : moz-landing-system : lando
When uploading texture data with a PBO we currently ensure the PBO
is the size of `(height - 1) * stride + (width * bpp)`, ie the final row
only contains the width's worth of data, not the stride. This should
be okay, and works fine on other implementations, but the android
emulator thinks it is invalid and emits a GL_INVALID_OPERATION error
in the glTexSubImage* call. To avoid this, ensure that the PBO is the
full `height * stride` size.
Differential Revision: https://phabricator.services.mozilla.com/D48541
--HG--
extra : moz-landing-system : lando
This was already working for toolbars, but it wasn't working for the titlebar in windows that
actually have a real separate titlebar.
All our windows use NSFullSizeContentViewWindowMask, so we no longer get this behavior for free.
In windows with titlebars, the titlebar area is covered with a TitlebarGradientView, so that's
where we need to handle the double clicks.
Differential Revision: https://phabricator.services.mozilla.com/D48593
--HG--
extra : moz-landing-system : lando
Bug 1329593 introduced this for the mingw-gcc build; but we no longer support this
build and mingw-clang does not need it.
Differential Revision: https://phabricator.services.mozilla.com/D48606
--HG--
extra : moz-landing-system : lando
The framebuffer clear was accidentally removed due to a rebase
error. We need to clear the framebuffer (and z) here when the
non-picture caching path is active.
Differential Revision: https://phabricator.services.mozilla.com/D48600
--HG--
extra : moz-landing-system : lando