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

Consider opening source files in debugger as well #5114

Open
canova opened this issue Sep 4, 2024 · 2 comments
Open

Consider opening source files in debugger as well #5114

canova opened this issue Sep 4, 2024 · 2 comments
Labels
discussion Idea / Issue that needs to be discussed, typically not directly actionable through the issue feature Work that is user facing, and typically should be planned through https://airtable.com/shrRydo6UXheb JS Execution Tracing Related to the new JS tracer implementation

Comments

@canova
Copy link
Member

canova commented Sep 4, 2024

Currently we have our own source view but DevTools team suggested that we can also add an option open the devtools panel with the WebChannel. This option could possible be a context menu item. This way they can have more options and features.

There are some open questions though:

  • Where do we open the debugger?
    • new window? in a new tab? In an existing tab?
  • How to attach to the right tab?
  • Firefox-internal JS: Works only for live files, not files in another version of Firefox
  • User files: How do we know if the website JS file is not changed?

┆Issue is synchronized with this Jira Task

@canova canova added feature Work that is user facing, and typically should be planned through https://airtable.com/shrRydo6UXheb discussion Idea / Issue that needs to be discussed, typically not directly actionable through the issue JS Execution Tracing Related to the new JS tracer implementation labels Sep 4, 2024
@ochameau
Copy link

ochameau commented Sep 5, 2024

It would be nice to start with a simple usecase.

You use devtools to generate a (tracer) profile, that profile is opened in a new tab, you navigate through frames, you want to open that frame in the devtools still opened. This would mean going back and forth between the website tab with devtools and the distinct profiler tab. We could followup to make the DevTools magically move to the profiler tab.
There is no particular challenge in term of implementation or UX. I'm only wondering if the existing codebase knows from which tab the profiler was recorded ? I'm not seeing many references to browserId in devtools/client/performance-new/, so that sounds unlikely.
I imagine we would have to do something where we open the profiler from devtools:
https://searchfox.org/mozilla-central/rev/cc01f11adfacca9cd44a75fd140d2fdd8f9a48d4/devtools/client/framework/toolbox.js#737-747
in order to store the browser element/ID of the profiled tab. We aren't passing any such information to the profiler codebase.

@canova
Copy link
Member Author

canova commented Oct 17, 2024

We actually record the innerWindowIds of frames and also we keep the record of seen innerWindows with their browserIds in the pages array. , but we weren't doing that for the JS tracer. I'm changing the backend of JS tracer to include this information as well. Will share the patches soon after polishing them a bit more.

I filed the Bug 1925391 for the backend changes that are required for this task.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion Idea / Issue that needs to be discussed, typically not directly actionable through the issue feature Work that is user facing, and typically should be planned through https://airtable.com/shrRydo6UXheb JS Execution Tracing Related to the new JS tracer implementation
Projects
None yet
Development

No branches or pull requests

2 participants