New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 769479 link

Starred by 1 user
Status: Assigned
Owner:
weili@chromium.org
Cc:
█ nick@chromium.org
thestig@chromium.org
wfh@chromium.org
creis@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment

PrintPreviewDialogController seems unaware of OOPIFs

Project Member Reported by lukasza@chromium.org, Sep 27 2017 
We haven't yet found specific issues, but the PrintPreviewDialogController seems unaware of OOPIFs (e.g. it seems to use contents->GetMainFrame()->GetProcess() in a few places without considering OOPIFs).

Let's use this bug to track auditing the PrintPreviewDialogController and fixing any discovered issues.

Comment 1 by lukasza@chromium.org, Sep 27 2017 

Please note that this bug is a follow-up to https://chromium-review.googlesource.com/c/chromium/src/+/673124/10/chrome/browser/printing/print_preview_dialog_controller.cc#406

Looking at the CL above might give some more context about this bug.

Comment 2 by weili@chromium.org, Feb 17 2018

Blocking: -455764
Status: Assigned (was: Untriaged)
Yes, PrintPreviewDialogController keeps a 1-to-1 mapping between print preview dialog and previewed content's main frame process. This is ok since it is used to decide when to close preview dialog. Only when the main frame's rph is gone, we close preview dialog seems reasonable to me. Pls let me know if you have other thoughts.

Since this doesn't affect printing itself, I doesn't block other bugs.
►

Sign in to add a comment