200159 - Options (and cookie) dialogs are modal

Status: VERIFIED WONTFIX

(Firefox :: Settings UI, defect)

Description

[Shawn B]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4a) Gecko/20030324 Phoenix/0.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4a) Gecko/20030324 Phoenix/0.5

The Preferences dialog, as well as the cookies dialog are now modal.  When they
are open, you can't do anything in the browser window until you close the
dialogs.  This makes it very difficult, for example, to watch your cookies as
you surf.  The old functionality (present in Mozilla 1.3, but not the newest
builds of Phoenix) left the Preference dialogs as non-modal.

Reproducible: Always

Steps to Reproduce:
1.open up Preferences dialog
2.try to do anything in the browser.  it doesn't work
3.

Actual Results:  
you must close the dialog in order to access the main browser window again

Expected Results:  
left the preferences dialogs as non-modal

Comment 1

[David Tenser [:djst]]

I suggest WONTFIX. A modal Options dialog is standard behavior in almost all
Win32 applications.

Comment 2

[Shawn B]

Those dialogs have always been non-modal for Mozilla/Phoenix.  It's non-modal 
on Mozilla 1.3.  Just because other Windows apps do it that way doesn't mean 
that is how Mozilla/Phoenix should do it.  You get much more benefit without 
any detriment by making them non-modal.

Comment 3

[Simon Paquet [:sipaq]]

Seconding David. Suggesting WONTFIX.

Comment 4

[Sébastien Delahaye]

<aol>me too</aol>
It's probably a better design decision than the Mozilla way.

Comment 5

[Shawn B]

Well, I guess I'm outnumbered.  That sucks, because the old way of doing things 
(non-modally) made Phoenix BY FAR the easiest browser to test cookies with 
(i.e. when doing web development).  Now I'm going to have to switch to Mozilla 
1.3. :(

Comment 6

[David Tenser [:djst]]

Verifying resolution.

Reporter, you can always open a second browser window and open the Options
dialog from there. It's only modal to its owner window.

Comment 7

[Phil Endecott]

I was about to file a dupe of this bug.  Here's my scenario:

I have the cookie manager window open.  I'm scrolling down wondering what all
these cookies are and which of them I want to delete.  I see a domain name I'm
not sure about, and I decide to visit it.  I can copy from the Host: text in the
"information" pane.  But I can't paste it into the location bar.  Why I can't is
non-obvious, especially as most of the rest of the application still functions
(for example I have the Cookie Manager open while I type this).  Until I read
this bug I didn't realise that it was only one window that is locked out -
that's not obvious in any way.  Why are other windows still active, but other
tabs are not?  Aren't tabs just like windows except they're contained in the
same "frame"?

I'd argue that the cookie manager doesn't belong in the Options dialogs because
it's not showing options.  Real "options" are shown in the Cookies section of
the Privacy tab of the options dialog (enable for... etc) and in the
"exceptions" dialog, but the Cookie Manager is showing cookies that I have
aquired, not "options".  I'd give it its own entry under Tools.  Then, you can
decide whether it should be modal or non-modal independently of whether the rest
of the options dialogs are modal or not.

Let's decide this based on what is most useful, or most intuitive to use, not
what is "most like Windows".  If I wanted to be "just like windows", I'd be
using Internet Explorer on Windows, not Firefox on Linux.

Comment 8

[Kevin Brosnan]

*** Bug 314773 has been marked as a duplicate of this bug. ***

Comment 9

[Peter Helcmanovsky]

(In reply to comment #1)
> I suggest WONTFIX. A modal Options dialog is standard behavior in almost all
> Win32 applications.

That's IMHO very bad reason.

Just because almost all Win32 application have similar bad UI decision, you are following the same path?

I think every modal dialog is either bad UI design (using modal where it is not needed), or lazy programmers (using modal to make underlaying source code shorter).

I don't see any gains with "modal" dialogs, whole X-server thing did work many years without them, until Windows 3.1 appeared and added (IMHO bad) things like modal dialogs and non-resizable windows.

Comment 11

[L A Walsh]

Bug 373120 was incorrectly marked as a duplicate of this bug.  How do I unduplicate it?

This has nothing to do with the "modality" of a dialog.  

It has to do with the presence of an "Apply" button.  

Using the argument that things should be same in FF because that's how something is done in Windows should lead one to see that IE DOES have an Apply button.

Therefore by the "logic" of this bug, it's a "bug" in FF not to include Apply.

Do I have to refile the bug because someone didn't understand the problem and thought it was the same as this modal thing?   Grrrr....  (not that I ever take these things too personally when, logically, I know they are not meant that way...:-/)

Comment 12

[L A Walsh]

FWIW....I think it is broken logic to say FF implements modal dialogs because it's done that way in Windows when the reason it was done in windows was because they didn't know how to program for possibly re-entrant cases.  Just because a 5-year old doesn't know how to code non-modal dialogues doesn't mean that is a "better" way to do it.  Since when is Window's held up as a standard of excellence?  Isn't FF suppose to be better than that?....

Comment 13

[Thomas Oskk]

((In reply to comment #9)
> (In reply to comment #1)
> > I suggest WONTFIX. A modal Options dialog is standard behavior in almost all
> > Win32 applications.
> 
       
   > That's IMHO very bad reason.

Agree multiple times. 
Is there any change in sight, or do users still have to live with limited functionality, just 'cause it's "Win32-style"? Netscape could and still can do, and FF really should do even better. 

Comment 15

[Timwi]

What is the benefit of having this dialog modal? I think the benefit of removing the modality is obvious.

I think modal dialogs are an artifact of the past. Modern UI designers have realised that they usually do not make sense. Modal dialogs should only be used if the application cannot continue without user input (e.g. a yes/no prompt). The Tools/Options dialog is not an example of this.

Please reopen this bug.

Comment 16

[:aceman]

It seems Preferences (Options) dialog is no longer modal at least since FF 3.6 (and also in 4) on Linux. What is the state on Windows? Was this bug win32 only? Then the platform is not set correctly.

The cookie dialog modality is handled in other bugs, e.g. bug 633763. I suggest reducing this bug to the Options dialog.

Comment 17

[Timwi]

It is still modal on Windows (Firefox 3.6.15), and there is still no rationale provided for the WONTFIX resolution.

Comment 18

[:aceman]

The reason cited was that it is platform (Windows) standard. It is true that Mozilla developers do not need to follow these "standards" invented by Microsoft. But they wish to do so, because they think it is better for users, common users, to keep all applications behave similarly, according to those "standards". It seems there would be no sense in reopening the bug, the reasons for closing are not technical and haven't changed.

It is up to you to take these "standards" into account when you decide to keep using a platform (Windows in this case). As I said, at least Linux has the Options (Preferences) window non-modal. It is probably more the standard there.