1420885 - Google Page-Hiding Snippet un-hide logic is delayed by tracker tailing leaving the document blank with opacity:0 for at least 4 seconds

Status: RESOLVED WONTFIX

(Core :: Networking: HTTP, defect, P3)

Description

[Anton Frick]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.94 Safari/537.36

Steps to reproduce:

The problem can be reproduced with Firefox 57

Just visit our site: https://www.traum-ferienwohnungen.de/suchergebnis/ergebnisse/?is_in_clicked_search=1


Actual results:

The page stays blank until the content is fully loaded.


Expected results:

Chunked content should be rendered partially as before (FF < 57)

Comment 1

[Anton Frick]

User arai from the firefox irc channel could provide me with the following ticket that seemed to be helpful https://bugzilla.mozilla.org/show_bug.cgi?id=1406159

When I set network.http.tailing.enabled to false everything works fine in latest FF (just like before 57)

Comment 2

[Tooru Fujisawa [:arai]]

regression range:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=10d42af6319d08daca29d5d163f301696b5ff1fd&tochange=b37a0bd71bbb1f3e5b4f58f1936d9cc0a38851d2

Comment 3

[Honza Bambas (:mayhemer)]

Thanks for the regressions range!  Going to look at this.

Comment 4

[Anton Frick]

Okay I'm not sure if this is relevant but the "bug" seems to be related to the page hide snippet https://developers.google.com/optimize/ from Google's Optimize tool. If I remove that one, everything works as expected, just like when I set network.http.tailing.enabled to false or use an older FF version. My brain implodes.

Comment 5

[Honza Bambas (:mayhemer)]

(In reply to Anton Frick from comment #4)
> Okay I'm not sure if this is relevant but the "bug" seems to be related to
> the page hide snippet https://developers.google.com/optimize/ from Google's
> Optimize tool. If I remove that one, everything works as expected, just like
> when I set network.http.tailing.enabled to false or use an older FF version.
> My brain implodes.

That's a helper, thanks and also thanks for this whole report!

This is not about chunked encoding at all.  The snippet hides the document content (opacity:0) and shows it in either 4 seconds or when unhidden sooner by the A/B testing script.  That script loads dynamically from the ga script, we tail both because both are loading from a tracking script, and it's even worse because the tailing cascades (analytics.js has to load to start loading gtm/js?id=GTM-57Z8VSB&cid=897476427.1512149439 which unhides the document content.)

It's bad that a tracking script may have such an effect, but it's understandable.  It's also unfortunate that we didn't catch something like this during the Beta phase.

I have to think on how we should fix this, since the first reaction to this is that we fail performance, even though the cause here is obviously not a perf issue.  The intention of tailing is to help performance by delaying something that is assumed to not have any visible effect.  The google's A/B experiment and the Page-Hiding Snippet apparently has...

Comment 6

[Honza Bambas (:mayhemer)]

(In reply to Honza Bambas (:mayhemer) from comment #5)
> both are loading from a tracking script

tracking *domain*

Comment 7

[Jim Mathies [:jimm]]

Hey Honza, can you give us a status update on this bug?

Comment 8

[Honza Bambas (:mayhemer)]

(In reply to Jim Mathies [:jimm] from comment #7)
> Hey Honza, can you give us a status update on this bug?

There is currently nothing we could do on our side except completely disabling the tailing (de-prioritization) feature.  There is a study pending to figure out what effect tailing has on various metrics like domcontentloaded, onload, first-paint etc.  If there is a regression or only very negligible improvement, we may consider it to disable.

OTOH, note that the symptoms of this bug manifest also when users turn Tracking Protection to Always Enable or when they use Private Browsing windows (where TP is enabled by default).

So, I think we can make this pending on the result of the study, bug 1434379.

Comment 9

[Ryan VanderMeulen [:RyanVM]]

Did we ever circle back to this in the 3 months since the study completed?

Comment 10

[Honza Bambas (:mayhemer)]

(In reply to Ryan VanderMeulen [:RyanVM][PTO July 4-9] from comment #9)
> Did we ever circle back to this in the 3 months since the study completed?

We did, but it was inconclusive (no reg, no improve).  We are likely going to include tailing in the upcoming study for FastBlock (Smart Blocking) that is more detailed.

Also, if FastBlock approach shows better results than tailing, tailing will be disabled for trackers (I will then file necessary bugs and duplicate this one to it.)  So far I want to keep this open for reference.

Comment 11

[Honza Bambas (:mayhemer)]

It would be interesting to think about a solution here, but this is definitely no more a P2.  There are no major complains regarding this issue to my knowledge.

OTOH, IIRC a similar/same bug appeared more often with FastBlock being enabled.  Ehsan, do you recall?

Comment 12

[(no longer active)]

This is a dupe of bug 1516552 as far as I can tell (see https://bugzilla.mozilla.org/show_bug.cgi?id=1516552#c15 and https://bugzilla.mozilla.org/show_bug.cgi?id=1484713#c18). The page in comment 0 has the same code snippet and comment 4 verifies this also.

I don't think this has anything to do with tailing. We just end up blocking GA/GTM, and as a result we don't run their async initializer, so the backup 4 second timeout initializer is used, hence the delay observed.

Feel free to dupe against that bug unless there is any other work that's supposed to be done here besides the solution proposed there...

Comment 13

[Honza Bambas (:mayhemer)]

Thanks. The difference here is that bug 1484713 manifests when Tracking Protection is enabled, something we don't ship by default. Tailing (shipped default on) may cause this delay to manifest as well.

OTOH, I don't see this delay much while browsing myself.

I'll duplicate this to 1516552, which seems like a general solution.

Comment 14

[(no longer active)]

I think the only possible way that tailing can make this happen is if it delays the loading of the GA/GTM script by so long that the 4-second timeout kicks in before that... Actually, now that I think about that, if my guess there is true, then that problem wouldn't be fixed if we fixed bug 1516552, since that bug is purely about the resource being blocked. Perhaps there is more to this bug then?

(But similar to you, I can't reproduce this right now either...)

Comment 15

[Honza Bambas (:mayhemer)]

Ups, yes. When we block, we can replace. But when we delay, we likely are not going to replace with a shim...

The purpose of tailing /is/ to delay. And the use case from comment 0 reproduced this very well, when the snippet was deployed.

I can't think of a solution except referring the scripts in question as sync or defer (which actually hurts the web and perfomance...) or do some kind of a whitelisting on our side.

Since 57, I've hit just one other page that was manifesting this delay during my daily browsing.

Some googling for this issue shows that it's not anything that people would widely suffer from.

I'm changing to WONTFIX.