none
Evitar back mientras se está procesando RRS feed

  • Pregunta

  • Buenas,

    Tengo una app MVC 5 donde hay un formulario y un botón submit. El envío y proceso del formuario hace un Postback completo de la página y tarda unos 5 segundo aproximadamente. Al usuario se le muestra un loading que bloquea la pantalla para que espere mientras se está realizando el proceso. El problema es que tiene el botón atrás y esto causa problemas cuando lo pulsa. ¿De qué manera puedo controlar que no pueda volver atrás mientras el formulario se está procesando?

    Saludos.


    • Editado eduar2083 jueves, 3 de septiembre de 2020 23:01
    jueves, 3 de septiembre de 2020 22:09

Respuestas

  • No estoy de acuerdo con la respuesta anterior. Esas tres guias dan la misma solucion: No deshabilitan en realidad el boton de retroceso, sino que hacen un "history.forward" de manera que en caso de retroceder te vuelven a cambiar a la pagina en la que estabas, y de esa manera da la apariencia visual de que no se puede retroceder. Esto puede resultar oportuno en uno de los casos tipicos en que los programadores desean deshabilitar el retroceso, que es cuando haces "logout" pero si retrocedes a la pagina anterior volerias a estar viendo los datos que habia antes de hacer logout. Rebotando de nuevo hacia adelante se impide que veas esos datos, por lo que en este caso la solucion aportada podria ser correcta.

    Pero esto no resuelve la situacion de la pregunta que nos ocupa, en la que lo que se plantea es que se estan procesando unos datos. Si utilizasemos el truco de volver a avanzar en caso de retroceso, volveriamos a entrar en la pagina que procesa los datos, cosa que es algo a evitar porque no queremos ocasionar que se dispare de nuevo el procesamiento.

    Mi opinion acerca de como resolver este tipo de situaciones es que "se debe hacer lo que sea más amistoso para el usuario, y no lo que sea más cómodo para el programador". Lo cómodo para el programador es impedirle al usuario que retorceda, y asi no hay que programar nada para contemplar esta situación. Pero lo amistoso para el usuario es poder utilizar todos los controles que tiene su navegador en la forma habitual. Para facilitar esto, lo que se puede hacer es poner true en un booleano en el lado servidor cuando se inicia el procesamiento, y quitarlo cuando se termina. En la pagina que hemos llamado "anterior", se comprueba ese booleano, y si es true se muestran solo los datos que no dependen del procesamiento, y se informa que el resto de la informacion no se puede mostrar (o no se puede modificar) porque se encuentra en procesamiento en ese momento. Esto tiene la ventaja de que tambien funciona en caso de que el usuario pegue la URL de esa página en el navegador, en lugar de usar el boton de retroceso, o en caso de que tenga varias pestañas y acceda a esa página desde otra pestaña (o desde otro navegador). Nada de esto se resolveria si nos limitamos a bloquear el boton de retroceso.


    viernes, 4 de septiembre de 2020 13:13

