691011 - DOMTemplate stack is per 'class' not per 'thread'

Status: RESOLVED FIXED

(DevTools :: General, defect, P3)

Description

[Joe Walker [:jwalker]]

DOM Template stores the debug stack in a member variable (i.e. this.stack) which was fine while we were not doing anything async, however async processing breaks this.

What we need is an extra parameter to all methods which contains the stack.

For an added bonus processNode(), in addition to taking a stack parameter as an array would allow a simple string to be passed in (from which it constructs an array with that string as single entry) This would allow the following pattern from client code:
  templater.processNode(node, this, 'foo.html');

Which would help debug show not just where the problem was in a template, but in which template the problem occured.

Comment 1

[Joe Walker [:jwalker]]

While we're at it:

const Ci = Components.interfaces;
const Cu = Components.utils;
Cu.import("resource://gre/modules/Services.jsm");

Could usefully be:

Components.utils.import("resource://gre/modules/Services.jsm");

Comment 2

[Joe Walker [:jwalker]]

Comment from robcee
> +Templater.prototype._envEval = function(script, data, frame) {
>
> not super-keen on these argument names. "data" doesn't scream "the environment"
> to me. Nor does "frame" equate to a debugging string, though maybe the contents
> of that param are typically information about the originating frame, in which
> case, it's ok!

Comment 3

[Joe Walker [:jwalker]]

While we're at it, __element should be treated the same way.