1372217 - can we exempt loads from tracking scripts from the overall page "loading in progress" state?

Status: NEW

(Core :: DOM: Core & HTML, enhancement, P3)

Description

[Ben Kelly [:bkelly, not reviewing]]

As we de-prioritize and throttle tracking scripts we may be lengthening the time until the browser declare the page is "loaded".  By this I mean the favicon icon stops spinning on desktop and the orange progress bar completes on android.

Would it be possible to exempt loads from tracking scripts from this loading-in-progress state?

I know we wait to throttle tracking timeouts because of this, but did we ever consider this approach instead?

I ask because I noticed on android nightly that some washingtonpost.com pages never seem to "finish loading".  The orange progress indicator gets stuck around 60%.  If I enable tracking protection then the page loads without getting stuck.

Comment 1

[(no longer active)]

(In reply to Ben Kelly [reviewing, but slowly][:bkelly] from comment #0)
> As we de-prioritize and throttle tracking scripts we may be lengthening the
> time until the browser declare the page is "loaded".  By this I mean the
> favicon icon stops spinning on desktop and the orange progress bar completes
> on android.

I think you're talking about this feature, right? Bug 1141814?  Not throttling of tracking timeouts?  (Because the latter isn't related to network loads)  CCing Francois and Kershaw.

> Would it be possible to exempt loads from tracking scripts from this
> loading-in-progress state?

Hmm.  Define exempt.  Are you suggesting that we should not add such loads to the load group?  I'm pretty sure that would break something inside Gecko.  Perhaps we should teach the load group to pretend to the external world that those loads don't exist but still track them for our internal purposes?  But then there is DOMContentLoaded and load events and whatnot, I'm not sure what you're proposing to do about them.  Can you please be more specific?

> I know we wait to throttle tracking timeouts because of this, but did we
> ever consider this approach instead?
> 
> I ask because I noticed on android nightly that some washingtonpost.com
> pages never seem to "finish loading".  The orange progress indicator gets
> stuck around 60%.  If I enable tracking protection then the page loads
> without getting stuck.

Did you try setting the privacy.trackingprotection.lower_network_priority pref to false to see whether that changes the behavior?  That would tell us whether this was related to bug 1141814 or not...

Comment 2

[Hsin-Yi Tsai (she/her)[:hsinyi]]

I tried to disable privacy.trackingprotection.lower_network_priority but didn't think I notice differences. Some pages were still stuck at 60% for a relevant while.

Comment 3

[François Marier [:francois]]

(In reply to Hsin-Yi Tsai (55 Regression Engineering support) [:hsinyi] from comment #2)
> I tried to disable privacy.trackingprotection.lower_network_priority but
> didn't think I notice differences. Some pages were still stuck at 60% for a
> relevant while.

What about if you set all of these to false?

privacy.trackingprotection.annotate_channels = false (NEW)
privacy.trackingprotection.enabled = false (should be already false by default)
privacy.trackingprotection.lower_network_priority = false (which you tried already)

Comment 4

[Kershaw Chang [:kershaw]]

> Hmm.  Define exempt.  Are you suggesting that we should not add such loads
> to the load group?  I'm pretty sure that would break something inside Gecko.
> Perhaps we should teach the load group to pretend to the external world that
> those loads don't exist but still track them for our internal purposes?  But
> then there is DOMContentLoaded and load events and whatnot, I'm not sure
> what you're proposing to do about them.  Can you please be more specific?
> 
> > I know we wait to throttle tracking timeouts because of this, but did we
> > ever consider this approach instead?
> > 

FYI

We've discussed something like this before in bug 1319359.

Comment 5

[Hsin-Yi Tsai (she/her)[:hsinyi]]

I noticed several related issues (I meant blocking/de-prioritizing tracking scripts) today - bug 1373694, bug 1373547 
Wondering if there's a meta bug for discussing the tracking scripts issue in general ...

Comment 6

[Hsin-Yi Tsai (she/her)[:hsinyi]]

Oops, didn't mean to set priority ...

Comment 7

[Hsin-Yi Tsai (she/her)[:hsinyi]]

(In reply to François Marier [:francois] from comment #3)
> (In reply to Hsin-Yi Tsai (55 Regression Engineering support) [:hsinyi] from
> comment #2)
> > I tried to disable privacy.trackingprotection.lower_network_priority but
> > didn't think I notice differences. Some pages were still stuck at 60% for a
> > relevant while.
> 
> What about if you set all of these to false?
> 
> privacy.trackingprotection.annotate_channels = false (NEW)
> privacy.trackingprotection.enabled = false (should be already false by
> default)
> privacy.trackingprotection.lower_network_priority = false (which you tried
> already)

I tried, but didn't think I observed obvious differences.
That said, I did see pages loading stuck at 60% for a while, but the loading will be completed if waiting longer.

NI Ben to see what he will get.

Comment 8

[Ben Kelly [:bkelly, not reviewing]]

I think its really hard to verify this because the ads change over time and they do different things with setTimeout, network loads, etc.  I don't think I can verify this one way or the other.  Sorry.