62395 - window.screen properties do not change when screen depth and resolution (size) is changed

Status: NEW

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

Description

[Kevin McCluskey (gone)]

Hello, my name is Brad Maness and i use Mozilla, for mild web deveolpment, to
get ready for Javascript 1.5 and DOM compliance. Currently i'm using M18 [
Build2000101014 ] and i've run into some problems. I've created my own "property
viewer" for objects, to help me develop a few things, which currently [ though
probably not enough for public use ] works with M18, and this is what i found out.

I started with a 1024x768 resolution and ran the prop. viewer on the [
window.screen ] object and this is what i got :

- window.screen.top = 0
- window.screen.left = 0
- window.screen.width = 1024
- window.screen.height = 768
- window.screen.pixelDepth = 16
- window.screen.colorDepth = 16
- window.screen.availWidth = 1024
- window.screen.availHeight = 740
- window.screen.availLeft = 0
- window.screen.availTop = 0

Then, i minimized all windows, changed the screen resolution to 640x480, and ran
the prop view on the same obj. [ window.screen ]
and this is my output :

- window.screen.top = 0
- window.screen.left = 0
- window.screen.width = 1024
- window.screen.height = 768
- window.screen.pixelDepth = 16
- window.screen.colorDepth = 16
- window.screen.availWidth = 1024
- window.screen.availHeight = 740
- window.screen.availLeft = 0
- window.screen.availTop = 0

None of the vaules updated when i changed the screen resolution. Height, width,
available values, nothing. The only way i was able to get the correct values of
the screen resolution, was if i opened a new Mozilla window and loaded the prop
viewer again on that obj.

Comment 1

[Kevin McCluskey (gone)]

I confirmed that window.screen does not return the correct values in Netscape
6.0 on WINNT when the screen size/depth is changed while N6 is running.

Comment 2

[Kevin McCluskey (gone)]

The problem is the DeviceContext held by the presentation context is not updated
when the depth changes.

See ScreenImpl::GetDeviceContext

nsIDeviceContext* ScreenImpl::GetDeviceContext()
{

   if(!mDocShell)
      return nsnull;

	nsCOMPtr<nsIContentViewer> contentViewer;
   mDocShell->GetContentViewer(getter_AddRefs(contentViewer));

   nsCOMPtr<nsIDocumentViewer> docViewer(do_QueryInterface(contentViewer));
   if(!docViewer)
      return nsnull;

   nsCOMPtr<nsIPresContext> presContext;
   docViewer->GetPresContext(*getter_AddRefs(presContext));

	nsIDeviceContext* context = nsnull;
   if(presContext)
      presContext->GetDeviceContext(&context);

   return context;
}

Reassigning to myself

Comment 3

[Kevin McCluskey (gone)]

Setting milestone to mozilla1.0

Comment 4

[Kevin McCluskey (gone)]

Clearing milestone.

Comment 5

[Kevin McCluskey (gone)]

Setting milestone to future.

Comment 6

[Johnny Stenback (:jst)]

*** Bug 73961 has been marked as a duplicate of this bug. ***

Comment 7

[R.K.Aa.]

*** Bug 118340 has been marked as a duplicate of this bug. ***

Comment 8

[Kevin McCluskey (gone)]

Build moving all existing future-P3 bugs to future-P4.

Comment 9

[Tuukka Tolvanen (sp3000)]

*** Bug 135953 has been marked as a duplicate of this bug. ***

Comment 10

[Phil Schwartau]

*** Bug 133483 has been marked as a duplicate of this bug. ***

Comment 11

[R.K.Aa.]

*** Bug 148571 has been marked as a duplicate of this bug. ***

Comment 12

[R.K.Aa.]

*** Bug 136030 has been marked as a duplicate of this bug. ***

Comment 13

[R.K.Aa.]

*** Bug 150213 has been marked as a duplicate of this bug. ***

Comment 14

[R.K.Aa.]

*** Bug 154591 has been marked as a duplicate of this bug. ***

Comment 15

[R.K.Aa.]

*** Bug 180310 has been marked as a duplicate of this bug. ***

Comment 16

[Boris Zbarsky [:bzbarsky]]

*** Bug 182991 has been marked as a duplicate of this bug. ***

Comment 17

[Boris Zbarsky [:bzbarsky]]

*** Bug 184459 has been marked as a duplicate of this bug. ***

Comment 18

[Gérard Talbot]

Let's say I have a scr. res. of 1024x768 with the following values:

screen.top  = 0
screen.left = 0
screen.availTop = 270
screen.availLeft = 60

and then I change the scr. res. to 640x480. 
What are the current values with such scr. res.? What should be the current values?

I would be appreciative of an answer.

Comment 19

[Boris Zbarsky [:bzbarsky]]

*** Bug 186551 has been marked as a duplicate of this bug. ***

Comment 20

[R.K.Aa.]

*** Bug 155717 has been marked as a duplicate of this bug. ***

Comment 21

[Boris Zbarsky [:bzbarsky]]

*** Bug 195971 has been marked as a duplicate of this bug. ***

Comment 22

[Boris Zbarsky [:bzbarsky]]

*** Bug 211441 has been marked as a duplicate of this bug. ***

Comment 23

[how can i unsubscribe?]

I can remember that you have to restart MOZILLA - then it should work. It's 
faster to save the values on Mozilla start because normally the resolution does 
not change.

