Otherwise, looking into our codebase, nothing prevents us from failing to set "Referer" request header directly. Let's block it somewhere here. The error code might be NS_ERROR_ILLEGAL_VALUE. This will force privileged code to use setReferrerInfo() and others will just fail.

Thanks for the explanation, Emilio!

Thanks! LGTM.

I'll probably need a little more background. How does this ensure that when we hit the regular tag later, we DO block onload? Because as I understand, top-data are there only once, in the hashtable, shared for all preloads and regular loads. So where is the distinction?

f+ for netwerk/base/ changes

r+ for PreloadService changes and somewhat the Document changes.

You need to update following places too:
https://searchfox.org/mozilla-central/rev/a315a1a0f09550e23e4590a77e74f36543315da3/dom/html/HTMLLinkElement.cpp#814-815

Nice catches, Junior! Hopefully this will fix the intermittent. Thanks.

This is nonsense

In D84700#2627384, @froydnj wrote:

I am not sure this is needed after the other patch is straightened out. WDYT?

Thanks for the quick feedback. This all looks like a depth from bug 1437167.

r+ with a proper explanation of the flag setting position.

I'll let Josh double check.

@dragana can you please overlook the changes around the new RESOLVE_IGNORE_SOCKS_DNS resolution flag?

addressed flod`s comment

rebase

@kershaw, there was one little update: we don't need to do the notification part when we no longer have the listener. It happens exactly as explained in the added comment and generally makes sense because we can't notify in that case anyway.

sorry for late answer. This is a low priority work.

In D83649#2597411, @flod wrote:

I am not sure I follow all the details in your reply but if you are willing to backout my patch that actually fixes something really important in the platform code (just adds messages, mistaken with a different patch) because of simple typos in console messasges, then this workflow is simply not right. If you want to control properties files with such power then be a mandatory automated reviewer, or just propose followup fixes. Not that I would not appreciate your feedback - I really do, but you coming from nowhere like this is not what I would expect. Hence the above proposal from the point of view of a mere engineer.

Feel free to escalate (not sure where, to be completely honest), but there's simply not enough people to carry on this type of work. Would you prefer for any patch touching strings to be stuck for a week or more? That doesn't seem reasonable either, because that's on the reviewer to double check the strings on top of the code, so there's already a review level in the workflow (which failed this time, but works in 99% of them).

thanks!

typos fix, properly this time

In D83649#2593965, @flod wrote:

In D83649#2593780, @mayhemer wrote:

In D83649#2593114, @flod wrote:

I've asked sheriffs to back this out, since all these strings have the same typo (Cooke instead of Cookie).

Yeah - a backout is always better than a quick followup fix. I think instead of just subscribing to properties files changes you should have a group that will be a blocking reviewer. That could save these loops.

We have a group reviewer for Fluent, because not all developers have experience with them yet. That's not really the case for .properties.

On top of that, UX would be in charge of English copy (not localization), and it's not really involved in messages like console errors, or where developers feel comfortable in coming up with their own strings.

rebase + typos fix

In D83649#2593114, @flod wrote:

I've asked sheriffs to back this out, since all these strings have the same typo (Cooke instead of Cookie).