Picking up from comment 11: * layout/forms/nsComboboxControlFrame.cpp ** `nsComboboxControlFrame::GetCSSTransformTranslation`: This is about figuring out placement of the dropdown menu. It's a helper for `nsComboboxControlFrame::GetAvailableDropdownSpace()` and has no other callers besides that. `GetAvailableDropdownSpace()` has two callers, both of which are skipped in content processes, `via XRE_IsContentProcess()` checks: [here](https://searchfox.org/mozilla-central/rev/ac7da6c7306d86e2f86a302ce1e170ad54b3c1fe/layout/forms/nsComboboxControlFrame.cpp#616-618,625) and [here](https://searchfox.org/mozilla-central/rev/ac7da6c7306d86e2f86a302ce1e170ad54b3c1fe/layout/forms/nsListControlFrame.cpp#537,546,551). So fission doesn't make a difference here. ==> **no action needed** * layout/generic/nsGfxScrollFrame.cpp: ** `GetPaintedLayerScaleForFrame`: This function has two callers, and it's used to get the potentially-transformed-up size of the scrolled-frame, so that we can scroll properly (in this content process). If this is called inside a fission OOP iframe, there shouldn't be any reason for this operation to consider scales from outer cross-process documents, since those scales would effectively be compositing effects that happen outside of our process, I think. ==> **no action needed** ** `ScrollFrameHelper::RestrictToRootDisplayPort`: This function is seems to just be an optimization for stability, as described in its [initial comment](https://searchfox.org/mozilla-central/rev/ac7da6c7306d86e2f86a302ce1e170ad54b3c1fe/layout/generic/nsGfxScrollFrame.cpp#4208-4211) -- it limits the size of the display port that we set up for a scrollable element, I think. In a scenario with an OOP iframe that happens to be huge, with even-huger scrollable elements inside of it, it looks like maybe we'll now only limit those scrollable elements to the size of the iframe, rather than the size of the ultimate browser viewport (which would be managed by a separate content process). This change could conceivably result in increased memory usage for this (somewhat-pathological) scenario, but I think it's kinda necessary, and it wouldn't have any other user-detectable effects. ==> **no action needed** ** `ScrollFrameHelper::PostOverflowEvent`: This is about a paint-time update (determining whether this particular scrollframe just started overflowing and requesting a will-paint callback to account for that, using the root pres context's painting cycle). This is fine; we should use our own content-process's painting cycle for this. ==> **no action needed**
Bug 1727437 Comment 12 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Picking up from comment 11: * layout/forms/nsComboboxControlFrame.cpp ** `nsComboboxControlFrame::GetCSSTransformTranslation`: This is about figuring out placement of the dropdown menu. It's a helper for `nsComboboxControlFrame::GetAvailableDropdownSpace()` and has no other callers besides that. `GetAvailableDropdownSpace()` has two callers, both of which are skipped in content processes, `via XRE_IsContentProcess()` checks: [here](https://searchfox.org/mozilla-central/rev/ac7da6c7306d86e2f86a302ce1e170ad54b3c1fe/layout/forms/nsComboboxControlFrame.cpp#616-618,625) and [here](https://searchfox.org/mozilla-central/rev/ac7da6c7306d86e2f86a302ce1e170ad54b3c1fe/layout/forms/nsListControlFrame.cpp#537,546,551). So fission doesn't make a difference here. ==> **no action needed** * layout/generic/nsGfxScrollFrame.cpp: ** `GetPaintedLayerScaleForFrame`: This function has two callers, and it's used to get the potentially-transformed-up size of the scrolled-frame, so that we can scroll properly (in this content process). If this is called inside a fission OOP iframe, there shouldn't be any reason for this operation to consider scales from outer cross-process documents, since those scales would effectively be compositing effects that happen outside of our process, I think. ==> **no action needed** ** `ScrollFrameHelper::RestrictToRootDisplayPort`: This function is seems to just be an optimization for stability, as described in its [initial comment](https://searchfox.org/mozilla-central/rev/ac7da6c7306d86e2f86a302ce1e170ad54b3c1fe/layout/generic/nsGfxScrollFrame.cpp#4208-4211) -- it limits the size of the display port that we set up for a scrollable element, I think. In a scenario with an OOP iframe that happens to be huge, with even-huger scrollable elements inside of it, it looks like maybe we'll now only limit those scrollable elements to the size of the iframe, rather than the size of the ultimate browser viewport (which would be managed by a separate content process). This change could conceivably result in increased memory usage for this (somewhat-pathological) scenario, but I think it's kinda necessary, and it wouldn't have any other user-detectable effects. ==> **no action needed** ** `ScrollFrameHelper::PostOverflowEvent`: This is about a paint-time update (determining whether this particular scrollframe just started overflowing and requesting a will-paint callback to account for that, using the root pres context's painting cycle). This is fine; we should use our own content-process's painting cycle for this. ==> **no action needed** [more to come...]