autostar-novoross.ru - Map is not fully displayed

[webcompat-bot]

URL: https://autostar-novoross.ru/

Browser / Version: Firefox 90.0
Operating System: Windows 10
Tested Another Browser: Yes Chrome

Problem type: Design is broken
Description: Items not fully visible
Steps to Reproduce:
Maps both on desktop and mobile are not working correctly in Firefox - are cut up to 80 percent.

In mobile version Firefox text is overlapping on another block. In other browsers everything is ok

View the screenshot

Browser Configuration

• None

From webcompat.com with ❤️

[softvision-oana-arbuzov]

Thanks for the report, I was able to reproduce the issue. Scrolling down the page until reaching the end, the second map is cropped.

Note: The issue is not reproducible on Chrome.

Tested with:
Browser / Version: Firefox Nightly 92.0a1 (2021-07-18)
Operating System: Windows 10 Pro

Moving to Needsdiagnosis for further investigation.

[wisniewskit]

The map is in an iframe which is given the HTML attribute height="100%". But its parent element has no height defined:

<div class="tn-atom tn-atom__html" style="height: 100%;">
  <iframe src="https://www.google.com/maps/embed?..." allowfullscreen="" loading="lazy" width="100%" height="100%"></iframe>
</div>

If I give that div a height of 100%, then Firefox renders the same way as Chrome. Also, if I change the display:table on the parent of the div, then Chrome renders the same way Firefox does.

Indeed, Chrome is treating the div as though it has display:table-cell, because of that display:table on its parent. Firefox seems to be falling back on display:block, according to the devtools, but it doesn't matter if I explicitly set display:table-cell (or table-row) on the element; Firefox needs height:100% set on it, or it treats the height as auto.

This strikes me as a known interop issue (or perhaps even two issues, one with height:100% differences, and one with how implied table cells are handled). @dholbert, do you recall which of our Bugzilla bugs this should fall under? I've lost track.

[dholbert]

Indeed, Chrome is treating the div as though it has display:table-cell, because of that display:table on its parent. Firefox seems to be falling back on display:block, according to the devtools

It's display:table-cell for me (in Firefox for Desktop) -- it's explicitly set to that, in a rule with selector .t396 .tn-atom {, and that shows up as the computed display in the computed style pane for me. So I don't think that computed display is actually a real point of difference here. (If you're seeing something different/weird there, let me know. :))

Firefox needs height:100% set on it, or it treats the height as auto.

This strikes me as a known interop issue [...] with height:100% differences

Yeah, this is https://bugzilla.mozilla.org/show_bug.cgi?id=1598458

[wisniewskit]

I think we'll just need to apply a site patch here, until the interop issue in bug 1598458 is addressed. Perhaps we'll have some luck with site outreach as well.

[webcompat-bot]

Generate outreach template

[wisniewskit]

Moved to: https://bugzilla.mozilla.org/show_bug.cgi?id=1891078