Opened 14 years ago

Last modified 7 years ago

#576 reopened Defect

Blank chat room bug with /reload style workaround

Reported by: davel Owned by: timothy
Component: Colloquy (Mac) Version: 2.1 (Mac)
Severity: Major Keywords: webkit safari 3 beta
Cc: jay@…, igbun, grahamperrin


rev 3189 on x86 mac. I have 3 channels in the join rooms list under autlomatic, plus one join command in the command section (for a channel with a password).

When I start Colloquy, I join all four channels. When a message comes in to one of the channel, the new message indicator is displayed, but when I switch to that channel, the display is blank. If I switch styles for that channel, the messages are displayed.

All channels are in the same window. I'm building the Release (Universal) target.

Change History (40)

comment:1 Changed 14 years ago by timothy

Check the system console for and colloquy errors.

comment:2 Changed 14 years ago by davel

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.

comment:3 Changed 14 years ago by VivekKhera@…

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.

comment:4 Changed 14 years ago by timothy

#668 is a dup of this.

comment:5 Changed 14 years ago by akempgen

#678 is also a dup of this one

comment:6 Changed 14 years ago by timothy

  • Resolution set to fixed
  • Status changed from new to closed

SHould be fixed. [3272]

comment:7 Changed 14 years ago by akempgen

  • Resolution fixed deleted
  • Status changed from closed to reopened
  • Version changed from Built Source to Latest Nightly

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

comment:8 Changed 14 years ago by timothy

  • Resolution set to fixed
  • Status changed from reopened to closed

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

comment:9 Changed 14 years ago by anonymous

  • Resolution fixed deleted
  • Status changed from closed to reopened

comment:10 Changed 14 years ago by akempgen

  • Resolution set to worksforme
  • Status changed from reopened to closed

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...

comment:11 Changed 14 years ago by Infininight

  • Resolution worksforme deleted
  • Severity changed from major to normal
  • Status changed from closed to reopened

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.

comment:12 Changed 14 years ago by rinoa

#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.

comment:13 Changed 14 years ago by Infininight

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

comment:14 Changed 14 years ago by rinoa

  • Summary changed from new messages invisible until user switches styles to Blank chat room bug

comment:15 Changed 13 years ago by Tom Tobin <korpios@…>

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.)

comment:16 Changed 13 years ago by bjorn@…

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?

comment:17 Changed 13 years ago by smokingbarrl@…

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

comment:18 Changed 13 years ago by killerbean@…

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.

comment:19 Changed 13 years ago by Rinoa

Encountered again in 3386.

comment:20 Changed 13 years ago by Rinoa

  • Version changed from Latest Nightly to Latest 2.1

comment:21 Changed 13 years ago by flump

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

comment:22 Changed 13 years ago by akempgen

  • Keywords webkit safari 3 beta added
  • priority changed from normal to high
  • Severity changed from normal to major

comment:23 Changed 13 years ago by Jeff

  • Cc jeff@… added

comment:24 Changed 13 years ago by Jeff

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.

comment:25 Changed 13 years ago by marrs

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.

comment:26 Changed 13 years ago by Rinoa

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.

comment:28 Changed 13 years ago by Jeff

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...

comment:29 Changed 13 years ago by Jeff

  • Cc jeff@… removed

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

comment:30 Changed 12 years ago by akempgen

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

comment:31 Changed 12 years ago by jayshao

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

comment:32 Changed 12 years ago by jayshao

  • Cc jay@… added

comment:33 Changed 12 years ago by gthing

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)

comment:34 Changed 12 years ago by jackr

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.

comment:35 Changed 12 years ago by Ycros

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.

comment:36 Changed 12 years ago by robla

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.

comment:37 Changed 11 years ago by igbun

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

comment:38 Changed 11 years ago by igbun

  • Cc igbun added

comment:39 Changed 11 years ago by grahamperrin

  • Cc grahamperrin added
  • Summary changed from Blank chat room bug to Blank chat room bug with /reload style workaround

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.

comment:40 Changed 7 years ago by anonymous

It's still doing this sometimes for me in Version 2.4 (5436), always on startup. The GUI seems to simply hang. It's usually when lots of stuff comes in just as I connect (I use a bouncer that plays back room activity so this is usually the case). Resizing doesn't work, didn't try /reload style yet because I only found this now when I went to log the ticket.

What works for me though is to minimize and open it again. Just wanted to let you know this still seems to happen in some cases.

Note: See TracTickets for help on using tickets.