Blank chat room bug with /reload style workaround

Check the system console for and colloquy errors.

The following errors appear in the console log when I start Colloquy:

CoreEndianFlipData?: error -4940 returned for rsrc type drag (id 128, length 48, native = yes) CoreEndianFlipData?: error -4940 returned for rsrc type drag (id 128, length 48, native = yes) CoreEndianFlipData?: error -4940 returned for rsrc type drag (id 128, length 48, native = yes) CoreEndianFlipData?: error -4940 returned for rsrc type drag (id 128, length 48, native = yes)

No errors appear when I go to a channel and flip the style back and forth.

I see same behavior on a Dual G4 1.25GHz powermac desktop. Running on 10.4.5 and 10.4.6 (as upgraded last night). The console log for the IRC server shows the messages coming in, but they don't appear on the chat windows.

I believe it was working fine the first day or two after I upgraded to 2D38 but now it is not. I tried switch styles but that only helped one chat tab.

Rooms joined manually seem to work ok.

#668 is a dup of this.

#678 is also a dup of this one

SHould be fixed. [3272]

the "first private message not visible" bug is still there. although i cant reproduce it with my source build of 3275, #683, #686 and nougatmachine still have it with r3275

There was a build issue with the 3275 release, 3275.1 fixes that.

anonymous: please download the latest beta, this really is fixed now. if you still have an issue, please provide more details and supply a name, so we can contact you...

I also get this on the latest r3290 and have more info to report…

It doesn't seem to affect private messages in general only those received while the window is still rendering. When it does happen is when I send a password to a bot on initial startup, I get a private success message back from it and can't see the message until I switch the styles on that chat. All the other chats work fine.

I'm on freenode most of the time with the nick 'Infininight', feel free to contact me.

#576 is about nothing loading in the window. If you're having issues with the first message not appearing, but the rest appearing, go to #155.

Should have been more explicit; no messages show up in above mentioned window until I switch styles, not just the first one.

