Richard Newman [:rnewman] Reporter
	Description • 11 years ago

We need to persist and obey configured proxy data.

	amoghbl1
	Comment 1 • 10 years ago

Hey rnewman, any idea on how one could go about this? I'm currently working with tor and trying to create a new secure browser for android using fennec(https://github.com/amoghbl1/orfox) and solving this would be really useful for it!

	Richard Newman [:rnewman] Reporter
	Comment 2 • 10 years ago

Sorry for the delay getting back to you; last week was unexpectedly busy.

In short: there are several different network stacks in use in the browser as a whole.

* Gecko itself uses Necko, just like desktop. We won't concern ourselves with that here.

* Other parts (e.g., favicon loading) use Android's android.net.http.AndroidHttpClient, which is a pre-configured wrapper around the Android version of Apache HttpClient. This might or might not respect system proxy settings. This is covered in Bug 942653.

* Android Background Services (in the android-sync repo on GitHub) uses a self-contained version of Apache HttpClient (httpclientandroidlib), because targeted versions of Android (a) have a buggy snapshot of HttpClient, and (b) deprecated HttpClient.

There are two ways to approach this bug.


The most straightforward "patch on top" approach is to address each client individually: you'd fix Bug 942653, and then you'd fix this bug, by adding code in the appropriate spot to configure proxy usage in the HttpClient layer.

This might become complicated if you're needing to respect non-system proxy settings -- i.e., those specified in Firefox, or (worse) in Gecko itself. That's because Android Background Services is developed separately, and is barely coupled to Firefox at all. You won't be able to rely on Fennec code, nor on side-effects from Fennec code having run earlier in the same process.


The second approach is to investigate whether SDK 9+ are still problematic from an HTTP library standpoint, and rework android-sync's self-contained HTTP layer accordingly. If you can switch to using android.net.http or HttpURLConnection, without introducing bugs, then you'll be able to reuse implementation code between Fennec core and ABS.


So step one is to figure out exactly what you want to do with proxying (Gecko-defined? Fennec-defined? System-defined?).

Step two is to do research to decide which strategy to take.

Step three is to do it.

Make sense?

	Richard Newman [:rnewman] Reporter
	Comment 3 • 10 years ago

A tiny bit more backstory on this one:

> * Android Background Services (in the android-sync repo on GitHub) uses a
> self-contained version of Apache HttpClient (httpclientandroidlib), because
> targeted versions of Android (a) have a buggy snapshot of HttpClient, and
> (b) deprecated HttpClient.

See <https://code.google.com/p/httpclientandroidlib/>.

At the time Android Sync was built, it had to support Android 5+. We now support 9+. I haven't done recent research to determine if things have improved.

	amoghbl1
	Comment 4 • 10 years ago

So as per the conversation that took place on IRC, I am going to be working on making an api call from LoadFaviconTask.java to get the proxy preferences from gecko and apply it on the httpClient object. This should solve this bug specifically but the other two related bugs are going to need a little more work. What do you think about this approach rnewman?

	Richard Newman [:rnewman] Reporter
	Comment 5 • 10 years ago

That would be a different bug, not this one. Favicon fetching isn't part of background services. See one of the linked bugs. 

But see the conversation snorp and I had about ten days ago: yes, fetching proxy settings from Gecko is part of the solution, but not the way you described. Define a proxy manager in Java, have it initialized by a message from Gecko, persist its state (works across Gecko lifetimes, necessary for solving this bug and pre-Gecko favicon fetches), and have a Gecko-side pref observer to handle changes to proxy settings. Fetches can then very quickly ask the proxy manager to give them a connection object that's correctly configured for proxy use. No immediate contact with Gecko required. 

There will be stumbling blocks around PAC file handling and other things. We'll cross those bridges as we come to them.

Makes sense?

	amoghbl1
	Comment 6 • 10 years ago

OK, we have a PrefsHelper defined on the side of Java to handle preferences, why don't we extend this to save the proxy settings, I think that it's persist by default (need to check that), but this could be used to check settings and we could have gecko call and update these.

	Richard Newman [:rnewman] Reporter
	Comment 7 • 10 years ago

Let's go with a standalone class. It'll need to do much more work than I'd want to cram into PrefsHelper, it makes sense from a design perspective, and it'll make access from background services easier when we come to tackle this bug. 

Remember that the primary mode of operation doesn't involve Gecko at all: we would very infrequently get a change notification from Gecko. I don't mind that living somewhere else. 

See how BrowserLocaleManager is integrated with the system. ProxyManager is a much simpler sibling of that class.

	Nick Alexander :nalexander [he/him]
	Comment 8 • 9 years ago

I'm marking this mentored because we're willing to help with it, but be aware that this is a very complicated ticket.

	Tom Ritter [:tjr] (OOTO until 4/30 at least)
	Comment 10 • 6 years ago

P3 unless the tor mobile devs want to bump it higher.

	Georg Koppen
	Comment 11 • 6 years ago

FWIW: For Tor this is actually much higher priority. Much higher than fixing fingerprinting or cross-site tracking bugs for mobile anyway. Or to put it differently: This is a blocker for Tor Browser on Android for which we at least have to write a patch if it is still an issue.

	Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]
	Comment 12 • 6 years ago

Please let the triage flag be set during Android Sync triage.

	Firefox Bug Husbandry Bot
	Comment 13 • 6 years ago

Re-triaging per https://bugzilla.mozilla.org/show_bug.cgi?id=1473195

Needinfo :susheel if you think this bug should be re-triaged.

	BMO Automation
	Comment 14 • 3 years ago

We have completed our launch of our new Firefox on Android. The development of the new versions use GitHub for issue tracking. If the bug report still reproduces in a current version of [Firefox on Android nightly](https://play.google.com/store/apps/details?id=org.mozilla.fenix) an issue can be reported at the [Fenix GitHub project](https://github.com/mozilla-mobile/fenix/). If you want to discuss your report please use [Mozilla's chat](https://wiki.mozilla.org/Matrix#Connect_to_Matrix) server https://chat.mozilla.org and join the [#fenix](https://chat.mozilla.org/#/room/#fenix:mozilla.org) channel.