Closed gcb closed 4 years ago
geo.enabled=false
breaks badly-coded sites when they try to accessnavigator.geolocation
directly.
Can you give an example?
I can't link to anything as my use cases was a real state site map search, behind a login.
But a proof of concept is pretty easy, just call the API on the code. It will cause an error on the thread since the geo object will be missing, and prevent the rest of the code (in my case, global scope) from continuing execution.
After my changes, it will instead work fine, but the API will trigger a callback with the exact same side effect as if the user had pressed Deny on the UI permission dialog.
Sorry but we can't set geo.enabled
to true
as it's against everything this project stands for, so I'm closing this. If you have some other work arounds for the breakage please let us know.
it's against everything this project stands for
The privacy side effect is the same.
today: site can't see the geo interface, and some sites break.
with the proposed change (unless i'm missing something): site will always be denied geo interface usage, without ever asking the user. No site break.
geo.enabled=false
breaks badly-coded sites when they try to accessnavigator.geolocation
directly.A better approach to replace the functionality of
geo.enabled=false
without breaking any site, is to setpermissions.default.geo=2
which silently and automatically denies geolocation requests (just likegeo.enabled=false
would do)wifi.logging
doesn't do anything for the last 10 firefox verions. So removed.