Open Bug 1563990 Opened 9 months ago Updated 1 month ago

Load more comments JS on mobilenet.cz behaving strangely

Categories

(GeckoView :: General, defect, P2)

Unspecified
Android

Tracking

(firefox68 wontfix, firefox69 affected, firefox70 affected, firefox71 affected)

Tracking Status
firefox68 --- wontfix
firefox69 --- affected
firefox70 --- affected
firefox71 --- affected

People

(Reporter: ekager, Unassigned, NeedInfo)

References

Details

(Whiteboard: [geckoview:p2])

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.

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

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

Flags: needinfo?(ekager)
OS: All → Android

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?

Flags: needinfo?(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?

Flags: needinfo?(twisniewski) → needinfo?(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?

Flags: needinfo?(cpeterson) → needinfo?(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.

Flags: needinfo?(esawin)
Flags: needinfo?(ehsan)

(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?

Flags: needinfo?(ehsan) → needinfo?(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.

Flags: needinfo?(esawin)

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

Depends on: 1557009
Priority: -- → P2

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

Whiteboard: [geckoview:fenix:m8]

(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...

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...

Flags: needinfo?(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

Flags: needinfo?(ekager) → needinfo?(s.kaspari)

Arturo, can you answer that?

Flags: needinfo?(s.kaspari) → needinfo?(amejiamarmol)
Rank: 11
Whiteboard: [geckoview:fenix:m8]

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

Flags: needinfo?(amejiamarmol)

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.

(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.

Priority: P2 → --

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.

Rank: 11
Component: General → Mobile
Flags: needinfo?(twisniewski)
Product: GeckoView → Web Compatibility
Version: 68 Branch → unspecified

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

Whiteboard: [geckoview]

(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.

Component: Mobile → General
Product: Web Compatibility → GeckoView
Rank: 11
Priority: -- → P2
Whiteboard: [geckoview] → [geckoview:p2]
You need to log in before you can comment on or make changes to this bug.