1532839 - Consider dropping sourceIDs as a concept, or more strictly validating

Status: RESOLVED WONTFIX

(DevTools :: Debugger, enhancement, P3)

Description

[Logan Smyth [:loganfsmyth]]

Having the sourceId as an extra degree of freedom in the APIs around sources & breakpoints seems like a recipe for confusion, specially if we allow both in parallel. I ended up spending quite a while yesterday tracking down a bug due to an accidental change that caused us to send the server both a URL and a source ID, causing duplicate breakpoints because one had a source ID and one didn't.

It seems like at a minimum, the API should throw an error if given both a URL and an ID.

I think the big question in my mind is, what is the actual goal of exposing source IDs at this point? As far as I'm aware, this breaks down into 2 primary things:

1. Identifying a specific source when multiple share the same URL.
2. Identifying sources that legitimately have no URL, like evaled code.

For the first case, my big question is essentially if it is something we actually want to expose. While kind of nice, I struggle to think of a time when we'd actually use it, or how we'd expose it in the UI. This point is also exacerbated by the fact that one Debugger.Source object can actually represent multiple instances of a file, because SpiderMonkey may choose to reuse a source object when cloning and re-evaluating a JSScript object, so even a source ID doesn't uniquely map to one logical evaulation of a script file.

For the second case, we could address it by returning a custom URL like dbg-internal:///12334523465546433456 as the URL and ditch the need for the source ID. The only addition we'd potentially need is to give sources the concept of a base URL so that relative paths could be computed relative to that.

What we end up with if we do this is essentially a concept of a "source file group" where each group has a URL as a unique identifier. If we were to do all of this, it also raises the question of whether url should be the primary key at all, in favor of a more general "source group name" or something similar. I bring this up because it would potentially allow us to distinguish two sources that have the same URL but different content. Two source groups with different names and content, but the same base URL is really all we would need.

Happy to continue this discussion, I just wanted to file it before I go off to do other stuff.

Comment 1

[Brian Hackett [Laid off!]]

Source actor IDs are used when setting breakpoints to support point 2 above; I don't think there is a need for point 1. I thought about faking up URLs for eval'ed sources, but didn't because it seemed nicer to be explicit about things. That may have been the wrong call, though.

Comment 2

[Logan Smyth [:loganfsmyth]]

I don't think this is tracking anything useful right now.