136422 - Don't use "Sheets" for all OS-X modal dialogs (Modal dialogs have no title bar on Mac OSX)

Status: RESOLVED INCOMPLETE

(Core :: XUL, defect)

Description

[sujay]

Publish Progress dialog has a title bar and so does Find dialog in composer.

However, Publish dialog DOES NOT have a title bar.

This is filed from bug 134182

Comment 1

[Kathleen :Brade]

this is a duplicate bug of a bug that was already fixed

Comment 2

[sujay]

Kathy, what about the publish dialog ? that has no title bar...

Comment 3

[Kathleen :Brade]

On my Macintosh build from this morning, the publish dialog has a window title
area so the dialog can be moved.  I have never seen a problem with the publish
dialog (only the publish progress dialog and find/replace dialog)

Comment 4

[michael wendell]

I am still seeing this problem on the Publish dialog in OSX on the 04-09 trunk.

I am reopening this bug, switching the OS, and changing the summary.

Comment 5

[sujay]

Chris, can you confirm if this is a regression or its been like this the 
whole time...

Comment 6

[Kathleen :Brade]

-->cmanske

Comment 7

[Charles Manske]

Please check more recent build. The dialog-launching code is:
        window.openDialog("chrome://editor/content/EditorPublish.xul","_blank", 
                          "chrome,close,titlebar,modal", "", "", publishData);
and if there is a problem, it's not in Composer code, but must be true for all
dialogs.

Comment 8

[michael wendell]

I am still seeing this problem on OSX using the 04-23 trunk and 04-22 1.0.0
branch builds.

And actually, it appears that this problem is affecting every dialog except for
Find and Publish Progress.

Comment 9

[Charles Manske]

By "every dialog", you also mean those in Browser?
This probably isn't a Composer problem and is VERY important that this is fixed!
Note that the Find and Publish dialogs use the "dependent" flag and are 
effectively nonmodal. I remember an earlier bug on that issue so obviously it's 
been fixed.

Comment 10

[michael wendell]

Actually it is mainly Composer dialogs, but there are a few browser dialogs that
are also experiencing the problem.

Here are the dialogs that are experiencing the problem:
Table Properties dialog, Link Properties dialog, Image Properties dialog,
Publish dialog, Spell Check dialog, Anchor Properties dialog, H.line Properties
dialog, Advanced Properties dialog, Save - Don't Save - Cancel dialog, Publish -
Don't Publish - Cancel dialog, Publish Site Settings dialog, Page Title dialog,
Text Color dialog, Page Background Color dialog, and the two that also effect
the browser, Alert "page cannot be found" dialog, and Open Web Location dialog.

And these dialogs are NOT experiencing the problems either in Composer or the
browser:
Print dialog, Preferences dialog, Find dialog, Publish Progress dialog, Open
File dialog, Save Page As dialog, Bookmarks dialog, Form Manager dialog, Cookie
Manager dialog, Password Dialog, Download Manager, and Print Page Setup dialog.

Comment 11

[Samir Gehani]

Nav triage team: nsbeta1+

Comment 12

[Samir Gehani]

danm,
Who do you think would be a more appropriate owner for this? 

Comment 13

[Dan M]

The Publish Dialog and the list of dialogs without titlebars from comment 10 is
a list of dialogs that appear as sheets. Of course they don't have titlebars.
They're sheets. I don't get what this bug is trying to say. Am I missing something?

The only problem I know of with sheets lacking titlebars is a potential spoofing
issue covered by bug 132279. Closing invalid.

Comment 14

[Charles Manske]

Ok, so I just got a demo of the OS-X 'sheets' concept! Do we have to use this?
I don't see the advantage of this over "normal" modal dialogs. For Composer 
property dialogs, without the dialog title, you loose valuable info: the type of
object your are editing. You can't move them out of the way; e.g., when editing 
table properties, it is especially useful to be able to do that.
When using a properties dialog, we use error dialogs to alert user for some 
error situation; when that happens the parent dialog "slides" up and away, the 
error dialog slides down, and vice versa after "Ok" is clicked on the error 
dialog. This seems very inefficient and annoying to me!
Adding hyatt and churchill since they were accused of implementing this!

Comment 15

[Steve Dagley]

I'm with cmanske on this.  Sheets have their application but we're overusing the
shit out of them.  Rather than arbitrarily making every modlal dialog a sheet we
need to determine where it does, and does not, make sense to do so.  If that
can't be done soon I'm all for turning off sheets until it can be done.

