Closed Bug 1334309 Opened 4 years ago Closed 4 years ago

Ship the Large-Allocation header in Firefox 52

Categories

(Core :: DOM: Core & HTML, defect)

defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: nika, Assigned: nika)

References

Details

Attachments

(6 files, 1 obsolete file)

This requires uplifting the changes only made in 53, and turning on the pref.

I'll be uploading patches to do that on this bug.

Patches on this bug are _not_ intended for mozilla-central, only for beta (Fx 52).

We want to ship the Large-Allocation header in Firefox 52, as that is the release which ships WASM, which we would like the header to ship alongside.
Comment on attachment 8830950 [details] [diff] [review]
Enable the Large-Allocation header, and bring the pref name in line with 53, r=ehsan

I'd also love it if you went over the other changes in this bug to make sure I didn't make any dumb mistakes when backporting the patches to beta :).

Thanks!
Attachment #8830950 - Flags: review?(ehsan)
Comment on attachment 8830950 [details] [diff] [review]
Enable the Large-Allocation header, and bring the pref name in line with 53, r=ehsan

Review of attachment 8830950 [details] [diff] [review]:
-----------------------------------------------------------------

::: dom/ipc/ContentParent.cpp
@@ +752,5 @@
>        sLargeAllocationContentParents = new nsTArray<ContentParent*>();
>      }
>      contentParents = sLargeAllocationContentParents;
>  
> +    maxContentParents = Preferences::GetInt("dom.ipc.processCount.webLargeAllocation", 2);

You should probably use 100 as the default here as well.  This is the usual convention for reading prefs...
Attachment #8830950 - Flags: review?(ehsan) → review+
Attachment #8830950 - Attachment is obsolete: true
We're not shipping the Large-Allocation header until 53 - closing this bug as WONTFIX.
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → WONTFIX
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.