Benoit Hudson Reporter
	Description • 19 years ago

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920 Firefox/1.0.7
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920 Firefox/1.0.7

The POSTDATA dialog is modal.  This is a problem for form responses that reload, producing two distinct bad behaviours.  (1) is more commonly annoying; (2) makes this a (for my grandmother) browser-downing bug.

(1) if I'm in tab A and the form-generated page in tab B decides to reload, firefox grabs the focus away from tab A and forces me to deal with the reloading page.  Firefox 1.5 at least switches the tab so that I know *which* tab I'm dealing with, but that's only barely progress.  Extra-annoying is if I'm typing in tab A and happen to hit the space bar or enter key when the POSTDATA dialog for tab B pops up -- then I've OK'd the resending of the data even before I knew there was a decision to be made.

(2) a misbehaving page can practically take down the browser.  All one needs to write is a page that has form data and has javascript to immediately reload the page.  Because the dialog is modal, I can't kill the tab or switch the URL -- I can only hit 'ok' or 'cancel'.  But in either case, the page reloads again.  I actually see this behaviour sometimes in the webgame www.travian.com but haven't been able to reproduce it from there.  It is *possible* to stop the loop, but only by feverously hitting escape and ctrl-w until finally the ctrl-w gets in before the javascript reloads.

To deal with both problems, make the dialog non-modal.  Then it only needs to pop up when I'm on the relevant tab (though there might need to be some way of communicating that there's an event to handle in a background tab), and I have the extra option of nuking the tab, changing the URL, or hitting 'back' again.

Reproducible: Always

	Robert O'Callahan (:roc) (email my personal email if necessary)
	Comment 1 • 19 years ago

I assume this is a Necko dialog and fixing it depends on the single-event-queue work.

	Christian :Biesinger (don't email me, ping me on IRC)
	Comment 2 • 19 years ago

it's a docshell dialog actually... I believe it's shown before necko is involved at all.

	Darin Fisher
	Comment 3 • 19 years ago

See also bug 112848.  I think this dialog should be replaced with an error page, which is what IE does in this case.

	Boris Zbarsky [:bzbarsky]
	Comment 4 • 19 years ago

Hmm..  Doing this as an error page would be great if we can pull it off, yeah.  We can remove a bunch of special-casing then, I think.

	Philip Withnall (unavailable)
	Comment 5 • 19 years ago

(In reply to comment #3)
> See also bug 112848.  I think this dialog should be replaced with an error
> page, which is what IE does in this case.
> 

If you want to suggest that, please file a new bug report and make it block https://bugzilla.mozilla.org/show_bug.cgi?id=28586.

	Boris Zbarsky [:bzbarsky]
	Comment 6 • 19 years ago

Might I ask why this was dumped in the tabbed browser component?

	Philip Withnall (unavailable)
	Comment 7 • 19 years ago

Because it was about problems relating to focus and different tabs. Where do you think it should go?

	Boris Zbarsky [:bzbarsky]
	Comment 8 • 19 years ago

Probably in a Core component; presumably docshell (which is what puts up the dialog).  All of which is spelled out in earlier comments in this bug.

For future reference, putting "focus" bugs in any Firefox component is a good way to bury them forever.

	Phil Ringnalda (:philor)
	Comment 9 • 18 years ago

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

	Thomas Bertels
	Comment 10 • 17 years ago

Since this breaks the back/forward buttons, I'd say that the severity is at least at the boundary between normal and major.

	Jo Hermans
	Comment 11 • 16 years ago

bug 451250 might fix this

	Shad Sterling
	Comment 12 • 14 years ago

This should block bug 160144, possibly also bug 123913.

No dialog should ever be modal, but I don't think bug 451250 is the solution; reposted from bug 451250 comment 5:

This approach is problematic:  If you're on a page which is a POST response, and you don't know it's a post response, when you hit reload your page will be replaced with an info page.  How do you get back to the original page?  Reload isn't supposed to change the target of the Back button.  With a dialog it's trivial: hit cancel.

	Roman
	Comment 13 • 14 years ago

Could someone please mark this as blocking bug 616843, in which I'm trying to
list all dialogs that should be tab-modal?

	Tobias
	Comment 14 • 14 years ago

I have listed a view solutions for this (overall) problem here https://bugzilla.mozilla.org/show_bug.cgi?id=160144#c213 and here https://bugzilla.mozilla.org/show_bug.cgi?id=515223#c2 – Hope this dialogue gets improved soon. But Bug 160144 being from 2002 doent get my hopes up =(.

	:Gavin Sharp [email: gavin@gavinsharp.com]
	Comment 15 • 10 years ago

(In reply to Jo Hermans from comment #11)
> bug 451250 might fix this

Bug 451250 removed the prompt for session history navigation, but not for the "reload" case, as far as I can tell.

	Johann Hofmann [:johannh]
	Comment 16 • 7 years ago

We made this dialog tab-modal in bug 1412559, I assume that solves this issue.