Comment 16

[Charles Manske]

I talked to DanM about this and I think there should be an additional flag for
dialog creation that turns on "sheets" when we really think they're a good idea.
I'm going to reopen this bug for this issue.

Comment 17

[Samir Gehani]

Charley/DanM,
Who would be the appropriate person to implement this extra parameter?  danm? 
And do we need a separate bug to turn off sheets in the interim?

Comment 18

[Charles Manske]

Yes, danm would be the man.

Comment 19

[Samir Gehani]

-> danm

Comment 20

[Robert John Churchill]

Note:  As long as a modal dialog blocks the entire app until it is dismissed,
they are worse for overall usability than sheets on Mac OS X.

I suggest that people who complain about sheets to read Apple's UI guidelines
regarding Mac OS X... closely.

It is a weak argument to say that important information is placed into a
dialog's titlebar and lost if the titlebar isn't there... as UI testing shows
that people tend to not read titlebars.)  If the information is indeed so
important, it should be in the content area of the dialog and easily readable.

Comment 21

[Robert John Churchill]

A couple of additional comments:

o  Virtually all of the modal dialogs mentioned in Comment 10 are dialogs which
would be considered modal to only their parent window... so, under Mac OS X,
they should be sheets.

o  I oppose plans to add a "sheet" option to window|dialog.open as, under Mac OS
X, almost all modal dialogs are modal to only their parent and should be sheets.
 Therefore, sheets should be the default behavior.  However, I would probably
support efforts to add/extend the "modal" option to allow something like
"modal=app" for the edge-case dialogs which really should block the entire app.


To try and address Charley's comments in comment 14:

> Ok, so I just got a demo of the OS-X 'sheets' concept!
> Do we have to use this?
> I don't see the advantage of this over "normal" modal dialogs.

If you are a long-time Mac OS 9 user (I'm just guessing that's the case, as
sheets have been "on" in Mozilla for several months now), switching to Mac OS X
can be a shock. We all know this to be true. It takes some adjustment. However,
sheets are a way of life under Mac OS X.  Like other true OS X apps, Mozilla
should follow the expected UI of the platform. After you use OS X for a while,
and read the UI guidelines, the advantages of sheets will be more apparent I think.

The big problem that I see with our app is that we are MODAL-DIALOG-HAPPY which
unfortunately causes sheets to get a "bad rap" from the uninitiated.  We have
way too many modal dialogs, just in general... and it makes the app feel clunky
-- on all platforms, not just Mac.


To try and address sdagley's comments in comment 15:

> If that can't be done soon I'm all for turning off sheets until it can be done.

IMO The idea of "turning off sheets" is just being reactionary and not
especially helpful.  However, I'd certainly support cleaning up the UI by
identifying which dialogs shouldn't be modal... it has already been done for
some dialogs. (I made all the cookie/wallet/image/password/form dialogs be
non-modal a while ago.)

Comment 22

[Charles Manske]

First, I just want to mention that I'm not a Mac user, so I have no experience
with either OS9.x or OS-X behavior. It's obvious that the heart of the problem
is the system-modal behavior of Mac dialogs rather than the window-modal model
used by Windows and Linux. So Sheets are Mac's solution to this problem. That's 
fine if they really did thorough user testing and that's what users really
wanted. It just seemed strange to me as an "outsider" to the Mac UI style.
As for using too many modal dialogs, they are preferred for Composer property 
dialogs since we can't let user edit the document while at the same time they are
changing properties in a dialog. We can obviously work around that limitation in
a future release, but we certainly can't attempt to do that for the upcomming 
release. We have always wanted to explore other UI models for Composer, such as
non-modal palettes or toolbar/sidebar, but other priorities have prevented us
from doing that. I'm fine with leaving dialogs as sheets if that's the 
"OS-X way".

Comment 23

[Dan M]

Personally I'm not keen on the "sheet" parameter to openWindow because I can't
imagine what any other platform would do with that. I'd still add it if there
were a compelling reason for one platform but it sounds to me like Robert is
making a good case that there isn't a compelling reason. Or rather that we have
a UI problem in general for which a sheet/not-sheet switch isn't the right solution.

I'm also relatively unhappy with the "modal=app" suggestion. For dumb reasons
that's technically difficult (sort of. not a slam-dunk, anyway.) and it's still
platform-specific. It implies that other platforms should code support for app
modal dialogs, and I can't think of any platform outside OS 9 that willingly
provides app-modal dialog support.

