From owner-freebsd-hackers Tue Nov 7 21:03:26 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id VAA21422 for hackers-outgoing; Tue, 7 Nov 1995 21:03:26 -0800 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id VAA21413 for ; Tue, 7 Nov 1995 21:03:22 -0800 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id VAA02874; Tue, 7 Nov 1995 21:03:00 -0800 To: Jake Hamby cc: hackers@FreeBSD.org, x_cbug@netscape.com Reply-To: hackers@FreeBSD.org Subject: Re: Timing bug with Netscape 2.0b2 In-reply-to: Your message of "Tue, 07 Nov 1995 20:38:47 PST." Date: Tue, 07 Nov 1995 21:03:00 -0800 Message-ID: <2872.815806980@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@FreeBSD.org Precedence: bulk > It isn't just blinking text (although if you want a cool example, try the > Netscape Hall of Shame: http://www.meat.com/netscape_hos.html and click > on "Blink Sink"). Another thing which is supposed to blink (but in > FreeBSD does not) is the insertion point in the currently active > TextField (for example, in the Location box at the top, or in a fill-out > form). OK, I just verified this. You're right! I even know what's happening, though not exactly why. The event loop select()'s on the X / network sockets and also sets a timeout (or *should*) for processing any interval tasks, like blinking. Apparently, it's not falling out of select on the timeout to the blink task and it requires some other event on one of the selected fds before the blink task can run. I actually kinda doubt that this is a FreeBSD specific problem. It's more likely something in the Motif or Xt libraries they're using. I'd lean towards Xt since that's where XtAppAddTimeout() lives, unless Motif has added a wrapper function for this in 2.0. It could also be an application side error in Netscape itself. Jordan