Nochum Sossonko [:Natch] Reporter
	Description • 14 years ago

XHR is run even with a modal dialog open.

See bug 618856 comment 20.

	Nochum Sossonko [:Natch] Reporter
	Comment 1 • 14 years ago

Testcase in url

	Nochum Sossonko [:Natch] Reporter
	Comment 2 • 14 years ago

Cloning bugs inherits blocking...

	Jonas Sicking (:sicking) No longer reading bugmail consistently
	Comment 3 • 14 years ago

Jason, do you know what prevents network events from arriving while a modal window is open on windows?

	:Gavin Sharp [email: gavin@gavinsharp.com]
	Comment 4 • 14 years ago

It should be the call to mSuspendedDoc->SuppressEventHandling() in nsGlobalWindow::EnterModalState(), presumably?

	:Gavin Sharp [email: gavin@gavinsharp.com]
	Comment 5 • 14 years ago

(that gets called for tab-modal prompts via nsDOMWindowUtils::EnterModalState() in nsPrompter.js' openTabPrompt)

	Jonas Sicking (:sicking) No longer reading bugmail consistently
	Comment 6 • 14 years ago

I don't think that deals with network events. IIRC it's use for sync-XHR which obviously means that network requests *do* have to go through since otherwise the XHR would never un-suspend.

	Jonas Sicking (:sicking) No longer reading bugmail consistently
	Comment 7 • 14 years ago

Note that this only regressed on windows. It never worked on mac. Don't know situation on Linux. But I'm not convinced this is needed for web compat. 

In any case, assigning to dolske.

	Justin Dolske [:Dolske] Assignee
	Comment 8 • 14 years ago

I'm curious what's broken here, the tab-modal prompts should be doing everything the window-modal prompts used to do.

	Jonas Sicking (:sicking) No longer reading bugmail consistently
	Comment 9 • 14 years ago

They are not. Run the testcase in the linked url on Firefox 3.6 and trunk on windows.

	Jason Duell
	Comment 10 • 14 years ago

> Jason, do you know what prevents network events from arriving while a modal
window is open on windows?

I don't, but bz and/or honza might.

	Boris Zbarsky [:bzbarsky]
	Comment 11 • 14 years ago

Presumably something spins up an extra event loop, and we stop processing events on the event loop the network events are going to.

But I didn't think we did that....

	Kyle Huey (Exited; not receiving bugmail, old account, do not use)
	Comment 12 • 14 years ago

If we've only regressed this on Windows I don't think this should block.

	Honza Bambas (:mayhemer)
	Comment 13 • 14 years ago

To better understand: expected behavior is that while a modal dialog is open, we do not dispatch the xhr progress events, but only cache them and invoke after the dialog has been closed?

If so, where code responsible for this should be?

	Johnathan Nightingale [:johnath]
	Comment 14 • 14 years ago

(In reply to comment #12)
> If we've only regressed this on Windows I don't think this should block.

That's where most of our users are - and it sounds like bustage that might surprise web sites. Am I misunderstanding the scale of the impact here?

	Kyle Huey (Exited; not receiving bugmail, old account, do not use)
	Comment 15 • 14 years ago

(In reply to comment #14)
> (In reply to comment #12)
> > If we've only regressed this on Windows I don't think this should block.
> 
> That's where most of our users are - and it sounds like bustage that might
> surprise web sites. Am I misunderstanding the scale of the impact here?

Since we've been behaving this way on Mac (and Linux?) previously presumably websites are depending on that behavior.  The "presumably" is an assumption, of course, but afaik we haven't seen any bug reports about websites breaking because of this.

	Kyle Huey (Exited; not receiving bugmail, old account, do not use)
	Comment 16 • 14 years ago

presumably websites *aren't* depending on that behavior, of course.

	Johnathan Nightingale [:johnath]
	Comment 17 • 14 years ago

K. We should still fix it, but it does sound softer the more I think about it.

	Jonas Sicking (:sicking) No longer reading bugmail consistently
	Comment 19 • 14 years ago

My concern is that websites will break over this yes. There are plenty of websites out there that doesn't test on mac.

My concern here is that the only way to fix this is to back out tab-modal dialogs.

Removing the soft-blocker marking to get this re-triaged based on this.

	Mike Beltzner [:beltzner, not reading bugmail]
	Comment 20 • 14 years ago

Random website breakage isn't cool, and I agree with Jonas that the advantage of modal JS dialogs isn't worth that cost.

That said, some real evidence needs to be brought to the table. Let's find some patterns where we know this happens. Adding Blizzard and Paul.

	Justin Dolske [:Dolske] Assignee
	Comment 21 • 14 years ago

(In reply to comment #7)
> Note that this only regressed on windows. It never worked on mac. Don't know
> situation on Linux. But I'm not convinced this is needed for web compat. 

Are you still only seeing a regression on Windows? I don't see any platform differences.

With Firefox 3.6 and the test in attachment 502857 [details], I get (for both Windows and OS X):

    sending xhr
    about to show alert
    alert no longer open
    xhr finished. alertIsOpen is false

With a current Firefox 4 nightly, I get (for both Windows and OS X):

    sending xhr
    about to show alert
    xhr finished. alertIsOpen is true
    alert no longer open

But this isn't solely due to tab-modal prompts -- I'd suspect a regression elsewhere in Firefox 4... If I disable tab-modal prompts with the prompts.tab_modal.enabled preference, I still get the broken behavior (ie, pref does not affect results).

I'll investigate some more. (Initial WAG: maybe another symptom of bug 577385, as bug 621764 might be?)

	Justin Dolske [:Dolske] Assignee
	Comment 22 • 14 years ago

I went looking for a regression range; the attachment here works as expected with the 5/3/2010 win32 nightly, but not the next nightly.

That gives a range of: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=83c887dff0da&tochange=d6bb0f9e9519

Nothing jumps out at me strongly... Could the HTML5 parser be involved?

Also, I caught jst briefly -- he mildly surprised that 3.6 was blocking the XHR callback, but suggested some stuff had changed in that regard recently for compatability with other browsers. So, CCing jst and smaug intothe fray. ;)

	Justin Dolske [:Dolske] Assignee
	Comment 23 • 14 years ago

The HTML5 parser made me notice that the testcase here is running an in-line script... So I modified the testcase to start only when a button is clicked (ie, well after after the page has loaded).

With the modified testcase, I get the same behavior on Firefox 3.6 and a current Firefox 4 nightly, as tested on both Windows and OS X. All 4 flavors run the XHR callback while the prompt is open.

So, the issue seems here seems to be that with the HTML5 parser, XHR callbacks are now invoked during a pageload while a modal prompt is shown. Bug or feature?

(Also, note that early May is well before I started changing any prompt stuff, so that further indicates the prompt code isn't causing this.)

	Justin Dolske [:Dolske] Assignee
	Comment 24 • 14 years ago

Final nail: if I disable the html5.enable pref, Firefox 4 + original testcase behaves as Firefox 3.6 did, even with tab-modal prompts. (Both Windows and OS X)

	Jonas Sicking (:sicking) No longer reading bugmail consistently
	Comment 25 • 14 years ago

Oooh, this testcase is severely affected by the fact that we're loading the document URL from the XHR. Necko is only able to serve one consumer of a given URL at once under some circumstances, so it makes a lot of sense that the HTML5 parser affects things since the parser finishes loading, allowing the XHR load to start.

So if that's the case, then this bug is INVALID or at least WONTFIX.

Thanks for looking into this Dolske!