Todas las respuestas

  • Hola eduar2083,

    Aquí te dejo 3 guías que explican como logar desactivar este botón del navegador:

    JavaScript Deshabilita el botón de retroceso del navegador en ASP.Net

    Desactivar el botón Atrás del navegador

    Deshabilite el botón Atrás del navegador usando JavaScript (jQuery) en ASP.Net MVC

    Espero que te sea de ayuda. Por favor no olvides marcar una respuesta si resolviste tu consulta. Quedo pendiente de cualquier actualización. Gracias por levantar tu consulta en los foros de msdn.

     

    Saludos cordiales

    Gabriel Castro

     ____________________________ 

    Por favor recuerde "Marcar como respuesta" las respuestas que hayan resuelto su problema, es una forma común de reconocer a aquellos que han ayudado, y hace que sea más fácil para los otros visitantes encontrar la solución más tarde. 

    viernes, 4 de septiembre de 2020 0:58
  • No estoy de acuerdo con la respuesta anterior. Esas tres guias dan la misma solucion: No deshabilitan en realidad el boton de retroceso, sino que hacen un "history.forward" de manera que en caso de retroceder te vuelven a cambiar a la pagina en la que estabas, y de esa manera da la apariencia visual de que no se puede retroceder. Esto puede resultar oportuno en uno de los casos tipicos en que los programadores desean deshabilitar el retroceso, que es cuando haces "logout" pero si retrocedes a la pagina anterior volerias a estar viendo los datos que habia antes de hacer logout. Rebotando de nuevo hacia adelante se impide que veas esos datos, por lo que en este caso la solucion aportada podria ser correcta.

    Pero esto no resuelve la situacion de la pregunta que nos ocupa, en la que lo que se plantea es que se estan procesando unos datos. Si utilizasemos el truco de volver a avanzar en caso de retroceso, volveriamos a entrar en la pagina que procesa los datos, cosa que es algo a evitar porque no queremos ocasionar que se dispare de nuevo el procesamiento.

    Mi opinion acerca de como resolver este tipo de situaciones es que "se debe hacer lo que sea más amistoso para el usuario, y no lo que sea más cómodo para el programador". Lo cómodo para el programador es impedirle al usuario que retorceda, y asi no hay que programar nada para contemplar esta situación. Pero lo amistoso para el usuario es poder utilizar todos los controles que tiene su navegador en la forma habitual. Para facilitar esto, lo que se puede hacer es poner true en un booleano en el lado servidor cuando se inicia el procesamiento, y quitarlo cuando se termina. En la pagina que hemos llamado "anterior", se comprueba ese booleano, y si es true se muestran solo los datos que no dependen del procesamiento, y se informa que el resto de la informacion no se puede mostrar (o no se puede modificar) porque se encuentra en procesamiento en ese momento. Esto tiene la ventaja de que tambien funciona en caso de que el usuario pegue la URL de esa página en el navegador, en lugar de usar el boton de retroceso, o en caso de que tenga varias pestañas y acceda a esa página desde otra pestaña (o desde otro navegador). Nada de esto se resolveria si nos limitamos a bloquear el boton de retroceso.


    viernes, 4 de septiembre de 2020 13:13
  • Hola,

    Gracias a ambos por responder.

     Esto puede resultar oportuno en uno de los casos tipicos en que los programadores desean deshabilitar el retroceso, que es cuando haces "logout" pero si retrocedes a la pagina anterior volerias a estar viendo los datos que habia antes de hacer logout

    Alberto, respecto de este punto que mencionas, he notado que cuando se coloca el atributo Authorize en un controlador, no se puede volver a él si previamente se hizo logout. Yo entendería que el Atributo Authorize tiene cierta lógica que valida la autenticación y hace un redirect al Login. Desviándome un poquito del tema de este hilo, yo tengo un atributo que hereda de Authorize pero cuando utilizo mi atributo en los controladores este sí permite volver y no redirecciona al login (mvc5, net-framework 4.6)

    Si utilizasemos el truco de volver a avanzar en caso de retroceso, volveriamos a entrar en la pagina que procesa los datos, cosa que es algo a evitar porque no queremos ocasionar que se dispare de nuevo el procesamiento.

    En realidad pensándolo bien, el problema no sólo es con el botón atrás; el usuario podría hacer muchas cosas: recargar la página, cambiar la url, incluso cerrar el navegador e irse. Entiendo que el proceso en el back continúa a pesar que haga cualquiera de estas acciones. 

    Esto tiene la ventaja de que tambien funciona en caso de que el usuario pegue la URL de esa página en el navegador, en lugar de usar el boton de retroceso, o en caso de que tenga varias pestañas y acceda a esa página desde otra pestaña (o desde otro navegador). Nada de esto se resolveria si nos limitamos a bloquear el boton de retroceso.

    Tienes razón, debe ser controlado en el servidor. Entendería que esa variable booleana debería ser tipo Session

    sábado, 5 de septiembre de 2020 12:58
  • En cuanto a lo del Authorize, sí, debería funcionar, incluso si utilizas un atributo tuyo derivado de Authorize, siempre que use el mismo mecanismo, que verifica si ya has hecho logout para no conceder el login. Si en tu clase derivada has suplantado el mecanismo de autorización y no estás haciendo la comprobación, entonces no tiene por qué redirigirte al Login.

    Lo de la variable booleana es un poco más complicado. Sí, al ponerla en true podrías meterla en el Session y las demás páginas que se vean afectadas por el procesamiento de la información podrían leerla. Pero yo iría más allá y guardaría algún valor persistente; por ejemplo, si el procesamiento implica hacer una serie de cambios en base de datos, yo metería en una tabla auxiliar alguna indicación de qué usuario y qué cambios se están haciendo. Esto permite que se detecte el procesamiento en curso en caso de acceder desde otro navegador a esa página o esa información, ya que en este caso no se compartiría el Session.

    sábado, 5 de septiembre de 2020 16:14
  • Hola eduar2083,

    ¿Alguna novedad sobre tu pregunta? ¿Han sido útiles las respuestas proporcionadas? Por favor no olvides marcar una respuesta si resolviste tu consulta.

     

    Saludos cordiales

    Gabriel Castro

     ____________________________ 

    Por favor recuerde "Marcar como respuesta" las respuestas que hayan resuelto su problema, es una forma común de reconocer a aquellos que han ayudado, y hace que sea más fácil para los otros visitantes encontrar la solución más tarde. 

    lunes, 7 de septiembre de 2020 20:32