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

Issue 889748 link

Starred by 4 users

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 2
Type: Compat



Sign in to add a comment

Clicking on print button gives a blank page. But works in every other browser.

Reported by senurama...@gmail.com, Sep 27

Issue description

UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:63.0) Gecko/20100101 Firefox/63.0

Example URL:
https://community.superoffice.com/en/crm-online/partners-and-app-store/How-To-Develop-on-the-SuperOffice-Online-Platform/building-your-first-application/Security-and-Authentication/non-interactive-rest-access/

Steps to reproduce the problem:
1. Open incognito (To clear cache)
2. Go to the URL (https://community.superoffice.com/en/crm-online/partners-and-app-store/How-To-Develop-on-the-SuperOffice-Online-Platform/building-your-first-application/Security-and-Authentication/non-interactive-rest-access/)
3. Click on the print button in that site (Top right)

What is the expected behavior?
The print page dialog box should appear with the text content

What went wrong?
The print page dialog box appears, but not the text content.
However, if we click on that button 3 times (In the same browser session), it will display correctly. It happens in the first two clicks. 
This is working fine in all the other browsers (IE, Edge and Firefox).

Does it occur on multiple sites: N/A

Is it a problem with a plugin? No 

Did this work before? N/A 

Does this work in other browsers? Yes

Chrome version: 71.0.3562.0  Channel: canary
OS Version: 10.0
Flash Version: 24.0.0.189 internal-not-yet-present

Should need a fix definitely ASAP. 
This is somewhat similar to this issue : https://groups.google.com/a/chromium.org/forum/#!topic/chromium-discuss/KYxVuVd1oTs
 
Labels: Needs-Triage-M71
Cc: ajha@chromium.org
Components: UI>Browser>PrintPreview
Labels: Target-71 M-71 FoundIn-71 OS-Linux OS-Mac
Status: Untriaged (was: Unconfirmed)
Able to reproduce the issue on the latest canary 71.0.3564.0 on Windows-10, Mac OS 10.13.6 and Linux Debian Rodete, in incognito mode. Similar behavior is seen on older chrome version 60.0.3112.20 as well.

Marking this as Untriaged as non regression issue for further investigation.
Components: Blink>Loader
Labels: -M-71 -Target-71 -FoundIn-71
Summary: Clicking on print button gives a blank page. But works in every other browser. (was: Cliking on print button gives a blank page. But works in every other browser.)
This may be some weird document loading + timing issue. When I saved a copy of the HTML document to disk, this problem does not happen.
This works in every browser except Chrome. So the Chrome might have to deal with the document loading + timing issue from itself as every other browser could handle that.
Yes, I'm saying Chromium has a document loading issue. I'm not saying the webpage itself is bad.
@thestig@chromium.org
Thanks for diagnosing this. Hope you guys will work on that :) 
Is there any update about this issue ? 
Status: Available (was: Untriaged)
Did some initial investigation. Attached file is a minimized repro.

Print preview is blank because render-blocking stylesheet is still loading when window.print() is called.
HTML spec [1] says print() should defer printing until the document is ready for post-load tasks:

"""When the print() method is invoked, if the Document is ready for post-load tasks, then the user agent must run the printing steps in parallel. Otherwise, the user agent must only set the print when loaded flag on the Document."""

LocalDOMWindow::print() attempts to do that with the |should_print_when_finished_loading_| flag [2]:

  void LocalDOMWindow::print(ScriptState* script_state) {
    // (snip)
    if (GetFrame()->IsLoading()) {
      should_print_when_finished_loading_ = true;
      return;
    }
    // (snip)
    page->GetChromeClient().Print(GetFrame());
  }

But GetFrame()->IsLoading() returns false in this case. It seems because document.write() doesn't update the frame loading status?

[1] https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html#printing
[2] https://chromium.googlesource.com/chromium/src/+/2819b8659153560cf923bfb4b6d507e0660cd893/third_party/blink/renderer/core/frame/local_dom_window.cc#694

index.html
1023 bytes View Download
Cc: yhirano@chromium.org tkonch...@chromium.org esprehn@chromium.org le...@chromium.org nainar@chromium.org msten...@opera.com nyerramilli@chromium.org japhet@chromium.org hirosh...@chromium.org
 Issue 568536  has been merged into this issue.
Able to reproduce the issue on the latest canary 72.0.3608.4
As I have seen, this issue is not reproducible in the latest canary ver.73.0.3632.0.
The minimized repro file provided by the @ksakamoto@chromium.org is greatly appreciated. And everyone worked on this issue. Could you officially declare the status of this issue (Whether it has been officially fixed or not)? And when this will be in the stable release ?

Sign in to add a comment