[JS/HTML5] navigator.geolocation error FF/ IE issue

[Verwijderd]

Tweakers,

Ik heb ruzie met de error callback van navigator.geolocation.getCurrentPosition(). Die zou daar als tweede parameter in moeten.

Zo ziet de call eruit in mijn code;
navigator.geolocation.getCurrentPosition(getHtmlPositionHandler, getHtmlPositionErrorHandler, {maximumAge:600000});

getHtmlPositionHandler gaat altijd goed als de browser door de Modernizr.geolocation check heen gaat (die erboven staat) en de user toestemming geeft voor het gebruiken van zijn locatie.

Echter, wanneer de user géén toestemming geeft gaat het mis in IE en FF.
function getHtmlPositionErrorHandler(data) wordt nooit gecalled volgens Firebug en de IE dev tool. Ik werk daar nu omheen door altijd eerst met mijn fallback code (1. GeoIP WS, 2. manuele fallback coördinaten) te callen en vervolgens de navigator.geolocation in te zetten (zodat bij geen toestemming in IE en FF wel een fallback locatie adv IP gebruikt kan worden). Maar het zou natuurlijk mooi zijn als dat in één keer goed ging (scheelt me een JSON call in moderne browsers).

WebKit afstammelingen als Chrome en Safari roepen wel gewoon de getHtmlPositionErrorHandler aan als de gebruiker geen toestemming geeft.
Krijg verder geen JS fouten in de console van Firebug of IE.

Staat o.a. hier beschreven dat het zou moeten werken IMHO;
https://developer.mozilla...olocation#Handling_errors
http://dev.w3.org/geo/api/spec-source.html

Zag wel dat er meer mensen waren met een issue met deze call;
http://stackoverflow.com/...es-works-sometimes-doesnt

Iemand een idee waarom dit niet werkt?

[CH4OS]

Wat heb je zoal al geprobeerd, naast de work-around en wat zoeken? Heb je ook wat (relevante!) code?

[ Voor 32% gewijzigd door CH4OS op 28-07-2011 23:43 ]

[Verwijderd]

CptChaos schreef op donderdag 28 juli 2011 @ 23:43:
Wat heb je zoal al geprobeerd, naast de work-around en wat zoeken? Heb je ook wat (relevante!) code?

Ik heb even heel hard aan mijn laptop gerammeld, mijn stoel verstelt en daarna heb ik een blik cola open getrokken...

Ook heb ik zonder de 3de parameter geprobeerd. Niet veel andere zaken om te proberen leek me, suggesties welkom uiteraard.

Goed nog wat relevante code;

JavaScript:

function getUserLocation() {
    if (Modernizr.geolocation) {
        /* Use HTML5 */
        if (navigator.geolocation) {
            navigator.geolocation.getCurrentPosition(getHtmlPositionHandler, getHtmlPositionErrorHandler, {maximumAge:600000});
        } else {
            getLocationByLegacy();
        }
    }
}
function getHtmlPositionHandler(position) {
          _startLat = position.coords.latitude;
          _startLng = position.coords.longitude;
          setInitialPostion(_initialZoomKnownPosition);
}
function getHtmlPositionErrorHandler(data)
{
    getLocationByLegacy();
}

[ Voor 69% gewijzigd door Verwijderd op 28-07-2011 23:54 . Reden: Relevante code toegevoegd en CptChaos gequote ]

[crisp]

De test op Modernizr.geolocation is al een test op navigator.geolocation; uit de broncode van Modernizr:

JavaScript:

/**
 * geolocation tests for the new Geolocation API specification.
 *   This test is a standards compliant-only test; for more complete
 *   testing, including a Google Gears fallback, please see:
 *   http://code.google.com/p/geo-location-javascript/
 * or view a fallback solution using google's geo API:
 *   http://gist.github.com/366184
 */
tests['geolocation'] = function() {
    return !!navigator.geolocation;
};

Je moet dus feitelijk ook een else hebben voor als Modernizr.geolocation false teruggeeft, of gewoon die hele check skippen:

JavaScript:

function getUserLocation() {
    if (navigator.geolocation) {
        /* Use HTML5 */
        navigator.geolocation.getCurrentPosition(getHtmlPositionHandler, getHtmlPositionErrorHandler, {maximumAge:600000});
    } else {
        getLocationByLegacy();
    }
}

[Verwijderd]

True, maar dat is het probleem niet. Als de user weigert komt de browser nog altijd door Modernizr.geolocation. Zal dat aanpassen maar dat is niet het probleem dus. Was al laat natuurlijk ;-).

[ Voor 10% gewijzigd door Verwijderd op 29-07-2011 10:26 ]

[crisp]

Modernizr heeft daar niets mee te maken want meer dan alleen de check op navigator.geolocation doet die niet

[Verwijderd]

Ja... Zoiets zei ik toch? Verwarring alom.

Vergeet de code.
navigator.geolocation.getCurrentPosition(getHtmlPositionHandler, getHtmlPositionErrorHandler, {maximumAge:600000});

getHtmlPositionErrorHandler wordt in IE en FF bij user deny niet aangeroepen.
Dat is het probleem. Geloof me.

[RobIII]

Verwijderd schreef op vrijdag 29 juli 2011 @ 10:46:
Ja... Zoiets zei ik toch? Verwarring alom.

