1563990 - Load more comments JS on mobilenet.cz behaving strangely

Status: RESOLVED FIXED

(GeckoView :: General, defect, P2)

Description

[Emily Kager [:ekager]]

Filed in Fenix here: https://github.com/mozilla-mobile/fenix/issues/3917

STR:

1. go to mobilenet.cz
2. click on any article with more than 4 comments
3. scroll down to comment section (called DISKUZE KE ČLÁNKU)
4. click on "NAČÍST VŠECHNY KOMENTÁŘE" (load all comments)

Expected: More comments are displayed

Actual: This is displayed: https://user-images.githubusercontent.com/2920574/60758676-3fb60c80-a01a-11e9-8747-8a099fee6799.jpg

Can reproduce in Reference Browser. Cannot reproduce in Chrome.

Comment 1

[Chris Peterson [:cpeterson]]

Emily, can you reproduce this bug in Fennec 68? Does enabling or disabling Tracking Protection make a difference?

Comment 2

[Emily Kager [:ekager]]

Not reproducing on Fennec, but reproducing with and without TP in Fenix

Comment 3

[Chris Peterson [:cpeterson]]

Thomas, I think this bug is a webcompat issue on Android, but it affects Fenix (with or without Tracking Protection) but not Fennec (with or without Tracking Protection). What is the process for getting an Android bug on the Webcompat team's triage radar?

Comment 4

[Thomas Wisniewski [:twisniewski]]

You've basically just done what was needed; just ni? at least one of myself, :denschub, :miketaylr, :ksenia, and :karlcow. If you're not sure who would be best, ni? :miketaylr first.

As for what's going on here, it looks like there are click listeners added on that "load more" link in Fennec, but not in Fenix. Without that handler, the link just takes you to the URL ?script=LoadMore&t=1&o1=article&o2=38409, so it makes sense that the user would end up on a page filled with gibberish script text.

It seems that the click handler is added in this script:

