Something is up, I can't reproduce this at all. It looks fine to me, see my screencast.
I also can't detach the tab in fullscreen when there's only one. It's not supposed to so that's really weird.

I just checked though and my machine is 10.12.2? Maybe it's only an issue on 10.12.3?
Can you confirm if you can reproduce it on 10.12.2?

Deleted: attempt.mov 17.4 MB

attempt.mov 17.4 MB Download

I'm upgrading to 10.12.3 right now, fyi

This is strange, I still can't reproduce any of the issues. I'll go around tomorrow and see if anyone else can reproduce it

Screencast for #3

Deleted: attempt 2.mov 28.7 MB

attempt 2.mov 28.7 MB Download

I can reproduce it on 10.12.3 (iMac 21,5 2013 NonRetina), but I can't reproduce it on 10.11.6 (MacBook Air 11'' 2012).

So it seems to be a 10.12.x issue only.

(I filed this issue ( Issue 603918 ) a while ago for 10.11.x, but we closed it since we couldn't reproduce it any longer.)

I can't replicate this on neither of my dev machines (one of them is retina), but I'm able to replicate this on the new MBP. It's strange, I have no idea why the behavior is different :/

spqchan / shrike: This issue seems to be caused by the settings of the display resolution.

This means especially with my iMac 21,5 Non-Retina:

Standard Resolution 1920x1080 -> Bug appears.

Resolution 1600 x 900: No bug.

Resolution 1280 x 720: No bug.

I hope this helps :-)

In addition to my comment 8: After switching the display back to the standard resolution of 1920x1080 the bug is gone... This is really strange!!!

Probably it will appear again after rebooting the Mac?!

Thanks a ton for testing this out! It's really helpful

This is really strange, I'm only able to reproduce this buy on the standard resolution, but not all machines. I'll give a try and switch the displays and see if the bug fixes itself on the ones I can reproduce it in. 

Hey spqchan@, I am happy to help :-)

I have a new theory: The Dock is also a culprit (also in standard display resolution.)

Attached a screencast:

- When the Dock is in hidden mode, the bug doesn't appear.
- When the Dock is in unhidden mode, the bug appears.

I hope this helps.

Deleted: fullscreen_bug.mov 13.7 MB

fullscreen_bug.mov 13.7 MB Download

Yes! It looks like the Dock is the root of evil. I'm able to replicate the problem once I made it visible. Thanks for diagnosing the issue :)

Great. Thanks for fixing it in advance.

It's not the dock - I can reproduce it regardless of the dock hide setting.

:-( Does it go away when you change the screen resolution?

Inside of continueDrag:, for me, [sourceController_ menubarOffset] returns -22 and [sourceController_ menubarHeight] returns 22. They get added together and cancel each other out. Making menuBarOffset a positive value gets closer to the correct position but the tab is still in the wrong location relative to the click-down point.

It seems like -[BrowserWindowController menubarOffset] must be returning an incorrect value for my situation. Seems like that's dependent on the result of -[FullscreenToolbarLayout computeLayout].

How different it is when the menubar is there and when it's not there?

Also menubar should be -22 when there's a menubar, since it's how much the toolbar should be offset from the top.

> How different it is when the menubar is there and when it's not there?

When the menubar is visible the drag window is about 8pt (hard to give the precise #) lower on the screen than when the menu bar is not visible. In other words, the window is closer to the mouse when the menu is not visible (by 8pt).

> Also menubar should be -22 when there's a menubar, since it's how much the toolbar should be offset from the top.

I'm not following all of the logic there - it seems like you don't need fancy calculations to compute the vertical location of the drag tab under the mouse? For example if I click in a tab 5pt below its top edge, it seems like the new window's tab just needs to be positioned so that its top edge is 5pt above the mouse.

>I'm not following all of the logic there - it seems like you don't need fancy calculations to compute the vertical location of the drag tab under the mouse? For example if I click in a tab 5pt below its top edge, it seems like the new window's tab just needs to be positioned so that its top edge is 5pt above the mouse.

Sorry, I should've explained. So the menubarOffset should be -22 when the menubar is fully revealed, because it means that the toolbar needs to be offset 22 pts in order to stay underneath the menubar.

Anyway, the calculation is there because when the menubar is shown, the vertical location need to get offset by 22 pts along with the toolbar. Like what you said, if you click 5pts from the top of the tab, the tab's top edge needs to be 5pts away from the mouse. We calculate the vertical offset, assuming the tabstrip is at the top of the window

However, if the menubar is shown, the tabstrip is actually 22 below the top of the source window, not at the top. Since the tabstrip of the destination window is at the top and will not have that -22 offset, we need to add the menubar height back to it to cancel it out.

But yeah, it looks like the dock or w/e is throwing the calculation off =/
In my case, it works really well, until I change the dock setting to "Always show". Then it gets weird.

Re: my comment about all of the logic - where I was going with that is that it seems like if you work with screen coordinates you don't need to worry about vertical offsets from other screen elements.

For example, if I click a tab in the tabstrip and start dragging, if I note the screen location of the mouse when I tear the tab out, that's all I need to know to correctly position the tab under the mouse in the new window. I don't have to think about offsetting the new window by some amount because the tabstrip window is or isn't offset by the menu bar. You completely avoid worrying offsets, and all of the code gets a lot simpler and less likely to suffer from edge case bugs. Does that make sense?

This Mac quality of life bug haven't been touched by its owner in a while, so I'm bumping it back to "available". Feel free to change it back to "assigned" if you'd rather not have someone else take it.

Mac triage: over to sdy@

*** UI Mass Triage***

Providing observations on latest Chrome verions:

Tested the reported issue on the latest Stable #71.0.3578.62(available to DUT) and Canary #72.0.3618.0 and observed different behavior as the UI of latest Chrome versions is updated:

Followed the below steps:
1. Launch Chrome.
2. Open two new tabs (A & B) and focus is on tab B
3. Shift to full screen mode.

Stable: 
4. Pull the tab 'B' out.
5. Observed that tab is swiped to right and opened in full screen mode.

Canary:
4. Observed that no other tabs are displayed and only (selected tab B) is seen in full screen mode.

Thanks!