2012-02-09 11 views
7

Estoy usando el objeto Geolocation y getCurrentPosition().¿Cómo se maneja cuando el usuario cierra el mensaje "Ubicación física" en Firefox y Chrome?

¿Has visto que cada vez que usas getCurrentPosition Firefox y Chrome solicitan estos masajes?

Chrome:

Example.com wants to track your physical location [allow] [deny] [ X close ] 

Firefox:

Example.com wants to know your location [Share Location] [Don't Share] [Close] 

Mi pregunta es: ¿Cómo manejar cuando un usuario no "permite" ni "Deny" opción de ubicación, pero en su lugar se cierra el símbolo?

tengo este código Javascript pero no funciona cuando el usuario cierra el símbolo:

  if (navigator.geolocation) { 
       navigator.geolocation.getCurrentPosition(
        onSuccess, 
        onError, 
        { 
         //enableHighAccuracy: true, 
         timeout: 5000 
         //maximumAge: 120000 
        } 
       ); 
        alert("holaaaa"); 
      } else { 
       alert('Geolocation not supported.'); 
      } 

Estoy teniendo algunos problemas con eso, cualquier ayuda por favor?

Esta pregunta está relacionada con este post: How to call function when user Allows or Denies access to "Physical Location"?

+0

he tenido este problema antes y no pudo encontrar ningún soluciones en ese momento, dudo que haya soluciones, incluso ahora. –

+0

Ese comportamiento es configurable en esos navegadores. Los míos ni siquiera preguntan, así que nunca "cierro el mensaje". Los míos están configurados para simplemente siempre negar. Esperaría que "cercano" se comporte igual que "negar". –

+0

@StephenP: si configuró Chrome para "nunca preguntar", de inmediato activa el 'errorCallback' (como si hubiera hecho clic en Denegar). Firefox no hace nada. – josh3736

Respuesta

15

El spec es en realidad bastante tranquilo sobre si es o no una devolución de llamada debe ser ejecutado si el usuario simplemente rechaza la solicitud de permiso (en oposición a clic en el botón Denegar):

Por tanto getCurrentPosition y watchPosition, la aplicación no debe invocar el successCallback sin tener abetos t obtuvo permiso del usuario para compartir la ubicación. Además, la implementación siempre debe obtener el permiso del usuario para compartir la ubicación antes de ejecutar cualquiera de los pasos getCurrentPosition o watchPosition descritos anteriormente. Si el usuario concede permiso, se debe invocar la devolución de llamada apropiada como se describe arriba. Si el usuario niega el permiso, el errorCallback (si está presente) debe invocarse con el código PERMISSION_DENIED, independientemente de cualquier otro error que se encuentre en los pasos anteriores. El tiempo dedicado a obtener el permiso de usuario no se debe incluir en el período cubierto por el atributo timeout del parámetro PositionOptions. El atributo timeout solo debe aplicarse a la operación de adquisición de ubicación.

Yo diría que rechazar la solicitud de permiso equivale a denegar la solicitud desde el punto de vista getCurrentPosition. Hacer clic en Denegar es explícito, mientras que descartar (hacer clic en X) es implícito.

Funcionalmente, la diferencia es que presionar el botón Denegar significa (1) la solicitud actual es denegada, y (2) el sitio está en la lista negra y nunca se le pedirá al usuario compartir ubicación nuevamente para el sitio; simplemente descartar la solicitud solo significa que la solicitud actual es denegada – solicitudes futuras (en el futuro BROWSINGCONTEXT s — después de que se recargue la página) volverán a aparecer.

En mi opinión, Chrome, Firefox, y el comportamiento actual del IE es un error – los tres no hacen nada si el usuario rechaza la solicitud de permiso haciendo clic en la X. El errorCallback debe ser llamado si la solicitud de permiso de geolocalización es despedido porque cualquier las llamadas posteriores al getCurrentLocation en el actual BROWSINGCONTEXT fallarán silenciosamente. (Opera 11.52 'se comporta correctamente' debido a que su solicitud de permiso de interfaz de usuario sólo ha permitir/denegar botones – sin X.)

Mozilla tiene una bug donde se dice que el comportamiento actual es correcta y una nueva bug error accesible que es relevante; Chromuim also says el comportamiento actual es correcto. IE tiene a bug(se requiere registro), pero curiosamente, Microsoft lo cerró como no reproducible.

Esto es realmente algo que el Grupo de Trabajo W3C debe abordar. La página debe ser capaz de reaccionar al usuario la disminución de la solicitud de permiso de ubicación – ya sea de forma permanente o simplemente negó declinó para esta sesión haciendo clic en la X.


La única cosa que realmente puede hacer ahora mismo para hacer frente a esta situación está configurando su propio tiempo de espera. Establecer un tiempo de espera en la solicitud de geolocalización, a continuación, establecer el tiempo de espera de error a ser mayor que (para permitir al usuario tiempo para reaccionar a la solicitud):

if (navigator.geolocation) { 
    var etimeout = setTimout(onError, 10000); 
    navigator.geolocation.getCurrentPosition(onSuccess, onError, {timeout:5000}); 
} 
function onSuccess(pos) { 
    clearTimeout(etimeout); 
    // ... 
} 
function onError(err) { 
    clearTimeout(etimeout); 
    // Note `err` will actually be undefined if this is the result of our timeout 
    // and anything you do here should be undone by `onSuccess` (in case the user 
    // took longer than 5 seconds to approve the request; for that reason, you 
    // shouldn't display any modal UI from here. 

    // ... 
} 
+1

El caso específico del usuario que desestima la barra parece estar marcado como WontFix en [Firefox] (https://bugzilla.mozilla.org/show_bug.cgi?id=564397) y [Chrome] (http: // code. google.com/p/chromium/issues/detail?id=43548) –

+0

@TimStone: gracias, enlaces actualizados. – josh3736

+1

¿Alguna actualización sobre este problema? – Sergiu

Cuestiones relacionadas