Closed
Bug 515880
Opened 15 years ago
Closed 15 years ago
Add drawintitlebar attribute to XUL root elements and sync it to the window widget
Categories
(Core :: XUL, defect)
Core
XUL
Tracking
()
RESOLVED
FIXED
mozilla1.9.3a1
People
(Reporter: mstange, Assigned: mstange)
References
Details
(Keywords: dev-doc-complete, Whiteboard: [doc-waiting-1.9.3])
Attachments
(2 files, 2 obsolete files)
|
(deleted),
image/png
|
Details | |
|
(deleted),
patch
|
Details | Diff | Splinter Review |
screenshot
This is necessary for bug 513157.
Attachment #399963 -
Flags: superreview?(roc)
Attachment #399963 -
Flags: review?(neil)
|
Assignee | |
Comment 1•15 years ago
|
||
I don't intend to land this before the Mac implementation is finished.
Looks good, but we need documentation of this new attribute as we discussed.
|
||
Comment 3•15 years ago
|
||
What's the intended use case here i.e. why a XUL attribute?
|
|
Assignee | |
Comment 4•15 years ago
|
||
Spec:
Setting drawintitlebar="true" on the root XUL element of a window extends the window's content area into the window frame. In the titlebar, the titlebar controls and the window title are drawn on top of the window content. The titlebar area may not respond to mouse events.
|
|
Assignee | |
Comment 5•15 years ago
|
||
(In reply to comment #3)
> What's the intended use case here i.e. why a XUL attribute?
What else could it be? Would you prefer a CSS property?
Use cases are listed in bug 513157 comment 0.
If themes want to make use of this functionality, they can use CSS to add a binding that sets the attribute, like we used to do for (in)activetitlebarcolor in Firefox 3.0 (see globalBindings.xml).
|
|
Assignee | |
Comment 6•15 years ago
|
||
Updated to trunk. I noticed that I forgot to rev the nsIWidget IID; I'll do that when I land this.
Attachment #399963 -
Attachment is obsolete: true
Attachment #404718 -
Flags: superreview?(roc)
Attachment #404718 -
Flags: review?(neil)
Attachment #399963 -
Flags: superreview?(roc)
Attachment #399963 -
Flags: review?(neil)
Comment on attachment 404718 [details] [diff] [review]
v1.1
+ NS_LITERAL_STRING("true").Equals(*aValue));
EqualsLiteral?
Attachment #404718 -
Flags: superreview?(roc) → superreview+
|
|
||
Comment 8•15 years ago
|
||
Comment on attachment 404718 [details] [diff] [review]
v1.1
> // Hide chrome if needed
[I wonder why we don't check for root content here too.]
> if (aName == nsGkAtoms::hidechrome &&
> mNodeInfo->Equals(nsGkAtoms::window) &&
> aValue) {
> HideWindowChrome(aValue && NS_LITERAL_STRING("true").Equals(*aValue));
[Heh, this checks aValue twice!]
>+ virtual void SetDrawsInTitlebar(PRBool aState);
> virtual PRBool ShowsResizeIndicator(nsIntRect* aResizerRect);
> virtual void FreeNativeData(void * data, PRUint32 aDataType) {}
Could write virtual void SetDrawsInTitlebar(PRBool aState) {} perhaps?
Attachment #404718 -
Flags: review?(neil) → review+
|
|
||
Comment 9•15 years ago
|
||
(In reply to comment #7)
> (From update of attachment 404718 [details] [diff] [review])
> + NS_LITERAL_STRING("true").Equals(*aValue));
>
> EqualsLiteral?
[Maybe aValue used to be an nsAString* and so ->EqualsLiteral wouldn't compile; it's an nsString* now so no such problem any more of course!]
|
|
Assignee | |
Comment 10•15 years ago
|
||
(In reply to comment #7)
> (From update of attachment 404718 [details] [diff] [review])
> + NS_LITERAL_STRING("true").Equals(*aValue));
>
> EqualsLiteral?
OK.
(In reply to comment #8)
> (From update of attachment 404718 [details] [diff] [review])
> > // Hide chrome if needed
> [I wonder why we don't check for root content here too.]
I wondered that too, but I don't want to change it in this patch.
> > if (aName == nsGkAtoms::hidechrome &&
> > mNodeInfo->Equals(nsGkAtoms::window) &&
> > aValue) {
> > HideWindowChrome(aValue && NS_LITERAL_STRING("true").Equals(*aValue));
> [Heh, this checks aValue twice!]
Fixed. Also changed this to EqualsLiteral.
>
> >+ virtual void SetDrawsInTitlebar(PRBool aState);
> > virtual PRBool ShowsResizeIndicator(nsIntRect* aResizerRect);
> > virtual void FreeNativeData(void * data, PRUint32 aDataType) {}
> Could write virtual void SetDrawsInTitlebar(PRBool aState) {} perhaps?
Sure.
Attachment #404718 -
Attachment is obsolete: true
|
|
Assignee | |
Comment 11•15 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.3a1
|
||
Updated•15 years ago
|
Keywords: dev-doc-needed
|
||
Updated•15 years ago
|
Whiteboard: [doc-waiting-1.9.3]
|
|
||
Comment 12•14 years ago
|
||
Documented here:
https://developer.mozilla.org/en/XUL/Attribute/drawintitlebar
Listed here:
https://developer.mozilla.org/en/XUL/window#Attributes
And on:
https://developer.mozilla.org/en/Firefox_4_for_developers#Miscellaneous_XUL_changes
Keywords: dev-doc-needed → dev-doc-complete
|
||
Comment 13•13 years ago
|
||
This attribute definitely needs better documentation. I set it to true and expected the topmost element to magically jump up into the titlebar, but nothing happened. I know my approach is lame, but nothing I googled gave me a clue. A short usage example would be really helpful.
|
||
Comment 14•7 years ago
|
||
Moving to Core:XUL per https://bugzilla.mozilla.org/show_bug.cgi?id=1455336
Component: XP Toolkit/Widgets: XUL → XUL
You need to log in
before you can comment on or make changes to this bug.
Description
•