Comment 24

[Johnny Stenback (:jst)]

*** Bug 211441 has been marked as a duplicate of this bug. ***

Comment 25

[Johnny Stenback (:jst)]

*** Bug 211441 has been marked as a duplicate of this bug. ***

Comment 26

[Simon Paquet [:sipaq]]

*** Bug 101103 has been marked as a duplicate of this bug. ***

Comment 27

[Fabian Guisset]

*** Bug 152872 has been marked as a duplicate of this bug. ***

Comment 28

[Stefan Borggraefe]

*** Bug 230391 has been marked as a duplicate of this bug. ***

Comment 29

[José Jeria]

*** Bug 232871 has been marked as a duplicate of this bug. ***

Comment 30

[Henrik Skupin [:whimboo][⌚️UTC+2]]

*** Bug 233897 has been marked as a duplicate of this bug. ***

Comment 31

[Rene Pronk]

*** Bug 167263 has been marked as a duplicate of this bug. ***

Comment 32

[R.K.Aa.]

*** Bug 225908 has been marked as a duplicate of this bug. ***

Comment 33

[R.K.Aa.]

*** Bug 240044 has been marked as a duplicate of this bug. ***

Comment 34

[PikeUK]

*** Bug 249276 has been marked as a duplicate of this bug. ***

Comment 35

[R.K.Aa.]

related to bug 11709?

Comment 36

[Alexandre Gomes]

(In reply to comment #23)
> I can remember that you have to restart MOZILLA - then it should work. It's 
> faster to save the values on Mozilla start because normally the resolution does 
> not change.

Just dont forget I may be testing an webapplication that have some values in
session or something like that. That would require me to open and fill that
values again, and also redo to all the other open pages.

Comment 37

[Mike Connor [:mconnor]]

*** Bug 273120 has been marked as a duplicate of this bug. ***

Comment 38

[:Gavin Sharp [email: [e-mail]]]

*** Bug 273484 has been marked as a duplicate of this bug. ***

Comment 39

[:Gavin Sharp [email: [e-mail]]]

*** Bug 178497 has been marked as a duplicate of this bug. ***

Comment 40

[:Gavin Sharp [email: [e-mail]]]

*** Bug 169869 has been marked as a duplicate of this bug. ***

Comment 41

[:Gavin Sharp [email: [e-mail]]]

*** Bug 273538 has been marked as a duplicate of this bug. ***

Comment 42

[Asa Dotzler [:asa]]

*** Bug 267133 has been marked as a duplicate of this bug. ***

Comment 43

[James Ross]

Is catching WM_SETTINGCHANGE (not supported on NT 3.51) useful here?

Comment 44

[timeless]

sounds right. istr doing research into this, i wonder if i actually have it in a
tree somewhere, actually i think i do have a tree which does it halfway.

Comment 45

[[e-mail]]

Note that only on multiple-monitor systems are we apparently prepared to take
the perf hit of not caching the screen dimensions (in that case simply dragging
the window from one screen to the other will update the window.screen values).

Comment 46

[PikeUK]

*** Bug 282586 has been marked as a duplicate of this bug. ***

Comment 47

[Frank Wein [:mcsmurf]]

*** Bug 283326 has been marked as a duplicate of this bug. ***

Comment 48

[José Jeria]

*** Bug 290945 has been marked as a duplicate of this bug. ***

Comment 49

[:Gavin Sharp [email: [e-mail]]]

*** Bug 298401 has been marked as a duplicate of this bug. ***

Comment 50

[José Jeria]

*** Bug 315561 has been marked as a duplicate of this bug. ***

Comment 51

[Matthias Versen [:Matti]]

*** Bug 316359 has been marked as a duplicate of this bug. ***

Comment 52

[Matthias Versen [:Matti]]

*** Bug 321391 has been marked as a duplicate of this bug. ***

Comment 53

[zug_treno]

*** Bug 327414 has been marked as a duplicate of this bug. ***

Comment 54

[dolphinling]

*** Bug 270461 has been marked as a duplicate of this bug. ***

Comment 55

[zug_treno]

*** Bug 335004 has been marked as a duplicate of this bug. ***

Comment 56

[dolphinling]

*** Bug 337907 has been marked as a duplicate of this bug. ***

Comment 57

[Wayne Mery (:wsmwk)]

Timeless in comment #44:
> i think i do have a tree which does it halfway.

would this give someone a start at fixing?

any reason not to dup Bug 335776 to this? 

Comment 58

[Tim Stone]

(In reply to comment #57)

> any reason not to dup Bug 335776 to this? 

Related I think. My bug 152872 simulates this somewhat, but, not directly. 

Comment 60

[David Fraser]

(In reply to comment #45)
> Note that only on multiple-monitor systems are we apparently prepared to take
> the perf hit of not caching the screen dimensions (in that case simply dragging
> the window from one screen to the other will update the window.screen values).

On Linux (Ubuntu 8.04, Firefox 3), using xrandr to add another screen does not update window.screen properties. So the system can start out being a single-monitor one but change to be multi-monitor, and in this case we should throw out the cache.

See also bug 29100 which is triggered by this, and the related upstream Ubuntu bug at https://bugs.launchpad.net/ubuntu/+source/firefox-3.0/+bug/229298

Comment 62

[Frank]

Can someone from Mozilla state this is actually a bug? IE and Chrome handle this well.