New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

External javascript not being loaded/executed in headers in 0.12.2.1 on OS/X #2183

Closed
johnedo1234 opened this Issue Jan 29, 2015 · 18 comments

Comments

Projects
None yet
4 participants
@johnedo1234

johnedo1234 commented Jan 29, 2015

header.html:

    <html>
        <head><script src='/header.js' type="text/javascript"></script></head>
        ...

header.js:

    console.log("header");

"header" is not output to the log.

As a result, if the page numbering logic is stored in an external javascript file, it won't be executed and page numbering won't work.

This is broken in 0.12.2.1 32-bit on OS/X, but it works in 0.12.1 32-bit on OS/X.

Please help!

@johnedo1234 johnedo1234 changed the title from Page numbers not being passed in 0.12.2.1 to Javascript not being loaded in headers in 0.12.2.1 on OS/X Jan 30, 2015

@johnedo1234 johnedo1234 changed the title from Javascript not being loaded in headers in 0.12.2.1 on OS/X to Javascript not being executed in headers in 0.12.2.1 on OS/X Jan 30, 2015

@johnedo1234 johnedo1234 changed the title from Javascript not being executed in headers in 0.12.2.1 on OS/X to External javascript not being loaded/executed in headers in 0.12.2.1 on OS/X Jan 30, 2015

@sle-odoo

This comment has been minimized.

sle-odoo commented Feb 9, 2015

Hello,
I can confirm this issue on my side: with the relases of 0.12.2.1 for Windows 7 x64 and Debian Jessie x64, using the subst* function in an external js file an calling it with <script src='subst.js'></script> is not working. The same script used inline is working. I tried to tweak --javascript-delay, without success.

It works as expected in 0.12.1.

Regards
*The one referenced in the documentation.

@ashkulz

This comment has been minimized.

Member

ashkulz commented Feb 9, 2015

@sle-odoo: can you do a git bisect and see if you can identify the offending commit?

@ashkulz

This comment has been minimized.

Member

ashkulz commented Jun 2, 2015

@sle-odoo: can you post a minimal test case which can reproduce this issue? I'll try a bisect and see if I can track down the offending commit. Also, is it random or always happens?

@sle-odoo

This comment has been minimized.

sle-odoo commented Jun 16, 2015

@ashkulz you can use the test case of the @johnedo1234, it's really the same thing. Yes, it always happen. At least during my hundreds of tests :)

@ashkulz

This comment has been minimized.

Member

ashkulz commented Jun 17, 2015

@sle-odoo: does this happen on local files or on files served via HTTP/HTTPS? I'm not able to reproduce it, see the test case:

2183_m.html

<!DOCTYPE html>
<html>
  <head>
    <title>MAIN</title>
    <script type="text/javascript" src="2183.js"></script>
  </head>
  <body>
    <h1>MAIN</h1>
  </body>
</html>

2183_h.html

<!DOCTYPE html>
<html>
  <head>
    <title>HEADER</title>
    <script type="text/javascript" src="2183.js"></script>
  </head>
  <body>
    <h1>HEADER</h1>
  </body>
</html>

2183.js

console.log('script loaded');

Command Line

wkhtmltopdf --debug-javascript 2183_m.html --header-html 2183_h.html 2183.pdf

Output

Warning: file:///D:/wkhtmltopdf/static-build/msvc2013-win32-dbg/app/2183.js:1 script loaded
Warning: file:///D:/wkhtmltopdf/static-build/msvc2013-win32-dbg/app/2183.js:1 script loaded
Counting pages (2/6)
Resolving links (4/6)
Loading headers and footers (5/6)
Warning: file:///D:/wkhtmltopdf/static-build/msvc2013-win32-dbg/app/2183.js:1 script loaded
Printing pages (6/6)
Done
LEAK: 1 CachedResource
LEAK: 15 RenderObject
LEAK: 3 Page
LEAK: 3 Frame
LEAK: 48 WebCoreNode
@johnedo1234

This comment has been minimized.

johnedo1234 commented Jun 17, 2015

Yes, the problem occurred using HTTP on OS/X.

Looks like you might be testing with a 32-bit Windows Debug build. Try a 64-bit Release build if that’s the case.

@ashkulz

This comment has been minimized.

Member

ashkulz commented Jun 20, 2015

@johnedo1234: do you mean to say it happens only for release builds? or is it a 64-bit issue?

@sle-odoo: how does it happen for you?

@johnedo1234

This comment has been minimized.

johnedo1234 commented Jun 21, 2015

I just observed that you're testing against a Windows 32-bit debug build, and the original report was an OS/X 64-bit release build.

It could easily be a debug/release issue, or a 32/64 bit issue, or a Windows/Posix issue, so I'd try all of those permutations rather than just a win32 debug build before concluding it can't be reproduced.

