4

The CSS dynamic viewport units svh, dvh & lvh are calculated based on collapsing browser chrome metrics (details here). Orion does not correctly calculate these values, instead calculating all three with the same value.

The three units should use the same values as Safari in all four situations:

  1. Before scrolling with the toolbars fully expanded
  2. While scrolling as the toolbars gradually collapse
  3. After scrolling with the toolbars now collapsed
  4. After manually collapsing the toolbars via the menu

The following test document demonstrates the issues:

<!DOCTYPE html>
<html>
<head>
  <meta charset="utf-8" />
  <meta name="viewport" content="width=device-width,initial-scale=1,shrink-to-fit=no" />
  <style>html,body{margin:0;padding:0}</style>
</head>
<body>
  <div style="display:flex;">
    <div style="height:100svh;flex:1;background:#dff;">100svh</div>
    <div style="height:100dvh;flex:1;background:#fdf;">100dvh</div>
    <div style="height:100lvh;flex:1;background:#ffd;">100lvh</div>
  </div>
  <div style="height:1000px;"></div>
</body>
</html>

And here are screen recordings comparing both browsers (of a slightly modified document to make it very clear where the differences are):

Orion:

Safari:

(This is related to https://orionfeedback.org/d/6111-hide-toolbar-on-scroll-recalculates-viewport-height but that is specific to how Orion causes a page re-render when crossing the magic scroll position Orion internally considers "toolbars collapsed"; this is about adherence to the CSS spec.)

1.3.7 (15) (WebKit 8617.2.4.10.8)

17

  • Vlad replied to this.

    adamaveray On iOS Orion uses exactly same WebKit as Safari and does not recalculate anything (WebKit does). Having said that cna you add Firefox and Chrome to the testing mix, very curious about what happens?

        Vlad I don't believe it's a Webkit issue – I think the issue is Orion is not informing Webkit of the correct viewport insets. If Orion calls setMinimumViewportInset with the correct minimum & maximum values on its WKWebView that should this issue.

        The method's description seems to confirms that:

        For apps with size-changing UI around the WKWebView, specify minimumViewportInset and maximumViewportInset to supply webpages with the appropriate value for CSS "large viewport" lv* units and CSS "small viewport" sv* units respectively. Set minimumViewportInset to the smallest inset a webpage may experience in your app's maximally collapsed UI configuration. Set maximumViewportInset to the largest inset a webpage may experience in your app's maximally expanded UI configuration.

            10 days later
            No one is typing