Open Bug 1327082 Opened 6 years ago Updated 6 months ago

Inspector highlighter tooltip reports wrong width of element (0.0001 difference)

Categories

(DevTools :: Inspector, defect, P3)

Product:
DevTools
Component:
Inspector
Type:
defect

Tracking

(Not tracked)

People

(Reporter: arni2033, Unassigned)

References

(Blocks 1 open bug)

Details

>>>   My Info:   Win7_64, Nightly 52, 32bit, ID 20161001030430 (2016-10-01)
STR_1:
1. Open url [1]
2. Open devtools, select <div> element -> inspector -> computed view
3. Hover mouse over <div> element in markup

AR:  Step 2 - box model reports width 100px.  Step 3 - element highlighter tooltip reports 99.9999px
ER:  Devtools should display the same value in both cases. Preferably, 100px

> [1] data:text/html,<!DOCTYPE html><div style="width:100px; height:225px; margin-left:916.2px; background:gray;">
No longer blocks: 1277113
Component: Untriaged → Developer Tools: Animation Inspector
Component: Developer Tools: Animation Inspector → Developer Tools: Inspector
Inspector bug triage, filter on CLIMBING SHOES.
Priority: -- → P3
Some background on why we have this bug. 

# Highlighter implementation
The highlighter is generated by in devtools/server/actors/highlighters/box-model.js. It relies on the box quads to compute the width. It computes the width by looping on the quads and getting the extreme right and left coordinates and then substracting them. We have a floating point margin left, so I expect the difference between the two to have precision errors. But interestingly, even getting directly getBoxQuads()[0].bounds.width returns 99.99993896484375.

# Box model implementation
The box model panel is using getLayout from devtools/server/actors/styles.js, which relies on getBoundindClientRect and also does some rounding:
>     layout.width = parseFloat(clientRect.width.toPrecision(6));
>     layout.height = parseFloat(clientRect.height.toPrecision(6));

getBoundingClientRect().width returns 100 for the element of the test page so the rounding is unnecessary here. 

So we could simply apply a rounding in the highlighter implementation too. However, it might be worth checking why getBoxQuads returns a floating point width here. If this could be fixed, we could use the bounds width for single quad elements (would still have to use rounding for elements spanning over multiple quads).

# Note about toPrecision vs toFixed:
If we end up using rounding here, I feel like we should use toFixed rather than toPrecision here. For toPrecision(6) 1234567px will be approximated to 1234570px which is just wrong. parseFloat(number.toFixed(4)) would yield more consistent results regardless of how many digits preceed the floating point. Note that this should also be changed in the box model panel.
Product: Firefox → DevTools
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.