Skip to content
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

Fail upon JS console errors #263

Open
leoc opened this issue Oct 9, 2024 · 3 comments
Open

Fail upon JS console errors #263

leoc opened this issue Oct 9, 2024 · 3 comments

Comments

@leoc
Copy link

leoc commented Oct 9, 2024

Ok, hope this does not come over as too negative. I love this gem and all it provides. Thanks a lot!

Just want to share my situation of today:

  • my rails app is running inside docker (in dev, test and production), the whole project is set up that way
  • I render a PDF from a page that is loading a view from a React SPA
  • the React SPA failed to render, leaving the page blank, only printing some errors via console.error

How can I grab this console output and maybe let me know in test, or when debugging in dev?

My ideal situation would be to assert in test, that the rendering of the PDF did not cause any JS errors. And if there are errors, I would like to see them in the test failure output.

Browserless did not connect correctly. I only found out about the JS errors, because I tediously extracted the Rails app from Docker and run it locally. This should not have been necessary.

Did I miss something?

Anyway, heres a dog with pizza.

image

@abrom
Copy link
Contributor

abrom commented Oct 10, 2024

no worries @leoc. There are a few options:

If the error is a request failure, you can enable the raise_on_request_failure option (see the README for details).

If it is an unhandled JS error, puppeteer does support capturing those with an event handler: https://pptr.dev/api/puppeteer.pageevent Although it isn't currently supported, it seems like it would be pretty straight forward to add something to puppeteer to raise an error (with the list of JS errors attached) if any have occurred whilst trying to render the page.

Alternatively, you could have your application "flag" a successful render somewhere in the global scope, then have Grover wait until that holds true. It wouldn't tell you what the error was, but it would timeout the render request thus at least tell you that something went wrong. eg:

... render your page ...
window.renderSuccessful = true;
....

then in grover options add something like:

wait_for_function: 'window.renderSuccessful === true'

Alternatively #2, you could add a window.onerror event handler to capture the errors, where you could assign them to a global object then use the execute_script Grover option to extract them out:

window.pageErrors = [];
window.onerror = (message) => window.pageErrors.push(message);
...

then in grover:

execute_script: "if (window.pageErrors.length > 0) throw `Errors occurred! ${JSON.stringify(window.pageErrors)}`"

or similar.

Note, I haven't tested these, but they should work 😄

Although, if your issue is that your instance wasn't able to connect to Browserless, then that should have raised errors when trying to launch the browser?!

Anyway, hopefully the above will give you something to go on

@leoc
Copy link
Author

leoc commented Oct 10, 2024

Wow, thanks for the thorough feedback!

Yeah, I fixed my issue by ejecting the rails app onto my docker host and running it with the debug flags.
But until then I spent a good day on trying to get info without doing so, because I had to tackle a lot of environment specifics by pulling it out of the docker setup. And I thought I must have missed something by then. 😄

Browserless behaved in a weird way and I did not want to spent too much time debugging network issues, so I stopped after a quick try. :)

I will give hooking into onerror a try. I definitely want to be informed about missed renders in production.
Currently any error on the rendering page is lost and not logged anywhere.

It cloud be a good addition to the project to have a raise_on_js_error: true. What do you think?

@abrom
Copy link
Contributor

abrom commented Oct 11, 2024

FYI raise_on_js_error feature has been added in v1.1.11 😄

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants