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

NEW
Unassigned

Status

()

defect
P4
normal
19 years ago
2 years ago

People

(Reporter: kmcclusk, Unassigned)

Tracking

(Blocks 1 bug, {dom0})

Trunk
Future
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Reporter

Description

19 years ago
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.
Reporter

Comment 1

19 years ago
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.
Reporter

Comment 2

19 years ago
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
Assignee: jst → kmcclusk
Reporter

Updated

19 years ago
Status: NEW → ASSIGNED
Keywords: dom0
Reporter

Comment 3

19 years ago
Setting milestone to mozilla1.0
Target Milestone: --- → mozilla1.0
Reporter

Comment 4

19 years ago
Clearing milestone.
Target Milestone: mozilla1.0 → ---
Reporter

Updated

19 years ago
Target Milestone: --- → Future
Reporter

Comment 5

19 years ago
Setting milestone to future.
*** Bug 73961 has been marked as a duplicate of this bug. ***

Comment 7

18 years ago
*** Bug 118340 has been marked as a duplicate of this bug. ***
Reporter

Comment 8

18 years ago
Build moving all existing future-P3 bugs to future-P4.
Priority: P3 → P4
*** Bug 135953 has been marked as a duplicate of this bug. ***

Comment 10

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

Comment 11

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

Comment 12

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

Comment 13

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

Comment 14

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

Comment 15

17 years ago
*** Bug 180310 has been marked as a duplicate of this bug. ***
*** Bug 182991 has been marked as a duplicate of this bug. ***
*** Bug 184459 has been marked as a duplicate of this bug. ***

Comment 18

17 years ago
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.
*** Bug 186551 has been marked as a duplicate of this bug. ***

Comment 20

17 years ago
*** Bug 155717 has been marked as a duplicate of this bug. ***
*** Bug 195971 has been marked as a duplicate of this bug. ***
*** Bug 211441 has been marked as a duplicate of this bug. ***
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.
*** Bug 211441 has been marked as a duplicate of this bug. ***
*** Bug 211441 has been marked as a duplicate of this bug. ***
OS: Windows NT → All
Hardware: PC → All
*** Bug 101103 has been marked as a duplicate of this bug. ***

Comment 27

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

Comment 28

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

Comment 29

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

Updated

16 years ago
Assignee: kmcclusk → general
Status: ASSIGNED → NEW
QA Contact: desale → ian
*** Bug 233897 has been marked as a duplicate of this bug. ***

Comment 31

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

Comment 32

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

Comment 33

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

Comment 34

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

Comment 35

15 years ago
related to bug 11709?

Comment 36

15 years ago
(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.
*** Bug 273120 has been marked as a duplicate of this bug. ***
*** Bug 273484 has been marked as a duplicate of this bug. ***
*** Bug 178497 has been marked as a duplicate of this bug. ***
*** Bug 169869 has been marked as a duplicate of this bug. ***
*** Bug 273538 has been marked as a duplicate of this bug. ***
*** Bug 267133 has been marked as a duplicate of this bug. ***

Comment 43

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

Comment 44

15 years ago
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.
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

15 years ago
*** Bug 282586 has been marked as a duplicate of this bug. ***
*** Bug 283326 has been marked as a duplicate of this bug. ***

Comment 48

14 years ago
*** Bug 290945 has been marked as a duplicate of this bug. ***
Summary: window.screen properties do not change when screen depth and size is changed → window.screen properties do not change when screen depth and resolution (size) is changed
*** Bug 298401 has been marked as a duplicate of this bug. ***

Comment 50

14 years ago
*** Bug 315561 has been marked as a duplicate of this bug. ***
*** Bug 316359 has been marked as a duplicate of this bug. ***
*** Bug 321391 has been marked as a duplicate of this bug. ***

Comment 53

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

Comment 54

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

Comment 55

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

Comment 56

13 years ago
*** Bug 337907 has been marked as a duplicate of this bug. ***
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

13 years ago
(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. 

Updated

12 years ago
Blocks: 206435

Updated

12 years ago
Duplicate of this bug: 255896

Updated

11 years ago
Blocks: 343081

Comment 60

11 years ago
(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
Assignee: general → nobody
QA Contact: ian → general

Updated

3 years ago
Duplicate of this bug: 1316434

Comment 62

2 years ago
Can someone from Mozilla state this is actually a bug? IE and Chrome handle this well.
You need to log in before you can comment on or make changes to this bug.