My web application generates a PDF from an HTML page via Google Chrome 76.0.3809.100 headless on Debian GNU/Linux 9.9 (stretch). My call looks like this:
google-chrome --headless --ignore-certificate-errors --hide-scrollbars --print-to-pdf='mypdf.pdf' --run-all-compositor-stages-before-draw --no-sandbox --virtual-time-budget=60000 https://example.com/mypage.html
Everything works perfectly... about 9 times out of 10. But sometime I got an empty PDF.
I thought it was a bug in my code, so I tried to run the same command from the command line directly. I also added --dump-dom to exclude the PDF generation and display the HTML on the console. Again, about 9 times out of 10 it works, one... it doesn't.
When it doesn't, I get this error:
[0814/090047.461433:ERROR:headless_shell.cc(434)] Failed to serialize document: Uncaught
Well, actually this is my full console output, but all the other messages are there also when it runs OK, so I don't think they matter:
Fontconfig warning: "/etc/fonts/fonts.conf", line 100: unknown element "blank"
Fontconfig warning: ignoring UTF-8: not a valid region tag
[0814/090046.673042:ERROR:command_buffer_proxy_impl.cc(107)] ContextResult::kTransientFailure: Shared memory region is not valid
[0814/090046.674622:WARNING:ipc_message_attachment_set.cc(49)] MessageAttachmentSet destroyed with unconsumed attachments: 0/1
[0814/090046.736342:ERROR:cert_verify_proc_nss.cc(969)] CERT_PKIXVerifyCert for example.com failed err=-8102
[0814/090047.461433:ERROR:headless_shell.cc(434)] Failed to serialize document: Uncaught
[0814/090047.474334:ERROR:browser_process_sub_thread.cc(203)] Waited 3 ms for network service
Ok, so back to "my bad" route. I switched https://example.com/mypage.html to https://google.com and... lo and behold! Same "sometime" error!
I'm fresh out of ideas, even more since I cannot replicate the behaviour in a consistent manner: sometime it works, sometime it doesn't.
Any help is appreciated, thanks!
Ok, I reported this to the Chromium devs as Issue 993686. It was recognized as a bug in Chromium.
As a workaround, I removed som aync-loaded fonts I had in my CSS and now it works 10/10.
Related
I released a Chrome DevTools extension a couple years ago that uses
chrome.devtools.panels.elements.createSidebarPane(title, callback)
to add an ExtensionSidebarPane. This worked fine until Chrome 92. Now the Pane is created with the title, but it is blank.
The calls I am using are still documented: https://developer.chrome.com/docs/extensions/reference/devtools_panels/, but the example code that I used has been moved to into the mv2-archive section of the google-extension-samples repo. And the chrome-query example code no longer works either. So maybe that means it is unsupported now. On the other hand, everything I have found so far seems to say v2 should be supported to the end of 2021. And I haven't found any alternative v3 examples of adding info to the devtools UI.
Obviously createSidebarPane is getting called, because the blank pane is created with the expected title. And intentionally throwing an error in the callback shows that it is getting called with the expected ExtensionSidebarPane object as a parameter, it's just that calling setExpression or setObject on it doesn't do anything. I am not seeing any other errors or warnings.
I would hate to retire my extension, since I know people use it, but I am not sure what else to try.
I'm trying to use Splash via scrapinghub/splash Docker image and have some alerts coming after the first request (which is to /robots.txt endpoint because I'm using scrapy-splash plugin for scrapy library (with Python 3.6).
[-] "172.17.0.1" - - [18/Jan/2018:00:05:12 +0000] "GET /robots.txt HTTP/1.1" 404 153 "-" "Scrapy/1.5.0 (+https://scrapy.org)"
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
process 1: D-Bus library appears to be incorrectly set up; failed to read machine uuid: UUID file '/etc/machine-id' should contain a hex string of length 32, not length 0, with no other text
See the manual page for dbus-uuidgen to correct this issue.
qt.network.ssl: QSslSocket: cannot resolve SSLv2_client_method
qt.network.ssl: QSslSocket: cannot resolve SSLv2_server_method
And the saddest thing is that it doesn't render this page. Also need to mention that sometimes it renders this page, and it contains redirect in case JS is available.
How to make it work?
UPDATE
When using scrapinghub/splash:3.0 these messages still, but render works.
So should I report it as bug in scrapinghub/splash image or these errors can be caused by my environment?
UPDATE
For some reason, even 3.0 doesn't render from now, as well as master (docker image tag). So for every image with latest or master or 3.0 tag, after asking (form on index endpoint) for render http://floodlist.com/news page it only shows a page with You are being redirected... title.
I found this issue so d-bus problem may be harmless.
process 1: D-Bus library appears to be incorrectly set up; failed to read machine uuid: UUID file '/etc/machine-id' should contain a hex string of length 32, not length 0, with no other text
See the manual page for dbus-uuidgen to correct this issue.
These would appear to be fairly concise instructions on how to fix the D-Bus issue.
I don’t know about the other warnings, or whether any of them are relevant.
These warnings/errors seems to be harmless (see #491 on Splash and #122 on scrapy-splash)
And the problem with rendering was solved by increasing wait value up to 1 second. More info about rendering issues here.
I've been trying for hours, but can't build and use Light Table. Every time I try to run deploy/LightTable, it hangs on a screen that simply says "Light Table". I receive this error*:
[14381:0519/204037:INFO:CONSOLE(27860)] "Uncaught TypeError: Cannot read property 'thread_STAR_' of undefined", source: file:///home/zaz/Desktop/LightTable/builds/lighttable-0.8.0-linux/resources/app/core/node_modules/lighttable/bootstrap.js (27860)
Here's what I've tried:
git clone https://github.com/LightTable/LightTable.git
cd LightTable
bash linux_deps.sh
./deploy/LightTable # creates frozen window, throws the error above
cd deploy
./LightTable # creates frozen window, throws the error above
./ltbin # creates frozen window, throws the error above
I also tried similar things after checking out the atom-shell branch and the 0.7.2 tag (and cleaning up all the files from the previous build). Each time, I received the error above.
Does anyone know what's going on here?
Has Light Table been completely abandoned? It seems the last commit was in March.
* Depending on the version I was trying to run, I also received other errors, but I don't think they're relevant (the error above was the only one that appeared for all versions):
[18593:0519/222845:INFO:gpu_info_collector_x11.cc(80)] NVCtrl extension does not exist.
[18593:0519/222845:ERROR:browser_main_loop.cc(226)] Gdk: gdk_window_set_icon_list: icons too large
Fontconfig warning: FcPattern object size does not accept value 11(i)
[14413:0519/204035:INFO:renderer_main.cc(212)] Renderer process started
A year later (question was written in May 2015, now is June 2016), LightTable 0.8.1 is out, and I tried both Linux binary and cloned it from git, and it works fine.
For complete info, I'm using also Atom, and although I had not problems with "Cannot read property 'something' of undefined"" in Atom core, I met such problems in two or three Atom packages.
Both editors are based on same electron platform, LightTable is beautiful eye candy with quite revolutionary REPL integration, but it needs more polish to be usable to same extent as Atom.
For example, LightTable does not have workspace saving by default, that is done via plugin. That's ridiculous.
But although Atom looks so nice and powerful compared to simple editors, with realy huuuge number of available packages/plugins, LightTable is more elegant.
As I don't want to start new semi-religious war Atom vs LightTable resembling vi-vs-emacs, I'll stop here. :)
I can't replicate your problems in LightTable v0.8.1, so I think that answers this question. If not, please add errors you get with v0.8.1.
For info about releases, please check: https://github.com/LightTable/LightTable/releases
I'm new to Pharo ,my problem is when I try to run the BouncingAtomsMorph openInWorld example I keep getting the following error message:
Unknown variable:BouncingAtomsMorph openInWorld please correct or cancel
Please help!
Sadly Bouncing Atoms are no longer included in the standard distribution of newer Pharo versions.
To load it evaluate in a workspace or playground:
Gofer it
url: 'http://smalltalkhub.com/mc/PharoExtras/MorphExamplesAndDemos/main';
package: 'MorphExamplesAndDemos';
load.
Then
BouncingAtomsMorph new openInWorld
will work.
Pharo 5 update:
The MorphExamplesAndDemos package does no longer load correctly starting with Pharo 5. As described here, you can still look at the BouncingAtomsMorph by just clicking on Abandon when a debugger message tells you that this message is no longer understood (It's a problem with another example in the same package):
FileList class>>registerFileReader
I've attempted to make some modifications to a userscript to enable it to work under Chrome, but when I drag it into Chrome's window in order to install it, a dialog pops up and says 'Invalid Script Header'.
I've tried to use the Developer Tools, and built-in Javascript Console, to debug any errors occurring, but nothing appears to list any information.
Console.app does not list anything meaningful, except for the same error message I already know.
[0x0-0x2d02d].com.google.Chrome: [346:1547:16686819618022:ERROR:extension_error_reporter.cc(55)] Extension error: Invalid script header.
How can I reasonably debug this error message and figure out what about the header is incorrect?
I'm using Chrome 15.0.861.0 on the dev channel, under OS 10.7 Lion.
I finally stumbled across the answer to this question, amusingly via a Chromium Bug Report.
As it turns out, the answer to my question was in the (significantly brief) Userscript Documentation for Chrome page.
With Greasemonkey-style #include rules, it is not possible for Chrome to know for certain the domains a script will run on (because google.* can also run on google.evil.com). Because of this, Chrome just tells users that these scripts will run on all domains, which is sometimes scarier than necessary. With #match, Chrome will tell users the correct set of domains a user script will run on.
As it turns out, I had been using #match http://*musicbrainz.org in an attempt to match www.musicbrainz.org as well as musicbrainz.org, but per the quoted text, that doesn't save you from accidentally matching evilmusicbrainz.org. So, my solution was to use two lines:
#match http://*.musicbrainz.org
#match http://musicbrainz.org
Type:
debugger;
Somewhere in the code, and the Web Inspector will pop up in that location. I have answered similar question here Chrome debugger inject javascript
I figured out while I got the same error message ( INVALID SCRIPT HEADER ) that it accoured cause of a typo between the // ==UserScript== Header info.
wronge line
// #run-at document.end
corrected line
// #run-at document-end