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: 0.9.91.1 (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
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Chatzilla does not populate channels → Chatzilla does not populate channels in join dialog
Duplicate of this bug: 1123540
Assignee: rginda → gijskruitbosch+bugs
Status: NEW → ASSIGNED
Pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=62f0b771583c&tochange=a280a03c9f3c Ohi, bug 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?
That's ... odd. Does chatzilla have some sort of custom nsITreeView implementation?
Flags: needinfo?(khuey) → needinfo?(gijskruitbosch+bugs)
Yes, implementation is here: http://hg.mozilla.org/chatzilla/file/2f6817b26141/xul/lib/tree-utils.js#l1198 and called from here: http://hg.mozilla.org/chatzilla/file/2f6817b26141/xul/content/channels.js#l107 (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)
That is similar to mine where it also doesn't populate channels, but the Join button doesn't even show at all, too.
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 18.104.22.168 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...)
Peter suggested a fix, which seems to work. Patch momentarily.
Component: ChatZilla → DOM
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+
(In reply to :Gijs Kruitbosch from comment #14) > remote: https://hg.mozilla.org/integration/mozilla-inbound/rev/b3040e65bab9 N8ce. :)
(In reply to :Gijs Kruitbosch from comment #14) > remote: https://hg.mozilla.org/integration/mozilla-inbound/rev/b3040e65bab9 I meant that previous comment to say, "Nice."
Status: ASSIGNED → RESOLVED
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
status-firefox36: affected → fixed
status-firefox37: affected → fixed
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
Status: RESOLVED → VERIFIED
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.