Open Bug 62395 Opened 24 years ago Updated 2 years ago

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

Categories

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

Product:
Core
Component:
DOM: Core & HTML
Type:
defect

Tracking

()

Milestone:
Future

People

(Reporter: kmcclusk, Unassigned)

References

Details

(Keywords: dom0) 

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.
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.
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
Status: NEW → ASSIGNED
Keywords: dom0
Setting milestone to mozilla1.0
Target Milestone: --- → mozilla1.0
Clearing milestone.
Target Milestone: mozilla1.0 → ---
Target Milestone: --- → Future
Setting milestone to future.
*** Bug 73961 has been marked as a duplicate of this bug. ***
*** Bug 118340 has been marked as a duplicate of this bug. ***
Build moving all existing future-P3 bugs to future-P4.
Priority: P3 → P4
*** Bug 135953 has been marked as a duplicate of this bug. ***
*** Bug 133483 has been marked as a duplicate of this bug. ***
*** Bug 148571 has been marked as a duplicate of this bug. ***
*** Bug 136030 has been marked as a duplicate of this bug. ***
*** Bug 150213 has been marked as a duplicate of this bug. ***
*** Bug 154591 has been marked as a duplicate of this bug. ***
*** 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. ***
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. ***
*** 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. ***
*** Bug 152872 has been marked as a duplicate of this bug. ***
*** Bug 230391 has been marked as a duplicate of this bug. ***
*** Bug 232871 has been marked as a duplicate of this bug. ***
Assignee: kmcclusk → general
Status: ASSIGNED → NEW
QA Contact: desale → ian
*** Bug 233897 has been marked as a duplicate of this bug. ***
*** Bug 167263 has been marked as a duplicate of this bug. ***
*** Bug 225908 has been marked as a duplicate of this bug. ***
*** Bug 240044 has been marked as a duplicate of this bug. ***
*** Bug 249276 has been marked as a duplicate of this bug. ***
related to bug 11709?
(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. ***
Is catching WM_SETTINGCHANGE (not supported on NT 3.51) useful here?
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).
Blocks: 281148
*** Bug 282586 has been marked as a duplicate of this bug. ***
*** Bug 283326 has been marked as a duplicate of this bug. ***
*** 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. ***
*** 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. ***
*** Bug 327414 has been marked as a duplicate of this bug. ***
*** Bug 270461 has been marked as a duplicate of this bug. ***
*** Bug 335004 has been marked as a duplicate of this bug. ***
*** 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? 
(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.
Blocks: 206435
Blocks: 343081
(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
Can someone from Mozilla state this is actually a bug? IE and Chrome handle this well.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.