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

When debugging a webdev app from VS Code, hitting a breakpoint opens copy of actual file #2383

Open
elliette opened this issue Mar 7, 2024 · 4 comments
Labels
P2 A bug or feature request we're likely to work on package:webdev triaged

Comments

@elliette
Copy link
Contributor

elliette commented Mar 7, 2024

It seems like when we hit a breakpoint, we are downloading a copy of the source instead of mapping it to a local source on disk. See for more details and repro steps: Dart-Code/Dart-Code#5024

@DanTup
Copy link
Contributor

DanTup commented Mar 7, 2024

To be clear, what's happening here is that the source has an org-dartlang-app: URI and we don't know how to map that back to the users local file system so we (the legacy debug adapter in Dart-Code) chooses to download the source from the VM.

It's possible that lookupResolvedUris fixes this, but we only implemented that in the new DAPs (and so far have not migrated webdev to new DAPs...). I can do some testing of this and if lookupResolvedUris fixes it, we can either implement that in the legacy DAP or (ideally) make a webdev DAP in the SDK.

@DanTup
Copy link
Contributor

DanTup commented Mar 14, 2024

I did some testing today and confirmed that lookupResolvedPackageUris is mapping org-dartlang-app to file: URIs, so I may be able to fix this in the legacy DAPs (and if we migrate to hew SDK DAPs, that would already be implemented).

I don't know why this only occurs here - maybe the Dart VM is probably not using org-dartlang-app URIs for things outside the lib folder? If so, making webdev match that might also be a fix - but I don't know a) if that's correct or b) if there are other implications of that (I presume there's a reason it's working like this).

@bkonyi bkonyi added P2 A bug or feature request we're likely to work on triaged labels Aug 7, 2024
@bkonyi
Copy link
Collaborator

bkonyi commented Aug 7, 2024

How much work would this be to look into @DanTup?

@DanTup
Copy link
Contributor

DanTup commented Aug 7, 2024

Do you mean how much work to support look lookupResolvedPackageUris in the legacy DAP for webdev?

We previously discussed EOLing that debug adapter because it's wildly out of date and there are almost no users of it. If we think we need to continue supporting it, I think a better route would be to create a new Dart-based DAP for it (possibly in pkg:webdev?). That would be a little more effort in the short-term, but less over a longer period because we wouldn't be developing things twice (or having inconsistent experience between Dart web and debugging other platforms).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
P2 A bug or feature request we're likely to work on package:webdev triaged
Projects
None yet
Development

No branches or pull requests

3 participants