If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Implement nsIXULWindow::Enabled attribute

RESOLVED FIXED in mozilla1.2alpha

Status

()

Core
XUL
RESOLVED FIXED
16 years ago
16 years ago

People

(Reporter: Robert Ginda, Assigned: Robert Ginda)

Tracking

Trunk
mozilla1.2alpha
x86
All
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Assignee)

Description

16 years ago
The debugger needs to fully disable a window that is being debugged.  It should
not respond to any user interaction events, though it should probably still
paint and reshape.  It should also not be possible to close the window via
window manager widgetry.
(Assignee)

Comment 1

16 years ago
Created attachment 67808 [details] [diff] [review]
xulwindow changes, round one

Possible changes to the nsXULWindow, comments?
(Assignee)

Comment 2

16 years ago
Assuming something similar to the previous patch goes in, the nsWindow
implementations on various platforms need to properly implement the |Enabled()|
method.

I *think* windows works as is, gtk doesn't, and I'm not sure about the mac.  I
spoke to blizzard about this and he has pointed me to bug 121011.
Status: NEW → ASSIGNED
Depends on: 121011
(Assignee)

Updated

16 years ago
Target Milestone: --- → mozilla0.9.9
(Assignee)

Comment 3

16 years ago
Should this be pushed to nsIBaseWindow?

Comment 4

16 years ago
Three thoughts leading three places:

  The patch looks fine as far as it goes, but the Mac widgetry, as you've
probably noticed, will need its Enabled property a little more hooked up.
  Yes, I think nsIBaseWindow makes (a little) more sense than nsIXULWindow. From
there it's a short step to also add it to nsIEmbeddingSiteWindow, the embedding
version. Why we have both is something of a mystery to me.
  This is basically what bug 122695 is trying to do, though that one's more
specific. Do you need both?
(Assignee)

Comment 5

16 years ago
> The patch looks fine as far as it goes, but the Mac widgetry, as you've
> probably noticed, will need its Enabled property a little more hooked up.

That's where peterv comes in :)  I havn't delved too deeply into what needs to
happen for the mac, yet.

>  Yes, I think nsIBaseWindow makes (a little) more sense than nsIXULWindow. 
> From there it's a short step to also add it to nsIEmbeddingSiteWindow, the 
> embedding version. Why we have both is something of a mystery to me.

I ran into a link error trying to build viewer when I had this on nsIBaseWindow.
 I'll have another look see.  Would a addition to nsIBaseWindow incur a ton of
embedding fallout?

> This is basically what bug 122695 is trying to do, though that one's more
> specific. Do you need both?

Welp, I'll need to disable the debug target regardless of whether or not it's
modal.  If it happens to be modal, I'll have to de-modal the window before
disabling.  Possibly we can work both sets of changes into a single bug, where
setting Enable(PR_FALSE) also turns off modalMien.

Comment 6

16 years ago
Moving Netscape owned 0.9.9 and 1.0 bugs that don't have an nsbeta1, nsbeta1+,
topembed, topembed+, Mozilla0.9.9+ or Mozilla1.0+ keyword.  Please send any
questions or feedback about this to adt@netscape.com.  You can search for
"Moving bugs not scheduled for a project" to quickly delete this bugmail.
Target Milestone: mozilla0.9.9 → mozilla1.2
(Assignee)

Comment 7

16 years ago
danm fix this in a recent check in.
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.