Open Bug 1508396 Opened 2 years ago Updated 2 months ago

Flexbox size table: Fix rounding error that results in value of "1e-9px"


(DevTools :: Inspector, enhancement, P2)



(Not tracked)


(Reporter: victoria, Unassigned)


(Blocks 1 open bug)



(1 file, 1 obsolete file)

In , if you inspect the element named id="search", the Flex Item pane shows a basis-size of "1e-9px." In the CSS it says it should be 0.000000001px. Maybe rounding to 0 (or we can be extra careful by saying ~0) would be good.
Blocks: 1478396
Assignee: nobody → mtigley
Attached image example.png
I'm unable to replicate this. I've inspected the element with id="search" but it's showing a basis size of 0 for me. I attached a screenshot of what I'm seeing.
Flags: needinfo?(victoria)
Priority: -- → P2
Oh, I see. I just looked at this in the latest nightly with the multi-colored headers, and there's no longer a "(basis-size:...)" subtitle in the Content Size section (which had the error), it just has the main "Content Size" header now. 

This might mean I have a separate bug to file, because I think "basis-size" info should be appearing here :D 

I'll follow up in
Flags: needinfo?(victoria)
Blocks: dt-flexbox
No longer blocks: 1478396

This URL functions as a reduced testcase:

data:text/html,<div style="flex-basis:0.000000001px"><div>

Unassigning myself since I'm not actively working on this.

Assignee: mtigley → nobody

Test with this URL:

data:text/html,<body style="display:flex;"><div style="flex-basis:0.000000001px"><div>

  • Inspect the <body> element
  • Switch to the Layout sidebar tab
  • Click on the div Flex Item

Both InspectorUtils.getCSSStyleRules() and return authored values with numbers in exponential notation past a certain value.

To convert back to decimal notation, there isn't a built-in JS APIs. The problem is quite complex to solve right:

The fact that we're getting authored values (including CSS unit type) adds to the complexity.

If we're not striving for comprehensive coverage of all possible exponential format variations (I'd hypothesize it's more common to have very large decimal precision, than integers in exponential notation), one naive way to approach this issue is as follows:

  • Use parseFloat to separate the number from the unit:
num = parseFloat("1e-9px") // => 1e-9
  • Stringify that and use it to isolate the unit type:
unit = "1e-9px".replace(num.toString(),""); // => "px"
  • Guard that we haven't parsed bogus stuff:
if ("1e-9px" !== `${num}${unit}`) return;
  • Naively infer the precision from the number; regular expressions, I know :(
precision = num.toString().match(/\d+$/) // => Array["9"]
precision = precision && parseInt(precision[0]) // => 9
  • Check if we have a precision (it may be null if no regex match was found):
if (!precision) return;
  • Convert from exponential to decimal notation with the precision we found:
decimal = num.toFixed(precision);
  • Append the unit and call it a day:
str = `${decimal}${unit}` // => "0.000000001px"

Whether all this is warranted for the accuracy of the display of an authored value in an edge case, I don't know.
But it's one naive way of approaching it without tripping on many of the common use cases like auto, 0, --var-with-e-in-name or 3em.

So it seems we write in exponential notation past 6 numbers, looking at the implementation for that.

Assignee: nobody → mtigley
Assignee: mtigley → nobody
Attachment #9028431 - Attachment is obsolete: true
You need to log in before you can comment on or make changes to this bug.