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

RESOLVED FIXED in Firefox 30

Status

P3
normal
RESOLVED FIXED
7 years ago
4 months ago

People

(Reporter: jwalker, Assigned: jwalker)

Tracking

Trunk
Firefox 30
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

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.
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 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!
Priority: -- → P3
While we're at it, __element should be treated the same way.
Depends on: 933727
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Assignee: nobody → jwalker
Target Milestone: --- → Firefox 30

Updated

5 years ago
QA Whiteboard: [qa-]

Updated

4 months ago
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.