LibWeb: Compute position of relative blocks before placing them

Turns out compute_position should be invoked before placing the element
in normal flow. Otherwise, the position isn't set on the first layout.
The effect was that the block would "jump" into place on a secondary
layout.

This is a follow-up to commit:
deda7c899525eeb989ab79d5d9e24d685569c84d

1 files changed, 3 insertions, 3 deletions

diff --git a/Userland/Libraries/LibWeb/Layout/BlockFormattingContext.cpp b/Userland/Libraries/LibWeb/Layout/BlockFormattingContext.cpp
index fe767a037b..195658fb77 100644
--- a/Userland/Libraries/LibWeb/Layout/BlockFormattingContext.cpp
+++ b/Userland/Libraries/LibWeb/Layout/BlockFormattingContext.cpp
@@ -409,14 +409,14 @@ void BlockFormattingContext::layout_block_level_children(Box& box, LayoutMode la
         layout_inside(child_box, layout_mode);
         compute_height(child_box);
 
+        if (child_box.computed_values().position() == CSS::Position::Relative)
+            compute_position(child_box);
+
         if (is<ReplacedBox>(child_box))
             place_block_level_replaced_element_in_normal_flow(child_box, box);
         else if (is<BlockBox>(child_box))
             place_block_level_non_replaced_element_in_normal_flow(child_box, box);
 
-        if (child_box.computed_values().position() == CSS::Position::Relative)
-            compute_position(child_box); // Note: Shifting position should occur after the above layout.
-
         // FIXME: This should be factored differently. It's uncool that we mutate the tree *during* layout!
         //        Instead, we should generate the marker box during the tree build.
         if (is<ListItemBox>(child_box))