Charlie/Daniel - could you please confirm that this problem repros for you?  If you can also repro the problem, then I'll proceed with the rest of https://chromium-review.googlesource.com/c/chromium/src/+/695913 (which preserves the correct page-level view-source behavior, but also preserves [AFAICT] the incorrect frame-level view-source behavior wrt POST data).

What version are you testing?  I'm not seeing the bug on ChromeOS 60.0.3112.114, but maybe it changed with PlzNavigate or something else recent?

I can repro on Linux with 61.0.3163.100 and with 63.0.3236.7
I cannot repro on Mac with 60.0.3112.113
Let me try bisecting further.

It bisected down to r502251 (Enable PlzNavigate on trunk).

Yes it only reproduces with PlzNavigate.
I will try to understand what caused the issue today.

Thanks Arthur!  I wonder if fixing the view-*frame*-source might be easier after https://chromium-review.googlesource.com/c/chromium/src/+/695913:


Pros of depending on the other CL:

- Easier to write browser tests for this scenario (see ViewSourceTest.HttpPostInSubframe in chrome/browser/tab_contents/view_source_browsertest.cc in this CL/CR;  note that the test is currently short-circuited for PlzNavigate)

- Fixing this in //content might be easier than fixing this in //chrome layer (//chrome cannot easily access to FrameNavigationEntries)


Cons of depending on the other CL:

- More difficult to merge the fix back to M63 (if the merge is needed)

I started a simple CL built on top of https://chromium-review.googlesource.com/c/chromium/src/+/695913 that fixes the issue.

It seems to work, but I am still in the "I don't know what I am doing" state.
ViewSourceTest.HttpPostInSubframe passes and when I use the manual repro steps, it works too.

It looks like it also fixes the non-plznavigate issue described by the comment:
```
  // TODO(lukasza):  https://crbug.com/774691 : Verify the responce nonce
  // (similarily to how this is done in the ViewSourceTest.HttpPostInMainframe
  // test).  Today the nonce is mismatched (e.g. the http server sees a new POST
  // request) even without PlzNavigate :-(.
```

I think the issue is that WebContentsImpl::ViewSource() only copy the PageState but not the FrameNavigationEntry. PlzNavigate uses the FrameNavigationEntry. I think blink relies more on the PageState, maybe that's why it worked better without PlzNavigate.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/e1b954d9a6cf66a123ddf719860aa4e5b5cd2888

commit e1b954d9a6cf66a123ddf719860aa4e5b5cd2888
Author: Lukasz Anforowicz <lukasza@chromium.org>
Date: Mon Oct 30 21:28:06 2017

Move view-source handling to the //content layer.

This CL moves most of handling of view-source into the //content layer,
exposing it through a single public API:
  void RenderFrameHost::ViewSource()

This move helps to
- Avoid passing PageState to the //chrome layer (e.g. via
  content::CustomContextMenuContext).
- Create browser tests that can simulate triggerring a view-source
  from the code (e.g. without having to simulate mouse clicks).
- Ensure that the right navigation entries are used - preventing
  incorrect reusing of main frame's site instance for showing
  a subframe's view-source ( https://crbug.com/770946 )

This CL adds regression tests for  https://crbug.com/523  that ensure that
view-source for HTTP POST works fine in case of main frame and subframe.
Works fine = no new network requests are issued (verified by a response
nonce added to the /echoall default handler in the embedded http test
server).

