I'm afraid that I've tested this patch against 16.0b4 and it does not resolve the issue on Ubuntu 10.04 which is exactly what I expected, having previously spent a lot of time tracing this stuff to establish where the popup dialog comes from.
I honestly don't see how anyone gets a popup with the error in this bug when only gconf is in use. But anyway, the proposed fix patches the function nsGConfService::GetAppForProtocol to prevent a '+' sign being looked up by the GConf client.
But due to the following code, that function is only called if GIO is not enabled and in my experience, that code path does only causes a message to stdout and not a popup:
uriloader/exthandler/unix/nsGNOMERegistry.cpp
28 nsGNOMERegistry::HandlerExists(const char *aProtocolScheme)
29 {
30 nsCOMPtr<nsIGIOService> giovfs = do_GetService(NS_GIOSERVICE_CONTRACTID);
31 nsCOMPtr<nsIGConfService> gconf = do_GetService(NS_GCONFSERVICE_CONTRACTID);
32 if (giovfs) {
33 nsCOMPtr<nsIGIOMimeApp> app;
34 if (NS_FAILED(giovfs->GetAppForURIScheme(nsDependentCString(aProtocolScheme),
35 getter_AddRefs(app))))
36 return false;
37 else
38 return true;
39 } else if (gconf) {
40 bool isEnabled;
41 nsCAutoString handler;
42 if (NS_FAILED(gconf->GetAppForProtocol(nsDependentCString(aProtocolScheme), &isEnabled, handler)))
43 return false;
44
45 return isEnabled;
46 }
47
48 return false;
49 }
So we could apply almost the exactly the same change to GetAppForURIScheme although in newer versions of GIO, the perfectly valid '+' character in a URI is handled.
The best long-term fix would determine if the version of libgio is greater then whenever they stopped backing-off URI Handler lookups to GConf in GIO, and then to block '+' signs if using the older version and allow then with the newer version.
It really all depends on whether anyone cares if Thunderbird can't automatically turn URIs containing a plus sign to the left of the colon into a link. If not, then just always block plus signs in GetAppForURIScheme and this is fixed.
I should add that this bug is really the fault of the GNOME Team for choosing a datastore for URI Handlers which cannot actually support all valid URIs. However, GNOME has moved on: The latest versions don't have this problem and I can't see them back-porting any changes to GConf so this will have to be fixed from the Thunderbird side.
(In reply to <email address hidden> from comment #56)
> Comment on attachment 680081
> fix for gconf v1
>
> Sorry, we can't accept a diff against the mozilla-beta part of a comm-beta
> checkout. If you think the issue affects Thunderbird 17 then you will need
> to submit a patch against mozilla-central and get it uplifted to
> mozilla-beta.
>
> Also I'm not a reviewer for toolkit/system/gnome, please try karlt instead.
(In reply to jhorak from comment #55)
> Created attachment 680081
> fix for gconf v1
>
> This is simple hack to avoid showing the error window. It shouldn't affect
> Firefox or Thunderbird when GIO backend was enabled, as long as gvfs is used
> only as fallback when GIO service is not available. This fix suitable for
> long time support version of Linux (like RHEL or Ubuntu).
I'm afraid that I've tested this patch against 16.0b4 and it does not resolve the issue on Ubuntu 10.04 which is exactly what I expected, having previously spent a lot of time tracing this stuff to establish where the popup dialog comes from.
I honestly don't see how anyone gets a popup with the error in this bug when only gconf is in use. But anyway, the proposed fix patches the function nsGConfService: :GetAppForProto col to prevent a '+' sign being looked up by the GConf client.
But due to the following code, that function is only called if GIO is not enabled and in my experience, that code path does only causes a message to stdout and not a popup: exthandler/ unix/nsGNOMEReg istry.cpp ::HandlerExists (const char *aProtocolScheme) nsIGIOService> giovfs = do_GetService( NS_GIOSERVICE_ CONTRACTID) ; nsIGConfService > gconf = do_GetService( NS_GCONFSERVICE _CONTRACTID) ; nsIGIOMimeApp> app; giovfs- >GetAppForURISc heme(nsDependen tCString( aProtocolScheme ), AddRefs( app)))) gconf-> GetAppForProtoc ol(nsDependentC String( aProtocolScheme ), &isEnabled, handler)))
uriloader/
28 nsGNOMERegistry
29 {
30 nsCOMPtr<
31 nsCOMPtr<
32 if (giovfs) {
33 nsCOMPtr<
34 if (NS_FAILED(
35 getter_
36 return false;
37 else
38 return true;
39 } else if (gconf) {
40 bool isEnabled;
41 nsCAutoString handler;
42 if (NS_FAILED(
43 return false;
44
45 return isEnabled;
46 }
47
48 return false;
49 }
So we could apply almost the exactly the same change to GetAppForURIScheme although in newer versions of GIO, the perfectly valid '+' character in a URI is handled.
The best long-term fix would determine if the version of libgio is greater then whenever they stopped backing-off URI Handler lookups to GConf in GIO, and then to block '+' signs if using the older version and allow then with the newer version.
It really all depends on whether anyone cares if Thunderbird can't automatically turn URIs containing a plus sign to the left of the colon into a link. If not, then just always block plus signs in GetAppForURIScheme and this is fixed.
I should add that this bug is really the fault of the GNOME Team for choosing a datastore for URI Handlers which cannot actually support all valid URIs. However, GNOME has moved on: The latest versions don't have this problem and I can't see them back-porting any changes to GConf so this will have to be fixed from the Thunderbird side.
(In reply to <email address hidden> from comment #56) system/ gnome, please try karlt instead.
> Comment on attachment 680081
> fix for gconf v1
>
> Sorry, we can't accept a diff against the mozilla-beta part of a comm-beta
> checkout. If you think the issue affects Thunderbird 17 then you will need
> to submit a patch against mozilla-central and get it uplifted to
> mozilla-beta.
>
> Also I'm not a reviewer for toolkit/
(In reply to jhorak from comment #55)
> Created attachment 680081
> fix for gconf v1
>
> This is simple hack to avoid showing the error window. It shouldn't affect
> Firefox or Thunderbird when GIO backend was enabled, as long as gvfs is used
> only as fallback when GIO service is not available. This fix suitable for
> long time support version of Linux (like RHEL or Ubuntu).