Bug 47618 – offsetHeight and offsetWidth of inline box wrapping a block box is 0

• Status: REOPENED
• Component: Layout and Rendering

Created attachment 70653 [details]
Simplest repro case

offsetHeight and offsetWidth are always reported as 0 for <ins> elements with text content enclosed in some other element.

The <ins> element still renders properly.

See simple-test-ins.html for simplest case that reproduces.

NOTE: Tested same case with <del> and it is NOT affected by this bug.

Noticed on WebKit 534.7 from a Linux Google Chrome beta, and also reproduced on OSX Safari 5.0 (5533.16).

[Ahmad Saleem]

I am able to reproduce this bug in Safari 15.6 on macOS 12.5 based on attached test cases and it shows following values across all browsers:

*** Safari 15.6 on macOS 12.5 ***

This insertion's content is wrapped in a <p>:

offsetHeight of ins with p-wrapped content: 0
offsetWidth of ins with p-wrapped content: 0

*** Chrome Canary 106 ***

offsetHeight of ins with p-wrapped content: 19
offsetWidth of ins with p-wrapped content: 948

*** Firefox Nightly 105 ***

offsetHeight of ins with p-wrapped content: 19
offsetWidth of ins with p-wrapped content: 966

Just wanted to share updated test results. Thanks!

[Anne van Kesteren]

It seems it's now consistent across ins/del/span at least.

[Anne van Kesteren]

I briefly looked into this.

RenderInline uses linesBoundingBox() for offset size calculations.

However, for <span><div>test</div></span> the span is not considered to have hasContent() so LineLayout::enclosingBorderBoxRectFor() returns a 0-rect. If I remove the hasContent() check it returns what appears to be the correct height, but the width is still 0. And who knows what side effects removing the hasContent() check might have.

As such this seems like something best tackled by the layout team.

[zalan]

(In reply to Anne van Kesteren from comment #3)
> I briefly looked into this.
> 
> RenderInline uses linesBoundingBox() for offset size calculations.
> 
> However, for <span><div>test</div></span> the span is not considered to have
> hasContent() so LineLayout::enclosingBorderBoxRectFor() returns a 0-rect. If
> I remove the hasContent() check it returns what appears to be the correct
> height, but the width is still 0. And who knows what side effects removing
> the hasContent() check might have.
> 
> As such this seems like something best tackled by the layout team.

<span><div>test</div></span> creates continuation which probably confuses enclosing logic somewhere.

[zalan]

Created attachment 469136 [details]
Patch

[zalan]

(In reply to Anne van Kesteren from comment #3)
> I briefly looked into this.
> 
> RenderInline uses linesBoundingBox() for offset size calculations.
> 
> However, for <span><div>test</div></span> the span is not considered to have
> hasContent() so LineLayout::enclosingBorderBoxRectFor() returns a 0-rect. If
> I remove the hasContent() check it returns what appears to be the correct
> height
It only returns the height of the pre block of the continuation which is not quite the height of the entire inline box.
e.g. in case of this
<span>pre block content<div>block</div>post block content</span>
the height would still be incorrect as both the block container (<div>) and "post block content" part would be ignored.

[zalan]

Created attachment 469137 [details]
Patch

[zalan]

Created attachment 469145 [details]
Patch

[zalan]

Created attachment 469146 [details]
Patch

[zalan]

Created attachment 469149 [details]
[fast-cq]Patch

[EWS]

Committed 272386@main (cfe7ff2ca750): <https://commits.webkit.org/272386@main>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 469149 [details].

[Radar WebKit Bug Importer]

<rdar://problem/119955792>

[WebKit Commit Bot]

Re-opened since this is blocked by bug 267596

[zalan]

*** Bug 277733 has been marked as a duplicate of this bug. ***

[Karl Dubost]

Also Bug 28810

[Brent Fulgham]

This is now tracked by:
<rdar://119955792>

[Karl Dubost]

See the testcase in https://bug-277733-attachments.webkit.org/attachment.cgi?id=472138
and the comment in https://bugs.webkit.org/show_bug.cgi?id=277733#c6
which shows the difference in between Safari on one side and Firefox/Chrome on the other.