1955495 - Disable dom.timeout.defer_during_load or make it disableable on a per-site basis

Status: RESOLVED FIXED

(Core :: Performance: General, enhancement)

Description

[Jeff Muizelaar [:jrmuizel]]

Bug 1270059 has caused a number of webcompat regresssions. It doesn't seem practical to rely on outreach to get these site bugs fixed. Given this, I'd say our options are:

1. Disable it everywhere
2. Make it possible to disable based on url via an intervention

My leaning is towards disabling it everwhere as that avoids us having to find, diagnose and ship interventions for issues. However, it would be good to get a sense of the performance benefit defer_during_load gives us to know how much we'd be loosing.

Comment 1

[Randell Jesup [:jesup] (needinfo me)]

Attachment: Bug 1955495: disable defer_during_load via a pref for specific sites/urls r=smaug!

Sites with racy code can sometimes fail if we don't run timeouts
immediately. Note that in most cases it will still be racy and can still
fail.

Comment 2

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/eeb9af1573c8
disable defer_during_load via a pref for specific sites/urls r=smaug

Comment 3

[amarc]

https://hg.mozilla.org/mozilla-central/rev/eeb9af1573c8

Comment 4

[Geoff Lankow (:darktrojan)]

I'm looking into why browser_preferences_usage.js has started failing in Thunderbird and it's because IsURIInPrefList is now being called a lot. It seems to me that a null principal would never be in a pref list, so IsURIInPrefList could be short-circuited.

Comment 5

[Randell Jesup [:jesup] (needinfo me)]

Links to data on the failures?
Agreed null principals wouldn't be in the pref list; we could check that before calling IsURIInPrefList, though the check could be out there too

Comment 6

[Magnus Melin [:mkmelin]]

Test failure: https://treeherder.mozilla.org/logviewer?job_id=500833291&repo=comm-central&lineNumber=17924
I've sent a patch in bug 1956233