Open Bug 1518433 Opened 5 years ago Updated 2 years ago

Very high CSS <length> values may be misinterpreted due to NS_{UNCONSTRAINEDSIZE,INTRINSICSIZE,AUTOHEIGHT,AUTOOFFSET} being equal to nscoord_MAX

Categories

(Core :: Layout, defect, P3)

65 Branch
defect

Tracking

()

Tracking Status
firefox64 --- affected
firefox65 --- affected
firefox66 --- affected

People

(Reporter: andyearnshaw, Unassigned)

References

Details

(Keywords: parity-chrome)

Attachments

(1 file)

Attached file css-length-clamp.html

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36

Steps to reproduce:

  1. Create web page containing a solitary div with a height unsupported by Firefox (max is about 17187496px, but if you want to compare other browsers then you might want to double this value).
  2. Open the dev tools/element inspector and inspect the div
  3. Check both the computed height and offsetHeight

Actual results:

The element has a computed height of 0px

Expected results:

According to the spec,

In cases where the used length cannot be supported, user agents must approximate it in the actual value.

0 is not an approximation of whatever very large number you enter. Both Chrome and Safari clamp the height to the maximum permitted value. Not sure on IE/Edge's behaviour.

I checked Edge in SauceLabs, it clamps like Safari and Chrome.

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:66.0) Gecko/20100101 Firefox/66.0
Build ID: 20190114014511

I managed to reproduce this issue on macOS 10.13.6 with the latest Firefox Nightly version 66.0a1.

Status: UNCONFIRMED → NEW
Component: Untriaged → CSS Parsing and Computation
Ever confirmed: true
OS: Unspecified → All
Product: Firefox → Core
Hardware: Unspecified → All
Flags: webcompat?
Keywords: parity-chrome
Priority: -- → P3
See Also: → 1527883

I took a quick look, we're not clamping to zero, the style system properly propagates the number and layout clamps it.

We're treating the height as auto instead (you can see this easily if you add some text to the <div>). This is because we're using the maximum value as auto height:

https://searchfox.org/mozilla-central/rev/8ff2cd0a27e3764d9540abdc5a66b2fb1e4e9644/layout/base/LayoutConstants.h#22

Summary: Very high CSS <length> values are not approximated/clamped → Very high CSS <length> values may be misinterpreted due to NS_{UNCONSTRAINEDSIZE,INTRINSICSIZE,AUTOHEIGHT,AUTOOFFSET not approximated/clamped
Component: CSS Parsing and Computation → Layout
Summary: Very high CSS <length> values may be misinterpreted due to NS_{UNCONSTRAINEDSIZE,INTRINSICSIZE,AUTOHEIGHT,AUTOOFFSET not approximated/clamped → Very high CSS <length> values may be misinterpreted due to NS_{UNCONSTRAINEDSIZE,INTRINSICSIZE,AUTOHEIGHT,AUTOOFFSET} being equal to nscoord_MAX

I'd note that margins use a different constant just to get around this problem:

https://searchfox.org/mozilla-central/rev/8ff2cd0a27e3764d9540abdc5a66b2fb1e4e9644/layout/base/LayoutConstants.h#26

So not sure whether this behavior is intentional or not.

See Also: → 1223282

Well that clearly needs a bit more debugging :)

Assignee: emilio → nobody

See bug 1547409. Moving webcompat whiteboard tags to project flags.

Webcompat Priority: --- → ?
Webcompat Priority: ? → revisit
Severity: normal → S3
Webcompat Priority: revisit → ---
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: