The issue seems to be specific to mac dual monitor and ET-team doesn't have the set up to test the issue. Hence, forwarding the issue to inhouse team for further triaging of the issue.

Thanks...!!

I am able to reproduce this as well. Additionally, the behavior on the new window is broken:

- When right-clicking on a link and selecting "Open Link in New Tab", nothing happens
- If a link is set up to open a new tab, it opens in the same window but the back button is disabled

 Issue 836156  has been merged into this issue.

Able to reproduce the issue on the latest stable(66.0.3359.117) on Mac OS 10.3.3 and below are the observations:

Precondition1: Always show toolbar in full screen enabled and Chrome is opened in full screen.

Scenario 1:
==========
1. Dragging the tab from secondary screen to primary shows the enlarged window/window flickering/arrow pointer misplaced(onthe dragged window) in the secondary screen.

Precondition2: Always show toolbar in full screen enabled but chrome is not in full screen.

Scenario 2:
===========
1. Dragging the tab from secondary screen to primary and then back to secondary shows the behavior as attached in the screenshot of C#0. New tab is missing.

Scenario 1: seems to be reproducible on canary(68.0.3406.0), dev(67.0.3396.18), stable(66.0.3359.117)
Scenario 2: seems to be reproducible only on the latest stable(66.0.3359.117) and works fine on canary(68.0.3406.0), dev(67.0.3396.18) for me.


Bisect for scenario1:

Last good build: 66.0.3328.0
First bad build: 66.0.3329.0

Changelog:
https://chromium.googlesource.com/chromium/src/+log/44cf3977560cac12416f8f88a93aa92628cf0e57..dec06ed3705dc353977df4441eed7cb16d170927

shrike@: Could you please take a look at this.
 

Note: Will update the reverse bisect for scenario2.

shrike@ is no longer on chromium, reassigning to lgrey@

I can't repro on 66.0.3359.117. Is it possible to attach a video? If it's only possible to record a single screen, the one where the tabstrip goes away would be best.

Also: is the setup a desktop with two monitors or a laptop with an external monitor attached?

I am on iMac with 2 external monitors on it. I'm only able to record with 1 screen with quicktime. I also found out it only works if you have your screen resolution setting set on scaled.

Deleted: Screen Shot 2018-04-25 at 18.18.22.png 95.8 KB

	Screen Shot 2018-04-25 at 18.18.22.png 95.8 KB View Download

Correction in C#7:

> Both scenarios seems to be reproducible on the latest stable(66.0.3359.117), dev(67.0.3396.18) and the latest canary(68.0.3406.0) on Mac OS 10.13.3 on a laptop with an external monitor attached.

> Tabstrip missing sceanrio seems to be reproducible only at a specific window size when chrome window is moved from external monitor to laptop and then back to external monitor.

Test steps followed:
=====================
1. Connect an external monitor to laptop.
2. Open chrome on external monitor and drag any tab from ext. monitor to laptop and then back to ext. monitor.
3. Release the dragged tab and observe.

Observations: 
==============
1. Tab being released doesn't have new tab button. This is reproducible only when the chrome window is opened at specific size in external monitor.(Attached: 835296_Scenario_2.webm)
2. The arrow pointer is completely misplaced when tab is dragged from ext. monitor to laptop. (Attached: 835296_Scenario_1.webm)
3. Regression range and bisect is same as in C#7.

lgrey@: Please let me know if any further information required here.

Thank you!

Deleted: 835296_Scenario_1.webm 6.6 MB

	835296_Scenario_1.webm 6.6 MB View Download

Deleted: 835296_Scenario_2.webm 11.2 MB

	835296_Scenario_2.webm 11.2 MB View Download

Hey all,

I can reproduce this as well, and a couple other Googlers have reported it to me (I've asked them to file feedback reports).

- https://listnr.corp.google.com/report/85380971607
- https://listnr.corp.google.com/report/85381064051


Adding the con ops hotlist for tracking.

Thanks!

Unable to repro with my laptop either :/

craigtumblinson@ are you seeing any trends on the specific hardware people are using?

The display settings screenshot in #c10 is very helpful; if someone who can reproduce can show the settings for the external monitor (and maybe the "Arrangement" tab from the primary monitor), I'd appreciate it!

Screenshots that you asked for.
http://take.ms/0UOGX
http://take.ms/RlRRu
http://take.ms/qrvW6
http://take.ms/H9Ste
http://take.ms/xzzL4

lgrey@ - Happy to!

The Googler reports are coming from folks with a laptop and two additional displays (3 screens total).

Here's my setup details:
Arrangement: https://screenshot.googleplex.com/7fenz9VK1ZG.png
Left Display: https://screenshot.googleplex.com/BnGJcKnWWjV.png
Middle Display: https://screenshot.googleplex.com/rZkC2HoOgUW.png
Right Display: https://screenshot.googleplex.com/5KSNX1PBH1U.png

In my case, I usually see the issue when I drag a tab out of a window on my left display, across my laptop as the middle display, and drop it as it's own window on the right display.

Thanks!

Thanks, two monitors did the trick for me!

Thanks, suleman1103@!

I deleted your comment since it looks like the video has some data you might not want visible on a public bug.

*** Bulk Edit ***
M67 Stable promotion is coming soon. Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and request a merge into the release branch ASAP. 

If fix is already merged to M67 and nothing else is pending, pls mark the bug as fixed. Thank you.

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

commit 729c76b953de404aedd4ee6dd862656ac50100a6
Author: Leonard Grey <lgrey@chromium.org>
Date: Thu May 03 14:17:48 2018

Mac: Forward all messages from window delegates to TabWindowController

In https://chromium-review.googlesource.com/c/chromium/src/+/852978,
TabWindowController was changed to no longer subclass NSWindowController.
But, since many callers assumed that a browser window's window controller
was also its delegate, the new window controller proxies NSWindowDelegate
methods to the TabWindowController.

Unfortunately, it turns out that callers also make assumptions about the
delegate, and if we only forward NSWindowDelegate methods, some fall
through the cracks.

This change removes the NSWindowDelegate check from the forwarding code,
to ensure that TabWindowController receives all method calls meant for it.

Bug:  835296 
Change-Id: Ia16b8018c7c110e44a34b0f4cb1a636a143c3415
Reviewed-on: https://chromium-review.googlesource.com/1040945
Reviewed-by: Sidney San Martín <sdy@chromium.org>
Commit-Queue: Leonard Grey <lgrey@chromium.org>
Cr-Commit-Position: refs/heads/master@{#555720}
[modify] https://crrev.com/729c76b953de404aedd4ee6dd862656ac50100a6/chrome/browser/ui/cocoa/tabs/tab_window_controller.mm

Tested this on Mac OS 10.13.3 on the latest canary: 68.0.3419.0 as per the test steps and set up mentioned in C#12. This seems to be working fine on the latest canary 68.0.3419.0.

Adding the verified label for M-68.

 Issue 838878  has been merged into this issue.

[Auto-generated comment by a script] We noticed that this issue is targeted for M-67; 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-67 label, otherwise remove Merge-TBD label. Thanks.

I think this is safe for a merge to 67

This bug requires manual review: M67 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), govind@(Desktop)

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

+ Krishna (govind@) for M67 merge approval.

Approving merge to M67 branch 3396 based on comment #23, #27 and per offline chat with lgrey@. Pls merge ASAP. Thank you.

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

commit 982dd5b0cde6e5ff28da0ea23b3cf7396af49115
Author: Leonard Grey <lgrey@chromium.org>
Date: Fri May 04 17:51:55 2018

Mac: Forward all messages from window delegates to TabWindowController

In https://chromium-review.googlesource.com/c/chromium/src/+/852978,
TabWindowController was changed to no longer subclass NSWindowController.
But, since many callers assumed that a browser window's window controller
was also its delegate, the new window controller proxies NSWindowDelegate
methods to the TabWindowController.

Unfortunately, it turns out that callers also make assumptions about the
delegate, and if we only forward NSWindowDelegate methods, some fall
through the cracks.

This change removes the NSWindowDelegate check from the forwarding code,
to ensure that TabWindowController receives all method calls meant for it.

Bug:  835296 
Change-Id: Ia16b8018c7c110e44a34b0f4cb1a636a143c3415
Reviewed-on: https://chromium-review.googlesource.com/1040945
Reviewed-by: Sidney San Martín <sdy@chromium.org>
Commit-Queue: Leonard Grey <lgrey@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#555720}(cherry picked from commit 729c76b953de404aedd4ee6dd862656ac50100a6)
Reviewed-on: https://chromium-review.googlesource.com/1044686
Reviewed-by: Leonard Grey <lgrey@chromium.org>
Cr-Commit-Position: refs/branch-heads/3396@{#481}
Cr-Branched-From: 9ef2aa869bc7bc0c089e255d698cca6e47d6b038-refs/heads/master@{#550428}
[modify] https://crrev.com/982dd5b0cde6e5ff28da0ea23b3cf7396af49115/chrome/browser/ui/cocoa/tabs/tab_window_controller.mm

Verified the merge on the latest M-67, chrome version: 67.0.3396.40 on Mac OS 10.13.3 and this is WAI, hence adding the verified label.

 Issue 845035  has been merged into this issue.

 Issue 845808  has been merged into this issue.

 Issue 846420  has been merged into this issue.

Issue 848282 has been merged into this issue.

I am seeing this on the latest stable version of Chrome (67.0.3396.79) and on Chrome Canary (69.0.3455.0) using Mac OS (10.13.4).

Using 2 extended monitors on default resolution settings on all monitors. One of the extended monitors is used as the main display. When locking the machine and stepping away for a short time results in the attached screenshot. 

Monitor layout is in the other screenshot (Mac Screen on most right of layout) along with the version of Chrome affected. 

This is also being reported by other users who are using the same versions / settings although only using a single monitor.

Deleted: Screen Shot 2018-06-12 at 14.41.12.png 32.2 KB

	Screen Shot 2018-06-12 at 14.41.12.png 32.2 KB View Download

Deleted: Screen Shot 2018-06-12 at 14.53.24.png 1.6 MB

	Screen Shot 2018-06-12 at 14.53.24.png 1.6 MB View Download

Deleted: Screen Shot 2018-06-12 at 14.40.34.png 43.1 KB

	Screen Shot 2018-06-12 at 14.40.34.png 43.1 KB View Download