After Bug 1507244 Part 2 landed, only block or inline frames can have
NS_FRAME_HAS_MULTI_COLUMN_ANCESTOR bit set. We need to fix
IsColumnSpanInMulticolSubtree() for other types of frames.
In multi-column formatting context, every frame having a
"column-span:all" style will be wrapped by a -moz-column-span-wrapper
frame. We can use this to check whether a non-inline and non-block frame
is in a multi-column subtree or not.
Differential Revision: https://phabricator.services.mozilla.com/D15709
--HG--
extra : moz-landing-system : lando
Summary: Really sorry for the size of the patch. It's mostly automatic
s/nsIDocument/Document/ but I had to fix up in a bunch of places manually to
add the right namespacing and such.
Overall it's not a very interesting patch I think.
nsDocument.cpp turns into Document.cpp, nsIDocument.h into Document.h and
nsIDocumentInlines.h into DocumentInlines.h.
I also changed a bunch of nsCOMPtr usage to RefPtr, but not all of it.
While fixing up some of the bits I also removed some unneeded OwnerDoc() null
checks and such, but I didn't do anything riskier than that.
There is no reason to use nsAtoms*, it's error prone, i.e. the function
can take arbitrary nsAtoms*.
Depends on D15339
Differential Revision: https://phabricator.services.mozilla.com/D15340
--HG--
extra : moz-landing-system : lando
This is a big step in order to merge both.
Also allows to remove some very silly casts, though it causes us to add some
ToSupports around to deal with ambiguity of casts from nsIDocument to
nsISupports, and add a dummy nsISupports implementation that will go away later
in the series.
Differential Revision: https://phabricator.services.mozilla.com/D15352
The VisualViewport events are all nice and shiny, but unfortunately not quite
what is needed for the session store.
Firstly, the spec wants the "scroll" event to be fired only when the *relative*
offset between visual and layout viewport changes. The session store however
records the absolute offset and as such is interested in when *that* changes.
Secondly, again as per the spec the events don't bubble, and with the default
DOMEventTargetHelper implementation they don't escape the VisualViewport during
capturing, either. This means that any event listener must be added directly on
the VisualViewport itself in order to capture any events.
This might have been intended because the events use the same names as the
normal "scroll"/"resize" events, and as such you cannot specify separate event
listeners for VisualViewport and non-VisualViewport "scroll" events if both
events end up being dispatched to the same element (you can only try to filter
after the fact by looking at the originalTarget of the event).
At the same time, the VisualViewport is attached to the inner Window, and so
each time you navigate, you also get a different VisualViewport object.
All of this might be totally fine from the perspective of a page script, because
in that case you won't care anyway about what happens when the current page goes
away.
From the session store perspective on the other hand (especially Fennec's non-
e10s session store design), this is rather unfortunate because we don't want to
have to keep registering event listeners
a) manually for each subframe
b) each time the page navigates
The event target chain problem could be solved by letting the scroll events
escape the VisualViewport during the capturing phase (which the spec doesn't say
anything about), but this would mean that any scroll listener attached to a
window/browser/... that uses capturing will now catch both layout and visual
viewport scroll events.
In some cases this might even be beneficial, but in others (e.g. bug 1498812
comment 21) I'd like to specifically decide which kind of scroll event to
capture. Having to look at event.originalTarget to distinguish the two kinds
might be defensible in test code, but in case this distinction would be needed
in production code as well, given the existence of a C++-based filtering helper
in nsSessionStoreUtils for another use case where (scroll) events need to be
filtered, JS-based scroll event filtering might be a bad idea.
Additionally, in any case this wouldn't solve the fundamental conflict between
the spec and the session store about *when* the "scroll" event should be fired
in the first place.
Hence I'd like to introduce a separate set of events with distinct event names,
which will be dispatched according to the requirements of our internal users
(i.e. currently the session store). To avoid potential web compatibility issues
down the road, for now these events will be dispatched only to event listeners
registered in the system group (allowing *all* Chrome event listeners cannot be
done because checking the Chrome status of each event target might be too
expensive for frequently dispatched events).
Differential Revision: https://phabricator.services.mozilla.com/D14046
--HG--
extra : moz-landing-system : lando
Internally, Gecko stores and updates the *absolute* offset between the visual
viewport and the page, however the spec demands that the scroll event be fired
whenever the *relative* offset between visual and layout viewport changes.
Differential Revision: https://phabricator.services.mozilla.com/D14044
--HG--
extra : moz-landing-system : lando
ColumnSetFrame is always created by
nsCSSFrameConstructor::BeginBuildingColumns(). We search for it in the
possible child lists of ColumnSetWrapperFrame and its continuations.
Differential Revision: https://phabricator.services.mozilla.com/D14501
--HG--
extra : moz-landing-system : lando
The following APIs are changed.
1. Contains() needs to become contains(). (EnumSet's methods have lowercase names.)
2. Use list constructor rather than "|" like a plain enum.
3. Use operator+= instead of operator|=.
Differential Revision: https://phabricator.services.mozilla.com/D14908
--HG--
extra : moz-landing-system : lando
Support unprefixed min-content and max-content and treat the prefixed
version as aliases for
1. width, min-width, max-width if inline-axis is horizontal, and
2. height, min-height, max-height if inline-axis is vertical, and
3. inline-size, min-inline-size, max-inline-size, and
4. flex-basis.
Besides, update the test cases to use unprefixed max-content and
min-content.
Depends on D7535
Differential Revision: https://phabricator.services.mozilla.com/D7536
--HG--
extra : moz-landing-system : lando
The argument has never been used since the function the function was introduced
in bug 240276.
Differential Revision: https://phabricator.services.mozilla.com/D14713
--HG--
extra : moz-landing-system : lando
The main style of <table> is set on the inner TableFrame, not the outer
TableWrapperFrame. Thus, we fail to spot the table as a column-span kid
in nsCSSFrameConstructor::ConstructionBlock().
Differential Revision: https://phabricator.services.mozilla.com/D13957
--HG--
extra : moz-landing-system : lando
This patch does not change behavior - it's purely an optimization to some
existing logic.
Differential Revision: https://phabricator.services.mozilla.com/D13132
--HG--
extra : moz-landing-system : lando
Previously we were using SetProperty, which does a redundant walk through the
property list to see whether the property already exists. This was unnecessary
because we only invoke it in the scenario when the property wasn't set.
So, we can use AddProperty to simply append and skip the redundant walk. And to
be extra-sure that the frame property is not present, this patch makes us use
the stricter 'found' outparam that our GetProperty() API provides (to
differentiate between no-result vs. a null value being intentionally stored
[unexpected but theoretically possible, & now checked for via MOZ_ASSERT].)
Depends on D14221
Differential Revision: https://phabricator.services.mozilla.com/D14222
--HG--
extra : moz-landing-system : lando
Previously we were providing a hand-coded destructor for this type, but this
was unnecessary, because the default one (invoked by 'delete') will do the same
thing.
Differential Revision: https://phabricator.services.mozilla.com/D14221
--HG--
extra : moz-landing-system : lando