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

Simple stack trace in comments in the head #113

Closed
mattstauffer opened this issue Nov 29, 2013 · 6 comments
Closed

Simple stack trace in comments in the head #113

mattstauffer opened this issue Nov 29, 2013 · 6 comments

Comments

@mattstauffer
Copy link

I often get Whoops HTML output in a place that doesn't render HTML--the dev tools inspector, iOS inspectors, etc. (usually API-related.)

Is it possible or would it be easy to add a very simple stack track in an HTML comment at the top of the file? Just so anyone who's seeing the HTML non-rendered could still understand the error.

@Anahkiasen
Copy link
Contributor

+1

@denis-sokolov
Copy link
Collaborator

There are a few ways to improve the situation already.

  1. Add JsonResponseHandler. It only handles AJAX requests, so it's safe to just add it on top of PrettyPageHandler.
  2. On the client, on any Ajax error in development simply popup the HTML contents in a popup/new window.
    Works great for me.
  3. In Chrome developer tools, Network tab, use a "Preview" subtab on a request. Allows to interpret HTML.

But regardless of all these solutions, your idea is a good one and I've put it on the list. Thanks!

@staabm
Copy link
Contributor

staabm commented Nov 29, 2013

@denis-sokolov i think you made a typo with the issue number on the list?

Regarding this topic: couldn't we just check the http accepts header send in the repsonse to send pretty page html markup only on request which accept html?

@mattstauffer
Copy link
Author

Thanks so much for the tips, @denis-sokolov! I can't remember what the contexts were in which the Preview tab didn't render HTML correctly--I'll note it if I can find it. But the JsonResponseHandler looks perfect.

@mattstauffer
Copy link
Author

@denis-sokolov, FYI:

You're right--the JsonResponseHandler was great for in-browser, AJAX, API consumption (just had to set $jsonhandler->onlyForAjaxRequests(true) ), but since it doesn't care about the headers other than HTTP_X_REQUESTED_WITH, my iOS developers are still stuck. So I would definitely put a vote behind something like @staabm 's suggestion RE: Accept Headers.

But, seriously, thanks for adding it to the list, and for your tip on the Json handler.

@denis-sokolov
Copy link
Collaborator

@staabm, indeed a typo, thanks!

@staabm, using Accept html in PrettyPageHandler is an improvement, thanks. But it won't be too effective, as plenty of clients send that they accept html in situations that the original debugging scenario would deem ineffective, such as Ajax requests.

@mattstauffer, consider that you can add and remove handler dynamically yourself:

if (myClientDetectionLogic()) {
    $run->pushHandler(new JsonResponseHandler());
} else {
    $run->pushHandler(new PrettyPageHandler());
}

I've added the Accept idea to the list!

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

4 participants