Bug 68614 – [chromium] matchMedia('print') queries fire multiple times when printing

• Status: RESOLVED
• Resolution: WONTFIX
• Component: Printing

[Dominic Cooney]

Created attachment 108320 [details]
Repro

This was first reported as a Chromium bug <http://code.google.com/p/chromium/issues/detail?id=85013> however I believe this is a bug in the Chromium port of WebKit so refiling it here.

Repro steps:

1. Open the attached matchmedia.html (from the Chromium bug.)
2. File > Print
3. Print the document/generate and view a PDF

Expected printed output:

Listener triggered!
  media: print
  matches: true
  addListener: function addListener() { [native code] }
  removeListener: function removeListener() { [native code] }

What is actually printed:

Listener triggered!
  media: print
  matches: true
  addListener: function addListener() { [native code] }
  removeListener: function removeListener() { [native code] }
Listener triggered!
  media: print
  matches: false
  addListener: function addListener() { [native code] }
  removeListener: function removeListener() { [native code] }
Listener triggered!
  media: print
  matches: true
  addListener: function addListener() { [native code] }
  removeListener: function removeListener() { [native code] }

The matchMedia callback is being triggered too often.

I believe the problem stems from Chromium’s WebFrame creating and destroying a PrintContext when it generates the print preview, and again when the document is printed. It should probably reuse one PrintContext.

[Dominic Cooney]

Created attachment 108322 [details]
WIP Patch

[WebKit Review Bot]

Comment on attachment 108322 [details]
WIP Patch

Attachment 108322 [details] did not pass cr-mac-ews (chromium):
Output: http://queues.webkit.org/results/9792277

[WebKit Review Bot]

Comment on attachment 108322 [details]
WIP Patch

Attachment 108322 [details] did not pass chromium-ews (chromium-xvfb):
Output: http://queues.webkit.org/results/9801074

[Dominic Cooney]

Expect this to fail cr-*-ews, it is an API change; updated callers <http://codereview.chromium.org/7993005/>

[Dominic Cooney]

Created attachment 112162 [details]
Patch

[WebKit Review Bot]

Please wait for approval from [e-mail] before submitting because this patch contains changes to the Chromium public API.

[Dominic Cooney]

Comment on attachment 112162 [details]
Patch

CQ-: this should not be landed until the Chromium side is reviewed; see <http://crbug.com/85013>.

[WebKit Review Bot]

Comment on attachment 112162 [details]
Patch

Attachment 112162 [details] did not pass chromium-ews (chromium-xvfb):
Output: http://queues.webkit.org/results/10202732

[Steve VanDeBogart]

Drive by comment: WebFrame.h:427 Out of date comment? It looks like printBegin no longer actually reformats the page (for good reason). Now you must call setPageSizeResolution() at least once to set the other parameters and reflow the page.

[Dominic Cooney]

Created attachment 112260 [details]
Patch

[Dominic Cooney]

(In reply to comment #9)
> Drive by comment: WebFrame.h:427 Out of date comment? It looks like printBegin no longer actually reformats the page (for good reason). Now you must call setPageSizeResolution() at least once to set the other parameters and reflow the page.

Good point. I updated the comments.

[WebKit Review Bot]

Comment on attachment 112260 [details]
Patch

Attachment 112260 [details] did not pass chromium-ews (chromium-xvfb):
Output: http://queues.webkit.org/results/10201936

[Ojan Vafai]

Comment on attachment 112260 [details]
Patch

Patch looks fine, but you need to fix webkit/glue to work with the new code first (note that cr-linux didn't compile). Two sided patches aren't allowed (i.e. the chromium tip-of-tree webkit build should never be broken).

[Dominic Cooney]

The conclusion on the Chromium bug was that firing fewer media queries would require making the window less interactive (eg not resizing) when print preview was active.