Closed
Bug 35921
Opened 25 years ago
Closed 24 years ago
event notification outlives its event
Categories
(SeaMonkey :: General, defect, P3)
Tracking
(Not tracked)
VERIFIED
FIXED
M18
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.
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.
Comment 4•25 years ago
|
||
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.
Comment 5•25 years ago
|
||
Moving keywords over. The other bug had "beta2+", that should propably be moved
over as well.
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+]
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.
Comment 10•25 years ago
|
||
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.
Comment 11•25 years ago
|
||
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?
Comment 12•25 years ago
|
||
That bug has been there forever. I'll bet there's a bug open on it.
Comment 13•25 years ago
|
||
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.
Comment 14•25 years ago
|
||
I've noticed this too. I could be related but I don't have any evidence either
way.
Whiteboard: [nsbeta2+] → [nsbeta2+] problem understood, patch under review
Comment 16•24 years ago
|
||
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
Comment 17•24 years ago
|
||
Wait, I think that damn has a patch for this. I've seen it. I've tasted it.
Comment 18•24 years ago
|
||
You saw, you tested it, he went on vacation...
Anyone still have this patch?
Assignee | ||
Comment 20•24 years ago
|
||
checked in dan's patch
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Comment 21•24 years ago
|
||
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
Comment 22•24 years ago
|
||
Can somebody verify this bug? It seems that there is regression (see bug
42401)...
Comment 23•24 years ago
|
||
It's been fixed. I can verify it.
Whiteboard: [nsbeta2+] problem understood, patch under review → [nsbeta2+]
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•