Mac: make save/open dialogs operate as tab-modal sheets....

Mac: make save/open dialogs operate as tab-modal sheets.

(... at least whenever possible, which is usually.)

Depends on:
    http://codereview.appspot.com/109050 [Patch Set 5]

Includes:
  - Save Page As... (from File menu, or Cmd-S)
  - Open File... (from File menu, or Cmd-O)
  - Save Link/Image As... (from context menu)
  - file upload (e.g., attaching a file to a new bug at crbug.com)

Also:
  - improves enabling/disabling behaviour (some bug fixes); the
    disabling of the Encoding menu contents is now more Mac-ish

To do/issues:
  - Closing a tab nukes any save/open sheet; for open, fine, but for
    save? Presumably, if you wanted to save something, it might be
    imporant. Perhaps it just reactivate as a response?
  - Quitting always refuses to nuke any save/open sheet, but instead
    pops you to one; this seems unnecessary for open.
  - Make Cmd-Shift-[/] work while a save/open sheet is open and active?
  - Still need to add a check in CreateConstrainedDialog().
  - Maybe still some races left?
  - Modality nearly complete. (Perhaps) still not right:
      - Edit menu items (cut/copy/paste/etc. should apply to the sheet!)
        -- oy!
      - Print... are wonky -- not my fault.
      - Should Email Page Location be affected by sheets? (No, unless it
        ever wants to pop up an error message as a tab-modal sheet?)
        It's not currently hooked up to anything right now, anyway.
      - Open Recent has an IDC_... for disabling, but it doesn't do
        anything, ever, right now.
      - I have no idea what "Create Application Shortcut..." is supposed
        to do.
  - Bug: this CL has turned into a monster.

Hopefully-very-temporary note:
  - If you play with this and chromium dies a horrible death (due to a
    failed assertion), it's probably this bug: <http://crbug.com/19116>;.

BUG=19333
TEST=Try the above (saving/opening/cancelling), try switching/creating tabs, try closing tabs (while open/save sheet active, with tab selected and unselected), open/close bookmark bar while switching between tabs with/without sheets.

[viettrungluu-gmail, 2009-08-14 05:47:51]

Have a look. It needs a second- and third-look to make sure it's not leaking
anything and won't crash. (I'll pile on more reviewers after I look at it again
... after some sleep.)

Cheers,

- Trung

[viettrungluu-gmail, 2009-08-14 15:53:04]

I don't know how y'all feel about tab-modal save/open dialogs, but here it is
anyway. (It's really my solution to said dialogs being attached to the title
bar, which looks odd.) Perhaps some UI people should be consulted as well.

I don't think it has any leaks, but I wouldn't want to bet my life on it.

[Nico, 2009-08-14 16:08:05]

What happens when, say, a http auth sheet is open and you hit cmd-s on that tab?

[viettrungluu-gmail, 2009-08-14 16:12:04]

On 2009/08/14 16:08:05, thakis wrote:
> What happens when, say, a http auth sheet is open and you hit cmd-s on that
tab?

The http auth sheet cleverly (and logically) disables save and open. Save and
Open on the other hand ... don't. Oops. I'll have to figure out how to fix that.

[Nico, 2009-08-14 16:21:04]

Also, if this goes in, it should probably happen on all platforms.

I know it's technically possible to embed open/save widgets everywhere
(gtk_file_chooser_widget_new() I believe), and I can probably make that change.

On first sight, it looks like windows (GetOpenFileName()) doesn't support
embedding its dialogs onto other hwnds, so this won't work with windows's
ConstrainedWindows class (this could be wrong, I haven't done real windows
developement in years).

So, what I'd suggest is to write a mail to chromium-dev, that says:

* Open/save should be per tab (UI guys, objections?)
* Proof-of-concept CL for OS X is <link to here>
* It might not be technically feasible to do this on windows, only on mac/linux.
Is everyone fine with having the superior user experience on the platforms that
support it, at the cost of consistency? (or, better, does someone know how to
embed a windows file chooser dialog?)

…and then let's see what happens.

[viettrungluu-gmail, 2009-08-15 15:46:39]

Argh. The patch is in for an overhaul. After some meditation on the topic, I
came to the realization that we need to distinguish between true tab-modal
dialogs (e.g., Save Page As... and Open File...) from "content-modal" dialogs
(http auth, file selection pushed from content, etc.).

