1838524 - Unable to scroll the content in Firefox for this testcase, but can in Chrome and Safari

Status: VERIFIED DUPLICATE of bug 1890762

(Web Compatibility :: Site Reports, defect, P2)

Description

[Thomas Wisniewski [:twisniewski]]

Attachment: testcase.html

In the attached test-case, Firefox locks the scroll-area unless I drop the display:inline-table or change position:fixed to position:absolute.

This is breaking users' ability to scroll the filter menu's contents on www.urvaerket.dk, as reported on webcompat.com.

In addition, Firefox does not leave a 120px-height gap at the bottom of the screen, though I'm not sure if that's related.

Comment 1

[Hiroyuki Ikezoe (:hiro)]

(In reply to Thomas Wisniewski [:twisniewski] from comment #0)

Created attachment 9339177 [details]
testcase.html

In the attached test-case, Firefox locks the scroll-area unless I drop the display:inline-table or change position:fixed to position:absolute.

In the case of position:absolute the layout result is still wrong. The scroll frame you saw is the root scroll container, not the inner one.

This is breaking users' ability to scroll the filter menu's contents on www.urvaerket.dk, as reported on webcompat.com.

In addition, Firefox does not leave a 120px-height gap at the bottom of the screen, though I'm not sure if that's related.

I believe that's the root cause of this bug. The inner scroll container (filter .filter-content) height is too large, it's 48000px on my environment.

Moving into Layout:Tables.

Comment 2

[Daniel Holbert [:dholbert]]

(In reply to Hiroyuki Ikezoe (:hiro) from comment #1)

I believe that's the root cause of this bug. The inner scroll container (filter .filter-content) height is too large, it's 48000px on my environment.

Indeed. That element has a percent height, and it looks like we're declining to resolve that percent height (against the height of the table).

I've got a further-reduced testcase that demonstrates this a bit better; posting shortly.

Comment 3

[Daniel Holbert [:dholbert]]

Attachment: testcase 2

Here's a reduced testcase. The orange-bordered area has height:50%, which does indeed make it fill half of the table's height in Chrome, but doesn't resolve (and just falls back to content-height) in Firefox.

Comment 4

[Daniel Holbert [:dholbert]]

Attachment: testcase 3 (using table element)

Here's a testcase using an actual table element (with the various table-parts explicitly filled in as well).

I've added a teal border around the table-cell. This shows that we do size the table-cell to fill the table, but we apparently don't treat that as a definite height for resolving percentages against.

Comment 5

[Daniel Holbert [:dholbert]]

Two bug references:
(1) The underlying issue here is bug 1598458.
(2) We have bug 1890762 filed as a webcompat site-report for this same site.

So we've got (a) the underlying platform bug and (b) the fact that this urvaerket.dk site is affected (albeit for a different piece of UI on this site) tracked in their own bugs.

We should probably just dupe this bug to one or the other of those. For now I'll dupe this to the site-report since that's essentially how this was originally filed (though we didn't have a category for webcompat site-report at the time.)

Comment 6

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] from comment #5)

the fact that this urvaerket.dk site is affected (albeit for a different piece of UI on this site) [is] tracked in [another] bug

(Never mind about "different piece of UI" -- I didn't skim closely enough here. Turns out this bug was about the same piece of UI as in bug 1890762 after all. The filter .filter-content stuff identified in comment 1 here is the same piece of the page discussed in bug 1890762 comment 1.)

So: verified-dupe. \o/