Closed Bug 691011 Opened 12 years ago Closed 9 years ago

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

Categories

(DevTools :: General, defect, P3)

defect

Tracking

(Not tracked)

RESOLVED FIXED
Firefox 30

People

(Reporter: jwalker, Assigned: jwalker)

References

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
Closed: 9 years ago
Resolution: --- → FIXED
Assignee: nobody → jwalker
Target Milestone: --- → Firefox 30
QA Whiteboard: [qa-]
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.