This issue still exists for me on Colloquy 2.1 on OS X 10.4.7 (Intel). I'm not going to mess with the priority/severity settings on this ticket, as that's not my place, but I do feel that this issue makes Colloquy unusable. (I spend a heavy amount of time in IRC every day collaborating with my coworkers, and not being able to immediately notice that they've said something is unacceptable in an IRC client.)

I also have this problem with Colloquy 2.1 on OS X 10.4.7 Intel. Colloquy 2.0 (PPC) works fine, so I'm forced to stick with that for now. Is there anything I can do to help resolve this problem?

I've just now updated to Colloquy 2.1 (3321) on Mac OS X 10.4.7 (8J135) on PPC G4. Incoming messages in the non-active channel are not rendered until having switched styles. Incoming messages in the active channel have been rendered on-screen without any issue. Simply changing the Appearance preferences makes no difference in active channels. Yet changing the current style in the Toolbar for that channel window will force the application to re-draw the new messages.

I'm going to ahead and test in a new user account to see if cache or plist data is the culprit. I'll post here again.

I hope this helps. I've been thrilled with Colloquy but this behavior would force a switch to another app until resolved.

- Smoke

I'm using Colloquy 2.1 (3321) on a Dual PowerMac? G5 running 10.4.7. This issue still persists, but I have been able to restore visibility of messages with a /clear command.

Encountered again in 3386.

Also encountered again in 2.1/3590. A "/reload style" fixes the issue as before.

I do not use auto-join, but after connecting I join about 8 channels using the line: /join #chan1,#chan2,#chan3,... in the console.

I saw this problem intermittently before, but as noted, the latest Safari beta seems to have made things worse. It now seems to happen every time I run Colloquy.

I've tried to track down what is causing this, and in my case, I have one channel I join which has a chanserv notice on join (ie. colloquy pops up a notice bubble when the channel is joined). When I don't join that channel initially (with the other 7 channels), things seem to work better -- not sure if 100%, but I'll keep testing.

I never had this as far as I can tell, but I got the same problem right after installing Safari 3. Could this be some timing/concurrency issue (just a very wild guess)? In any case, the workaround is to keep leaving and joining until you can see your own text.

marrs: The workaround is typing '/reload style' while in the room. It was always an issue, but the new webkit that came with Safari 3 is what made it really bad.

http://bugs.webkit.org/show_bug.cgi?id=14171

Patch to reset room display automatically

The attached patch causes _resetDisplay to be called when creating a new chat room style. In my tests, this fixes the "blank chat room" problem.

Probably not a great permanent fix, but I think it works nicely until the bug gets sorted out here or in webkit...

The patch introduced in r3708 has been working fine for me so far.

for me it only fixed the safari 3 related bug, the good old occurs-once-a-week bug we have before s3 is still around

I still see this as well, though it is admittedly much less frequent than it was previously. I have Safari 3 installed.

I have never seen this bug before until I installed Leopard. I can confirm I am still seeing this bug. It happens on one particular room that I auto-join and which has a password. Perhaps the fact that it is password protected is affecting it somehow?

I am using Version 2.1 (3761)

This behavior seems inconsistent, and it's not clear to me from the discussion here whether anyone actually understands the cause, so I'm filing a "me too" report to help narrow things down.

Some details of my experience that don't quite match other reports (or supplement them): 1. so far as I know, it was fine in Tiger (with build 3761; had been happening a lot with earlier Colloquy builds and/or Safari betas) 2. for quite a while, it was also fine in Leopard (same build -- same binary, in fact) 3. the rooms went blank upon being launched as a Startup Item (but this is not unique, I do it that way all the time) 4. characteristically, I see one room working and all the rest blank 5. the working room is always the one listed first in the info bar

There are two errors from Colloquy in "All Messages" at the time of the log out/in: 11/5/07 12:38:25 PM Colloquy[133] Error loading /Library/Contextual Menu Items/DocumentsToGoXCM.plugin/Contents/MacOS/DocumentsToGoXCM: dlopen(/Library/Contextual Menu Items/DocumentsToGoXCM.plugin/Contents/MacOS/DocumentsToGoXCM, 262): no suitable image found. Did find:

/Library/Contextual Menu Items/DocumentsToGoXCM.plugin/Contents/MacOS/DocumentsToGoXCM: unknown file type, first eight bytes: 0x4A 0x6F 0x79 0x21 0x70 0x65 0x66 0x66

11/5/07 12:38:25 PM Colloquy[133] Cannot find function pointer MyCMPluginFactory for factory EB982613-2188-11D6-BE4F-000A27E36620 in CFBundle/CFPlugIn 0x16a68560 </Library/Contextual Menu Items/DocumentsToGoXCM.plugin> (not loaded)

I have no idea why Colloquy would care about Docs to Go, but I can confirm that DTG was first installed quite recently, perhaps since the last time Colloquy successfully connected to all rooms on startup.

Signature of the bug I'm talking about (just to be sure I'm talking about the one covered here): I autojoin two servers and three rooms on startup, and I launch Colloquy as a Startup Item. This has all been working fine, including post-Leopard. But today I logged out and back in, and all three rooms appeared to join (listed in the info bar to the left), but two of them were blank. Just to be sure, I selected the one that was working (they're all in a single window), and waited until one of the others showed pending messages, then switched to it -- still blank. And, finally, I find that switching style cures the problem (including if I switch back to the original style), both displaying the stuff that was formerly missing, and also new stuff. So far, anyway, the data continues to display properly.

I am having this same problem with version 2.1 under Leopard. I'm fairly sure it was happening on previous versions and on Tiger (I was using Safari 3, so I guess that could be it). I might pull down the source and have a shot at working around the webkit bug if I have some time.

Any chance "Reload style" or "Refresh display" can be added to the channel right click menu (short of actually fixing the bug)? I've learned to cope with just typing "/reload style", but it seems there's always another coworker who struggles with this one until one of us in the know notices the struggle. It'd be good for a determined novice to be able to discover the fix.

I'm having this same bug for ages (with Tiger and Leopard). Changing style seems to fix it.

For me, in recent months, the issue/symptoms have been rarer.

I wonder whether Safari 3.2 (13 November 2008) introduces any improvement to WebKit that may have a positive impact on this ticket:576.

My own workaround: amongst my TextExpander shortcuts I have /rs/ for macro /reload style — YMMV.