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

Define which methods should provide a stacktrace #203

Open
whimboo opened this issue Dec 7, 2021 · 8 comments
Open

Define which methods should provide a stacktrace #203

whimboo opened this issue Dec 7, 2021 · 8 comments

Comments

@whimboo
Copy link

whimboo commented Dec 7, 2021

While implementing stacktrace support for console API calls for the WebDriver BiDi support in Firefox I noticed differences between browsers. Per the specification we should include the stacktrace for the following methods:

If method is "assert", "error", "trace", or "warn", let stack be the current stack trace. Otherwise let stack be null.

Hereby Firefox does not add a stacktrace for calls to warn(), whereby Chrome does it.

It would be easy to add, but in general it would be great to have the availability of the stacktrace for methods defined in the console specification.

@terinjokes
Copy link
Collaborator

We do define at least one place where when a stack is expected: trace. In this instance, it's clear the behavior the developer wants.

Is the ask here to require agents to include the stack in their side effect actions? Or is the ask to make it clearer that agents may include a stack?

@whimboo
Copy link
Author

whimboo commented Dec 8, 2021

I see. So the requirement for console commands to have a stacktrace included only exists for trace and for other commands it's up to the user agent to optionally provide that object? So yes, it might be good to have some paragraph that clarifies that in the console specification.

@domfarolino
Copy link
Member

@whimboo Would you be willing to submit a spec PR for this? I'm happy to review it

@whimboo
Copy link
Author

whimboo commented May 24, 2022

@domfarolino I think it depends on the outcome of the above discussion. Can I assume that you all are fine with only trace requiring a stacktrace and for all others it's optional? If that is clarified I may be able to create a PR. Thanks.

@domfarolino
Copy link
Member

Sure, thanks for clarifying. Yes I think that sounds good to me, and would match implementations (i.e., Chrome adding stack trace information for console.warn()).

@terinjokes does this sound good?

@terinjokes
Copy link
Collaborator

That clarification, that it's optional for other logging methods, sounds fine by me.

OrKoN added a commit to w3c/webdriver-bidi that referenced this issue Nov 6, 2024
This would align behavior in Chrome and the spec.

Related discussions:

- puppeteer/puppeteer#13264
- whatwg/console#203
OrKoN added a commit to w3c/webdriver-bidi that referenced this issue Nov 14, 2024
This would align behavior in Chrome and the spec.

Related discussions:

- puppeteer/puppeteer#13264
- whatwg/console#203
@whimboo
Copy link
Author

whimboo commented Nov 14, 2024

Sure, thanks for clarifying. Yes I think that sounds good to me, and would match implementations (i.e., Chrome adding stack trace information for console.warn()).

In Chrome also the log() message contains a stack trace and there is now an ongoing effort to enable stack traces in WebDriver BiDi for both warn and log messages.

@domfarolino and @terinjokes does that still sound ok to you?

@domfarolino
Copy link
Member

Does log() contain stack trace information at all? I'm not seeing that.

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

No branches or pull requests

3 participants