@ashkulz

This comment has been minimized.

Member

ashkulz commented Jun 21, 2015

@johnedo1234: I think that it is up to you and @sle-odoo to help me reproduce it, as it demonstrably does not work in the environment I am using right now (not everybody has access to an OS X machine).

@johnedo1234

This comment has been minimized.

johnedo1234 commented Jun 21, 2015

Try reproducing on a 64-bit windows release build.

If that doesn't work, get yourself a Debian Jessie VM and test an x64 release build on there.

@ashkulz

This comment has been minimized.

Member

ashkulz commented Jun 21, 2015

@johnedo1234: instead of giving me instructions on what to do, why don't you show the steps to reproduce the issue with a public URL? Instructing the maintainer of an open-source project to reproduce an issue is in bad taste; the reporter has to do the legwork if he/she wants it to be fixed.

@sle-odoo

This comment has been minimized.

sle-odoo commented Jun 21, 2015

@ashkulz
Hey,
I tried your sample and yes, it's working. So i look back at my usecases (reports in Odoo) and again, it's not working until i inline the subst.js script (the one replacing the page classes by the page number). So i dug around and i found something interesting:

2183_h.html

<!DOCTYPE html>
<html>
  <head>
    <title>HEADER</title>
    <script type="text/javascript" src="2183.js"></script>
  </head>
  <body onload="subst()">
    <span class="page"/>
  </body>
</html>

2183_f.html

<!DOCTYPE html>
<html>
  <head>
    <title>FOOTER</title>
    <script type="text/javascript" src="2183.js"></script>
  </head>
  <body onload="subst()">
    <span class="page"/>
  </body>
</html>

2183_m.html

<!DOCTYPE html>
<html>
  <head>
    <title>MAIN</title>
  </head>
  <body>
    <h1>MAIN</h1>
  </body>
</html>
22:41 $ wkhtmltopdf --version
wkhtmltopdf 0.12.2.1 (with patched qt)

wkhtmltopdf --header-html 2183_h.html 2183_m.html 2183.pdf > header + main
wkhtmltopdf --footer-html 2183_f.html 2183_m.html 2183.pdf > footer + main
wkhtmltopdf --header-html 2183_h.html --footer-html 2183_f.html 2183_m.html 2183.pdf > header + main ; no footer.

Important note: once i inline the subst.js script, it is working as expected. Also, if i don't require the same file in the header (subst.js), the footer and the header are showing. So the issue is there, somewhere and this time it is reproducible. I'm still using debian jessie x64.

Thanks in advance

@ashkulz

This comment has been minimized.

Member

ashkulz commented Jun 22, 2015

@sle-odoo: good that it is now reproducible with local files, will look at it this evening.

@ashkulz

This comment has been minimized.

Member

ashkulz commented Jun 22, 2015

Ok, bisecting it identifies e02ff7e as the culprit. I suspect that the default --javascript-delay of 200ms allowed the rendering to happen but with this change the delay was reduced to zero. Not sure why it is happening only to the footer, though.

DanielCeregatti added a commit to DanielCeregatti/wkhtmltopdf that referenced this issue Jul 8, 2015

apply --javascript-delay settings for non-main resource loaders
In e02ff7e, the --javascript-delay
setting was ignored for all non-main resource loaders e.g. headers,
footers and TOC pages. This caused assets (CSS, JS) requested in
these loaders to sometimes fail to complete loading before the
loadFinished() signal was emitted, which was earlier masked by the
default 200ms delay.

The earlier behavior is now restored and longer --javascript-delay
can be used in case resources take longer to load.

fixes wkhtmltopdf#2183 and a number of related issues
@ashkulz

This comment has been minimized.

Member

ashkulz commented Jul 14, 2015

A preview for the next release 0.12.3-dev-79ff51e is available, which should contain the fix for this issue. Please report back if it is not solved with the above version.

Please note that the above downloads will be removed after the 0.12.3 release.

@Jovve

This comment has been minimized.

Jovve commented Aug 7, 2015

So if there is a fix to the vanishing footer, what version of the executable should I be pointing to regarding 64-bit Linux (CentOS 6) - built on CentOS 6.6?

I randomly have a vanishing footing on the CentOS version with the latest stable build (12.2.1), but have no problems with the Windows 7 version (64 bit 12.2.3). It would be nice to have the CentOS version of the stable build match the one for Windows 7.

Thanks.

@ashkulz

This comment has been minimized.

Member

ashkulz commented Aug 7, 2015

@Jovve: use the testing release, it has a generic linux binary which should work on all distros.

@ashkulz

This comment has been minimized.

Member

ashkulz commented Jan 21, 2016

0.12.3 has been released, which should contain the fix for this issue. Please report back if it is not solved with the above version.

Note that the preview downloads mentioned above have been removed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment