Shouldn't window.screen.width/height correspond to actual screen width/height?

Question

Toying around with the WebKit browser in the new Kindle 3G, I noticed that window.screen.width and window.screen.height don't reflect the actual screen dimensions. The physical screen (or rather, paper) dimensions are 800 x 600. I get:

• 800 x 506 in landscape mode
• 600 x 706 in portrait mode

But interestingly, both Chrome and Safari (which are also WebKit) running on my desktop report the actual screen resolution.

According to MDC, these properties are not part of any specification, so there's probably no strict definition of what width/height should report. But, shouldn't it be expected that they reflect the actual screen dimensions?

Sadducee

Answer 1

Update:

The issue we see in the emulator with window.screen.width is when we use screens which don't reflect the actual pixels of the device. So what you see on the screen is 320 and what the device has is 480 or whatever. I don't understand, though, why the value of screen width would give the emulator size on the screen and not the actual pixels.

This thing might be the same issue with the devices? If their density is higher at some sizes... for whatever the reason this could translate to some wrong screen width size?

Anyway, read below for my solution.

---

screen.availWidth does not work for me on certain screen sizes on the emulator.

Only thing is working for me now is:

window.innerWidth
window.innerHeight

Which will return the value of the Viewport. In my case I'm running an HTML5 app. This values will not update on zoom, apparently.

They have some issues with this sizes on Android's Webkit. You can see the devs from Android talking about it here. Probably fixed in Honeycomb.

Somebody claims it takes some sizes as if the soft keyboard would be present.

Photophore

Answer 2

It would seem that screen.availWidth and screen.width are both returning the availWidth all the time, on many mobile operating systems.

I was unable to find any documentation on this however I did tested Android 2.2 and got the screen size minus the top menu bar exactly no matter what a requested.

Hedrick

I have not tested this on anything other then webkit on mobile OS' however I have found multiple point of failure and some other oddities. The first oddity is that screen.height works on Linux and webkit (as well as it's prefork khtml) together. Yet on the kindle and Android it fails, both of which are running linux and webkit at their core. This leads be to start considering other possibilities like SquirrelFish being the distributor of the bad data. – Hedrick

Answer 3

I think WebKit can do nothing if it's getting wrong values from system. Sure these values should be represented by screen.availWidth and screen.availHeight, but I think this is related to event.screenX and event.screenY for mouse (pointer) positions.

Chaney

Interestingly, navigator.appVersion reports 5.0 (Linux; U; en-US) AppleWebKit/528.5 (KHTML, like Gecko, Safari/528.5 ) Version/4.0 Kindle/3.0 (screen 600x800; rotate) in both landscape and portrait modes. Even though the 600x800 bit is correct, I'm guessing that it's hard-coded and not read from the system. So, you're right, it's probably the system not properly(?) reporting the screen dimensions. – Sadducee

Answer 4

The difference are because the size of the Android status bar and or the bottom bar.

Wells