Issue 2807 - MOBILE3901_2015070622_RELBRANCH merge conflicts

Issue 2807 - MOBILE3901_2015070622_RELBRANCH merge conflicts

[René Jeschke, 2015-07-20 16:54:01]

Re-uploaded, diff was applied in the wrong direction :-D

[René Jeschke, 2015-07-20 17:16:02]

https://codereview.adblockplus.org/29322687/diff/29322688/mobile/android/app/...
File mobile/android/app/mobile.js (right):

https://codereview.adblockplus.org/29322687/diff/29322688/mobile/android/app/...
mobile/android/app/mobile.js:814: // These prefs require a restart to take
effect.
Yes, we probably want to change those three to 'false' again, I bet those cause
this here: https://issues.adblockplus.org/ticket/2785

[Felix Dahlke, 2015-07-22 16:19:19]

Looks good, can see nothing which still has to be change. A bunch of things we
need to investigate, however.

https://codereview.adblockplus.org/29322687/diff/29322688/docshell/base/nsAbo...
File docshell/base/nsAboutRedirector.cpp (right):

https://codereview.adblockplus.org/29322687/diff/29322688/docshell/base/nsAbo...
docshell/base/nsAboutRedirector.cpp:80: "memory",
"chrome://global/content/aboutMemory.xhtml",
We should check about:memory and about:compartments for Mozilla references.

https://codereview.adblockplus.org/29322687/diff/29322688/mobile/android/app/...
File mobile/android/app/mobile.js (right):

https://codereview.adblockplus.org/29322687/diff/29322688/mobile/android/app/...
mobile/android/app/mobile.js:104: pref("network.predictor.enabled", true);
I wonder if we actually want this. How I understand it, this will lead to
requests happening before the user clicks on a link - not convinced that this is
great from a privacy perspective. We should figure out what this really does.
Asking Wladimir, maybe he knows.

Which reminds me: I suggested a while ago that we keep a close eye on the
network requests happening in Adblock Browser, to ensure nothing unexpected is
happening, we should be on top of that. Can you look into that?

It'd be lovely to have automated tests for this, that load a bunch of sites and
see if any requests are happening that weren't whitelisted by the test. But for
now I guess we have to do this manually. If we explain how, our testers could do
it.

https://codereview.adblockplus.org/29322687/diff/29322688/mobile/android/app/...
mobile/android/app/mobile.js:180: pref("extensions.enabledScopes", 1);
Needs to be 4, but you already fixed that in a later commit. Might not hurt to
add a comment here too.

https://codereview.adblockplus.org/29322687/diff/29322688/mobile/android/app/...
mobile/android/app/mobile.js:861:
pref("extensions.adblockplus.preconfigured.suppress_first_run_page", true);
Since this one has nothing to do with Firefox, we might want to move it to the
bottom. Doesn't matter too much however, it's unlikely for upstream to set
overwrite this pref below :P

https://codereview.adblockplus.org/29322687/diff/29322688/mobile/android/base...
File mobile/android/base/BrowserApp.java (right):

https://codereview.adblockplus.org/29322687/diff/29322688/mobile/android/base...
mobile/android/base/BrowserApp.java:909: // We can't show the first run
experience until Gecko has finished initialization (bug 1077583).
lol, their term for this is even worse, "first run experience". Anyway, WE don't
need Gecko for our stuff, maybe we should trigger our stuff earlier then? Well,
doesn't have anything to do with the merge, if you agree let's tackle it in a
follow-up.

https://codereview.adblockplus.org/29322687/diff/29322688/mobile/android/base...
mobile/android/base/BrowserApp.java:2451: private void showFirstrunPager() {
Also more for the record, there's a change for re-adding our start pane under
review.

https://codereview.adblockplus.org/29322687/diff/29322688/mobile/android/conf...
File mobile/android/confvars.sh (right):

https://codereview.adblockplus.org/29322687/diff/29322688/mobile/android/conf...
mobile/android/confvars.sh:74: MOZ_INSTALL_TRACKING=1
Is this going to send data to Mozilla? We should check.