Closed Bug 1236262 Opened 10 years ago Closed 9 years ago

Responsive View width precision awfully high; either round to a full pixel or tell us

Categories

(DevTools :: Responsive Design Mode, defect)

43 Branch
Other
Linux
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
Firefox 52

People

(Reporter: Nick_Levinson, Unassigned)

References

Details

I found the following width when I thought I had 495px: 495.0000000000001 Another: 364.33333333333303 (decimals not all threes, thus not due to a child's simple fraction) This varies with slight taps or maybe just fingertip wiggles on my touchpad. It is obviously nearly impossible to wiggle my finger to make it come to the exact whole-pixel value, even more so to do it every time. Steps to reproduce: 1. Display a Web page. 2. Tools > Web Developer > Responsive Design View. 3. In the menu below the address bar, select a size that is not a user preset. To confirm this, after you select a size, reopen the menu and the last menu item should read "Add Preset". 4. Drag the right edge in or out slightly, so that it does not correspond to any width in the menu (in one trial, I control-dragged to "488", or "488x560", according to the menu). 5. Reopen that menu and select Add Preset. 6. Result: the Responsive Design View dialog says, as in one case, "Give a name to the 488.9999999999999x560 preset". This is a problem with responsive design, because I (and this appears to be normal) design for a whole number of pixels, such as with one at-media rule having a max-width of 495px and the next @media rule having a min-width of 496px. I don't expect values in between and have no information on how browsers would respond to an in-between value. Good software testing practice includes testing at the edges of a programmed condition, so I should test at exactly 495 and 496. This is impossible if Responsive View is applying fractional values with notice being concealed by the responsive view menu. When I do edge testing, I intermittently get anomalous results, because a display is appropriate for the adjacent at-media rule, not the one for the viewport width I've set in the browser for the test. I now believe that the anomalies are due to a fractional value placing Firefox's width between two at-media rules. I have seen it suggested that the width values for two at-media rules should be equal (e.g., one with max-width at 496px and another with min-width also at 496px), but that should confuse a user agent (browser) and give me unpredictable results, so I don't do that. I don't think specifying, say, max-width at "<496px", while mathematically accurate, would be widely supported and it might give wildly unexpected results (e.g., as if no value was specified), so I don't do that. I tested the same thing for height, but the dialog showed only rounded-to-one-pixel values. That means either that a height snaps to the nearest whole pixel or the dialog doesn't reveal a fraction that is present. While I don't set at-media rules for height, perhaps some designers need to. If the same problem applies to height, it probably needs the same fix that width needs. Therefore, in FF, responsive view normally should snap to the numbers selected. Fractional values should always be explicit and available only by selection. Possibly relevant is bug 1136829.
This bug appears to be fixed in the new RDM UI shipping in Firefox 52. I did not see a way to trigger fractional sizes in the new UI. Please reopen if it still applies!
Status: UNCONFIRMED → RESOLVED
Closed: 9 years ago
Depends on: enable-rdm
Resolution: --- → FIXED
Target Milestone: --- → Firefox 52
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.