Geolocation is not working in the browser

[Jono Bacon]

When going to maps.google.com and getting directions, selecting 'My Location' as the starting point has a spinner that never seems to resolve to the current location.

I am not sure how this gathers a location (geo IP or using GPS).

[Bill Filler (bfiller)]

@jono
Can you try removing /usr/lib/arm-linux-gnueabihf/qt5/plugins/position/libqtposition_geoclue.so on the phone and restarting and see if the results are any different?

[Jono Bacon (jonobacon)]

Doesn't seem to make any difference.

On Wed, May 22, 2013 at 6:27 AM, Bill Filler <email address hidden>wrote:

> @jono
> Can you try removing
> /usr/lib/arm-linux-gnueabihf/qt5/plugins/position/libqtposition_geoclue.so
> on the phone and restarting and see if the results are any different?
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1182658
>
> Title:
> Location services not working in Google Maps
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/webbrowser-app/+bug/1182658/+subscriptions
>

--
Jono Bacon
Ubuntu Community Manager
www.ubuntu.com / www.jonobacon.org
www.identi.ca/jonobacon www.twitter.com/jonobacon

[bjv (bjamesv)]

I have the same issue on saucy-29 Daily (http://cdimage.ubuntu.com/ubuntu-touch-preview/daily-preinstalled/20130629/)

clicking location button on maps.google.com has no effect, and 'My Location' on the directions page just spins

removing /usr/lib/arm-linux-gnueabihf/qt5/plugins/position/libqtposition_geoclue.so and rebooting has no visible impact on the behavior.

- No additional information is printed when running webbrowser-app from Terminal.
- http://html5demos.com/geo/ just sits at 'checking...'

[Bill Filler (bfiller)]

still not working in browser on 09.20.13 build. The browser now prompts that location is being requested, and after pressing "Allow" neither site mentioned was able to return the location. I see a process called "service" get launched and sometimes max the cpu.

[Thomas Voß (thomas-voss)]

Can you please check dmesg output and see if satellite visibility updates are reported there? Just flashed the latest image on GN and it is working for me.

@CPU maxing: The location HAL randomly enters an invalid state when trying to access AGPS information and subsequently spins, with the service maxing the CPU as a result. Digging into the issue.

[Olivier Tilloy (osomon)]

I’m seeing the same problem. The browser prompts for authorization to use the device’s location, but it seems the device is unable to provide its location. I looked for satellite visibility updates in dmesg, but couldn’t find anything relevant (`dmesg | grep -i sat` is empty).

[bjv (bjamesv)]

just flashed 2013-09-08.2 build to GN, i see the 'service' process launch and use 2-11% cpu after pressing 'Allow' (http://html5demos.com/geo/), but after long waits nothing prints to dmesg and eventually webbrowser-app seems to close/crash.

all subsequent attempts to open http://html5demos.com/geo/ prompt for 'Allow' but immediately exit (crash?) when tapped.

[Thomas Voß (thomas-voss)]

On Wed, Sep 25, 2013 at 5:48 AM, bjv <email address hidden> wrote:
> just flashed 2013-09-08.2 build to GN, i see the 'service' process
> launch and use 2-11% cpu after pressing 'Allow'
> (http://html5demos.com/geo/), but after long waits nothing prints to
> dmesg and eventually webbrowser-app seems to close/crash.
>

To eliminate variables, could you try:

  (1.) sudo apt-get install qtlocation5-examples
  (2.) /usr/lib/arm.../qt5/examples/qtlocation/declarative/flickr/qml_location_flickr

There is a small "window" having lat/lon markers. You need to tap on
its title bar to start position updates.
If that part works for you, we need to investigate into the
browser/qtwebkit and its use of qtlocation.

> all subsequent attempts to open http://html5demos.com/geo/ prompt for
> 'Allow' but immediately exit (crash?) when tapped.
>
> --
> You received this bug notification because you are a bug assignee.
> https://bugs.launchpad.net/bugs/1182658
>
> Title:
> Location services not working in Google Maps
>
> Status in Web Browser App:
> Confirmed
> Status in “location-service” package in Ubuntu:
> Confirmed
> Status in “webbrowser-app” package in Ubuntu:
> Confirmed
> Status in “location-service” source package in Saucy:
> Confirmed
> Status in “webbrowser-app” source package in Saucy:
> Confirmed
>
> Bug description:
> When going to maps.google.com and getting directions, selecting 'My
> Location' as the starting point has a spinner that never seems to
> resolve to the current location.
>
> I am not sure how this gathers a location (geo IP or using GPS).
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/webbrowser-app/+bug/1182658/+subscriptions

[bjv (bjamesv)]

installed qtlocation5-examples, but when running /usr/lib/arm-linux-gnueabihf/qt5/examples/qtlocation/declarative/flickr/qml_location_flickr > example.out 2>&1 from the terminal app on the device the small dialogue says only "Source: source error", no change when tapping on the small box's title bar.

As an additional test I flashed 20130925.2 to the GN, tapped location indicator check location detection + GPS, rebooted the device and again ran /usr/lib/arm-linux-gnueabihf/qt5/examples/qtlocation/declarative/flickr/qml_location_flickr > example.out 2>&1

no change in behavior or output (below):
loaded the dummy plugin
loaded the Linux plugin
Registered the AalSensorPlugin types

QObject::connect: No such slot QGeoPositionInfoSourceUbuntu::updateTimeout()
callbacks 0x423e898d 0x423e8939
creating surface at (0, 58) with size (720, 1222) with title 'Window 1'

[Olivier Tilloy (osomon)]

I’m seeing the same as bjv, with the latest image flashed today (#83).

[Olivier Tilloy (osomon)]

Following Thomas’ advice, I tested again with my device hanging from a window, and the test application eventually picked up the location from the GPS. However I still can’t get it to work in the browser, so it seems the issue is in QtWebKit itself.
Investigating now.

[Olivier Tilloy (osomon)]

Note that geolocation works in webbrowser-app on the desktop, so the issue is somewhere in the communication between the location provider and QtWebKit on devices.

[Olivier Tilloy (osomon)]

I wrote a simple C++ application that uses QtLocation to monitor location updates and print them out on the console, I built it on my device and ran it, and after a while (cold start is really slow) I got location updates, so I can confirm that the location stack works.

[Olivier Tilloy (osomon)]

When trying to use geolocation in the browser, the app sits idle for a while, and is eventually terminated with the following:

terminate called after throwing an instance of 'std::runtime_error'
  what(): Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
Aborted (core dumped)

[Olivier Tilloy (osomon)]

Unfortunately I’m unable to get a useful stacktrace from the crash, so I don’t know exactly where the crash happens.

It seems that the app fails to reach the service, for some reason.

[Olivier Tilloy (osomon)]

I managed to get a partially useful stacktrace:

#0 0x40f99706 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
#1 0x40fa75fe in raise () from /lib/arm-linux-gnueabihf/libc.so.6
#2 0x40fa9e1a in abort () from /lib/arm-linux-gnueabihf/libc.so.6
#3 0x40f217b4 in __gnu_cxx::__verbose_terminate_handler ()
    at ../../../../src/libstdc++-v3/libsupc++/vterminate.cc:95
#4 0x40f201d4 in __cxxabiv1::__terminate (handler=<optimized out>)
    at ../../../../src/libstdc++-v3/libsupc++/eh_terminate.cc:38
#5 0x40f1f67e in __cxa_call_terminate (ue_header=0x48a2e058)
    at ../../../../src/libstdc++-v3/libsupc++/eh_call.cc:54
#6 0x40f1ff0c in __cxxabiv1::__gxx_personality_v0 (state=<optimized out>,
    ue_header=0x48a2e058, context=<optimized out>)
    at ../../../../src/libstdc++-v3/libsupc++/eh_personality.cc:670
#7 0x4008879a in unwind_phase2 (ucbp=ucbp@entry=0x48a2e058,
    vrs=vrs@entry=0xbed5a004) at ../../../src/libgcc/unwind-arm-common.inc:294
#8 0x4008896a in __gnu_Unwind_Resume (ucbp=0x48a2e058, entry_vrs=0xbed5a004)
    at ../../../src/libgcc/unwind-arm-common.inc:502
#9 0x40089172 in _Unwind_Resume ()
    at ../../../src/libgcc/config/arm/libunwind.S:344
#10 0x42daaee6 in com::ubuntu::location::service::session::Stub::stop_position_updates() () from /usr/lib/arm-linux-gnueabihf/libubuntu-location-service.so.0
#11 0x490f44c4 in ?? () from /usr/lib/arm-linux-gnueabihf/libQt5WebKit.so.5
#12 0x490f44c4 in ?? () from /usr/lib/arm-linux-gnueabihf/libQt5WebKit.so.5
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Unfortunately if I install the debug symbols for QtWebKit, gdb runs out of memory when loading them. At least we know where in the location service the exception is thrown.

[Olivier Tilloy (osomon)]

I am able to reproduce the crash with a simple test program written in C++ that uses QtLocation to retrieve the current location. The crash happens when calling QGeoPositionInfoSource::stopUpdates() (which itself calls com::ubuntu::location::service::session::Stub::stop_position_updates()), so I’d say the problem lies in the location provider after all.

[Olivier Tilloy (osomon)]

For reference, I’m attaching the sources of the simple test program with which I can reproduce the crash on a device.

[Olivier Tilloy (osomon)]

I installed libubuntu-location-service0 built from the latest trunk (revision 40), that supposedly removes some exception throwing, however I’m still getting a very similar stacktrace:

[…]
#9 0x400af172 in _Unwind_Resume ()
    at ../../../src/libgcc/config/arm/libunwind.S:344
#10 0x42e23eee in com::ubuntu::location::service::session::Stub::stop_position_updates() () from /usr/lib/arm-linux-gnueabihf/libubuntu-location-service.so.0
#11 0x4f7b4a08 in ?? ()
Cannot access memory at address 0x1f
#12 0x4f7b4a08 in ?? ()
Cannot access memory at address 0x1f
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

So it seems stop_position_updates() still throws an exception. Here is the current implementation of this method:

    void culss::Stub::stop_position_updates() noexcept
    {
        auto result = d->object->invoke_method_synchronously<Interface::StopPositionUpdates,void>();

        if (result.is_error())
            LOG(WARNING) << result.error();
    }

[Olivier Tilloy (osomon)]

invoke_method_synchronously calls send_with_reply_and_block_for_at_most, which might throw a std::runtime error.
So we need to surround this call with a try…catch block to ensure we respect the noexcept promise.

[Olivier Tilloy (osomon)]

I can confirm that geolocation in the browser works with the last two fixes applied to lp:location-service.

[Olivier Tilloy (osomon)]

Attaching a visual proof that it works :)

[Launchpad Janitor (janitor)]

This bug was fixed in the package location-service - 0.0.1+13.10.20131011-0ubuntu1

---------------
location-service (0.0.1+13.10.20131011-0ubuntu1) saucy; urgency=low

  [ thomas-voss ]
  * Replace throwing an exception with logging, fulfill the noexcept
    promise. (LP: #1182658)

  [ Olivier Tilloy ]
  * Really fulfil the noexcept promise. (LP: #1182658)

  [ Ubuntu daily release ]
  * Automatic snapshot from revision 41
 -- Ubuntu daily release <email address hidden> Fri, 11 Oct 2013 05:41:09 +0000

[Bill Filler (bfiller)]

re-opening this to track the pending work with webbrowser-app and oxide to make this work again

[Launchpad Janitor (janitor)]

This bug was fixed in the package webbrowser-app - 0.23+14.10.20140620-0ubuntu1

---------------
webbrowser-app (0.23+14.10.20140620-0ubuntu1) utopic; urgency=low

  [ Olivier Tilloy ]
  * Re-enable the geolocation permission request dialog, now that it is
    implemented in oxide. Fix it in the webkit-based webapp container.
    (LP: #1182658)
  * Temporarily work around bug #1328839 in qtubuntu by not toggling
    fullscreen on the window on devices. Once the Qt compositor work
    lands (scheduled for mid July), the bug should be resolved and this
    workaround can be removed. (LP: #1328839)
 -- Ubuntu daily release <email address hidden> Fri, 20 Jun 2014 09:27:06 +0000

[Mitchell (curious-mitchell)]

Still finding an issue with this bug in rtm 5 on mako - not sure where work is at with this, but NONE of the webapp maps are working. This includes google maps, here maps, and osm maps.

[Loïc Minier (lool)]

This bug was about a specific issue which got resolved; there might be other bugs tracked elsewhere, like:
https://bugs.launchpad.net/ubuntu/+source/location-service/+bug/1382501
which affected webapps; this one has a fix proposed in rtm silo 4