Ik denk wel dat je gelijk hebt; ik kan het hier reproduceren: http://jsfiddle.net/ZKBfu/
Wat ik er, op 't eerste oog, van lijk te lezen is dat bij "user deny" (de "not now" keuze) de errorhandler niet aangeroepen zou worden "by design". Ik ben nog even verder aan 't graven naar evt. oplossingen of workarounds. Maar zelfs Google's voorbeelden falen.

Je kunt sowieso even hier voten en anders even kijken of je een bugreport kunt inschieten of een reeds bestaande upvoten

[ Voor 29% gewijzigd door RobIII op 29-07-2011 11:07 ]

[crisp]

Verwijderd schreef op vrijdag 29 juli 2011 @ 10:46:
[...]
getHtmlPositionErrorHandler wordt in IE en FF bij user deny niet aangeroepen.
Dat is het probleem. Geloof me.

Oh, dat geloof ik, en gezien de specificatie is dat dan een implementatie bug in zowel IE als FF. Voor Firefox zou je iig even in bugzilla kunnen kijken of het een bekende issue is en anders een issue aanmaken. wb IE ben je (zoals altijd) overgeleverd aan de 'Goden' in Redmont...

Even wat gezocht in bugzilla:
https://bugzilla.mozilla.org/show_bug.cgi?id=635175
https://bugzilla.mozilla.org/show_bug.cgi?id=650247
en die verwijzen door naar https://bugzilla.mozilla.org/show_bug.cgi?id=591745

beschrijft dat je probleem (in andere woorden: verwacht je dat klikken op 'not now' de errorhandler aanroept?)

offtopic:
komt die gekke RobIII weer tussendoor

[ Voor 27% gewijzigd door crisp op 29-07-2011 11:22 ]

[RobertMe]

Als collega van Pieter heb ik hier ook naar gekeken. Wat RobIII omschrijft klopt. De "not now" keuze callt de error callback niet, de "Never share" keuze daarentegen callt de error callback wel. De W3C testcase failt in Firefox dan ook. De "pass" komt alleen bij de "Never share". Hetzelfde gebeurd ook in IE. In die toolbar op het kruisje klikken geeft geen resultaat, "Options->Always deny" en er is een pass.

beschrijft dat je probleem (in andere woorden: verwacht je dat klikken op 'not now' de errorhandler aanroept?)

Dat klopt. Ik heb even de W3C specificatie erbij gepakt.

If the user denies permission, the errorCallback (if present) must be invoked with code PERMISSION_DENIED, irrespective of any other errors encountered in the above steps.

Deze omschrijft dus dat een deny de errorCallback moet aanroepen. Er staat niet omschreven wanneer het een deny is. Maar het lijkt mij logisch dat alles wat geen allow is een deny is, omdat er wel duidelijk staat aangegeven dat de gebruiker toestemming moet geven (of er een regel is dat de gebruiker ooit toestemming heeft gegeven en die onthouden moet worden).

De reactie van Mozilla vind ik ook raar. Aangezien bij "Not now" de user zelf een actie doet en daarmee antwoord geeft op de vraag (hij wil nu niet de gegevens delen), terwijl buiten de popup klikken de user geen antwoord geeft op de vraag.

Edit: Toevoeging op de edit van crisp

Edit2:
Zelf getest in Chrome en Safari.
Chrome geeft een "toolbar", deze heeft een kruisje. Het klikken op dit kruisje geeft geen error (hetzelfde dus als IE klikken op kruisje en FF klikken buiten popup).
Safari geeft een modal popup, deze sluiten met het kruisje geeft wel een error.

[ Voor 63% gewijzigd door RobertMe op 29-07-2011 11:40 ]

[crisp]

Mozilla stelt dat 'Not now' geen antwoord op de vraag is (dus geen deny of allow) maar een middel om de UI voor de toestemmingsvraag te verbergen en daarmee dus hetzelfde als buiten de popup klikken. Dat is dus puur een interpretatiekwestie...

[RobIII]

crisp schreef op vrijdag 29 juli 2011 @ 12:08:
Mozilla stelt dat 'Not now' geen antwoord op de vraag is (dus geen deny of allow) maar een middel om de UI voor de toestemmingsvraag te verbergen en daarmee dus hetzelfde als buiten de popup klikken. Dat is dus puur een interpretatiekwestie...

Interpretatie of niet; nu (als ik het goed begrijp althans) heb je dus geen manier om te achterhalen of de gebruiker überhaupt een antwoord heeft gegeven of nog gewoon naar die popup zit te staren.
Vind ik, persoonlijk, niet zo heel mooi

[ Voor 3% gewijzigd door RobIII op 29-07-2011 12:32 ]

[Verwijderd]

Yeah om het beste uit de situatie te halen doe ik nu maar eerst GeoIP en dan trigger ik de vraag voor betere precieze. Op die manier zit de gebruiker in ieder geval in de buurt.... (Hoewel... Dat ding denkt dat ik in Schinnen woon... Schinnen of all places...)

[crisp]

RobIII schreef op vrijdag 29 juli 2011 @ 12:31:
[...]

Interpretatie of niet; nu (als ik het goed begrijp althans) heb je dus geen manier om te achterhalen of de gebruiker überhaupt een antwoord heeft gegeven of nog gewoon naar die popup zit te staren.
Vind ik, persoonlijk, niet zo heel mooi

Daar ben ik het absoluut mee eens. Overigens deel ik de interpretatie van Mozilla ook niet hoor; 'not now' is in mijn ogen toch duidelijk een negatief antwoord...

[Verwijderd]

Maar toch... Schinnen?! Wie woont er nou in Schinnen?!