You are probably looking for a change made after 512624 (known good), but no later than 512625 (first known bad).
CHANGELOG URL:
The script might not always return single CL as suspect as some perf builds might get missing due to failure.
  
https://chromium.googlesource.com/chromium/src/+log/71e3928ee44b4768fc06d647a4f53c67f45fe7a0..e1b954d9a6cf66a123ddf719860aa4e5b5cd2888

Suspect: https://chromium.googlesource.com/chromium/src/+/e1b954d9a6cf66a123ddf719860aa4e5b5cd2888

Note: Issue is not seen on Mac OS.

Tagging with blocker label, please undo if not the case.

Thank you very much for reporting the issue.

It seems that WebContentsImpl::ViewSource works fine, but when it calls WebContentsDelegate::AddNewContents at the end, it goes to a WebContentsDelegate that doesn't override the AddNewContents method (and so the no-op version from ContentBrowserClient drops the new contents on the floor...).

I am not sure if it is okay to implement AddNewContents method in extensions::ExtensionOptionsGuest / guest_view::GuestView<> / guest_view::GuestViewBase, because I am not sure if it would be okay for the guest to open a new window (in the embedder?  elsewhere?).

An alternative to implementing AddNewContents method in the affected WebContentsDelegate might be to revert part of r512625 - instead of handling showing the new WebContents itself, RenderFrameHost::ViewSource and WebContentsImpl::ViewSource could instead return the new web contents (and the //chrome layer could handle inserting the new web contents into the tab strip or into a new browser window, like it used to do here: https://chromium-review.googlesource.com/c/chromium/src/+/695913/25/chrome/browser/ui/browser_commands.cc#b1231).

It seems to me that window.open in a guest view is able to open a new window in the embedder via window.open.  Therefore maybe it is okay to implement GuestViewBase::AddNewContents method.

AFAIK window.open is handled via WebContentsImpl::CreateNewWindow.  I see that this method doesn't always call WebContentsDelegate::AddNewContents - I am guessing this is why window.open seems to work fine today for guestview.  I am also guessing that window.open is broken in guestview when |params.opener_suppressed|.

FWIW, I've tested that the repro steps (showing a view-source of the backspace extension options page) are fixed after applying the following change:

$ git diff origin/master -- components/guest_view/browser/
diff --git a/components/guest_view/browser/guest_view_base.cc b/components/guest_view/browser/guest_view_base.cc
index e4cbdb2b9919..8584400a4a97 100644
--- a/components/guest_view/browser/guest_view_base.cc
+++ b/components/guest_view/browser/guest_view_base.cc
@@ -674,6 +674,17 @@ bool GuestViewBase::PreHandleGestureEvent(WebContents* source,
   return blink::WebInputEvent::IsPinchGestureEventType(event.GetType());
 }
 
+void GuestViewBase::AddNewContents(WebContents* source,
+                              WebContents* new_contents,
+                              WindowOpenDisposition disposition,
+                              const gfx::Rect& initial_rect,
+                              bool user_gesture,
+                              bool* was_blocked) {
+  embedder_web_contents()->GetDelegate()->AddNewContents(
+      source, new_contents, disposition, initial_rect, user_gesture,
+      was_blocked);
+}
+
 void GuestViewBase::UpdatePreferredSize(WebContents* target_web_contents,
                                         const gfx::Size& pref_size) {
   // In theory it's not necessary to check IsPreferredSizeModeEnabled() because
diff --git a/components/guest_view/browser/guest_view_base.h b/components/guest_view/browser/guest_view_base.h
index c12f4dc4358e..e8df7e6d7d8f 100644
--- a/components/guest_view/browser/guest_view_base.h
+++ b/components/guest_view/browser/guest_view_base.h
@@ -228,6 +228,12 @@ class GuestViewBase : public content::BrowserPluginGuestDelegate,
       const content::NativeWebKeyboardEvent& event) override;
   bool PreHandleGestureEvent(content::WebContents* source,
                              const blink::WebGestureEvent& event) override;
+  void AddNewContents(content::WebContents* source,
+                              content::WebContents* new_contents,
+                              WindowOpenDisposition disposition,
+                              const gfx::Rect& initial_rect,
+                              bool user_gesture,
+                              bool* was_blocked) override;

lfg@ - does what I wrote above make sense?  If yes, then I'll put the changes outlined in #c5 into a Gerrit CL and send them out for review.


I am not sure about tests for this bug yet.  I think that for mergability to M64 we might want to proceed with just the small change from #c5.  OTOH, it would be nice to also add automated tests for:

- |params.opener_suppressed| case of |window.open| from a guestview
  (this is assumming that it is indeed broken today - this needs a confirmation)

- view-source of extensions::ExtensionOptionsGuest

(I might put working on the tests on a backburner for now - it seems that tackling  issue 794079  [also guest-view related] is important for M65)

FWIW, I have manually verified that after overriding GuestViewBase::AddNewContents (as outlined in #c5) guest view cannot open new windows - this gets blocked with a javascript console error message saying: "<webview>: A new window was blocked.".  I've tested this with an ad-hoc modification of WebViewInteractiveTest.NewWindow_OpenInNewTab that I used for testing manually and where I replaced the anchor with <a href="guest.html" target="_blank" rel="noopener">This is a link</a>.

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

commit b8d59c2343c3692d868516c4e74efa83ed836988
Author: Lukasz Anforowicz <lukasza@chromium.org>
Date: Fri Dec 22 19:24:43 2017

Fixing RenderFrameHost::ViewSource() for ExtensionOptionsGuest.

After r512625, various ways of viewing page or frame source end up going
through RenderFrameHost::ViewSource which depends on ability to present
the view source WebContents to the user via WebContentsDelegate's
AddNewContent method.  This method was not overriden by
ExtensionOptionsGuest, leading to  https://crbug.com/796080 .

This CL fixes  https://crbug.com/796080  by overriding
ExtensionOptionsGuest::AddNewContent and making it forward the call to
the embedder.  This CL also adds a regression test for this scenario.

Note that by default guest views cannot open new windows - this is
blocked (unless the embedder explicitly allows this) and results
in "<webview>: A new window was blocked." error message.  This CL
does not change this - window.open('<url>', '_blank') as well
as <a target="_blank"...> in a guest view will continue to be
blocked by default.  I've tested this manually after temporarily
overriding AddNewContent method higher in the class hierarchy
- in GuestViewBase.  See also  https://crbug.com/796080#c7 .

A follow-up bug has been opened to investigate if AddNewContents
method should instead be implemented in the base class of
ExtensionOptionsGuest - in GuestViewBase: https://crbug.com/797340.

Bug:  796080 
Change-Id: I83ece7fc94bbf1005c5e2878159076949c48b076
Tbr: finnur@chromium.org or rdevlin.cronin@chromium.org
Reviewed-on: https://chromium-review.googlesource.com/841623
Commit-Queue: Łukasz Anforowicz <lukasza@chromium.org>
Reviewed-by: Lucas Gadani <lfg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#526041}
[modify] https://crrev.com/b8d59c2343c3692d868516c4e74efa83ed836988/chrome/browser/ui/webui/extensions/extension_settings_browsertest.cc
[modify] https://crrev.com/b8d59c2343c3692d868516c4e74efa83ed836988/chrome/browser/ui/webui/extensions/extension_settings_browsertest.h
[modify] https://crrev.com/b8d59c2343c3692d868516c4e74efa83ed836988/extensions/browser/guest_view/extension_options/extension_options_guest.cc
[modify] https://crrev.com/b8d59c2343c3692d868516c4e74efa83ed836988/extensions/browser/guest_view/extension_options/extension_options_guest.h

Next action on 12/28: Let's verify the fix in the Canary and request a merge to M64 if everything looks good.

[Auto-generated comment by a script] We noticed that this issue is targeted for M-64; it appears the fix may have landed after branch point, meaning a merge might be required. Please confirm if a merge is required here - if so add Merge-Request-64 label, otherwise remove Merge-TBD label. Thanks.

The NextAction date has arrived: 2017-12-28

How does this look in Canary?

Requesting a merge to M64.

commit b8d59c2343c3692d868516c4e74efa83ed836988 (the fix from #c8 above) was initially in 65.0.3302.0

I tried the Canary available today (65.0.3305.0) and confirmed that the bug is fixed (i.e. when following the repro steps I see the source in a new tab as expected).

Ooops, attached a wrong label in the previous comment.

This bug requires manual review: M64 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), kbleicher@(ChromeOS), abdulsyed@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Just to update:
Above issue is fixed on Windows(7,8,10)and Liunx(14.1LTS) using canary build 65.0.3307.0

Thank you.

Approving merge to M64. Branch:3282

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

commit e0a574d2070f1502dd7ee8f1bc5784264778f432
Author: Lukasz Anforowicz <lukasza@chromium.org>
Date: Tue Jan 02 18:19:10 2018

Fixing RenderFrameHost::ViewSource() for ExtensionOptionsGuest.

After r512625, various ways of viewing page or frame source end up going
through RenderFrameHost::ViewSource which depends on ability to present
the view source WebContents to the user via WebContentsDelegate's
AddNewContent method.  This method was not overriden by
ExtensionOptionsGuest, leading to  https://crbug.com/796080 .

This CL fixes  https://crbug.com/796080  by overriding
ExtensionOptionsGuest::AddNewContent and making it forward the call to
the embedder.  This CL also adds a regression test for this scenario.

Note that by default guest views cannot open new windows - this is
blocked (unless the embedder explicitly allows this) and results
in "<webview>: A new window was blocked." error message.  This CL
does not change this - window.open('<url>', '_blank') as well
as <a target="_blank"...> in a guest view will continue to be
blocked by default.  I've tested this manually after temporarily
overriding AddNewContent method higher in the class hierarchy
- in GuestViewBase.  See also  https://crbug.com/796080#c7 .

A follow-up bug has been opened to investigate if AddNewContents
method should instead be implemented in the base class of
ExtensionOptionsGuest - in GuestViewBase: https://crbug.com/797340.

TBR=lukasza@chromium.org

(cherry picked from commit b8d59c2343c3692d868516c4e74efa83ed836988)

Bug:  796080 
Change-Id: I83ece7fc94bbf1005c5e2878159076949c48b076
Tbr: finnur@chromium.org or rdevlin.cronin@chromium.org
Reviewed-on: https://chromium-review.googlesource.com/841623
Commit-Queue: Łukasz Anforowicz <lukasza@chromium.org>
Reviewed-by: Lucas Gadani <lfg@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#526041}
Reviewed-on: https://chromium-review.googlesource.com/847639
Reviewed-by: Łukasz Anforowicz <lukasza@chromium.org>
Cr-Commit-Position: refs/branch-heads/3282@{#381}
Cr-Branched-From: 5fdc0fab22ce7efd32532ee989b223fa12f8171e-refs/heads/master@{#520840}
[modify] https://crrev.com/e0a574d2070f1502dd7ee8f1bc5784264778f432/chrome/browser/ui/webui/extensions/extension_settings_browsertest.cc
[modify] https://crrev.com/e0a574d2070f1502dd7ee8f1bc5784264778f432/chrome/browser/ui/webui/extensions/extension_settings_browsertest.h
[modify] https://crrev.com/e0a574d2070f1502dd7ee8f1bc5784264778f432/extensions/browser/guest_view/extension_options/extension_options_guest.cc
[modify] https://crrev.com/e0a574d2070f1502dd7ee8f1bc5784264778f432/extensions/browser/guest_view/extension_options/extension_options_guest.h