Manual regression range:
Good Build: 48.0.2546.0 
Bad Build:  48.0.2548.0 

Narrow bisect:
https://chromium.googlesource.com/chromium/src/+log/41826031a78af14dc53ab525f01aa0613bef44f9..24f0671d7b69410c522349dd9ad8f02e852238c2?pretty=fuller&n=10

Suspecting: 356233 ?
Kindly help to re-assign, if your changes are not cause for this issue.

Note: 
1.Issue is seen on Mac 10.11.6, 10.12.1 as well.
2.Issue not seen on Win & Linux OS

Deleted: Actual_Result.mov 1.8 MB

Actual_Result.mov 1.8 MB Download

Deleted: Expected_Result.mov 2.2 MB

Expected_Result.mov 2.2 MB Download

Would you bisect again?

My patch only affects layout tests. So it probably doesn't cause this issue.
I'm sorry. I'm not sure who is the best guy who owns this issue.

Looking at the attached video (and reproducing by using MacPro), I think, it is caused by some code related to fix window position when the window is moved out side of visible area (of a display).

cc'ing some mac folks. I think i saw changes recently about resizing windows to better map to what's visible. 

I'm not sure, but looking at the print dialogbox, it is implemented by using <embed>.
So I guess, the following patch is related to this issue:
https://chromium.googlesource.com/chromium/src/+/8c6f10e481a5c2af50ac58d2971a171806015bc9

thestig, would you take a look at this issue?

I mean, <embed id=“plugin” type=“application/x-google-chrome-pdf” src=“chrome://pring/9/0/print.pdf” stream-url=“chrome://print/9/0/print.pdf” headers background-color=…>…</embed>

Yeah I don't think the bisect is right. I suspect this isn't a regression. I don't think it's related to the dialog contents.

My guess is -[ConstrainedWindowSheetController onParentWindowSizeDidChange:] is being received during a tab drag (but not a window drag), and that's causing the sheet position to update, but in a way that's inconsistent/racy with the parent window position at the time. But I haven't investigated fully.

IMO the bug is pretty minor - you really need to "shake" the tab to get the print dialog to "fall off" the parent window. But it is a bug.

MacViews dialogs have a more limited involvement with ConstrainedWindowSheetController (SingleWebContentsDialogManagerViewsMac rather than SingleWebContentsDialogManagerCocoa). Print Preview is special in other ways, but I couldn't repro this with any MacViews dialogs, and Print Preview will eventually be plumbed through using SWCDMVM rather than SWCDMC.

r356249 cannot be the cause. It only affects rendering in in a renderer/utility process and cannot affect the browser side. Setting this back to untriaged...

With response to comment #6:
Rechecked again and this is a regression issue as mentioned in comment #1 and below is the narrow bisect

https://chromium.googlesource.com/chromium/src/+log/314d48989a20ea933e3577e87284c23152c9608d..20c59e0632ec7a6e1c688e184226a7dbe0ca4e59?pretty=fuller&n=50

Kindly help to reassign this issue.

Unable to find a possible suspect from the above CL. Could some one please help us to find a right owner to fix the issue. Adding Needs-Triage label.

Thanks.!

I tried bisecting this twice and failed.

r326351 really does seem to be good.
r346071 really does seem to be bad.

But my attempts to narrow it down further have failed. It might be something to do with a navigation that occurs and dismisses the print preview while loading the NTP. Maybe dismissing the dialog once is needed to make it occur.

Neither of these look likey.

./tools/bisect-builds.py -amac64 --use-local-cache --good=200000 --bad=400000 -- --no-first-run
You are probably looking for a change made after 348375 (known good), but no later than 348378 (first known bad).
NOTE: There is a Blink roll in the range, you might also want to do a Blink bisect.
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/f0cf27e36a998f506342022738902751a19df1cc..cd56d6a29e707e851033eb52b113df6446ea9736

./tools/bisect-builds.py -amac64 --use-local-cache --good=326351 --bad=348378 -- --no-first-run
You are probably looking for a change made after 346067 (known good), but no later than 346071 (first known bad).
NOTE: There is a Blink roll in the range, you might also want to do a Blink bisect.
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/6abd8652f8bc7a1d825962003ac88ec6a37a82f1..de18baef79643e04e55ca2630a0bbc57af891b47


Anyway, I think this is a minor issue.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label.

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

I can't repro any more. Maybe this was an OS bug.