638
edits
Script Origin Tracking: Difference between revisions
Jump to navigation
Jump to search
→Open items
(Simplify browserContext markup origins: just refer to the window.) |
|||
| Line 123: | Line 123: | ||
<li>It's possible to provide more details about javascript: URLs: where does the URL appear? Who put it there. But it doesn't seem like it should be a high priority. | <li>It's possible to provide more details about javascript: URLs: where does the URL appear? Who put it there. But it doesn't seem like it should be a high priority. | ||
</ul> | </ul> | ||
jorendorff says: | |||
* This means every JSScript keeps the DOM elements relevant to its origin gc-alive, right? It seems like the kind of awful web site where everything is on a single page no matter what the user does, and all content is dynamically loaded, might produce really long origin chains basically documenting the user's path through the site and perhaps preventing GC from collecting anything. But maybe not. We can just try it and see how it goes. | |||
* It looks like anyone using this information would be getting important details from the DOM. Are we sure that navigation or DOM mutation won't cause the resulting information to be wrong or horribly misleading? Are the <code>browsingContext</code> examples immune to this? What about script elements being <code>adoptNode</code>d into other documents? | |||
* If it's no pain for a javascript: URL origin to say how we got there (for example, if it's as simple as calling <code>getCurrentLocation()</code> at the point where we compile that little script), we should do it. | |||
* It seems like the sensible way to hook this up to the Debug object is via something like Debug.Frame.prototype.location, but then we would want to provide Debug.Objects (or at least x-ray wrappers), not actual DOM nodes. | |||
* Also w.r.t. debuggers, is it possible for a debugger to what to know where something happened, and for the answer to contain non-debuggee information, such as chrome: URLs and line numbers? | |||