var App = App || {
};
App.loader = {
handle: $('[data-load2]'),
init: function () {
  var t = this;
  this.handle.click(function (n) {
    t.load(n)
  })
},

I see Fenix hitting the App.loader line when I place a breakpoint on it, but it never gets into the init function. Fennec does, with this stack trace:

init (general_gui.js#50)
<anonymous> (app.js#1)
each (jquery.js#1)
<anonymous> (app.js#1)
l (jquery.js#1)
c (jquery.js#1)

That is, it goes through this script:

'use strict';
var App = App || {
};
$(function () {
  objectFitImages(),
  $.each(App, function (p, n) {
    null != App[p] && 'function' == typeof App[p].init && App[p].init(),
    null != App[p] && 'function' == typeof App[p].scroll && (App[p].scroll(), $(window).scroll(function () {
      App[p].scroll()
    })),
    null != App[p] && 'function' == typeof App[p].resize && (App[p].resize(), $(window).resize(function () {
      App[p].resize()
    }))
  })
});

Where App is a list of apps including the one above. Unfortunately, that App comes after one named firebase, which is failing to initialize, with this console output:

Error: Messaging: This browser doesn't support the API's required to use the firebase SDK. (messaging/unsupported-browser). errors.ts:92:4
ReferenceError: sssp is not defined AdvSSP_2.js:182:13
    initSSP https://www.richmedia.cz/ssp/AdvSSP_2.js:182
    Init https://www.richmedia.cz/ssp/AdvSSP_2.js:25

Where SSSP is advertising-related:

        if(getCookie(_arrData[element].nameCookie) != 'hide') {
            //console.log("seznamad", sssp);
            sssp.getAds(data);
        } else {

And sure enough, Fenix is blocking scripts which may be related:

The resource at “https://ssp.imedia.cz/static/js/ssp.js” was blocked because content blocking is enabled. xiaomi-mi-a3-dorazilo-ma-amoled-displej-a-cisty-android-38409

But disabling Tracking Protection in Fenix doesn't help me, as requests to access cookies/storage are still blocked:

Request to access cookie or storage on “https://ssp.imedia.cz/static/js/ssp.js” was blocked because it came from a tracker and content blocking is enabled.

How would I bypass this on Fenix to test whether content blocking is the culprit?

Comment 5

[Chris Peterson [:cpeterson]]

Thanks, Thomas. This is a great analysis!

And sure enough, Fenix is blocking scripts which may be related:

The resource at “https://ssp.imedia.cz/static/js/ssp.js” was blocked because content blocking is enabled. xiaomi-mi-a3-dorazilo-ma-amoled-displej-a-cisty-android-38409

But disabling Tracking Protection in Fenix doesn't help me, as requests to access cookies/storage are still blocked:

Request to access cookie or storage on “https://ssp.imedia.cz/static/js/ssp.js” was blocked because it came from a tracker and content blocking is enabled.

Eugen, it looks like ETP is enabled in Fenix even though Fenix is using GV 68 and Thomas disabled standard Tracking Protection in the Fenix settings. Do you why ETP might be enabled in Fenix with GV 68?

Comment 6

[Eugen Sawin [:esawin]]

(In reply to Chris Peterson [:cpeterson] from comment #5)

Eugen, it looks like ETP is enabled in Fenix even though Fenix is using GV 68 and Thomas disabled standard Tracking Protection in the Fenix settings. Do you why ETP might be enabled in Fenix with GV 68?

That would be the case if Fenix sets cookieBehavior to COOKIE_ACCEPT_NON_TRACKERS without resetting it to COOKIE_ACCEPT_ALL when disabling TP.

Ehsan, we support per-session (per-window/tab) enabling/disabling of TP via {nsIDocShell, nsILoadContext}.useTrackingProtection.
I suspect this will not affect cookie blocking as controlled by network.cookie.cookieBehavior.
Now that we mix TP with cookie behavior settings (ETP) in app UI, we run into unexpected situations like this.

If my suspicion is correct, then this bug depends on the exceptions API, bug 1557009, which would allow the app to add Gecko-supported exceptions, disabling all types of content blocking, including cookies behavior, for a list of origins.

Comment 7

[(no longer active)]

(In reply to Eugen Sawin [:esawin] from comment #6)

(In reply to Chris Peterson [:cpeterson] from comment #5)

Eugen, it looks like ETP is enabled in Fenix even though Fenix is using GV 68 and Thomas disabled standard Tracking Protection in the Fenix settings. Do you why ETP might be enabled in Fenix with GV 68?

That would be the case if Fenix sets cookieBehavior to COOKIE_ACCEPT_NON_TRACKERS without resetting it to COOKIE_ACCEPT_ALL when disabling TP.

Right, more accurately, BEHAVIOR_REJECT_TRACKER. (COOKIE_ACCEPT_NON_TRACKERS is a GeckoView value...)

Ehsan, we support per-session (per-window/tab) enabling/disabling of TP via {nsIDocShell, nsILoadContext}.useTrackingProtection.
I suspect this will not affect cookie blocking as controlled by network.cookie.cookieBehavior.

Correct: https://searchfox.org/mozilla-central/rev/40e889be8ff926e32f7567957f4c316f14f6fbef/docshell/base/nsDocShell.cpp#12549

Now that we mix TP with cookie behavior settings (ETP) in app UI, we run into unexpected situations like this.

I'm not sure if I understand this part of your comment. The Fenix UI (as far as I can see) provides no options for changing the cookie policy (which controls whether ETP is turned on or off) which means you'll get Gecko's default behaviour (that is, ETP on as of bug 1561385).

If my suspicion is correct, then this bug depends on the exceptions API, bug 1557009, which would allow the app to add Gecko-supported exceptions, disabling all types of content blocking, including cookies behavior, for a list of origins.

If I understand that bug correctly, in that bug we're talking about allowing putting a specific origin on the content blocking allow list to exempt it from all content blocking features (ETP/TP/etc). But here the user is using the global Preferences UI to change the global application preferences, which to me sounds like it would need a separate API to adjust the cookie policy globally, no?

Comment 8

[Eugen Sawin [:esawin]]

(In reply to :Ehsan Akhgari from comment #7)

If my suspicion is correct, then this bug depends on the exceptions API, bug 1557009, which would allow the app to add Gecko-supported exceptions, disabling all types of content blocking, including cookies behavior, for a list of origins.

If I understand that bug correctly, in that bug we're talking about allowing putting a specific origin on the content blocking allow list to exempt it from all content blocking features (ETP/TP/etc).

Correct.

But here the user is using the global Preferences UI to change the global application preferences, which to me sounds like it would need a separate API to adjust the cookie policy globally, no?

The API to control cookie policy globally (per runtime) exists (ContentBlocking.cookieBehavior). But there is no way to disable it per session (or per origin) without bug 1557009. Since Fenix's current exceptions mechanics use the per-session TP on/off switch, which doesn't affect cookie behavior, it may cause confusion and failures like this.

I'm inclined to remove the per-session TP switch once we have a proper exceptions API to avoid confusion in future.

@Fenix: For the global TP app switch, you need to make sure to adjust both, ContentBlocking.setCategories and ContentBlocking.setCookieBehavior.

Comment 9

[Chris Peterson [:cpeterson]]

P2 for now because the TP exceptions API bug 1557009 is P2.

Comment 10

[Chris Peterson [:cpeterson]]

The Fenix team has asked if we can fix this bug in Q3.

Comment 11

[(no longer active)]

(In reply to Eugen Sawin [:esawin] on leave until 25 September from comment #8)

But here the user is using the global Preferences UI to change the global application preferences, which to me sounds like it would need a separate API to adjust the cookie policy globally, no?

The API to control cookie policy globally (per runtime) exists (ContentBlocking.cookieBehavior). But there is no way to disable it per session (or per origin) without bug 1557009. Since Fenix's current exceptions mechanics use the per-session TP on/off switch, which doesn't affect cookie behavior, it may cause confusion and failures like this.

Hmm, this is extremely surprising to me. I'm not familiar with the existing exception mechanics that Fenix uses and what that maps to when we get into GV, but at the Gecko level, there are two ways to disable functionality:

• (A) Per feature, using the prefs controlling each feature.
• (B) Per origin, using a permission per each origin (technically one permission for private contexts and another one for non-private contexts).

The latter works for all features that fall under "Content Blocking" category, that includes:

• Tracking Protection
• Enhanced Tracking Protection
• Fingerprinting resource blocking
• Cryptomining resource blocking

Above, you're saying that Fenix is using per-session (per-origin) exception mechanics to disable TP. To me that implies it is using the permission based mechanism (B), but if that were the case, that would automatically work for ETP as well. Based on that description, this bug shouldn't exist. ;-) So I'm completely lost as to what Fenix is doing and what Gecko is seeing when stuff goes through Fenix -> GV -> Gecko abstraction layers. (Probably because we have some confusing terminology that's different in between these layers)?

Is there any way to set environment variables in Fenix? If yes, setting MOZ_LOG=AntiTracking:5 will give you a log of what the anti-tracking backend thinks is going on, and that could help me figure out what Gecko is seeing at the end of these abstraction layers...

Comment 12

[Emily Toop (:fluffyemily)]

From reading through the comments on this bug it appears there are a number of questions and actions that have been requested from the Fenix team without anyone from the Fenix team being NI'd. Therefore I am pinging :ekager to take a look at the following comments:

https://bugzilla.mozilla.org/show_bug.cgi?id=1563990#c8

@Fenix: For the global TP app switch, you need to make sure to adjust both, ContentBlocking.setCategories and ContentBlocking.setCookieBehavior.

https://bugzilla.mozilla.org/show_bug.cgi?id=1563990#c11

Is there any way to set environment variables in Fenix? If yes, setting MOZ_LOG=AntiTracking:5 will give you a log of what the anti-tracking backend thinks is going on, and that could help me figure out what Gecko is seeing at the end of these abstraction layers...

Comment 13

[Emily Kager [:ekager]]

For the first question, AFAIK AC takes care of setting a new cookie policy when the tracking protection setting changes.
To the second question, I'm not sure what these are, so I'm assuming not?

I did a bit more investigation and found that I could reproduce in Focus (by toggling the "Block other content trackers" - ContentBlocking.AT_CONTENT). I'm wondering if this is an AC issue where this category is being added somehow since Focus manages toggling the categories itself and the browsers using AC seem to have this issue.

NI-ing Sebastian

Comment 14

[Sebastian Kaspari (:sebastian; :pocmo)]

Arturo, can you answer that?

Comment 15

[Arturo Mejia [:amejia]]

I'm doing some research. When I finish I will get back to you with a concise answer

Comment 16

[Arturo Mejia [:amejia]]

I don't this is an AC issue, I can reproduce it using geckoview_example (with tracking protection off). That is just vanilla geckoview.
https://tools.taskcluster.net/index/gecko.v2.mozilla-central.latest.mobile/android-api-16-debug

I even created a small app that just have plain geckoview and disabled everything related to tracking protection and I still can reproduce the issue.

Comment 17

[Dylan Roeh (:droeh) (he/him)]

(In reply to Arturo Mejia from comment #16)

I don't this is an AC issue, I can reproduce it using geckoview_example (with tracking protection off). That is just vanilla geckoview.
https://tools.taskcluster.net/index/gecko.v2.mozilla-central.latest.mobile/android-api-16-debug

I even created a small app that just have plain geckoview and disabled everything related to tracking protection and I still can reproduce the issue.

I can confirm this (after building for aarch64 because the site wouldn't even load in an emulator for me...); clearing priority because it seems pretty clear to me it's an actual GV/Gecko bug and needs to be re-triaged.

Comment 18

[Chris Peterson [:cpeterson]]

Request to access cookie or storage on “https://ssp.imedia.cz/static/js/ssp.js” was blocked because it came from a tracker and content blocking is enabled.

Hi Thomas, Dylan added site permission support for allowing Storage Access in the geckoview_example app (GV 71 in mozilla-central). He can still reproduce this bug in Fenix after disabling regular Tracking Protection and allowing Storage Access, so this looks likes a webcompat issue, not a Tracking Protection bug.

Comment 19

[Chris Peterson [:cpeterson]]

I can confirm this (after building for aarch64 because the site wouldn't even load in an emulator for me...); clearing priority because it seems pretty clear to me it's an actual GV/Gecko bug and needs to be re-triaged.

In that case, sending this bug back to GV triage

Comment 20

[Dylan Roeh (:droeh) (he/him)]

(In reply to Chris Peterson [:cpeterson] from comment #18)

Request to access cookie or storage on “https://ssp.imedia.cz/static/js/ssp.js” was blocked because it came from a tracker and content blocking is enabled.

Hi Thomas, Dylan added site permission support for allowing Storage Access in the geckoview_example app (GV 71 in mozilla-central). He can still reproduce this bug in Fenix after disabling regular Tracking Protection and allowing Storage Access, so this looks likes a webcompat issue, not a Tracking Protection bug.

This isn't quite right: we don't have third party storage access support in GV yet. All I tested was adding this site to the content blocking exception list, which did not have any effect on the problem.

Comment 21

[Emily Kager [:ekager]]

I can't reproduce the original behavior anymore. I'm going to close the Fenix issue (not sure if you all still think there's a Gecko/GV problem)

Comment 22

[[ex-Mozilla] Agi Sferro | :agi]

Dylan, Eugen, do you know/remember if there's anything left to do here?

Comment 23

[Eugen Sawin [:esawin]]

This was blocked on TP Exceptions API support, which has landed. I don't think there is anything left to do.