-- Each of my web pages maintains one XHR for getting notifications.
-- Another XHR may be used to send commands from FF to the server
(overlapping the pending notification XHR).
-- The user may have more than one such page open in different tabs
or
windows
-- These pages may be 'active' on 'hidden' tabs
-- The user may have navigated to a new page (and may later come
back).
The sort of information I'm locking for is:
-- When a page is in a hidden tab, will the XHR transactions and
javascript
contirue to run as through the page was visible? It won't get
an unload event.
-- When a page navigated away from, it is unloaded, and the JS stops
and
the XHR seem to end, and I seem to get the readystatechange
event.
When you press the back button, do you get an load event again?
-- How many simultaneous, independant, asynchronous XHRs can be
running
at a time? In one page/tab? In one FF window? On one
computer?
Who knew programming could be so complicated?
True the page is still loaded and continues to run code when events occur.
> -- When a page navigated away from, it is unloaded, and the JS stops
> and
> the XHR seem to end, and I seem to get the readystatechange
> event.
> When you press the back button, do you get an load event again?
Yes
> -- How many simultaneous, independant, asynchronous XHRs can be
> running
> at a time? In one page/tab? In one FF window? On one
> computer?
You can have as many XHRs as you like in any of the scenarios. However by
default a single FF process will only open a maximum of 8 connections per
server.
Are you sure the problem isn't at the server end? What is the server?
>
> Who knew programming could be so complicated?
>
Babbage, Turing, Jackson, ... and anyone with formal training in computer
science.
--
Anthony Jones - MVP ASP/ASP.NET
A long running XHR can occur when a web page is waiting for
notifications pushed from a server. Opening two or three such pages
from the same server can cause the browser to hang when the browser
attempts to load another page, image, script or CSS file.
I think that the limit of max-persistent-connections-per-server should
not apply to XHRs (which are under control of the web page creator);
that they should be limited by a separate count from connections
created by the browser while loading elements of a page; or, at least,
should not cause the browser display painting the UI function to hang.
Yes. However I didn't say 8 XHRs I said 8 connections. You can have as
many XHRs as you like but only a maximum of 8 can get a connection to a
server. When a 9th XHR requests a connection where 8 currently have a
connection the 9th will block until a connection is free. I've not tested
it but one would expect send to return even if a connection hasn't yet been
acquired.
Note this pool of connections is shared by all parts of FF that request
resources from the server. Hence if you already have 8 XHRs with
outstanding connections that haven't completed yet the browser will be
unable to fetch HTML or images or other resources from the server.
I don't know whether it was you or someone else I discussed this with some
time ago but frankly I think the whole approach is flawed. HTTP is
essentially a connectionless, stateless protocol. You're architecture is
trying to use it in a way very different from what it was designed for.
My guess is that connections are not being freed perhaps due to not tearing
down the XHRs properly. It could be that a JS closure is maintaining an XHR
that the client no longer is using which in turn is maintaining an
unfullfilled connection to the server. When the code has done that a few
times the whole thing will appear to lock up.
Or it could simply be because you have 8 or more genuine XHRs gobbling up
all the available connections.
Hi,
we had the same exact problem with our applications, and not by
writing strange apps using HTTP in a "non intented" way, but using
widely used tools like AjaxPro.dll and MS AJAX.NET 1.0.
The whole user experience "slows down", sometimes the page hangs, and
so on.
All this NEVER happens with IE 7 or Opera 9.
We are very sad, because FF is superior in many other aspects (page
rendering, javascript compliance, etc),
but we can't use FF anymore for our AJAX applications if the beahviour
is this !
We think something is to be done to correct this aspect of FF, because
all future applications will be more and more based on AJAX /
XmlHttpRequest technology.
Thanks for the support,
Corrado
CIDITECH
I can't say that I've found XmlHttpRequest to be slow on FF. If anything
with IEs default 2 connections per server I would have though IE would
stuggle more.