geolocation.getCurrentPosition() continues to return error after re-enabling location in DevTools
Reported by
zac.spit...@gmail.com,
Dec 11
|
|||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.80 Safari/537.36 Steps to reproduce the problem: There is a problem with toggling off Emulate Geolocation Co-ordinates After using Emulate Geolocation Co-ordinates, once you disable it, even with maximumAge:0 navigator.getCurrentPosition continues to return the 0,0 result It seems there is some caching of the result going on, with enabling emulate position unavailable and then turning it off, I'm seeing TIMEOUT and POSITION_UNAVAILABLE results. This is a per tab problem, open a new tab and it's ok. I have seen this happen in web apps as well (without emulation being involved), once a webpage stops returning a position, it never works again. Open Google maps in the same browser (new tab) or the app and they can get the location without issue. (from https://bugs.chromium.org/p/chromium/issues/detail?id=542923#c1 ) What is the expected behavior? After setting geolocation to Location unavailable, it should be possible to re-then enable geolocation What went wrong? cached results are returned Did this work before? N/A Chrome version: 71.0.3578.80 Channel: stable OS Version: 10.0 Flash Version:
,
Dec 12
,
Dec 12
James to put together a test case to confirm this issue.
,
Dec 12
,
Dec 19
I put this really simple quick demo and I could not recreate this issue(https://jameshollyer.github.io/api-tests/get-current-position.html). @zac.spitzer@gmail.com could you please take a look at this and let me know why I am not able to recreate your issue with this demo?
,
Dec 20
I have attached a tweaked version of your script, with console logging and also setting the timeout to be less than the refresh interval is better to occasionally demonstrate the extra timeout callback too (which only happens after you play around for a while.... it's weird) 1. open a new tab, open dev tools, set sensor to other, override to 0,0 2. open the demo url, Error(2) is returned. 3. select Berlin, location is returned. 4. edit the Berlin co-ords to 0,0, 0,0 is returned 5. set location unavailable, Error(2) is returned 6. go back to other which is still set to 0,0, Error(2) is returned it definitely starts to behave more weirdly in tab after you start playing around and perhaps reload a few times, as the location state is per tab and doesn't get reset with page reloads that's what I can reliably reproduce at the moment with canary on windows 10
,
Jan 17
(5 days ago)
Issue has been resolved with this CL: https://chromium-review.googlesource.com/c/chromium/src/+/1396862
,
Jan 17
(5 days ago)
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/a88364d518f8d9491e9482f5fe5e892a66f6d7b0 commit a88364d518f8d9491e9482f5fe5e892a66f6d7b0 Author: James Hollyer <jameshollyer@chromium.org> Date: Thu Jan 17 23:10:38 2019 Devtools: Apply location on switch to custom mode This change parses the custom location provided by the user and switches the override to that location when switching the mode to "custom". Without this the emulated location remains set to its previous value even if the user provided a custom one. Bug: 913922 Change-Id: I9b087aa1048d4dbef0408171d00cfaceee85b9b0 Reviewed-on: https://chromium-review.googlesource.com/c/1396862 Reviewed-by: Reilly Grant <reillyg@chromium.org> Reviewed-by: Andrey Kosyakov <caseq@chromium.org> Commit-Queue: James Hollyer <jameshollyer@chromium.org> Cr-Commit-Position: refs/heads/master@{#623894} [modify] https://crrev.com/a88364d518f8d9491e9482f5fe5e892a66f6d7b0/third_party/blink/renderer/devtools/front_end/emulation/SensorsView.js |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by susan.boorgula@chromium.org
, Dec 11