Closed
Bug 371067
Opened 18 years ago
Closed 18 years ago
Cannot switch channels on recent trunk builds
Categories
(Other Applications :: ChatZilla, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: iannbugzilla, Assigned: Gijs)
References
Details
(Keywords: regression, Whiteboard: [cz-0.9.78])
Attachments
(1 file)
(deleted),
patch
|
bugzilla-mozilla-20000923
:
review+
|
Details | Diff | Splinter Review |
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
Works fine in SM trunk BuildID 2007021808 so regression was in the 24 hour period to the next trunk build.
Comment 2•18 years ago
|
||
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.
Assignee | ||
Comment 3•18 years ago
|
||
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•18 years ago
|
||
Why don't you use the selectedTab property?
Comment 6•18 years ago
|
||
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•18 years ago
|
||
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•18 years ago
|
||
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•18 years ago
|
||
> Your opinion is not useful.
Oh, I didn't realize that.
Comment 10•18 years ago
|
||
Neither do I.
Comment 12•18 years ago
|
||
(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•18 years ago
|
||
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•18 years ago
|
||
(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.
Assignee | ||
Comment 15•18 years ago
|
||
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.
Assignee: rginda → gijskruitbosch+bugs
Status: NEW → ASSIGNED
Attachment #256335 -
Flags: review?(silver)
Comment 16•18 years ago
|
||
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. ;)
Attachment #256335 -
Flags: review?(silver) → review+
Comment 17•18 years ago
|
||
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]
Assignee | ||
Comment 18•18 years ago
|
||
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.
Assignee | ||
Comment 19•18 years ago
|
||
XBL bug is bug 371724, fwiw.
Assignee | ||
Comment 20•18 years ago
|
||
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
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Assignee | ||
Updated•18 years ago
|
Whiteboard: [cz-0.9.78]
Comment 21•18 years ago
|
||
(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.
You need to log in
before you can comment on or make changes to this bug.
Description
•