Using modal dialogs to trick users is far too common. Can we make all dialogs non-modal?

This was already on file.

Bug 616843 is proposing to make the dialogs tab-modal and will require a long time. I'm proposing to make them non-modal completely, which might be quite easier.

If you look at the discussion in bug 613785 alone, this is not as easy as "let's just do it". I agree with Gijs that a meta-bug for tracking the different dialogs is the right approach.

This is not a duplicate of bug 616843. Bug 616843 is suggesting to make dialogs tab-modal, this bug is suggesting to make them modeless. If we don't intend to do what suggested in comment 0 (make all dialogs non modal), then we should resolve this bug as WONTFIX.

(In reply to Marco Castelluccio [:marco] from comment #4) > This is not a duplicate of bug 616843. Bug 616843 is suggesting to make > dialogs tab-modal, this bug is suggesting to make them modeless. > If we don't intend to do what suggested in comment 0 (make all dialogs non > modal), then we should resolve this bug as WONTFIX. It's not 100% clear to me what you think "modeless" means here, but I will try to explain anyway... For alert/prompt/confirm, the spec requires that the dialog is modal (and in fact, the dialogs being tab-modal means we break the spec in some edgecases, which is its own issue...). For networking things like the http auth dialog, we could conceivably make it non-modal, but as Johann suggested, doing that is not a trivial problem. In fact, to the degree that it requires the calling code to use event loop spinning etc., it is no easier to do than making them tab-modal (which also requires such event loop spinning). So no, I'm not convinced that there's some kind of "easier" solution here that involves making the dialogs modeless...

(In reply to :Gijs (slow, PTO recovery mode) from comment #5) > (In reply to Marco Castelluccio [:marco] from comment #4) > > This is not a duplicate of bug 616843. Bug 616843 is suggesting to make > > dialogs tab-modal, this bug is suggesting to make them modeless. > > If we don't intend to do what suggested in comment 0 (make all dialogs non > > modal), then we should resolve this bug as WONTFIX. > > It's not 100% clear to me what you think "modeless" means here, but I will > try to explain anyway... For alert/prompt/confirm, the spec requires that > the dialog is modal (and in fact, the dialogs being tab-modal means we break > the spec in some edgecases, which is its own issue...). For networking > things like the http auth dialog, we could conceivably make it non-modal, > but as Johann suggested, doing that is not a trivial problem. In fact, to > the degree that it requires the calling code to use event loop spinning > etc., it is no easier to do than making them tab-modal (which also requires > such event loop spinning). So no, I'm not convinced that there's some kind > of "easier" solution here that involves making the dialogs modeless... Yeah, I know there would be problems with spec and UX, but the benefit would have outweighted the drawbacks in my opinion. Anyway, I was assuming it would be easier. Since it isn't, then there's no point in considering this further.