Bug: 770487,  770946 ,  774691 ,  699493 
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_site_isolation
Change-Id: Ic0afeed898b4f0900f3f8ad47a903f83f2c589d3
Reviewed-on: https://chromium-review.googlesource.com/695913
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Matt Menke <mmenke@chromium.org>
Reviewed-by: Charlie Reis <creis@chromium.org>
Reviewed-by: Scott Violet <sky@chromium.org>
Commit-Queue: Łukasz Anforowicz <lukasza@chromium.org>
Cr-Commit-Position: refs/heads/master@{#512625}
[modify] https://crrev.com/e1b954d9a6cf66a123ddf719860aa4e5b5cd2888/chrome/browser/chrome_navigation_browsertest.cc
[modify] https://crrev.com/e1b954d9a6cf66a123ddf719860aa4e5b5cd2888/chrome/browser/extensions/api/web_navigation/web_navigation_api.cc
[modify] https://crrev.com/e1b954d9a6cf66a123ddf719860aa4e5b5cd2888/chrome/browser/renderer_context_menu/render_view_context_menu.cc
[modify] https://crrev.com/e1b954d9a6cf66a123ddf719860aa4e5b5cd2888/chrome/browser/renderer_context_menu/render_view_context_menu_browsertest.cc
[modify] https://crrev.com/e1b954d9a6cf66a123ddf719860aa4e5b5cd2888/chrome/browser/tab_contents/view_source_browsertest.cc
[modify] https://crrev.com/e1b954d9a6cf66a123ddf719860aa4e5b5cd2888/chrome/browser/ui/browser.cc
[modify] https://crrev.com/e1b954d9a6cf66a123ddf719860aa4e5b5cd2888/chrome/browser/ui/browser.h
[modify] https://crrev.com/e1b954d9a6cf66a123ddf719860aa4e5b5cd2888/chrome/browser/ui/browser_command_controller.cc
[modify] https://crrev.com/e1b954d9a6cf66a123ddf719860aa4e5b5cd2888/chrome/browser/ui/browser_commands.cc
[modify] https://crrev.com/e1b954d9a6cf66a123ddf719860aa4e5b5cd2888/chrome/browser/ui/browser_commands.h
[modify] https://crrev.com/e1b954d9a6cf66a123ddf719860aa4e5b5cd2888/chrome/browser/ui/views/page_info/page_info_bubble_view_browsertest.cc
[add] https://crrev.com/e1b954d9a6cf66a123ddf719860aa4e5b5cd2888/chrome/test/data/form_that_posts_to_echoall.html
[modify] https://crrev.com/e1b954d9a6cf66a123ddf719860aa4e5b5cd2888/content/browser/frame_host/render_frame_host_delegate.h
[modify] https://crrev.com/e1b954d9a6cf66a123ddf719860aa4e5b5cd2888/content/browser/frame_host/render_frame_host_impl.cc
[modify] https://crrev.com/e1b954d9a6cf66a123ddf719860aa4e5b5cd2888/content/browser/frame_host/render_frame_host_impl.h
[modify] https://crrev.com/e1b954d9a6cf66a123ddf719860aa4e5b5cd2888/content/browser/web_contents/web_contents_impl.cc
[modify] https://crrev.com/e1b954d9a6cf66a123ddf719860aa4e5b5cd2888/content/browser/web_contents/web_contents_impl.h
[modify] https://crrev.com/e1b954d9a6cf66a123ddf719860aa4e5b5cd2888/content/common/frame_messages.h
[modify] https://crrev.com/e1b954d9a6cf66a123ddf719860aa4e5b5cd2888/content/public/browser/render_frame_host.h
[modify] https://crrev.com/e1b954d9a6cf66a123ddf719860aa4e5b5cd2888/content/public/browser/web_contents.h
[modify] https://crrev.com/e1b954d9a6cf66a123ddf719860aa4e5b5cd2888/content/public/browser/web_contents_delegate.cc
[modify] https://crrev.com/e1b954d9a6cf66a123ddf719860aa4e5b5cd2888/content/public/browser/web_contents_delegate.h
[modify] https://crrev.com/e1b954d9a6cf66a123ddf719860aa4e5b5cd2888/content/public/common/context_menu_params.h
[modify] https://crrev.com/e1b954d9a6cf66a123ddf719860aa4e5b5cd2888/content/renderer/context_menu_params_builder.cc
[modify] https://crrev.com/e1b954d9a6cf66a123ddf719860aa4e5b5cd2888/net/test/embedded_test_server/default_handlers.cc
[modify] https://crrev.com/e1b954d9a6cf66a123ddf719860aa4e5b5cd2888/third_party/WebKit/Source/core/page/ContextMenuClient.cpp
[modify] https://crrev.com/e1b954d9a6cf66a123ddf719860aa4e5b5cd2888/third_party/WebKit/public/web/WebContextMenuData.h

The issue is fixed. The fix I was talking about was integrated into the patch in comment 8.

Let me know if you think we should try to do something to merge it into M63.

The fix ended up pretty big (+422, -207 lines) so I'd rather avoid the merge if possible.  So far (at least AFAIK) this issue has not yet been reported externally, so hopefully the affected scenario does not happen frequently enough to require a merge.