Closed Bug 35921 Opened 25 years ago Closed 24 years ago

event notification outlives its event

Categories

(SeaMonkey :: General, defect, P3)

x86
Linux
defect

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: danm.moz, Assigned: pavlov)

References

Details

(Keywords: platform-parity, Whiteboard: [nsbeta2+])

"Certain conditions" demonstrate some weakness in event processing on the linux client. The most reliable way to see the problem is to use evaughan's recently checked in (and backed out by mscott 04/13/2000 00:43) changes to the box code, and then open the browser using -ProfileManager. Many bad things happen, all (probably) the result of the CPU pegging because an event delivery notification remains on the pipe used for that, while apparently there is no actual event to process. pavlov has checked in a workaround that solves the problem by dropping the errant notification. There's probably an unprocessed event remaining somewhere that's the real root of the problem. This wants to be tracked down.
talking about boxes.. see bug 35884 - related?
Wow. Nasty thing, bug 35884. I don't know what's causing that, so I'm really not certain, but I think the problems are not related. It's not the event delivery pipe stuck open causing the slowness -- the CPU isn't pegged while it's trying to bring up the dialog in that bug. In fact, the machine is basically idle.
*** Bug 29808 has been marked as a duplicate of this bug. ***
Since this problem has been around for a very long time, why wasn't this bug marked as a duplicate of bug 29808, instead. Seems to me that 29808 is hardly resolved, and now it looks as though this is a *new* bug and therefor has no history. Hardly the case.
Moving keywords over. The other bug had "beta2+", that should propably be moved over as well.
Keywords: beta2, dogfood, pp
Since the othe bug had the status whiteboard entry, I'm moving it over. The other bug also had a blocker severity which I'm moving over as well. We need this to be fixed for mail/aim to be useful.
Severity: major → blocker
Whiteboard: [beta2+]
Keywords: nsbeta2
Updating [beta2+] in Status Summary to [nsbeta2+]
Keywords: beta2
Whiteboard: [beta2+] → [nsbeta2+]
Is this bug actually a blocker? A workaround has been checked in. I know of no remaining symptoms. I'll be removing its dogfood and blocker attributes in a couple of days if no one knows of any reason not to...
Status: NEW → ASSIGNED
Target Milestone: --- → M16
dupe bug http://bugzilla.mozilla.org/show_bug.cgi?id=29808 contains some cases. Richard, Ken, Ben, Leaf, Laurel - since you were seeing this problem consistently in the duplicate bug, do you still see this problem in builds after 4-21? thanks. Want to make sure before the keywords are taken away.
Since the workaround was implemented, I get many... "we have an event stuck -- removing it." messages. The mail/news ui isn't acting up and the cpu isn't being pegged. So, it looks to me like the workaround is working, without the underlying problem being fixed.
I didn't see the problem in Mailnews anymore (doesn't necessarily mean, it's gone), but I see other similar, but different problems in the browser: Sometimes after closing a browser window, the content of the remaining one doesn't scroll anymore, the scrollbar moves however. Clicking on a link solves it sometimes. It it this bug or another one?
That bug has been there forever. I'll bet there's a bug open on it.
Is this the bug that covers dialogs not coming up until you force some extra events? Here's a simple test case: run mozilla -edit, type a few chars, type [mod]-Q to quit but don't touch the mouse ... and wait, and wait. Nothing happens. Now move the mouse around for a few seconds, and the "Do you want to save?" dialog comes up -- it was blocked. This happens for nearly every dialog on linux.
I've noticed this too. I could be related but I don't have any evidence either way.
Blocks: 40158
Mass-moving undated nsbeta2+ bugs to M18
Target Milestone: M16 → M18
Whiteboard: [nsbeta2+] → [nsbeta2+] problem understood, patch under review
reassigning to saari. Chris, since this seems to be event-related, could you take it on in Dan's absence? His last comment was in a private email: I have a patch for this. I've emailed several people asking for a review, and told them to go ahead and check it in if they like it. It's probably a good change, rather safe, but affecting really basic, ubiquitous code. I've been running with it without problems. However, fixing this problem doesn't seem to actually affect the product in any way.
Assignee: danm → saari
Status: ASSIGNED → NEW
Wait, I think that damn has a patch for this. I've seen it. I've tasted it.
You saw, you tested it, he went on vacation... Anyone still have this patch?
i'll check it in
Assignee: saari → pavlov
checked in dan's patch
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Sorry for the spam. New QA Contact for Browser General. Thanks for your help Joseph (good luck with the new job) and welcome aboard Doron Rosenberg
QA Contact: jelwell → doronr
Can somebody verify this bug? It seems that there is regression (see bug 42401)...
It's been fixed. I can verify it.
Whiteboard: [nsbeta2+] problem understood, patch under review → [nsbeta2+]
marking verified per blizzard's comment.
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.