-
Notifications
You must be signed in to change notification settings - Fork 40
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
Headless printing #36
Comments
Out of the blue, I have no idea. Have you tried waiting some more after the page loaded for the polyfill to do its work? |
OK, thanks for the reply. I did some tracking down here and found what seems to be the problem. Around line 2380 there's a call that is repeated to match the selector "" or ", ". These are casing a massive slowdown in a headless browser. (Taking 10 mins to print a 20 page PDF.) Changing this block caused me no negative effects and the following worked well for me:
I don't know whether this might be useful to merge upstream? If so, I can put in a PR... Best wishes, Martin |
Strange. I bet the slowness comes from an invalid selector, which forces the browser to enter the catch section, and might be the root cause of the problem. Can you please print a callstack and the value of "rule", "rule.selector" and "selector" of cases where the selector "" and "," is being looked for? It seems likely it is due to some (set of) css rules in particular, and it would be interesting to understand which. |
Thanks for this. Can I just check: did your post (in the selectors) get messed up by formatting? (Your "" and "," appears in italics and I want to check markdown hasn't killed it before I investigate). As above, this happens when selector is "*". Happy to investigate further, though, if you can clarify exactly what selectors I should be looking for. |
Ahaha, yes, I meant |
OK, so this happens hundreds of times per run, but I get the following for a print of rule, rule.selector, and then a console.trace done in Firefox rather than a command-line tool (this is just one example. The stacktrace is different in different cases. Also, the line numbers are slightly out in some cases because I've modified the script to debug it):
|
Oh, I see, that happens during copyStyle which manually computes the cascaded style of elements. This is not the polyfill framework trying to see which elements match the polyfilled css region properties. The funny part about it is that technically this callstack lies within an optimization. When cloning a fragment, I try to see which pseudo-elements exist and what their style might be, to preserve them in the cloned segments. For some reason this is very slow in your case, probably because you have some Your fix ignores those misleading selectors which likely improves the performance very visibly. The right fix would be to change the "mayExist" condition not to be the existence of a rule matching the pseudo, but the existence of such are rule that contains a |
Ah ha. Very interesting. Thanks so much for explaining. I have this at the top of my stylesheet:
and can now confirm that this is causing a major slowdown. Removing this doesn't affect my layout, in fact, so I can safely get rid of them! Thanks for investigating. |
Hi,
First off, thanks so much for all the work on this implementation. It's really great.
I've been trying, though, to print the output of a page created with this JS using various headless browsers (phantomjs, wkhtml2pdf etc.) and am having no luck. Where, in Chrome within X on Linux (for example), everything looks good (and I can print to PDF), running from the console yields the regions, but with no content. Any ideas?
(I haven't yet tried this with the latest fixes if this was addressed in the last 6 months or so, so please do let me know...)
Best wishes,
Martin
The text was updated successfully, but these errors were encountered: