Closed Bug 162029 Opened 22 years ago Closed 22 years ago

Privacy & Security windows all come up on top of the OS/2 WarpCenter

Categories

(Core Graveyard :: Security: UI, defect, P2)

Other Branch
x86
OS/2
defect

Tracking

(Not tracked)

VERIFIED FIXED
mozilla1.3alpha

People

(Reporter: julien.pierre, Assigned: danm.moz)

References

Details

Attachments

(1 file)

I have my OS/2 WarpCenter configured in the top of the screen. When I open the
following windows under "Privacy & Security", they end up covering my WarpCenter :
"Certificates / Manage certificates"
"Validation / Manage CRLs"
"Cookies Managed stored cookies"
"Images Manage image permissions"
"Forms / Manage sites"
"Passwords / Manage stored passwords"

Some of the dialogs got it right - eg. "Certificates / Manage security devices"
or "SSL / Edit ciphers", or "Passwords / Form manager", while the above listed
did not.
Blocks: 140195
I tried a brief look to find a potential difference, but I don't see attributes
that would be common to all good or all bad windows.

On my Linux system, in a new profile, all windows appear at the same location on
screen.

The answer should lie within the following snippets of code. Either we need to
have a XUL guru guide us, or we need to test changing the attributes.

good
====
oncommand="window.openDialog('chrome://pippki/content/pref-ciphers.xul', '',
               'modal=yes,resizable,chrome');"
<window id="pref-ciphers" title="&cipher.title;"
  xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"      
  onload="onLoad();">

good
====
window.open('chrome://pippki/content/device_manager.xul',  "devmgr",
            'chrome,width=540,height=360,resizable=yes');
<window id="devicemanager"
        xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul" 
        title="&devmgr.title;"
        persist="screenX screenY width height"
        onload="LoadModules();">

bad
===
window.open('chrome://pippki/content/certManager.xul',  "",
            'chrome,width=500,height=400,resizable=yes,dialog=no');
<window id="certmanager" 
	xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul" 
        title="&certmgr.title;"
        onload="LoadCerts();">

bad
===
window.open('chrome://pippki/content/crlManager.xul',  "",
            'chrome,width=500,height=400,resizable=1');
<window id="crlviewer"
        class="dialog"
        title="&validation.crlmanager.label;"
        xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"
        style="width: 30em;"
        onload="onLoad();">
Priority: -- → P2
Target Milestone: --- → Future
This bug is because of an oversight. These are windows with non-persistent
positions. We don't bother checking that such a window fits onscreen; we assume
that its default position of (0,0) is fine. This of course doesn't work so well
if (0,0) is covered by some system toolbar.
Assignee: ssaux → danm
Target Milestone: Future → 1.3
This fixes the oversight; even windows with non-persistent positions are
constrained to be on-screen.
Blocks: 165750
Comment on attachment 105880 [details] [diff] [review]
constrain all new windows to be on-screen

sr=jag
Attachment #105880 - Flags: superreview+
Attachment #105880 - Flags: review+
.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Julian, can you try this out on OS/2 WarpCenter and add your comments?
I never opened most of those windows before, and they all opened as they should
below my WarpCentre in 2002111712 OS/2 trunk.
verified fixed on 11/17 build.
Status: RESOLVED → VERIFIED
Product: PSM → Core
Target Milestone: psm1.3 → mozilla1.3alpha
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: