Bug 277733 – offsetWidth of an inline element containing a block element is 0px

• Status: RESOLVED
• Resolution: DUPLICATE
• Component: Layout and Rendering

[Ahmad Saleem]

Created attachment 472068 [details]
Bug - Video Recording

Hi Team,

While looking through vbulletin website, I noticed bug in Safari:

*** Steps To Reproduce ***

1) Go to - https://forum.vbulletin.com

2) Look at banner (in yellow)

3) Click on 'SEE-MORE'

*** Actual Results ***

It is expanded differently compared to other browsers

*** Expected Results ***

Behave like other browsers

____

Thanks!

[Radar WebKit Bug Importer]

<rdar://problem/133379227>

[Simon Fraser (smfr)]

Looks like a flex layout thing. The text is wrapped differently.

[Karl Dubost]

Created attachment 472130 [details]
rendering in safari

This is interesting because the content is wrapped in a box which is intentionally set as 0px, width and height. 

span (display: inline-block / width:0 / height: 0)
  p 

In the screenshot I specified an outline on the p so we can see it. it is a box of 
0 x 486px.

The rendering is the same in the 3 browsers with this kind of markup. 

```
    <span style="
        width: 0px; 
        height: 0px; 
        display: inline-block; 
        opacity: 1;">
        <p style="outline: 1px solid red;">Welcome to the vBulletin support forums! In our community forums you can
            receive professional support and assistance with any issues you might have with your vBulletin Products.</p>

    </span>
```

So maybe this is more about JS setting the style attribute. Let's see.

[Karl Dubost]

Created attachment 472132 [details]
developer tools in safari, firefox

So we can see in the developer tools, that

1. There are two repeated almost identical blocks of content.
   - one with display: none
   - the other being displayed with the see-more
2. The display: none content has at first load.
   <span class="js-notice-text" style="display: none;"> … </span>

When I click on see more, it calls in JQuery 3.7.1

        show: function() {
            return re(this, !0)
        },


This call to show has been done by 

```
    function q(a, b) {
        f("Expand Trigger: " + a.html());
        var e = a.parent(),
            c = e.prev();
        c.show();

// This is happening here
        var d = c.width(),
            k = c.height();

// Here the dimensions are being set with the wrong value for Safari. 
        c.width(e.width() + "px").height(e.height() + "px");


        e.hide();
        c.animate({
            height: k,
            width: d,
            opacity: 1
        }, b.moreSpeed, b.easing, function() {
            "function" == typeof b.onExpand && b.onExpand.apply(a, [c]);
            "function" == typeof b.onToggle && b.onToggle.apply(a, [c, e, !1])
        });
        e.attr("id") &&
        (d = e.attr("id"), e.attr("id", "condensed_" + d), c.attr("id", d))
    }
```

`c` at this stage is the full span html content. 

On Safari
`c.width()` and `c.height()` are 0px

But on Firefox

```
c.width()
479
c.height()
227 
```

width() and height() are functions of jQuery.


I wonder if Safari and Firefox/Chrome computes differently the size of a `display: none` element. 

This doesn't seem to be about user agent sniffing inside JQuery, because changing the UA doesn't affect the result.

[Karl Dubost]

Created attachment 472137 [details]
devtools getClientRects differences

```
    function ot(e, t, n) {
      var r = Xe(e),
      i = (!le.boxSizingReliable() || n) &&
      'border-box' === ce.css(e, 'boxSizing', !1, r),
      o = i,
      a = Ge(e, t, r),
      s = 'offset' + t[0].toUpperCase() + t.slice(1);
      if (_e.test(a)) {
        if (!n) return a;
        a = 'auto'
      }
      return (
        !le.boxSizingReliable() &&
        i ||
        !le.reliableTrDimensions() &&
        fe(e, 'tr') ||
        'auto' === a ||
        !parseFloat(a) &&
        'inline' === ce.css(e, 'display', !1, r)
      ) &&
      e.getClientRects().length &&
      (
        i = 'border-box' === ce.css(e, 'boxSizing', !1, r),
        (o = s in e) &&
        (a = e[s])
      ),
      (a = parseFloat(a) || 0) + it(e, t, n || (i ? 'border' : 'content'), o, r, a) + 'px'
    }
```


There is a point in the code when we hit e.getClientRects(), we can already see differences. 

When Firefox returns a list of 12 DOMRect
Safari returns a list of 3. 

e is the HTML span element. 
and in both cases e.childNodes returns a list of 10 nodes.

but then the value is extracted from

```
a = e[s]
```

where `e` is still the span
and `s` is 'offsetWidth'

in Firefox and for the width of my windows:
a = 479

in Safari
a = 0

So then later it goes specifying the width to be 0 on the block with a style attribute, hence the difference of behavior in between Firefox/Chrome and Safari. 


So two possible sources of bugs:
* getClientRects()
* offsetWidth

Let's create a test case

[Karl Dubost]

Created attachment 472138 [details]
reduced-testcase

Compute the offsetWidth of an inline element containing a block element.

span offsetWidth: 

Safari:    0px
Firefox: 200px
Chrome:  200px

data for:
Safari Technology Preview  200           20620.1.1
Firefox Nightly            131.0a1       13124.8.6
Google Chrome Canary       129.0.6654.0  6654.0

[Karl Dubost]

offsetWidth is used in a number of places in WPT (604 files), but not sure this specific behavior is tested.
https://github.com/search?q=repo%3Aweb-platform-tests%2Fwpt%20offsetWidth&type=code

It would be worth to check if there are previous bug reports about it.

[zalan]

This is a continuation bug (block level element inside an inline box).

[Karl Dubost]

https://drafts.csswg.org/cssom-view/#dom-htmlelement-offsetwidth

The offsetWidth attribute must return the result of running these steps:

    1. If the element does not have any associated box return zero and terminate this algorithm.

    2. Return the unscaled width of the axis-aligned bounding box of the border boxes of all fragments generated by the element’s principal box, ignoring any transforms that apply to the element and its ancestors.

    If the element’s principal box is an inline-level box which was "split" by a block-level descendant, also include fragments generated by the block-level descendants, unless they are zero width or height.

[zalan]

*** This bug has been marked as a duplicate of bug 47618 ***