Is this bug dead? Finger hovering over the "resolve invalid" switch...

Comment 24

[Charles Manske]

I agree that at least for the next release, we should probably keep the sheets
for the OS X platform and not add any further switches, but I'd like to keep the
issue open for further consideration. So please future this instead of marking
invalid.

Comment 25

[Christine Wozniak]

Adding custrtm-; no impact on customization.

Comment 26

[yaohw]

1

Comment 27

[Greg K.]

In regards to comment 21, is there a bug about generally reducing the use of
modal dialogs in Mozilla?

Comment 28

[Juan José Mata]

Reassigning futured nsbeta1+ bugs to Samir in case he wants to find people that
can pay attention to them.

Comment 29

[Samir Gehani]

Removing nsbeta1+ for nav triage reconsideration.

Comment 30

[Samir Gehani]

adt: nsbeta1-

Comment 31

[Adam Masri]

Attachment: Screenshot of spell checker in email, displaying current problem with sheets

From comment 14, Charles Manske asks,

"Ok, so I just got a demo of the OS-X 'sheets' concept! Do we have to use this?

I don't see the advantage of this over "normal" modal dialogs."

Tonight, I was fiddling with the built-in spell checker in Moz. I was writing
an email, and clicked the Spell button. Attached, please find a screenshot.
Note that the spell check sheet is covering the text in the document. I can't
see what the spell checker is referring to, so I don't know context of the
error in a sentence so I know how to correct it.

I think the problem here is that the people reading this bug, for the most
part, simply don't get the whole concept of sheets in OS X, and the obvious
eventuality that this innovation will probably make it into every GUI on the
planet. Every Windows user I've showed sheets to gets a big smile on their
face; it is obvious to me that this, like all Apple's innovations, will
eventually make it to Windows, then the other windowing environments.

The short description: a sheet is a dialog box attached to a window. Apple
calls them "Document-Modal Dialogs." This short movie on printing files in OS X
gives a nice demonstration of the sheet concept.

http://www.apple.com/macosx/theater/printing.html

This developer's page has good information on dialogs in OS X.

http://developer.apple.com/documentation/UserExperience/Conceptual/AquaHIGuidelines/AHIGDialogs/index.html


Click Next, then read the section on "Document-Modal Dialogs (Sheets)".

From Apple's description on the Aqua tech page:

http://www.apple.com/macosx/technologies/aqua.html

"Styling Sheets:
When you print or save, Mac OS X interacts with you via sheets attached to the
document window. If you’re printing or saving multiple interleaved documents,
each can have its own print or save sheet open simultaneously. You can proceed
to other tasks before dismissing the sheet. Sheet animation slides out from the
window title. The translucent quality makes sheets look as though they’re
floating above the document."

I believe that two things need to happen for Mozilla (and future spinoffs) to
be a good citizen in the OS X world, and eventually to be a good citizen in
other windowing environments that adopt the sheet concept.

1) For now, turn off sheets in the OS X build of Mozilla. Sheets should not be
used everywhere dialogs are used. In some cases, the sheet covers data the user
needs to see or interact with.

2) Add a new bug, asking for a new flag to be associated with all dialogs -- if
they're document-modal. If the OS doesn't support this flag, that's ok, just
paint a normal dialog. If the OS does support this feature, however, then draw
a sheet.

Now the bigger issue, especially for people who are developing Moz on an OS
that doesn't currently support sheets is, when do you use sheets? Read Apple's
developer page, referenced above, to get a better sense of this. But as my
screenshot shows, don't use a sheet when the dialog should be movable away from
the window. The way Moz works now, I can't move that sheet away to see what
it's spell checking.

- Adam

Comment 32

[Joachim Noreiko]

A number of Firefox pop-up dialogs are trying to be sheets, but failing:

theay appear as just a white rectangle, ie no window title bar, but are not
attached to the top of the main window.

Example of this include most dialogs that pop up from the preferences dialog.
Extensions tend to cause this behaviour too.

Is this related to this bug or should I file a new one?

Comment 33

[Simona Badau, Desktop QA]

After all the Proton changes, not sure this is still a valid issue. Neil, could you please take a look into it and close it if it's no longer reproducible or update it with the current affected versions. Thanks!

Comment 34

[Neil Deakin]

Not sure what this about, going to redirect to Markus.

Comment 35

[Markus Stange [:mstange]]

Yeah, no idea, let's close this.