The difference? Tab-modal dialogs should block navigation controls (including
the location bar -- oops! another bug) and also other tab-modal dialogs, but are
allowed to appear "over" content-modal ones. (In the case that a tab-modal
appears "over" a content-modal dialog and is then cancelled, the content-modal
should (re)appear untouched.) For example, you should be able to Open File...
even when there's an http auth dialog (Save Page As... is disabled not by the
presence of the http auth dialog in itself, but due to unsaveable contents).

On the other hand, for a content-modal one, navigation controls aren't (and
shouldn't be) blocked, and navigating away makes content-modal dialogs go away.
Content-modal dialogs should have little effect outside the web content area
(bugs notwithstanding -- why is Close Tab disabled during http auth? ... <goes
away to fle bug>), except insofar as they reflect content (mainly affecting Save
Page As...).

Unfortunately, this isn't entirely trivial to do, since we don't have separate
tab-content and web-content views (and one is limited, at least on Mac, to one
constrained window per view). Logically, I suppose tab-modal dialogs should hang
from the top of the tab (over the toolbar) whereas content-modal dialogs should
hang where they hang now; I think I'll ignore this, since hanging from the top
of the tab would look rather odd (there being nothing there).

[Nico, 2009-08-15 15:56:22]

I wouldn't worry about this. While it should arguably be possible to
open a file in a tab with an auth dialog, not supporting this is not a
huge deal. And the mental model "only one sheet per tab, if you want a
new one get rid of the existing one" is simpler, too.

So, I'd vote to make all tab-sheets what you call "content-modal". If
you really don't like this, then let cmd-o open a new tab with an
"open file" sheet if the current tab already has a sheet.

Would be nice to check who wrote the constrainedwindow stuff on
windows and ask him/her why tabcontents seems to support several
constrainedwindows.

On Sat, Aug 15, 2009 at 8:46 AM, <viettrungluu@gmail.com> wrote:
> Argh. The patch is in for an overhaul. After some meditation on the
> topic, I came to the realization that we need to distinguish between
> true tab-modal dialogs (e.g., Save Page As... and Open File...) from
> "content-modal" dialogs (http auth, file selection pushed from content,
> etc.).
>
> The difference? Tab-modal dialogs should block navigation controls
> (including the location bar -- oops! another bug) and also other
> tab-modal dialogs, but are allowed to appear "over" content-modal ones.
> (In the case that a tab-modal appears "over" a content-modal dialog and
> is then cancelled, the content-modal should (re)appear untouched.) For
> example, you should be able to Open File... even when there's an http
> auth dialog (Save Page As... is disabled not by the presence of the http
> auth dialog in itself, but due to unsaveable contents).
>
> On the other hand, for a content-modal one, navigation controls aren't
> (and shouldn't be) blocked, and navigating away makes content-modal
> dialogs go away. Content-modal dialogs should have little effect outside
> the web content area (bugs notwithstanding -- why is Close Tab disabled
> during http auth? ... <goes away to fle bug>), except insofar as they
> reflect content (mainly affecting Save Page As...).
>
> Unfortunately, this isn't entirely trivial to do, since we don't have
> separate tab-content and web-content views (and one is limited, at least
> on Mac, to one constrained window per view). Logically, I suppose
> tab-modal dialogs should hang from the top of the tab (over the toolbar)
> whereas content-modal dialogs should hang where they hang now; I think
> I'll ignore this, since hanging from the top of the tab would look
> rather odd (there being nothing there).
>
> http://codereview.chromium.org/164547
>

[viettrungluu-gmail, 2009-08-15 19:28:27]

Fair enough about the simplicity, but we still need to disable navigation while
save/open dialogs are up.

Given that neither Mac nor gtk support multiple constrained windows, it seems a
little silly to maintain a complicated interface in TabContents for that
purpose. I fired off an email to erg@... about this (it's unclear, at least to
me, from svn logs who the right person to ask is, but he seems like a reasonably
likely candidate).

On 2009/08/15 15:56:22, thakis wrote:
> I wouldn't worry about this. While it should arguably be possible to
> open a file in a tab with an auth dialog, not supporting this is not a
> huge deal. And the mental model "only one sheet per tab, if you want a
> new one get rid of the existing one" is simpler, too.
> 
> So, I'd vote to make all tab-sheets what you call "content-modal". If
> you really don't like this, then let cmd-o open a new tab with an
> "open file" sheet if the current tab already has a sheet.
> 
> Would be nice to check who wrote the constrainedwindow stuff on
> windows and ask him/her why tabcontents seems to support several
> constrainedwindows.