Steps to reproduce
This bug is highlighting some issues with our sourceURL implementation.
Repo page: http://andster-server/bugs/sourceURL.html
sourceURL mapped files should be promotoed to top level items and not mapped to their parent document. This was a regression when we added the mapping to parent for eval. So that eval documents can be shown as children on the files that created them which is awesome except for sourceURL docs which should be top and parented to the document for the window/frame (e.g. the root page or iframe). In the folder view the path should be soley based on the path specific in the sourceURL as with any other URL.
The sourceURL comment needs to be more tolrent to spaces before and after the = etc.
- Load dojo based application
- Open Dev Tools
- Open open documents panel
There are several issues here that make finding source code difficult if not impossible…
- Even though the modules have a sourceURL appended, this seems to be ignored. For example a module ending with //# sourceURL=app/ajax loaded by the dojo loader is found in:-
-------> Dynamic Scripts
----------> Function code (1)
rather than simply
To compound the problem of hiding these modules away deep under levels of namespaces, the filter function does not work properly. Type ajax into the filter and it does not find it (see screen shots). I was forced to break point in code I could find, and single step my way into the code I wanted to find.
Comments and activity
- Microsoft Edge Team
Changed Assigned To to “Leo L.”
Changed Steps to Reproduce
Changed Title from “difficulties finding source code in open document panel” to “#sourceURL is not promoting documents and is keeping them buried”
Changed Assigned To from “Leo L.” to “Rob L.”
Is it also affecting console log messages source code reporting? I am seeing links such as:
eval code (359) (24,13)
In the console log, rather than the module as named by sourceURL
- Microsoft Edge Team
Changed Status to “Fixed”
Changed Status from “Fixed” to “Fixed, not yet flighted”
Thank you for providing this information about the issue. We are pleased to report this feature is fixed in Edge 14393 and is available in our latest public stable build.
The MS Edge Team