Closed
Bug 25050
Opened 25 years ago
Closed 25 years ago
assert in nsViewManager :: Refresh
Categories
(Core Graveyard :: GFX, defect, P3)
Tracking
(Not tracked)
VERIFIED
FIXED
M15
People
(Reporter: jband_mozilla, Assigned: kmcclusk)
References
Details
Attachments
(1 file)
|
848 bytes,
patch
|
Details | Diff | Splinter Review |
[sorry, I'm clueless about what 'Component' to use for the bug]
Running demo "#8 Forms" in mozilla.exe asserts at:
NS_ASSERTION(!(PR_TRUE == mPainting), "recursive painting not permitted");
And continues to do so if I ignore the assert
I see that there is a similar old (fixed) bug:
http://bugzilla.mozilla.org/show_bug.cgi?id=4363
Also... It bothers me a bit that there are some return paths in this method
which come after mPainting is set to but before it is cleared.
Updated•25 years ago
|
Status: NEW → ASSIGNED
Target Milestone: M14
Comment 2•25 years ago
|
||
I'd need a stack crawl to identify the offender, but this is most likely a
problem with layout.
Assignee: beard → troy
Status: ASSIGNED → NEW
Component: Views → Layout
Target Milestone: M14 → M15
I don't hit an assert, and without a stack trace there's not much I can do with
it
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → WORKSFORME
| Reporter | ||
Comment 4•25 years ago
|
||
Hey, I'm sorry I didn't capture a stack trace at the time. It is not currently
aserting for me either.
I'm reopening to point out that the code in the two method with this name still
look broken to me...
http://lxr.mozilla.org/seamonkey/search?string=nsViewManager+%3A%3A+Refresh
They use a flag to protect from rentrance. But, after setting the flag there are
code paths that exit without clearing the flag. Is this not broken? I don't
understand this exit condition. The code claims that it is a resonable place
to return, but says nothing about the state of the mPainting flag. I'll attach a
proposed patch. Apply it if you think you should. Or reclose the bug. Whatever.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
| Reporter | ||
Comment 5•25 years ago
|
||
Changing component back to Compositor, because the patch is for a view manager
file
Assignee: troy → beard
Status: REOPENED → NEW
Component: Layout → Compositor
Comment 8•25 years ago
|
||
Waiting for kevin to check in latest nsViewManager2 files.
Assignee: beard → kmcclusk
Status: ASSIGNED → NEW
Comment 9•25 years ago
|
||
Checked in fix for nsViewManager.cpp.
Status: NEW → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
Updated•16 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•