Closed Bug 1035474 Opened 10 years ago Closed 10 years ago

innerWidth/innerHeight should be double, not int

Categories

(Core :: DOM: Core & HTML, defect, P1)

All
Gonk (Firefox OS)
defect

Tracking

()

RESOLVED WONTFIX

People

(Reporter: BenWa, Unassigned)

References

Details

Attachments

(1 file)

This was discussed briefly in bug 918345. They filed the followings bugs to track the issue: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24159 https://www.w3.org/Bugs/Public/show_bug.cgi?id=24160 This problem is worse with factional content scale of 1.5 like seen on the flame device because window.innerHeight returns the wrong value. See bug 1033538 Comment 15. This leads to code that was previously correct to calculate a fractional device pixel height (and cause performance implications) where the code is otherwise correct except for the unexpected rounding of innerWidth/innerHeight.
We probably want to convert more then just innerWidth/innerHeight. Can someone advice what the right thing to do here is?
Flags: needinfo?(peterv)
Flags: needinfo?(bzbarsky)
This is risky. People have run into compat problems changing properties from int to float before. A less risky fix would be to switch Gaia to compute the viewport height using document.getBoxQuads().bounds.width/height.
> get height() { > return window.innerHeight - > (this.keyboardEnabled ? KeyboardManager.getHeight() : 0) - > StatusBar.height - > softwareButtonManager.height; > }, In this calculation it's probably worth verifying that these getHeight() and height properties all support subpixel precision. That means they should use getBoxQuads or getClientRect/getBoundingClientRect instead of *Width or *Height attributes.
The right thing to do here is to introduce a new API as needed instead of incompatibly changing an existing one. See bug 825607 comment 5 and bug 825607 comment 18 and <https://www.w3.org/Bugs/Public/show_bug.cgi?id=24159#c2>, as well as bug 1024493 comment 9 (which, afaict, says that there is already an API that does what you want here, by the way).
Flags: needinfo?(peterv)
Flags: needinfo?(bzbarsky)
Nominating this one for 2.0, as we want to pick the less risky/contentious alternative between this and bug 1033538.
blocking-b2g: --- → 2.0?
Do we need a new API or are roc' suggestions enough? If they are then I'm happy to mark this bug as WONTFIX. Maybe we should morph this into cleaning up Window.webidl and perhaps having a comment explaining our decission. Assuming it's final.
Doesn't sounds like we need this for 2.0 then - but let's answer the question from comment 6.
blocking-b2g: 2.0? → ---
(In reply to Benoit Girard (:BenWa) from comment #6) > Maybe we should morph this into cleaning up Window.webidl To clarify there is a whole bunch of float signatures comment out in there.
(In reply to Benoit Girard (:BenWa) from comment #8) > To clarify there is a whole bunch of float signatures comment out in there. The commented out signatures are the ones from the spec. As long as the spec hasn't been changed I'd prefer to leave them there.
Alright then, I guess https://www.w3.org/Bugs/Public/show_bug.cgi?id=24159 is tracking the state of the spec. I don't think there's anything to do here. Marking as WONTFIX because of web compatibility.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: