The reftest-paged tests don't trigger the document clone code-path (I realized
that after writing them), but I guess they don't hurt, the printpreview test
does fail without the previous patch.
Depends on D39053
Differential Revision: https://phabricator.services.mozilla.com/D39054
--HG--
extra : moz-landing-system : lando
This should ensure that the inner window for each document is set up correctly
before iframe elements are created in them during a static clone. Other,
non-static-clone cases are not affected because they cannot load subframes.
Differential Revision: https://phabricator.services.mozilla.com/D38931
--HG--
extra : moz-landing-system : lando
This is what other browsers do, and it does make sense to me, it's useless to
try to scroll a frame with no scroll range in a given direction.
I think all callers of this function should be treated like this, so this is
more like a RFC / feedback request than a patch per se.
The wheel handling code already checks scroll range, so there's no difference of
behavior in that case, if I'm reading the code right.
There are a few other functions that check the result of
GetPerceivedScrollingDirections(), but I think if we change this we should
change this consistently.
I also think that if we do this we should rename the method to something like
GetAvailableScrollingDirections() or such.
Anyhow, wdyt? I should also add a test for this if we go with this.
Differential Revision: https://phabricator.services.mozilla.com/D38991
--HG--
extra : moz-landing-system : lando
Bug 1561547 introduces an SVG resource document in the UI in a way that the pref
changed callback ends up being called for that document _before_ being called for
the main document.
Given mDeviceContext is shared, it's a bug to depend on the return value of the
CheckDPIChange call, since then we only properly update the first document that
gets notified.
Differential Revision: https://phabricator.services.mozilla.com/D38974
--HG--
extra : moz-landing-system : lando
After bug 1555060, <tabs> elements should not use dom accessors to get
to the <tab> elements inside a <tabs>. This test was using lastChild,
this patch brings it up to date.
Differential Revision: https://phabricator.services.mozilla.com/D38526
--HG--
extra : moz-landing-system : lando
TraverseFrames gathers a bunch of frames into an array, and then at
forced breaks or the end of the block flushes its array by running
ResolveParagraph. ResolveParagraph can sometimes cause lines to break,
so lines recorded during TraverseFrames may no longer be accurate during
ResolveParagraph.
It may look like the lines are only needed during ResolveParagraph and
we could handle the one issue in TraverseFrames that deals with
preformatted newlines by restructuring the code a tad. However, in the
next patch, there will be an additional caller that needs the current
line during TraverseFrames to pass to CreateContinuation, which makes
such a structure less plausible.
This will also make it easier to produce a current line for the call to
SplitInlineAncestors within ResolveParagraph, which will be done in the
patch after the next.
Differential Revision: https://phabricator.services.mozilla.com/D38797
--HG--
extra : moz-landing-system : lando
This information is used in the next patch, which will use that information to
maintain a line iterator while iterating over mLogicalFrames (and will remove
the stored mLinePerFrame).
Differential Revision: https://phabricator.services.mozilla.com/D38796
--HG--
extra : moz-landing-system : lando
Rules and their declarations are a single object as far as the CC is concerned. They have a single nsCycleCollectionISupports and they are represented by a single node in the CC graph. That single object has two nsWrapperCache instances in it that point to different JS objects, and we need to make sure that the ordering of the unlink operations for those nsWrapperCache instances is handled correctly.
Differential Revision: https://phabricator.services.mozilla.com/D38326
--HG--
extra : moz-landing-system : lando
When we unlink, we may null out the mFontFaceSet pointer, but still keep
mInFontFaceset as true. Which can cause null dereference bugs as described in
comment 0.
This is mostly a speculative fix since I think that's a plausible cause for a
bug like that, but it may not be the only cause for the crash.
Differential Revision: https://phabricator.services.mozilla.com/D38822
--HG--
extra : moz-landing-system : lando
Many of these features are non-functional these days, but I'll keep them
hooked up in case we decide to fix them.
Differential Revision: https://phabricator.services.mozilla.com/D38413
--HG--
extra : moz-landing-system : lando
They're wrong. When a property that affects the parent frame changes, we get a
hint for both frames. This fixes this bug.
Depends on D38598
Differential Revision: https://phabricator.services.mozilla.com/D38599
--HG--
extra : moz-landing-system : lando
This is IMO the right RestyleManager change for what bug 1527210 tried to fix.
We need to apply the animation hints to the primary frame, not the style frame.
The other non-RestyleManager bits of that bug still apply and look fine to me.
Differential Revision: https://phabricator.services.mozilla.com/D38598
--HG--
extra : moz-landing-system : lando
Seems we can leave this node alive for too long if the user scrolls between
domcontentloaded (where GoToAnchor is called) and onload (where ScrollToAnchor()
is called).
Though it seems we can leave it for too long if we don't end up calling
ScrollToAnchor(), the documentation of the method claims that it's cleared
unconditionally.
Differential Revision: https://phabricator.services.mozilla.com/D38398
--HG--
extra : moz-landing-system : lando
This is a potential fix that I thought it was worth doing rather than
implementing Blink's platform-dependent silliness. This ensures that the display
frame always has enough space to display itself.
Note that it may still get clipped, if there's no room for both the display
frame and the button.
Differential Revision: https://phabricator.services.mozilla.com/D37922
--HG--
extra : moz-landing-system : lando
Unmasking is an optional style of showing password. Therefore, if callers of
`nsIEditor::Unmask()` specify middle of surrogate pair(s), it may mean that
they want to expand the unmask range from shorter range which does not include
the high and/or low surrogate. Therefore, one of the surrogates is in unmasked
range, we unmask the surrogate pair. However, we handle this in a lot of
places, i..e., we have duplicated code. This can get rid of these duplicates
with making `nsIEditor::Unmask()` expand the range automatically.
Differential Revision: https://phabricator.services.mozilla.com/D38432
--HG--
extra : moz-landing-system : lando
Mihai Alexandru Michis
longsonr
Narcis Beleuzu
Emilio Cobos Álvarez
Edwin Gao
Daniel Holbert
Brindusan Cristian
Nika Layzell
Dan Glastonbury
Ting-Yu Lin
Ciure Andrei
Andrew Swan
L. David Baron
Boris Zbarsky
harry
Coroiu Cristina
Cameron McCormack
Bogdan Tara
Hiroyuki Ikezoe
Masayuki Nakano