ItsNatStfulDocumentImpl itsNatDoc = getItsNatStfulDocument();
Document doc = itsNatDoc.getDocument();
AbstractView view = ((DocumentView)doc).getDefaultView();
ClientDocumentStfulImpl clientDoc = getClientDocumentStful();
Browser browser = clientDoc.getBrowser();
if (isReferrerEnabled())
{
EventTarget target;
String eventType;
int commMode;
if (browser.isClientWindowEventTarget())
{
target = (EventTarget)view;
if ( CommModeImpl.isXHRDefaultMode(clientDoc) &&
browser.hasBeforeUnloadSupport(itsNatDoc) &&
itsNatDoc.isUseXHRSyncOnUnloadEvent() &&
(!(browser instanceof BrowserWebKit) ||
((browser instanceof BrowserWebKit) && ((BrowserWebKit)browser).isXHRSyncSupported())) )
{
// Si no se soporta el modo s�ncrono corremos el riesgo de que no se env�e el evento en el proceso de cerrado de la p�gina
// lo cual normalmente ocurre en el evento "unload"
eventType = "beforeunload";
commMode = CommMode.XHR_SYNC; // As� aseguramos que se env�a pues por ejemplo no hay seguridad en modo as�ncrono en MSIE 6 desktop
}
else
{
// Intentamos soportar referrers tambi�n aunque de forma menos elegante.
// Registramos en el evento load y no cuando se carga el documento
// para evitar solapamiento con posibles iframes
eventType = "load";
commMode = clientDoc.getCommMode();
}
}
else
{
target = (EventTarget)doc.getDocumentElement();
eventType = "SVGLoad";
commMode = clientDoc.getCommMode();
}
clientDoc.addEventListener(target,eventType,RegisterThisDocAsReferrerListenerImpl.SINGLETON,false,commMode);
}
// Es necesario usar siempre el modo s�ncrono con unload para asegurar que llega al servidor
// sobre todo con FireFox, total es destrucci�n
// En FireFox a veces el unload se env�a pero no llega al servidor en el caso de AJAX as�ncrono,
// la culpa la tiene quiz�s el enviar por red as�ncronamente algo en el proceso de destrucci�n de la p�gina
// Curiosamente esto s�lo ocurre cuando se abre un visor remoto Comet y se cierra la p�gina principal.
// En teor�a "beforeunload" deber�a dar menos problemas que unload en FireFox
// pero sin embargo tambi�n ocurri� con beforeunload as�ncrono (adem�s beforeunload es cancelable).
// NOTA: es posible que en versiones recientes est� solucionado esto.
// De todas formas es �til el modo s�ncrono porque si hubiera alg�n
// JavaScript pendiente de enviar, pues evita que de error al haberse perdido la p�gina
// (pues el navegador ha de esperarse, no destruye la p�gina), si fuera asincrono
// seguir�a destruyendo la p�gina antes de retornar el evento (comprobado en MSIE y FireFox).
super.dispatchRequestListeners();
// En W3C en addEventListener el orden de dispatch es el mismo que el orden de inserci�n
// y en MSIE hemos simulado lo mismo (lo natural es primero el �ltimo)
// por ello insertamos despu�s de los listeners del usuario tal que
// nuestro unload "destructor" (invalida/desregistra el documento) sea el �ltimo
// Si se puede, los eventos de descarga deben enviarse como s�ncronos
EventTarget target;
String eventType;
int commMode;
int defaultCommMode = clientDoc.getCommMode();
if (CommModeImpl.isXHRMode(defaultCommMode))
{
if (!itsNatDoc.isUseXHRSyncOnUnloadEvent() ||
((browser instanceof BrowserWebKit) &&
!((BrowserWebKit)browser).canSendXHRSyncUnload())) // Este problema no se ha estudiado para SVGUnLoad pero por si acaso tambi�n lo consideramos
commMode = CommMode.XHR_ASYNC;
else
commMode = CommMode.XHR_SYNC;
}
else commMode = defaultCommMode; // Caso SCRIPT o SCRIPT_HOLD, siempre as�ncronos
if (browser.isClientWindowEventTarget())
{
target = (EventTarget)view;
eventType = "unload";
}
else