I’ve split the CLs as discussed. PTAL!
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Thanks and sorry for the delay, finally had the time to take a look at all three together.
// from the creator origin. This should only happen for renderer-initiated
// CreateNewWindow cases.Do you have a repro for this? Is it not possible to cover this case? How do these cases get their various other tokens then?
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
// from the creator origin. This should only happen for renderer-initiated
// CreateNewWindow cases.Do you have a repro for this? Is it not possible to cover this case? How do these cases get their various other tokens then?
SandboxViaInheritanceNavigationsToCoop
SandboxFlagsSetForNewWindow
CrossProcessPopupInheritsSandboxFlagsWithNoOpener
Yes, these are the few test cases where popups are opened from iframe with sandbox flags and we've few other tests for the repro.
Currently for opener scenario, frame/document/devtools tokens are generated uniquely when RenderFrameHostImpl is created here
https://source.chromium.org/chromium/chromium/src/+/main:content/browser/renderer_host/render_frame_host_manager.cc;l=719;bpv=1;bpt=1?q=render_frame_host_manager.cc&ss=chromium%2Fchromium%2Fsrc
To match with this, I used DeriveNewOpaqueOrigin that generates origin from random nonce (fallback to previous).
If at all we want to cover this scenario we should look at generating the origin from renderer and pass it to browser process as CreateNewWindow is sync. And yes we should be doing this case separately similar to sandbox origin generation for iframes (design and impl changes) but given other tokens are uniquely created during renderframeimplhost creation I think it is fine to let the browser to generate origin uniquely here unlike sandbox iframes. what do you think?
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |