Closed Bug 1853013 Opened 8 months ago Closed 8 months ago

Merge in scripting API and es module v119 webcompat addon updates early to get some more testing during the nightly cycle

Categories

(Web Compatibility :: Interventions, task)

Tracking

(firefox119 fixed)

RESOLVED FIXED
Tracking Status
firefox119 --- fixed

People

(Reporter: twisniewski, Assigned: twisniewski)

References

Details

(Keywords: perf-alert)

Attachments

(3 files)

Assignee: nobody → twisniewski
Status: NEW → ASSIGNED
Pushed by twisniewski@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/8771fccb94fa
Merge in scripting API and es module webcompat addon updates; r=denschub,webcompat-reviewers
Status: ASSIGNED → RESOLVED
Closed: 8 months ago
Flags: qe-verify+
Resolution: --- → FIXED

Hmm. Indeed, toolkit/components/passwordmgr/test/browser/browser_autofill_hidden_document.js also fails for me locally. It seems like all of the content scripts we're registering with the scripting API somehow end up with matchAboutBlank perma-set to true in makeInternalContentScript.

This strikes me as a pretty weird thing to do when add-ons probably don't want to match about:blank, which we definitely do not want here. It causes all of the interventions to load during the test, and worse, it loads them all in one execution context, meaning that const variables end up being re-declared. This causes the test to fail as it does not expect the resulting extra console spam.

We could work around this by disabling the compat addon for these tests, but that strikes me as a bad solution. The older contentScripts.register API had an matchAboutBlank option rather than "forcing" addon content scripts to match about:blank when they almost certainly don't actually want to. I think it's best for the addons team to chime in before I try landing this one again.

:rpl, what are your thoughts?

Flags: needinfo?(twisniewski) → needinfo?(lgreco)

For the record, we've roughly decided on a course of action here. rpl is working on the required changes in this PR (and possibly other related changes to Gecko in other bugs). Once that work lands, we'll update this patch and try again.

Flags: needinfo?(lgreco)
Depends on: 1853412

Bug 1853412 has been merged to mozilla-central, and so I thought to push to try an updated patch "vendoring webcompat with the changes from the previous attempt plus the changes from the new PR" along with an additional one line patch that is "setting extensions.webcompat.useScriptingAPI to true from modules/libpref/init/all.js" (which makes the webcompat builtin to opt-in on using scripting API for injections and shims, while it would be falling back to contentScripts API as before in builds where that pref isn't set):

Status: REOPENED → RESOLVED
Closed: 8 months ago8 months ago
Resolution: --- → FIXED
Pushed by twisniewski@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/f36c23c0efa6
Merge in scripting API and es module webcompat addon updates; r=denschub,webcompat-reviewers,ksenia

(In reply to Pulsebot from comment #11)

Pushed by twisniewski@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/f36c23c0efa6
Merge in scripting API and es module webcompat addon updates;
r=denschub,webcompat-reviewers,ksenia

== Change summary for alert #39620 (as of Wed, 20 Sep 2023 10:14:33 GMT) ==

Improvements:

Ratio Test Platform Options Absolute values (old vs new) Performance Profiles
38% office LastVisualChange windows10-64-shippable-qr cold fission webrender 1,888.65 -> 1,172.36 Before/After
30% office LastVisualChange windows10-64-shippable-qr fission warm webrender 1,144.13 -> 803.09 Before/After
30% office LastVisualChange macosx1015-64-shippable-qr cold fission webrender 1,717.64 -> 1,208.10 Before/After
26% office LastVisualChange linux1804-64-shippable-qr fission warm webrender 1,213.28 -> 896.02 Before/After
26% office LastVisualChange macosx1015-64-shippable-qr fission warm webrender 931.23 -> 689.87 Before/After
... ... ... ... ... ...
4% office SpeedIndex windows10-64-shippable-qr fission warm webrender 339.63 -> 327.18 Before/After

For up to date results, see: https://treeherder.mozilla.org/perfherder/alerts?id=39620

jftr, I was a bit skeptical about an improvement this large. However, in my quick tests with the Excel overscroll intervention, and the Outlook registerProtocolHandler intervention, everything appears to be working fine. I tried reloading a couple of times with different cache states and simulated network speeds in an attempt to provoke a race condition, but I couldn't break the intervention. So this might just be an improvement, not a bug.

Blocks: 1823436
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: