Script:

// ==UserScript==
// @name         New Userscript
// @namespace    http://tampermonkey.net/
// @version      0.1
// @description  try to take over the world!
// @author       You
// @match        https://twitter.com/*
// @icon         data:image/gif;base64,R0lGODlhAQABAAAAACH5BAEKAAEALAAAAAABAAEAAAICTAEAOw==
// @grant        none
// ==/UserScript==

(function() {
    'use strict';

    alert("??")
})();

1. Install Tampermonkey
2. Click the extension button and select "Create a new script"
3. Copypaste the above script
4. Save by Control+S (or equivalent)
5. Open https://twitter.com (it's okay not to log in)
6. See the popup alert opens
7. Hard refresh the page
8. See the popup opens this time

Expected: The script should be triggered when the tab opens
Actual: The script is only triggered by hard refresh

mozregression says bug 1697421 changed the behavior. Not sure which part is faulty here, though.

Not quite sure about the component, feel free to set it to webextensions. For now I'll copy it from the regressing bug.

Set release status flags based on info from the regressing bug 1697421

:smayya, since you are the author of the regressor, bug 1697421, could you take a look? Also, could you set the severity field?

For more information, please visit auto_nag documentation.

:valentin could this be triaged for priority/severity?
Next week is RC week for 107, would like to understand expectations around this bug

I am not exactly sure how the changes for fetch has caused this regression. I will discuss this further with Valentin.

So, I can confirm the STR from comment 0 are accurate.

If I enable debug logs in tamper monkey, and take a look at the terminal, I see the following:

content: normal start event processing for la10r7ys.8pk (1 to run) content.js:formatted:1849
env: schedule "New Userscript" for document-idle content.js:41:167
Content Security Policy: Ignoring “'unsafe-inline'” within script-src: nonce-source or hash-source specified 4
content: DOMContentLoaded content.js:formatted:1836
content: load content.js:formatted:1839
env: run "New Userscript" now content.js:formatted:1451
Content Security Policy: The page’s settings blocked the loading of a resource at eval (“script-src”).
Content Security Policy: The page’s settings blocked the loading of a resource at inline (“script-src”). moz-extension:21:453

So, for some reason it's getting blocked by CSP. I'm not totally sure how tampermonkey works around CSP, or how the bug 1697421 changes affect this.
Since this doesn't happen on a network load, but it does happen on a cache load, it makes sense that the way we are handling original-response-headers is to blame.
Looking at tamper monkey code, they seem to be using xhr here, not sure for what. It may be that the code is directly causing the CSP bug, or it could be something else.

I'll keep investigating.

One difference that I can see, in the latest build vs old builds when loading twitter.com an extra header is visible in the devtools panel:

x-content-security-policy
	connect-src 'self' blob: https://*.pscp.tv https://*.video.pscp.tv https://*.twimg.com https://api.twitter.com https://api-stream.twitter.com https://ads-api.twitter.com https://aa.twitter.com https://caps.twitter.com https://pay.twitter.com https://sentry.io https://ton.twitter.com https://twitter.com https://upload.twitter.com https://www.google-analytics.com https://accounts.google.com/gsi/status https://accounts.google.com/gsi/log https://app.link https://api2.branch.io https://bnc.lt wss://*.pscp.tv ht…ecaptcha.net/recaptcha/ https://www.google.com/recaptcha/ https://www.gstatic.com/recaptcha/ https://client-api.arkoselabs.com/ https://www.google-analytics.com https://twitter.com https://app.link https://accounts.google.com/gsi/client https://appleid.cdn-apple.com/appleauth/static/jsapi/appleid/1/en_US/appleid.auth.js *; style-src 'self' 'unsafe-inline' https://accounts.google.com/gsi/style https://*.twimg.com; worker-src 'self' blob:; report-uri https://twitter.com/i/csp_report?a=O5RXE%3D%3D%3D&ro=false

It seems this is set by the greasemonkey webextension. It's possible that this header is causing the CSP failure.

I can't figure out how bad this is. It could be that the extension is doing something wrong.
I confirmed that it's caused by https://hg.mozilla.org/mozilla-central/rev/5979ac92fa24
I recommend we backout bug 1697421 from beta and debug on nightly.

:valentin if you could reach out to the #sheriffs for backout of bug 1697421 on central, I can follow up with beta later.

(In reply to Donal Meehan [:dmeehan] from comment #7)

:valentin if you could reach out to the #sheriffs for backout of bug 1697421 on central, I can follow up with beta later.

Done!

Setting 107 and 108 to disabled.
Regressor Bug 1697421 backed out of beta and central.

So, this was fixed by backout.
Backout link: https://hg.mozilla.org/integration/autoland/rev/15acd3b1e975fe6e10d37b3ef88a010ed3504a96
Backout link https://hg.mozilla.org/releases/mozilla-beta/rev/bfbcde7b63f6d61821fe2097869e874b041d59c3

We'll make sure this use case is fixed when we land Bug 1697421 again.