Open Bug 566522 Opened 15 years ago Updated 2 years ago

"Save Page As" should not be a modal dialog

Categories

(Firefox :: General, defect)

defect

Tracking

()

People

(Reporter: jhill, Unassigned)

References

(Blocks 1 open bug)

Details

(Note: this is filed as part of the “Paper Cut” bugs — we assume that there may be multiple existing bugs on this. Please make them block this bug, and we will de-dupe if they are indeed exactly the same. Thanks!) To reproduce: 1. Open up multiple tabs 2. Go to File -> Save Page As 3. You can no longer to other tabs until you close the modal dialog Recommendation: Make the Save Page as dialog a non-modal dialog
Does this bug cover other save/open dialogs as well? If not, could it be extended to also cover them? Save Dialogs: - Save Page As... - Save Frame As... - Save Link As... - Save Image As... Open Dialogs: - Open File... - Upload inputs (input type=file) Miscellaneous: - Extensions' Open/Save Dialogs At least "Save Link As..." and "Save Image As..." are used a lot by me and probably also by others...
The proposed behavior is confusing I think. Firefox currently does what all Linux (read: GNOME) apps do.
Most Windows (and probably also Mac) apps use a modal save dialog as well. So using a non-modal dialog would make Firefox differ from the "standard". But Firefox is, in this respect, not a "standard" application anyway. Most applications make only very little use of tabs or don't use tabs at all. In this case it's usually: one window = one document; a modal save dialog does make sense. But Firefox uses tabs a lot, therefore: one window = a lot of documents; blocking the whole window because of a modal save dialog that belongs to one of the documents does not make sense. I agree though that making the save dialog non-modal could be confusing. If you open several save dialogs there is no way to tell which save dialog belongs to which tab. A solution might be to make the save dialog tab-modal and not completely non-modal.
I still don't see the point. It is not like web pages open file dialogs normally. The file dialog is a helper that the user asks for and is VERY likely to use right away. Why would someone open a file dialog and then switch to another tab?
>Why would someone open a file dialog and then switch to another tab? Normally users will interact with the dialog immediately, but there are a few different reasons why they might not, perhaps they saw an instant message come in, or they needed to check their calendar quickly. In GNOME these dialog boxes are application modal, but if you view Firefox as a platform for accessing a variety of different Web applications, you could make an argument that dialog boxes should at most only be modal to the that particular application (tab modal), instead of locking up the entire platform.
In testing it long after this bug was originally filed, I am easily able to multi-task and go to other applications per the use case mentioned above needing to ignore the modal dialogue. I think the current behavior is sufficient to give users enough flexibility to interact with other desktop apps while keeping focus in Firefox on the last action they took, File menu -> opening modal until dismissed/cancelled.
(In reply to agrigas from comment #7) > In testing it long after this bug was originally filed, I am easily able to > multi-task and go to other applications per the use case mentioned above No this is not about "other applications", certainly not "other desktop apps", and is very far from "sufficient to give users enough flexibility". Please re-read original use-case, specifically: "3. You can no longer [switch] to other **tabs** until you close the modal dialog" This bug has resulted in loss of other tabs session state (due to locking up user-events and having no option other than a force-quit) as recently as last year (2014). Specifically, it is possible to have a UI race-condition where you: 1. try to Save an HTML archive (including embedded images etc.) of one tab, 2. have it start saving, 3. switch to a *second* tab (same window), 4. and LATER have that first tab encounter network failures and put up a modal dialog saying so. At which point you are screwed because the modal dialog blocks events from going anywhere else, however the second tab has UI event focus so you can't interact with the dialog either, nor can you click anything to switch tabs (because the modal thinks it can block all other UI interactions).
(In reply to Tantek Çelik from comment #8) > (In reply to agrigas from comment #7) > > In testing it long after this bug was originally filed, I am easily able to > > multi-task and go to other applications per the use case mentioned above > > No this is not about "other applications", certainly not "other desktop > apps", and is very far from "sufficient to give users enough flexibility". > > > Please re-read original use-case, specifically: > > "3. You can no longer [switch] to other **tabs** until you close the modal > dialog" > > This bug has resulted in loss of other tabs session state (due to locking up > user-events and having no option other than a force-quit) as recently as > last year (2014). > > Specifically, it is possible to have a UI race-condition where you: > 1. try to Save an HTML archive (including embedded images etc.) of one tab, > 2. have it start saving, > 3. switch to a *second* tab (same window), > 4. and LATER have that first tab encounter network failures and put up a > modal dialog saying so. > > At which point you are screwed because the modal dialog blocks events from > going anywhere else, however the second tab has UI event focus so you can't > interact with the dialog either, nor can you click anything to switch tabs > (because the modal thinks it can block all other UI interactions). My mistake - I misunderstood the ticket given the use case description of people wanting to change tabs to go to other applications (text/calendar). Get the issue now and agree a in browser modal style similar to the one we use in Preferences > Content > Exceptions may be a good template to use for cases like this?
See Also: → 1548128
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.