What steps will reproduce the problem?
(1) Launch Chrome with --site-per-process or --isolate-origins=https://csreis.github.io and a clean profile
(2) Navigate to https://csreis.github.io
(3) Open DevTools, check "Preserve log" and "Disable cache" under network.
(4) Execute 
  document.cookie = "foo=bar"
(5) Do location.reload(), click on the network request in devtools, and double-check that the new cookie was sent in the Cookies pane.
(6) Go to http://csreis.github.io/tests/cross-site-iframe.html
(7) Click "Go cross-site (simple page)".
(8) In Devtools, click on the subframe's network request (https://csreis.github.io)
(9) Notice that the request does *not* have the "Cookies" pane.  When OOPIF is not used for the subframe, the pane appears properly, and it shows the "foo=bar" cookie under "Request cookies".

Note that the cookie still exists for https://csreis.github.io, which you can verify by inspecting the subframe and checking "document.cookie".  It's just that the request that creates an OOPIF is not showing the "Cookies" panel.  It also shows the status of the request as "(pending)", and there's a note "Provisional headers are shown" under request headers -- I'm not sure if that's expected?

Reloading the subframe shows the request and the cookie pane properly, but clicking "Go same-site" followed by "Go cross-site" shows the same issue for the second navigation.  So this seems to only affect cross-process subframe navigations.

dgozman: would you be able to triage this from the devtools side?  I recall at some point, such cross-process navigations showed up as two requests in devtools, one for the navigation starting in the original process (which was then canceled), the other for the (real) navigation in the new process.  That seems to be fixed now, but looks like we still might have issues showing some properties of the request?

There's also an issue with PlzNavigate, where the OOPIF's request does not show up in DevTools at all, but I'll file a separate bug with a simpler repro for that.