Bug 1685152 Comment 11 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

> As Petru mentioned, we'd ideally use just one parser in both Android code and Gecko, but extracting the Gecko parsers into a separate library that does not depend on libxul is non trivial.

Hi Valentin, thank you for chiming in! Your help is much appreciated. Can you expand a little bit on why do the parsers need to be extracted into a separate library?

> One of the main issues with having two URL parsers in Android and Gecko is that the Gecko nsIURI mostly aims to comply with the WHATWG URL standard, while the android URI and URL implementations are aligned with rfc3986 (as far as I know). This difference results in issues like bug 1813919.

Interesting, I was not aware of that. Do you happen to know the reason why they are different? My understanding has been that we would not have a separate parsers on the Android side, and instead replace them with the Gecko one. Do you know of any reasons we cannot do that? (At the moment it is not clear to me why would we want to use a Java library, if this functionality is already implemented in Gecko)

> I think one of the issues with that was that you still need libxul to be loaded to use JNI to call these xpcom methods, which I assume is not always the case. Petru, please correct me if that's not accurate.

This is the first time I hear that libxul is not loaded.... Without libxul neither GeckoView, nor Fenix would be able to function. What led you to that conclusion? Unless we are now discussing Android Components, which has the ability to swap the browsing engine - yes, if you use WebView, libxul would not be loaded. This is a GeckoView bug, however. Or are we discussing possibility of libxul not having loaded correctly / ending up in a bad state?
> As Petru mentioned, we'd ideally use just one parser in both Android code and Gecko, but extracting the Gecko parsers into a separate library that does not depend on libxul is non trivial.

Hi Valentin, thank you for chiming in! Your help is much appreciated. Can you expand a little bit on why do the parsers need to be extracted into a separate library?

> One of the main issues with having two URL parsers in Android and Gecko is that the Gecko nsIURI mostly aims to comply with the WHATWG URL standard, while the android URI and URL implementations are aligned with rfc3986 (as far as I know). This difference results in issues like bug 1813919.

Interesting, I was not aware of that. Do you happen to know the reason why they are different? My understanding has been that we would not have a separate parsers on the Android side, and instead replace them with the Gecko one. Do you know of any reasons we cannot do that? (At the moment it is not clear to me why would we want to use a Java library, if this functionality is already implemented in Gecko)

> I think one of the issues with that was that you still need libxul to be loaded to use JNI to call these xpcom methods, which I assume is not always the case. Petru, please correct me if that's not accurate.

This is the first time I hear that libxul is not loaded.... Without libxul neither GeckoView, nor Fenix would be able to function. What led you to that conclusion? Unless we are now discussing Android Components, which has the ability to swap the browsing engine - yes, if you use WebView, libxul would not be loaded. This is a GeckoView bug, however. Or are we discussing possibility of libxul not having loaded correctly / ending up in a bad state? Are there any other specific situations you have in mind?

Back to Bug 1685152 Comment 11