This commit implements candidate selection for a scroll frame using a frame tree
traversal. It roughly tries to follow the algorithm given in the scroll
anchoring draft specification, adapted to operate on the frame tree [1].
Some details, such as not selecting an anchor if the user hasn't scrolled are
not currently in the specification but will be to match Blink's implementation.
Once a scroll anchor has been selected, we maintain a bit on it and its ancestor
frame's states. This is used in a later commit to detect changes to position
during a reflow so the scroll frame can perform an adjustment.
A scroll anchor will be invalidated when the user scrolls the frame or the
scroll anchor is destroyed. Later commits will add logic to drive selection and
invalidation appropriately.
[1] https://drafts.csswg.org/css-scroll-anchoring/#anchor-node-selection
Differential Revision: https://phabricator.services.mozilla.com/D13268
--HG--
extra : rebase_source : e05ba48662aafef5957322def33ddc5d93f3ca5a
extra : source : bdb766faa8679386bf4e9740781262ea4bb36544
This commit adds a barebones class called 'ScrollAnchorContainer' that will
contain most of the logic for scroll anchoring. It is owned as a member of
ScrollFrameHelper, and has the same lifetime.
Differential Revision: https://phabricator.services.mozilla.com/D13267
--HG--
extra : rebase_source : 41f6f7691af60401f18f98a89f1878cfad2e74d3
extra : source : 3033401ef320414ef5f489c53526d015c38a89d7
This commit is used in a later commit to exclude frames that are sticky positioned
from being scroll anchors.
Differential Revision: https://phabricator.services.mozilla.com/D13266
--HG--
extra : rebase_source : efa0b81269dbf55d14d5702e4e4d4970cce2e5cb
extra : source : 6b96050386f6e9bae6b61747145e204d12cd7cf3
This restores the previous behavior of using calc().
Note that background-position / object-position, which test this, weren't
hitting the assertion because they use another codepath.
I didn't add more extensive tests for this because it's well tested for those
two properties, and because this is legacy anyway, see the comment in the test.
I did add the assertion to the codepath those two properties hit.
Differential Revision: https://phabricator.services.mozilla.com/D16176
It does not represent `<length> | <percentage>`, but `<length-percentage>`, so
`LengthOrPercentage` is not the right name.
This patch is totally autogenerated using:
rg 'LengthOrPercentage' servo | cut -d : -f 1 | sort | uniq > files
for file in $(cat files); do sed -i "s#LengthOrPercentage#LengthPercentage#g" $file; done
Differential Revision: https://phabricator.services.mozilla.com/D15812
--HG--
extra : moz-landing-system : lando
The concrete classes of nsIContentIterator are enough complicated, but they
are not tested simply. Therefore, it's dangerous to touch them even if we
meed bugs of them. Additionally, it's used in some hot paths, therefore,
I'd like to keep them simple as far as possible.
Therefore, this patch creates a mediator class between script and each
nsIContentIterator instance. So, this change shouldn't affect any of
actual behavior nor performance.
Differential Revision: https://phabricator.services.mozilla.com/D15285
--HG--
extra : moz-landing-system : lando
I think this should do. This still prints out stderr when it fails pointing to
the solution, and doesn't fail the build.
Differential Revision: https://phabricator.services.mozilla.com/D15784
--HG--
extra : moz-landing-system : lando
The XBL binding implementation relied on nsDateTimeControlFrame to call into
its nsIDateTimeInputArea implementation. This is correct because the XBL binding
is only constructed when the element has a frame. If the value is set while the
element is hidden, the XBL binding will pick up the correct value during construction.
That is not the case for UA Widget. As it is constructed when the DOM is attached,
relying on nsDateTimeControlFrame to send an event when attributes change means
the event won't be sent to the already constructed UA Widget.
This patch fixes that by moving the event dispatching calls originating from
HTMLInputElement out of nsDateTimeControlFrame, so they will behave correctly in
the absence of the frame.
I've also moved the gut of nsDateTimeControlFrame::HasBadInput() to
DateTimeInputTypeBase::HasBadInput(). Content script should be allowed to validate
the input without the frame.
Sadly this means the XBL implementation and the UA Widget implementation
have further diverged. The complexity should go away when we could finally
remove the XBL implementation.
nsDateTimeControlFrame still dispatches a few events to UA Widget, in
AttributeChanged() and SyncDisabledState(), as they are originated from the layout.
The name of the events in AttributeChanged() are incorrect though -- I am correcting
that in this patch too.
Differential Revision: https://phabricator.services.mozilla.com/D15601
--HG--
extra : moz-landing-system : lando
This converts the tabmodalprompt binding to a class, to be constructed along side with the element
by TabModalPromptBox.
TabModalPromptBox will keep the instances in a map and pass it to the callers, instead of the element.
The tests and callers can access the class instance by passing the element reference to the map.
Differential Revision: https://phabricator.services.mozilla.com/D15505
--HG--
rename : toolkit/components/prompts/content/tabprompts.xml => toolkit/components/prompts/content/tabprompts.jsm
extra : moz-landing-system : lando
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
It was enabled by default in bug 1041833 (for desktops) and
bug 1087562 (for Fennect).
Depends on D15706
Differential Revision: https://phabricator.services.mozilla.com/D15707
--HG--
extra : moz-landing-system : lando
By disallowing flushing layout in AccessibleCaret's callbacks, we don't
need to worry about dead PresShell affect other callbacks in the system.
Differential Revision: https://phabricator.services.mozilla.com/D15537
--HG--
extra : moz-landing-system : lando
Without this change, for example,
UpdateCarets(UpdateCaretsHint::DispatchNoEvent) won't update carets. We don't
have a wrong use case yet, but it's good to fix that beforehand.
Differential Revision: https://phabricator.services.mozilla.com/D15535
--HG--
extra : moz-landing-system : lando
GetParent() already returns nsContainerFrame*, and it's easier to use
with API like FinishBuildingColumns() demanding a nsContainerFrame*.
Differential Revision: https://phabricator.services.mozilla.com/D15549
--HG--
extra : moz-landing-system : lando
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
Just use nsTArray. They're used to keep an array of strong references to
documents, and never use nsISupports-specific methods.
Plus they're are allocated on the stack so it should be safe to access them via
ranged for, so do that.
This is needed because nsCOMArray<T> depends on the cast from T to nsISupports
not to be ambiguous. I could fix that if needed, but it seems easier to just not
use it in these two cases.
Differential Revision: https://phabricator.services.mozilla.com/D15351
This is to prevent Part 1 from breaking
testing/web-platform/tests/css/css-multicol/multicol-span-all-restyle-002.html
After introducing Part 1, we now use CreateContinuingFrame() to create
non-column-span wrapper frames, which use nsFrame::Init() rather than
InitAndRestoreFrame() to initialize them. Because the bits in
aState.mAdditionalStateBits are added to frames only when
nsCSSFrameConstructor::InitAndRestoreFrame() is called. We need a new
way to add the NS_FRAME_PART_OF_IBSPLIT to non-column-span wrapper
frames.
Note that we used to add NS_FRAME_PART_OF_IBSPLIT to both column-span
wrapper and non-column-span wrapper. After this patch, column-span
wrapper won't have NS_FRAME_PART_OF_IBSPLIT. That's fine because
column-span wrappers are not linked with other frames and they
shouldn't get this bit set.
Depends on D15134
Differential Revision: https://phabricator.services.mozilla.com/D15452
--HG--
extra : moz-landing-system : lando
In CreateColumnSpanSiblings(), aInitialBlock can be a DetailsFrame.
Therefore, when creating a non-column-span wrapper, we cannot assume
it's always a block frame. We need to use CreateContinuingFrame to
ensure the correct type of continuation is created.
Differential Revision: https://phabricator.services.mozilla.com/D15134
--HG--
extra : moz-landing-system : lando
This hopefully will address the test-verify failures that were reported in bug 1516006.
--HG--
extra : rebase_source : d01139f16469c631eb047d21e998dfaf0d58c3a5
extra : amend_source : 8543fd2e10bf485cabaf45dfac156e6b9094ea41
Also add an IsElement check in GetElementFromPoint in the APZ code since I think
the element cast is unsound in presence of Shadow DOM.
Differential Revision: https://phabricator.services.mozilla.com/D14355
--HG--
extra : moz-landing-system : lando
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
This changes the semantics of the relative visual viewport offset calculation in
the PresShell slightly, in that a missing root scroll frame will no longer
force the relative offset to zero, even if the visual viewport itself has a non-
zero scroll position [1].
On the other hand, the visual viewport's own relative offset calculations
already work that way today, in that layout and visual viewport scroll positions
are retrieved separately and then subtracted from one another regardless of
whether those values are actually valid or merely a fallback because the
PresShell/scroll frame weren't available.
[1] Though I'm not sure under what circumstances this could really be relevant.
Differential Revision: https://phabricator.services.mozilla.com/D14686
--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
The event rate throttling mechanism is modelled on the logic for "scroll" events
in nsGfxScrollFrame.cpp.
That is
1. When a request to fire an event is posted to the VisualViewport, we create a
new runnable for this and register it with the RefreshDriver. If we already
have a pending runnable, calling VisualViewport->Post...Event() becomes a
no-op.
2. When the RefreshDriver is ready, it executes the runnable, which in turn
fires the actual event and then cleans itself up.
To keep this patch manageable, we simply fire a scroll event every time the
stored visual viewport offset is changed. Because we are storing the absolute
offset of the viewport relative to the page, this behaviour doesn't match the
spec, which demands that scroll events are fired only when the relative offset
between visual and layout viewport changes. We'll fix this up in the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D14043
--HG--
extra : moz-landing-system : lando
So we do it while we're still handling re-entrant changes for SVG, since SVG can
post change hints from UpdateOverflow().
Differential Revision: https://phabricator.services.mozilla.com/D12102
--HG--
extra : moz-landing-system : lando
This has no behavior change, since it just expands to
NS_IMPL_QUERY_TAIL_INHERITING, but it's clearer, and clang-format understands
it.
Also, these are the only uses of this macro, so I don't think we should make
clang-format understand it.
Differential Revision: https://phabricator.services.mozilla.com/D15125
--HG--
extra : moz-landing-system : lando
If a ColumnSetWrapperFrame already has column-span children,
ColumnSetWrapperFrame::GetContentInsertionFrame() will return itself to
let WipeContainingBlock() aware this is the case to reframe.
To make this work, we need to move the reframe condition prior to check
NS_FRAME_HAS_MULTI_COLUMN_ANCESTOR bit because the top level
ColumnSetWrapperFrame never has NS_FRAME_HAS_MULTI_COLUMN_ANCESTOR bit
set.
Differential Revision: https://phabricator.services.mozilla.com/D14819
--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 function doesn't do painting synchronously but schedule painting if
certain conditions are met. Hence the rename.
Differential Revision: https://phabricator.services.mozilla.com/D15021
--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
The <iframe> in the test case is getting the "column-span:all" style,
but it's under a position:fixed frame subtree. After the patch in bug
1507244 landed, NS_FRAME_HAS_MULTI_COLUMN_ANCESTOR won't be added
incorrectly to the out-of-flow subtree.
Differential Revision: https://phabricator.services.mozilla.com/D14626
--HG--
extra : moz-landing-system : lando
1. Test the most simple cases when we use max-content/min-content on
width/height/block-size.
* block-size-with-min-or-max-content-1a.html
* block-size-with-min-or-max-content-1b.html
2. Test base cases when we use max-content/min-content on
width/height/block-size inside the table element.
* block-size-with-min-or-max-content-table-1a.html
* block-size-with-min-or-max-content-table-1b.html
3. For {horizontal|vertical} writing mode, we use max-content/min-content on
{min-|max-}{height|width} and {min-|max-}block-size on the inner element.
* hori-block-size-small-or-larger-than-container-with-min-or-max-content-1.html
* vert-block-size-small-or-larger-than-container-with-min-or-max-content-1.html
4. For {horizontal|vertical} writing mode, we use max-content/min-content on
{min-|max-}{height|width} on the outer element (i.e. the container).
* hori-block-size-small-or-larger-than-container-with-min-or-max-content-2a.html
* vert-block-size-small-or-larger-than-container-with-min-or-max-content-2a.html
5. For {horizontal|vertical} writing mode, we use max-content/min-content on
{min-|max-}block-size on the outer element (i.e. the container).
* hori-block-size-small-or-larger-than-container-with-min-or-max-content-2b.html
* vert-block-size-small-or-larger-than-container-with-min-or-max-content-2b.html
Depends on D14320
Differential Revision: https://phabricator.services.mozilla.com/D13485
--HG--
extra : moz-landing-system : lando
We should let block-size/min-block-size/max-block-size accept keywords as the
initial value, just like width in vertical writing mode or height in horizontal
writing mode.
Depends on D7536
Differential Revision: https://phabricator.services.mozilla.com/D14320
--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
ExtremumLength is the keyword type for css sizing properties, so we
could use cbindgen.
In Gecko, we use nsStyleCoord to store the sizing properties, and use
integer values to check the enum values, so I keep the macros in nsStyleConsts.
Even though we need to convert the enum type into integer, we still have
benefits to reduce the complexity of converting Rust into C++, and leave
the simplified mappings in C++ for better readability.
Differential Revision: https://phabricator.services.mozilla.com/D7535
--HG--
extra : moz-landing-system : lando
Bug 1506163 fixed only part of the issue. There are more types of frames
such as table, grid, flex, etc. that create their own block formatting
context.
Instead of propagating NS_FRAME_HAS_MULTI_COLUMN_ANCESTOR to the
children, we explicit carry the bit over to block and inline frames by
checking that their parent doesn't suppress column-span descendants.
Also, remove the unused "onload" from <body> in the tests.
Differential Revision: https://phabricator.services.mozilla.com/D13597
--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
This backs out the main patch landed earlier in bug 1194856 and the
patch from bug 1225004.
Differential Revision: https://phabricator.services.mozilla.com/D14050
--HG--
extra : moz-landing-system : lando
This is a followup to bug 1089326.
The other kind of elements other than <button> that use this frame are
input[type="reset|submit|button"], via nsGfxButtonControlFrame. And that frame
is a leaf, so it can only contain anonymous content (which is chromeonly
content and thus doesn't show up in event.target and co.).
This changes behavior for event.originalTarget, I suppose, but that's what we
do elsewhere as well, and that's a Gecko-specific thing.
Differential Revision: https://phabricator.services.mozilla.com/D14604
--HG--
extra : moz-landing-system : lando
Ryan Hunt
Emilio Cobos Álvarez
Brindusan Cristian
Olli Pettay
longsonr
Masayuki Nakano
Brian Hackett
Gurzau Raul
Andrea Marchesini
Timothy Guan-tin Chien
Ting-Yu Lin
Miko Mynttinen
Hiroyuki Ikezoe
Ciure Andrei
Jan Henning
Ting-Yu Lin
Matt Woodrow
Bogdan Tara
Daniel Holbert
Jason Kratzer
Daniel Varga
shindli
Paolo Amadini
Jonathan Kew
Cosmin Sabou
Coroiu Cristina
Sylvestre Ledru
Margareta Eliza Balazs
quasicomputational
Cameron McCormack
sharath
arthur.iakab
Andreea Pavel
Kartikaya Gupta
Timothy Nikkel
Jeff Muizelaar
Boris Chiou
Botond Ballo
Razvan Maries
Geoff Brown
Markus Stange
Mats Palmgren
Julian Descottes
Jonathan Kingston
Mark Banner