Mac non-sheet modal dialogs should not show any buttons on the title-bar.

RESOLVED WORKSFORME

Status

()

Core
Widget: Cocoa
P2
normal
RESOLVED WORKSFORME
10 years ago
2 years ago

People

(Reporter: Nick Kreeger, Assigned: Nick Kreeger)

Tracking

Trunk
All
Mac OS X
Points:
---
Bug Flags:
wanted1.9.2 +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

(Assignee)

Description

10 years ago
Created attachment 322316 [details]
Safari Modal Dialog SS

Currently, the modal dialogs show disabled close, minimize, and zoom buttons for modal dialogs. These disabled buttons should be hidden to enhance appearance. 

See screenshots for comparison.
(Assignee)

Comment 1

10 years ago
Created attachment 322317 [details]
Firefox Modal Dialog SS
(Assignee)

Comment 2

10 years ago
Created attachment 322319 [details] [diff] [review]
Patch V1

Proposed patch.
Assignee: joshmoz → nick.kreeger
Status: NEW → ASSIGNED
Attachment #322319 - Flags: review?(joshmoz)
(Assignee)

Updated

10 years ago
Attachment #322319 - Attachment is patch: true
Attachment #322319 - Attachment mime type: application/octet-stream → text/plain

Comment 3

10 years ago
Comment on attachment 322319 [details] [diff] [review]
Patch V1

Are we sure that this won't result in modals coming up that can't be closed? I'm worried about cross platform apps that assume they don't need to put close UI within the modal dialog. Windows Vista, at least, has a close button. I'd be more comfortable with this patch if it only hid minimize and maximize.
(Assignee)

Comment 4

10 years ago
(In reply to comment #3)
> (From update of attachment 322319 [details] [diff] [review])
> Are we sure that this won't result in modals coming up that can't be closed?
> I'm worried about cross platform apps that assume they don't need to put close
> UI within the modal dialog. Windows Vista, at least, has a close button. I'd be
> more comfortable with this patch if it only hid minimize and maximize.
> 

Sure that sounds good - but I should note that currently the maximize button (or any other button) is currently _always_ disabled. So I suggest that we leave that button enabled where we start doing all the sudo-modal configuration for the cocoa window. 

Does this sound OK Josh?
(In reply to comment #3)
> Are we sure that this won't result in modals coming up that can't be closed?
> I'm worried about cross platform apps that assume they don't need to put close
> UI within the modal dialog. Windows Vista, at least, has a close button.

From Nick's screenshot, Safari faces the same issue and apparently seems to believe it's a non-issue.

> I'd be
> more comfortable with this patch if it only hid minimize and maximize.

They either need to all be there (disabled if not applicable), or all not be there; mix-and-match hiding is against the HIG: http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/XHIGWindows/chapter_18_section_4.html#//apple_ref/doc/uid/20000961-SW34

Updated

9 years ago
Attachment #322319 - Flags: review?(joshmoz) → review-

Comment 6

9 years ago
Comment on attachment 322319 [details] [diff] [review]
Patch V1

At the very least we need to unhide the standard buttons on the native window when a modal dialog goes away in case the window is used again non-modally.

If you save a page in Firefox you get a native modal save window (ignore whether or not that should be a sheet) and the window allows maximizing - the other two buttons to the left are disabled (not hidden). I think we're going to need a more complex solution - maybe disable close and minimize for modal dialogs, leave maximize enabled by default and if the XUL app disables maximize then totally hide all 3 buttons for the modal session.

Updated

9 years ago
Flags: wanted1.9.2+
Priority: -- → P2

Updated

9 years ago
Hardware: x86 → All
This WFM on latest Nightly 49.0a1, 20160518030234
Status: ASSIGNED → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.