Issue metadata
Sign in to add a comment
|
Constrained dialogs do not fully block pages
Reported by
aiman.an...@etouch.net,
Jul 3
|
||||||||||||||||||||||||
Issue descriptionChrome Version : 69.0.3480.0 (Official Build) 3c4342c43a5e8e33042613038d4777cc1c9349af-refs/branch-heads/3480@{#1} 64 bit OS: Mac(10.12.6, 10.13.1, 10.13.6, 10.14). Pre-Condiiton: Enable 'Use Views browser windows instead of Cocoa' flag from chrome://flags and relaunch the browser. Test URL: http://www.pdf995.com/samples/pdf.pdf Steps to reproduce: 1. Launch chrome, navigate to the above Test URL and click on 'Print Button' (print preview window opens) 2. Try to click on Download/Rotate/Print button on pdf toolbar seen in the background. 3. Observe. Actual Result: Background controls are accessible even when print-preview is open. Expected Result: Background controls should not be accessible when print-preview is open. This is a Non-regression issue, seen from M-67 series, build #67.0.3381.0 Kindly refer the screen-cast using the below given link. https://drive.google.com/drive/folders/1erD1bc2x7Mu4XNOroT3U4d708pUMXTgf?usp=sharing Thank You.
,
Jul 11
Looks like an issue with the Mac Views Constrained Dialog.
,
Jul 12
Okay - over to spqchan@ :)
,
Aug 27
,
Aug 28
Mac triage: over to avi@ :)
,
Aug 28
,
Aug 28
WebContentsModalDialogManager::BlockWebContentsInteraction only marks the widget of the top-level frame as blocked. How did this work for the Mac before? How does this work for Windows?
,
Aug 28
It doesn't. On Windows, the preview dialog is so big it covers the page. If you cause a small dialog to show up, it doesn't block things. This is not a Mac issue.
,
Aug 28
Is this the same as https://crbug.com/863582 ?
,
Aug 28
|
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by rbasuvula@chromium.org
, Jul 3