Bug 56468 – [Symbian][Qt] Webkit 2.1 requires Location capability

• Component: WebKit Qt
• Status: RESOLVED INVALID

[Lucian Tomuta]

It would appear that QtWebkit 2.1 requires Location capability in oder to support the geocoding feature. If the application loading webkit does not have this capability (presumably any API built against earlier QtWebkit) then loading any website which will try to access the geocoding feature will cause the application to panic:

STOPPED: pc=80441e1b pid=9c3 tid=9c4 - Thread 0x9c4 has panicked. Category: Lbs Client Fault; Reason: 6

( see QTBUG-15716 )

The issue was already addressed here in bug 43235 but the fix applied there does not seem to go to the core of the problem. Yes, the crash can be avoided by adding the Location capability but that is not an option for existing applications, which would have to be rebuilt in order to have the capability added to them.

The correct way of handling this is for the Webkit code to be modified such that it would not crash if the capability is missing. Whether that requires better error handling or simply not calling the location acquisition APIs when the capability is not present in the running process, that remains to be decided by whoever knows the internal implementation best.

The API call used to enable the geolocation feature may then be modified so that it gives error/warning to developers if the capability Location is now available.

[Janne Koskinen]

Right. This means checking the capabilities in Webkit geolocation API backend in Symbian. If capability is missing return PERMISSION_DENIED http://dev.w3.org/geo/api/spec-source.html#permission_denied_error .

As you know missing capabilities are already reported by S60 emulator environment so I'm not sure if additional notification to developer is required other than document this requirement. Maybe something similar should be added to Qt Creator simulator environment. If wanted, in debug mode, printing out a warning is an option. Problem here is that we don't build Webkit for debug due to it's size. i.e. if there would be a print it would have to go to release code.

Now how to evaluate the importance of this issue. We can assume that not everyone has built QtWebkit based browser application on top of Qt 4.6.3. Binary Break then can be limited to applications using services that have geolocation or introduces geolocation later. My concern is in latter as we don't really know which services will introduce geolocation and neither does the developer. For this I'd say this is very high risk issue and blocker is the correct assessment.

[Janne Koskinen]

I'll poke around but it would be appreciated if guys who wrote the geolocation backend could also look into this.

[Janne Koskinen]

Created attachment 86061 [details]
one option

So reading the geolocation code a bit more. Attached my first idea which would be non-intrusive to webkit code.
Least what needs to be disabled is the user prompt and the loading of the GeolocationServiceQt from QtMobility. Patch does latter.

Anyone know a common entry point for these? I looked at WebCore\page\geolocation.cpp but not quite sure if this is the correct place.
Problem again for me is that I can't set breakpoints in Symbian so actual runtime stuff can be found only with debug prints.

[Mahesh Kulkarni]

This is QtMobility issue and seems like they have fixed this issue in http://bugreports.qt.nokia.com/browse/QTMOBILITY-691

Janne, can you try with your use case including the above fix?

 - Also "Permission Denied" error isn't something expected when QtMobility fails to initialize GPS. "Position Unavailable" is the error given back to JS

[Mahesh Kulkarni]

(In reply to comment #4)
> This is QtMobility issue and seems like they have fixed this issue in http://bugreports.qt.nokia.com/browse/QTMOBILITY-691
> 
> Janne, can you try with your use case including the above fix?
> 
>  - Also "Permission Denied" error isn't something expected when QtMobility fails to initialize GPS. "Position Unavailable" is the error given back to JS

Confirmed with QtMobility team that the fix has been released to 1.2.0. Please mark the bug resolved once you varify?

[Janne Koskinen]

(In reply to comment #5)
> (In reply to comment #4)
> > This is QtMobility issue and seems like they have fixed this issue in http://bugreports.qt.nokia.com/browse/QTMOBILITY-691
> > 
> > Janne, can you try with your use case including the above fix?
> > 
> >  - Also "Permission Denied" error isn't something expected when QtMobility fails to initialize GPS. "Position Unavailable" is the error given back to JS
> 
> Confirmed with QtMobility team that the fix has been released to 1.2.0. Please mark the bug resolved once you varify?

Sure. I'll check device packages to see which week this fix went into or if it is already in. This sets dependency to QtMobility 1.2.0 then...

[Janne Koskinen]

After a discussing release schedules, QtMobility 1.2.0 is too late for our release. We need this workaround just for QtWebkit2.1.

Argh.. We need to start locking all dependencies to versions.

[Ademar Reis]

We're about to release 2.1.0... should this block the release or not?

[Janne Koskinen]

Yes it should be added as a blocker. We can't wait for QtMobility 1.2.0 and backporting was said to be not possible (as the mobility releases have been released).

I'll create a proper patch for 2.1 out of my suggestion.

[Ademar Reis]

Blocking 2.1.x for now (not sure if we'll have time to include the fix in 2.1.0)

[Janne Koskinen]

Something related, with up-to-date QtWebkit2.1 I get

Error: L6200E: Symbol WebCore::GeolocationService::s_factoryFunction multiply
defined (by GeolocationService.o and GeolocationServiceQt.o).

when building with --client-based-geolocation.

[Mahesh Kulkarni]

(In reply to comment #11)
> Something related, with up-to-date QtWebkit2.1 I get
> 
> Error: L6200E: Symbol WebCore::GeolocationService::s_factoryFunction multiply
> defined (by GeolocationService.o and GeolocationServiceQt.o).
> 
> when building with --client-based-geolocation.

Its enabled by default. Just do a clean build (remove WebKitBuild folder).

[Laszlo Gombos]

I would recommend not to work around this QtMobility problem in WebKit - removing the bug from the 2.1 blocker list. 

QtMobility fix for this is available both in QtMobility 1.1 branch and in Mobility trunk.

[Janne Koskinen]

> Its enabled by default. Just do a clean build (remove WebKitBuild folder).

Umm, I think I used wrong wording :) I used latest 2.1.0 which required a fix to make it to link.

[Janne Koskinen]

(In reply to comment #13)
> I would recommend not to work around this QtMobility problem in WebKit - removing the bug from the 2.1 blocker list. 
> 
> QtMobility fix for this is available both in QtMobility 1.1 branch and in Mobility trunk.

I checked today and W13 included the fix for Symbian^3. For 5.0 QtMobility.sis didn't include the fix, but if you say it is there then -> invalid.