Document valid actions for nsITreeView.performAction*




10 years ago
a year ago


(Reporter: WeirdAl, Unassigned)



Firefox Tracking Flags

(Not tracked)




10 years ago
From a thread I started on m.d.t.xul:

> I have finally been convinced - after seeing nsTreeContentView.cpp -
> that I should at least try to build a tree view component instead of
> blindly adding <xul:treeitem/> elements everywhere.  Yet I am confused
> by the existence of three methods on the nsITreeView interface:
> performAction, performActionOnRow, performActionOnCell.  In particular,
> these methods seem unused in the code base - I see no one calling it,
> and most implementations are null ops.

Either we need to document what the valid actions are, or these methods need to die.


10 years ago
Version: unspecified → Trunk

Comment 1

10 years ago
<Enn> there is a place where those functions are used I think
<Enn> I wouldn't worry about it until bug 350264 is worked on
<Enn> i think its was intended to be like commands but for specific items, cells, etc
<WeirdAl>I have no problem leaving the methods there, if we document what the valid actions are, or what the intent is.
<Enn> weirdal: you make them up
<WeirdAl> Enn: it'd be really, really, really nice if the IDL would have just said that...
<WeirdAl> "Implementers of this interface define the set of valid actions for consumers."
Summary: Document valid actions for nsITreeView.performAction*, or remove the methods → Document valid actions for nsITreeView.performAction*


10 years ago
Component: XP Toolkit/Widgets: Trees → XUL
QA Contact: xptoolkit.trees → xptoolkit.widgets
I am trying to resurrect some code that adds search / filtering in the message filters list on SeaMonkey through my (XUL based) addon quickFilters. I suspect the "delete" action has never been properly tested, I am going through a loop removing non-matching filters, like this:

for (let i = rows - 1; i>=0; i--){
	// SeaMonkey
	item = getFilter(i); // SM / Postbox: defined in FilterListDialog.js 
	title = item.filterName;
	if (title.toLocaleLowerCase().indexOf(keyWord) === -1){
		filterList.view.performActionOnRow("delete", i); // the view is same as gFilterTreeView
		filterList.boxObject.rowCountChanged(i+1, -1); // was i + 1  -- same as gFilterTreeView.tree
		// problem: gFilterTreeView.filterList is not updated; see setServer(uri) in FilterListDialog.js
		// maybe we can replace set filterList(val) { ... }
		//   this.mFilterList = val  => replace with the "filtered" values

The problem is the rowCountChanged seems to only always remove the _last_ item in the list - (ignored the efirst parameter?) after calling invalidateRow(i). I made sure to iterate the array backwards from the end. I don't want to remove anything from the underlying data structure (the editable filter list) just hide from the view what doesn't fit with the filter criteria (in above example the name but in Thunderbird I have more powerful filter methods)

Any ideas on how to fix it? Can I somehow access the XUL contents and make them invisbile or does the CPP implementation make this impossible for any script.
You need to log in before you can comment on or make changes to this bug.