Chatzilla does not populate channels in join dialog (MozTreeView as returned from TreeBoxObject is no longer QId to nsITreeView)

VERIFIED FIXED in Firefox 36



3 years ago
3 years ago


(Reporter: ste, Assigned: Gijs)




Firefox Tracking Flags

(firefox36 verified, firefox37 verified, firefox38 verified)


(Whiteboard: [bugday-20150204])


(1 attachment)



3 years ago
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:36.0) Gecko/20100101 Firefox/36.0
Build ID: 20141228004007

Steps to reproduce:

I have been using chatzilla for awhile now and had no issues populating channels until now.

Running Firefox Dev (Aurora 36.a02) on OS X 10.10.1
Chatzilla version: (Released 19/12/14)

1. Run chatzilla, open IRC > Join Channels
2. Start searching for channels I.E introduction / firefox / remo
3. select refresh now if no results are shown
4. try step 2 again. no channels populated.

Actual results:

Unable to find/join channels via the Chatzilla GUI as normal

Expected results:

Chatzilla should populate a list of channels for users instead of using /list or /rlist
I can reproduce this; the channel dialog spews:

TypeError: this.tree.view.selection is undefined

pointing to:

    if (!this.tree || this.tree.view.selection.getRangeCount() < 1)

in tree-utils.js
Ever confirmed: true
Flags: needinfo?(gijskruitbosch+bugs)


3 years ago
Duplicate of this bug: 1122883


3 years ago
Summary: Chatzilla does not populate channels → Chatzilla does not populate channels in join dialog
Duplicate of this bug: 1123540
Assignee: rginda → gijskruitbosch+bugs
Flags: needinfo?(gijskruitbosch+bugs)
Egh, copy paste is hard.
Blocks: 979835
No longer blocks: 1083810
We're getting a treeview object here that is no longer automatically QI'd to nsITreeView, which is breaking all the things. Manually QI'ing fixes the issue. Kyle, that seems to me like something we should fix in core code, is that right?
Flags: needinfo?(khuey)
That's ... odd.  Does chatzilla have some sort of custom nsITreeView implementation?
Flags: needinfo?(khuey) → needinfo?(gijskruitbosch+bugs)
Yes, implementation is here:

and called from here:

(nb: tree is just a JS object there; the treeBoxObject is the interesting assignment)

. I noticed we don't seem to implement QI ourselves on that object - but since Mozilla 1.0, we never needed to. Maybe that is a problem now that this has been shifted to webidl? Even so, it's kind of odd that (a) the assignment works, and then (b) all the properties are suddenly gone when you request the same object back and it's grown wings, err, an XPCOM "wrapper" that has a QI and nothing else :-)
Flags: needinfo?(gijskruitbosch+bugs) → needinfo?(khuey)

Comment 9

3 years ago
That is similar to mine where it also doesn't populate channels, but the Join button doesn't even show at all, too.

Comment 10

3 years ago
But, interestingly, I noticed that when I changed NOT the FF browser type back down to FF 34 or 34.0.5, but kept it at FF dev edition, but change, instead, my OS type, that it seemed to help.  I upgraded my OS from Ubuntu LTS (Lubuntu) to (lubuntu) 14.01.1 LTS (lubuntu) for my old computer.  And then the Chatzilla FF extension worked, perfectly.
Bobby/Ms2ger, can either of you have a look as Kyle is on PTO? If necessary, I can help with the actual debugging / getting info - but right now I don't know what to look for, particularly. :-)

(Bobby, I know that it says you're busy, and I'm sorry - but the choice is between you and bz, who also tells me he's busy...)
Flags: needinfo?(khuey)
Flags: needinfo?(bobbyholley)
Flags: needinfo?(Ms2ger)
Keywords: regression
Peter suggested a fix, which seems to work. Patch momentarily.
Component: ChatZilla → DOM
Flags: needinfo?(bobbyholley)
Flags: needinfo?(Ms2ger)
Product: Other Applications → Core
Version: unspecified → Trunk
Created attachment 8554497 [details] [diff] [review]
ensure nsITreeView is already QId when returned,
Attachment #8554497 - Flags: review?(peterv)
status-firefox36: --- → affected
status-firefox37: --- → affected
status-firefox38: --- → affected
Summary: Chatzilla does not populate channels in join dialog → Chatzilla does not populate channels in join dialog (MozTreeView as returned from TreeBoxObject is no longer QId to nsITreeView)
Attachment #8554497 - Flags: review?(peterv) → review+

Comment 15

3 years ago
(In reply to :Gijs Kruitbosch from comment #14)
> remote:

N8ce.  :)

Comment 16

3 years ago
(In reply to :Gijs Kruitbosch from comment #14)
> remote:

I meant that previous comment to say, "Nice."
Last Resolved: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla38
Comment on attachment 8554497 [details] [diff] [review]
ensure nsITreeView is already QId when returned,

Approval Request Comment
[Feature/regressing bug #]: bug 979835
[User impact if declined]: add-on treeviews get broken because core code no longer returns them QueryInterface'd to nsITreeView
[Describe test coverage new/current, TreeHerder]: nope :-(
[Risks and why]: very very very very small, considering it's only this bindings.conf change on an API that is not web-exposed
[String/UUID change made/needed]: no
Attachment #8554497 - Flags: approval-mozilla-beta?
Attachment #8554497 - Flags: approval-mozilla-aurora?
status-firefox38: affected → fixed
Attachment #8554497 - Flags: approval-mozilla-beta?
Attachment #8554497 - Flags: approval-mozilla-beta+
Attachment #8554497 - Flags: approval-mozilla-aurora?
Attachment #8554497 - Flags: approval-mozilla-aurora+
QA Whiteboard: [good first verify]
Reproduced with Firefox Dev (Aurora 36.a02) with the instruction from comment 0 and on Windows 7 x64.

Verified as fixed with Firefox Beta 36.0b6  (Build ID: 20150202183609) , Firefox Nightly 38.0a1 (Build ID: 20150203062848) and latest Aurora 37.0a2 (Build ID: 20150204004155) 

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:36.0) Gecko/20100101 Firefox/36.0
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:37.0) Gecko/20100101 Firefox/37.0
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Firefox/38.0
Whiteboard: [bugday-20150204]
QA Whiteboard: [good first verify] → [good first verify][bugday-20150204]
status-firefox36: fixed → verified
status-firefox37: fixed → verified
status-firefox38: fixed → verified
You need to log in before you can comment on or make changes to this bug.