6

We have an IE extension implemented as a Browser Helper Object (BHO). We have a utility function written in C++ that we add to the window object of the page so that other scripts in the page can use it to load local script files dynamically. In order to resolve relative paths to these local script files, however, we need to determine the path of the JavaScript file that calls our function:

  • myfunc() written in C++ and exposed to the page's JavaScript
  • file:///path/to/some/javascript.js
  • (additional stack frames)

From the top frame I want to get the information that the script calling myfunc() is located in file:///path/to/some/javascript.js.

I first expected that we could simply use the IActiveScriptDebug interface to get a stacktrace from our utility function. However, it appears to be impossible to get the IActiveScript interface from an IWebBrowser2 interface or associated document (see Full callstack for multiple frames JS on IE8).

The only thing I can think of is to register our own script debugger implementation and have myfunc() break into the debugger. However, I'm skeptical that this will work without prompting the user about whether they want to break into the debugger.

Before doing more thorough tests of this approach, I wanted to check whether anyone has definitive information about whether this is likely to work and/or can suggest an alternative approach that will enable a function written in C++ to get a stack trace from the scripting engine that invoked it.

Stevoisiak
  • 23,794
  • 27
  • 122
  • 225
Matthew Gertner
  • 4,487
  • 2
  • 32
  • 54

2 Answers2

1

Each script you load may have an id and each method of the script calling myfunc() may pass this id to myfunc(). This means that first you have to modify myfunct() and finally alter your scripts and calls.

  • I should have been more clear: myfunc() can't get any information from the caller that could be used to determine the path. (If anyone is curious, we are implementing the require() function as per the CommonJS spec, so we have to stick to what the spec says.) – Matthew Gertner Jun 07 '12 at 15:48
  • This is totally different. The best you can do is to have a look at the current implementations and possibly get an idea (if you haven't already). An example would be the "Smart Platform" require implementation on https://github.com/joyent/smart-platform/blob/master/share/internal_js/require.js –  Jun 13 '12 at 06:28
  • How does that help? We already have an implementation of require() for IE (written in C++) but for it to work according to the spec, it needs to know the path to the JS file that invokes it. – Matthew Gertner Jun 13 '12 at 09:39
-1

This answer describes how I solved the actual issue I described in the original question. The question description isn't great since I was making assumptions about how to solve the problem that actually turned out to be unfounded. What I was really trying to do is determine the path of the currently running script. I've changed the title of the question to more accurately reflect this.

This is actually fairly easy to achieve since scripts are executed in an HTML document as they are loaded. So if I am currently executing some JavaScript that is loaded by a script tag, that script tag will always be the last script tag in the document (since the rest of the document hasn't loaded yet). To solve this problem, it is therefore enough just to get the URL of the src attribute of the last script tag and resolve any relative paths based on that.

Of course this doesn't work for script embedded directly in the HTML page, but that is bad practice anyway (IMO) so this doesn't seem like a very important limitation.

Matthew Gertner
  • 4,487
  • 2
  • 32
  • 54
  • This wouldn't work if the script is defered or async, and if some other script inserts another script tag into the dom. See https://stackoverflow.com/questions/14409982/is-it-the-last-script-element-the-currently-running-script I would argue that it is a very important limitation, especially if different teams are working on the same page. Inevitably someone(typically a SEO implementation guy) would do use a hack and break your code. See http://fractallambda.com/2014/11/15/Get-current-script-element-in-javascript.html for comparison of some different approaches. – Xun Yang Feb 19 '20 at 13:54