This was spawned from https://bugzilla.mozilla.org/show_bug.cgi?id=1538056 but I'm going to file it separately since there is at least some work that can be done there on its own without this.
In 67, the JS debugger will begin treating breakpoints as line/column positions, where traditionally they have been treated as line-based. One of the outstanding issues is that while that is fine for
where a breakpoint might be specifically at column 2 (the
we run into issues with
because the position of
c, as far as the engine knows is
0, even though visually it is column
8, which causes our breakpoint markers to render in the wrong place.
While hand-written markup usually has that newline and doesn't tend to encounter this, we see it pop up in contexts where the inline code has been minified, which can be quite frustrating for users since debugging minified code is already tough and this will make it even tougher. Things can be especially frustrating if there are multiple <script> elements on the same line, because then it isn't just that the breakpoints are rendered off by 8 characters, but also that there could in fact be multiple sets of breakpoints overlapping.
nsIScriptElement type already has a
SetScriptColumnNumber, which is set by the XML parser, but not the HTML parser, so that would be the objective of this bug.
The XML case also doesn't work, so I'm going to co-opt https://bugzilla.mozilla.org/show_bug.cgi?id=1538056 to address that (we just never used the column from
nsIScriptElement at all right now). Then once this lands we should be all set.