371067 - Cannot switch channels on recent trunk builds

Status: RESOLVED FIXED

(Other Applications :: ChatZilla, defect)

Description

[Ian Neal]

Using both SM BuildID 2007021909 and Firefox BuildID 20070220 with chatzilla 0.9.77
Steps to reproduce:
1. Fire up chatzilla
2. Attach to a server
3. Try to join a channel

Expected results:
1. Joins channel and displays conversations happening in there.

Actual results:
1. When attaching get following error in server window:
[ERROR]	Internal error dispatching command “set-current-view”.
[ERROR]	TypeError: setting a property that has only a getter @ <chrome://chatzilla/content/static.js> 2806

2. When trying to join a channel get following error in server window each time:
[ERROR]	Internal error dispatching command “set-current-view”.
[ERROR]	TypeError: setting a property that has only a getter @ <chrome://chatzilla/content/static.js> 2769

Comment 1

[Ian Neal]

Works fine in SM trunk BuildID 2007021808 so regression was in the 24 hour period to the next trunk build.

Comment 2

[:Gavin Sharp [email: [e-mail]]]

Bug 370742 changed a tab's selected property to be read-only. There should be no need to set it directly. See also bug 371055.

Comment 3

[:Gijs (he/him)]

Actually, see also bug 92933, which told us to move from attributes (which, if I read bug 370742 correctly, are now back to being (one of) the "preferred" route(s) to take on this) to properties. What kind of solution do you expect from us? Moving back to attributes will most likely upset some of the old versions we support. Can you please figure out what you want the API to be?
</rant>

Comment 5

[Asaf Romano (gone)]

Why don't you use the selectedTab property?

Comment 6

[James Ross]

Neil told us to set the selected property, back in 2001, that's why. What the best, long-term compatible, solution is is undecided currently. Please don't suggest things unless you can give a full compatibility history of the method from Mozilla 1.0 to today's XPFE and Toolkit. ;)

Comment 7

[Neil Deakin]

Changing the selected property never changed the tab selection before, so I'm unclear what the chatzilla code needs to do. And I'm not sure why you would think that something from long before even mozilla 1.0 would even apply.

The way to change the selected tab is by using selectedIndex/selectedItem on the <tabbox>/<tabs> or by using the selectedTab property.

Comment 8

[James Ross]

I said it's why the code currently uses the selected property, not why it should continue to use it. Your opinion is not useful.

Comment 9

[Neil Deakin]

> Your opinion is not useful.

Oh, I didn't realize that.

Comment 10

[Asaf Romano (gone)]

Neither do I.

Comment 12

[[e-mail]]

(In reply to comment #6)
>Neil told us to set the selected property, back in 2001, that's why.
Sorry about that. At the time I didn't look closely enough into its use.

>Please don't suggest things unless you can give a full compatibility history
>of the method from Mozilla 1.0 to today's XPFE and Toolkit. ;)
This should work on all builds since 2001/10/21, so that's 0.9.6 or later:
if (tb) {
    document.getElementById("views-tbar-inner").selectedItem = tb;
    tb.setAttribute ("state", "current");
}

Comment 13

[Caio Tiago Oliveira (asrail)]

Rob Marshall told on #seamonkey that tb.parentNode.selectedItem would do the same.
Well... I believe it's a bit faster and should work well on these builds (he verified in Mozilla 1.0).

Comment 14

[James Ross]

(In reply to comment #12)

No worries, you told us to use it before the interface (that eventually caused the changes in bug 370742, and thus this entire mess) even existed. :)

tb.parentNode does indeed seem like the best option to get the <tabs> element.

Comment 15

[:Gijs (he/him)]

Attachment: Patch

Might as well go and fix this then, eh? It's bugging me on trunk. This seems to fix it for me fine. Tested on Fx 2.0.0.2 and latest trunk nightly, on Mac. The earlier comments suggested this approach was tested on Moz 1.0, so I'm assuming that'll work too.

Comment 16

[James Ross]

Comment on attachment 256335 [details] [diff] [review]
Patch

r=silver; I wouldn't object to those two setAttribute lines being updated to current coding guidelines, as well. ;)

Comment 17

[Jim Jeffery not reading bug-mail 1/2/11]

FWIW, I find today that Chatzilla is working with today's nightly Minefield build.  I dont' know what was checked in that may have corrected the issue..

I am using the Chatzilla build from: ChatZilla 0.9.77 2007-02-22 11:00
and Todays Minefield:
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9a3pre) Gecko/20070225 Minefield/3.0a3pre Firefox ID:2007022504 [cairo]

Comment 18

[:Gijs (he/him)]

It doesn't actually work properly: the tab in question is not being focused if it's called from ChatZilla's code, even though the right tabpanel does get selected. The reason it does work is that xbl stopped yelling at us for setting properties. We still need the patch if we want our UI to work correctly. I'm filing a bug on xbl not yelling at us.

Comment 19

[:Gijs (he/him)]

XBL bug is bug 371724, fwiw.

Comment 20

[:Gijs (he/him)]

This should be fixed on the trunk version of ChatZilla now.

Checking in mozilla/extensions/irc/xul/content/static.js;
/cvsroot/mozilla/extensions/irc/xul/content/static.js,v  <--  static.js
new revision: 1.229; previous revision: 1.228
done

Comment 21

[[e-mail]]

(In reply to comment #14)
>No worries, you told us to use it before the interface (that eventually caused
>the changes in bug 370742, and thus this entire mess) even existed. :)
The checkin to which I referred only renamed the selectedTab property to selectedItem so .selected may have been incorrect even before then.