aboutsummaryrefslogtreecommitdiffstats
path: root/components/layout_2020/tests/floats.rs
Commit message (Collapse)AuthorAgeFilesLines
* Migrate to the 2024 edition (#35755)Simon Wülker2025-03-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | * Migrate to 2024 edition Signed-off-by: Simon Wülker <simon.wuelker@arcor.de> * Allow unsafe_op_in_unsafe_fn lint This lint warns by default in the 2024 edition, but is *way* too noisy for servo. We might enable it in the future, but not now. Signed-off-by: Simon Wülker <simon.wuelker@arcor.de> * Compile using the 2024 edition Signed-off-by: Simon Wülker <simon.wuelker@arcor.de> --------- Signed-off-by: Simon Wülker <simon.wuelker@arcor.de>
* Update deprecated use of PanicInfo to PanicHookInfo (#34659)Narfinger2024-12-171-2/+2
| | | Signed-off-by: Narfinger <Narfinger@users.noreply.github.com>
* Use inline-start/inline-end instead of left/right terminology for floats ↵Oriol Brufau2024-12-131-18/+18
| | | | | | | | | | (#34608) It was a bit confusing that e.g. a float with `FloatSide::InlineStart` would set `FloatBand::left`, or that `PlacementAmongFloats` would compute `max_inline_start` from the various `FloatBand::left`. So now all the float logic will consistently use logical terminoligy. Signed-off-by: Oriol Brufau <obrufau@igalia.com>
* Upgrade Stylo to 2024-12-04 (#34501)Oriol Brufau2024-12-061-7/+6
| | | | | | | | | | | | | | | | | * Upgrade Stylo to 2024-12-04 Signed-off-by: Oriol Brufau <obrufau@igalia.com> * Fixup for https://phabricator.services.mozilla.com/D229998 Signed-off-by: Oriol Brufau <obrufau@igalia.com> * Update test expectations Signed-off-by: Oriol Brufau <obrufau@igalia.com> --------- Signed-off-by: Oriol Brufau <obrufau@igalia.com>
* layout: Right-to-left support for other layout modes (#33375)Martin Robinson2024-09-111-20/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This change removes the `effective_writing_mode` concept and tries to properly implement right-to-left layout support for all non-inline writing modes. In general, what needs to happen is that rectangles need to be converted to physical rectangles using the containing block. A right-to-left rectangle's inline start is on the right physical side of the containing block. Likewise a positive inline offset in right-to-left text is a negative physical one. The implementation here is pretty good for most layout modes, but floats are still a bit in process. Currently, floats are processed in the logical layout of the block container, but there still might be issues with float interaction with mixed RTL and LTR. While this does move us closer to supporting vertical writing modes, this is still unsupported. New failures: - Vertical writing mode not supported: - `/css/CSS2/floats/floats-placement-vertical-001b.xht` - `/css/CSS2/floats/floats-placement-vertical-001c.xht` - Absolutes inlines should avoid floats (#33323) - `/css/css-position/position-absolute-dynamic-static-position-floats-004.html` - No support for grid - `/css/css-align/self-alignment/self-align-safe-unsafe-grid-003.html` - `/css/css-position/static-position/inline-level-absolute-in-block-level-context-009.html` - `/css/css-position/static-position/inline-level-absolute-in-block-level-context-010.html` - Cannot reproduce these locally on any platform. Very mysterious: - `/css/css-tables/row-group-margin-border-padding.html` - `/css/css-tables/row-margin-border-padding.html` - Exposes bugs we have related to hanging whitespace in preserved whitespace inlines: - `/css/css-text/white-space/trailing-space-and-text-alignment-rtl-003.html` - `/css/css-text/white-space/white-space-pre-wrap-trailing-spaces-023.html` Signed-off-by: Martin Robinson <mrobinson@igalia.com> Co-authored-by: Rakhi Sharma <atbrakhi@igalia.com>
* Remove lazy static (#33078)Hayashi Mikihiro2024-08-161-4/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * remove from rand Mutex<OsRng> can be initialized in compile time. Signed-off-by: Hayashi Mikihiro <34ttrweoewiwe28@gmail.com> * remove from layout_2020 Mutex<()> can be initialize in compile time Signed-off-by: Hayashi Mikihiro <34ttrweoewiwe28@gmail.com> * remove from media `IS_MULTIPROCESS` doesn't be used. Signed-off-by: Hayashi Mikihiro <34ttrweoewiwe28@gmail.com> * remove lazy_static from dependencies Signed-off-by: Hayashi Mikihiro <34ttrweoewiwe28@gmail.com> * rewrite suppressed_leaks_for_asan.txt For all of lazy_static was replaced with LazyLock. Signed-off-by: Hayashi Mikihiro <34ttrweoewiwe28@gmail.com> --------- Signed-off-by: Hayashi Mikihiro <34ttrweoewiwe28@gmail.com>
* layout: use `Au` in `BoxFragment` (#31794)atbrakhi2024-03-221-2/+2
| | | | | * use au in BoxFragement * review fix
* Lint layout_2020 with clippy (#31169)Oriol Brufau2024-01-251-16/+10
| | | cargo clippy --fix -p layout_2020 --allow-dirty --broken-code
* Use App units in flow layout (#30894)atbrakhi2024-01-191-58/+74
| | | | | | | | | | | | | | | * use app_unit in flow layout * fmt * Avoid crash * Drop assert that doesn't hold anymore * update expectation --------- Co-authored-by: Oriol Brufau <obrufau@igalia.com>
* Allow raising FloatContext ceiling after processing box with overflow (#30539)Martin Robinson2023-10-171-1/+1
| | | | | | | | | | | | | | | When a box has overflow, any floats placed in that box will lower the float ceiling into the overflow. If no float is placed in the box though, the ceiling should be the block position where the overflow starts. We already know where this is, because we might be passing a negative value for the new block position after processing a box (content_size - actual_size would be negative). This negative value never raises the ceiling though since a maximum is used. In the case that there is overflow, this change allows raising the ceiling, but never passed the lowest float. This necessitates keeping two values for the ceiling: one for floats and one for non-floats. Fixes #30304.
* Layout 2020: Rename `flow_relative` types to `Logical...` (#30324)Martin Robinson2023-09-121-5/+5
| | | | | | This makes the names of flow relative geometry consistent with what is used in the style crate and removes them from a module. With this change it's more obvious what makes these types different from the ones in `euclid`.
* Strict import formatting (grouping and granularity) (#30325)Samson2023-09-111-9/+9
| | | | | * strict imports formatting * Reformat all imports
* remove `extern crate` (#30311)Samson2023-09-081-2/+1
| | | | | | | | | | | * remove extern crate * Update components/script_plugins/lib.rs Co-authored-by: Martin Robinson <mrobinson@igalia.com> --------- Co-authored-by: Martin Robinson <mrobinson@igalia.com>
* Fix failing unit test due to overflow (#30074)Yutaro Ohno2023-08-081-1/+1
|
* Remove ClearSide enum (#30035)Oriol Brufau2023-07-271-15/+15
| | | Just use Clear instead, they have the same values.
* Run unit tests with both layout 2013 and layout 2020 (#30032)Oriol Brufau2023-07-271-3/+3
| | | | | | | | Since #29950, unit tests were only running with the legacy layout, and there was no way to run them for layout 2020. This patch makes './mach test-unit' run unit tests for both. Also doing some changes so that the layout 2020 floats.rs tests compile.
* Correct rendering of floated rootMartin Robinson2023-06-201-1/+1
| | | | | | | | | | | | | | | Fix two issues around floating a root element: 1. In the StackingContext code handle the case where a root element is a Float fragment and not a Box fragment. This fixes a debug assertion failure in the css/CSS2/float/float-root.html test. 2. When initializing the SequentialLayoutState, use the containing block width as the maximum inline float placement position instead of infinity. This fixes the rendering of css/CSS2/float/float-root.html. Note that css/CSS2/float/float-root.html was passing before, because both the test and reference were subject to the same bug. This fixes a couple other tests as well.
* Fix the unit testMartin Robinson2023-06-031-39/+45
| | | | These were broken for various issues.
* Do not hoist floated fragmentsMartin Robinson2023-06-031-10/+11
| | | | | | | | | | | | | | | | | | | | | Instead of hoisting floated fragments to be siblings of the fragment created by their containing block formatting context, keep them in "normal" fragment tree position and adjust their positioning to be relative to the containing block. This means that float fragments follow the existing invariants of the fragment tree and properly handle hit testing, painting order, and relative positioning. The tradeoff here is more complexity tracking the containing block offsets from the block formatting context (including handling collapsed margins), but less complexity dealing with hoisting / shared ownership in addition to the correctness benefits. Some tests are failing now because this change revealed some additional shortcomings with clearing block formatting context content size past the end of their contained floats. This will be fixed in a followup change. Co-authored-by: Oriol Brufau <obrufau@igalia.com>
* Place floats in layout 2020, but don't flow text around the floats yet.Patrick Walton2023-06-031-24/+30
| | | | | | | | | | | | | | | This commit puts floats behind the `layout.floats.enabled` pref, because of the following issues and unimplemented features: * Inline formatting contexts don't take floats into account, so text doesn't flow around the floats yet. * Non-floated block formatting contexts don't take floats into account, so BFCs can overlap floats. * Block formatting contexts that contain floats don't expand vertically to contain all the floats. That is, floats can stick out the bottom of BFCs, contra spec.
* Use the size of the containing block, not the size of the block formattingPatrick Walton2020-07-221-53/+64
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | context, to place floats in layout 2020. The containing block for a float is not necessarily the same as the block formatting context the float is in per CSS 2.1 [1]: "For other elements, if the element’s position is relative or static, the containing block is formed by the content edge of the nearest block container ancestor box." This shows up in the simplest case: <html> <body> <div style="float: left">Hello</div> </body> </html> In this case, the `<html>` element is the block formatting context with inline size equal to the width of the window, but the `<body>` element with nonzero inline margins is the containing block for the float. The float placement must respect the content box of the `<body>` element (i.e. floats must not overlap the `<body>` element's margins), not that of the `<html>` element. Because a single block formatting context may contain floats with different containing blocks, the left and right "walls" of that containing block become properties of individual floats at the time of placement, not properties of the float context itself. Additionally, this commit generalizes the float placement logic a bit to allow the placement of arbitrary objects, not just floats. This is intended to support inline layout and block formatting context placement. This commit updates the `FloatContext` and associated tests only and doesn't actually wire the context up to the rest of layout, so floats in pages still aren't actually laid out. [1]: https://drafts.csswg.org/css2/#containing-block-details
* Add an implementation of the core float and clear placement logic in layoutPatrick Walton2020-07-201-0/+823
2020, not yet wired to the rest of layout. This commit implements an object that handles the 10 rules in CSS 2.1: https://www.w3.org/TR/CSS2/visuren.html#float-position The implementation strategy is that of a persistent balanced binary search tree of float bands. Binary search trees are commonly used for implementing float positioning; e.g. by WebKit. Persistence enables each object that interacts with floats to efficiently contain a snapshot of the float list at the time that object was laid out. That way, incremental layout can invalidate and start reflow at any point in a containing block. This commit features extensive use of [QuickCheck](https://github.com/BurntSushi/quickcheck) to ensure that the rules of the CSS specification are followed. Because this is not yet connected to layout, floats will not actually be laid out in Web pages yet. Note that unit tests as set up in Servo currently require types that they access to be public. Therefore, some internal layout 2020 types that were previously private have been made public. This is somewhat unfortunate. Part of #25167.