Closed
Bug 4883
Opened 26 years ago
Closed 26 years ago
[PP] Apprunner frequently crashing in CalcOffset (upon closing Window)
Categories
(Core :: Layout: Form Controls, defect, P1)
Tracking
()
VERIFIED
FIXED
M5
People
(Reporter: elig, Assigned: mikepinkerton)
Details
(Whiteboard: QA BLOCKER)
* TITLE/SUMMARY
Apprunner frequently crashing in CalcOffset
* STEPS TO REPRODUCE
0) Launch Apprunner
1) Do something. (Normally consisting of clicking in the URL text field, or
closing an Apprunner window.)
* RESULT
- What happened
Irreproducibly, Apprunner crashes. Simon says that Pinkerton should get this.
* REGRESSION
- Occurs On
Mac OS Apprunner (4.9.99 AM optimized build)
- Haven't Seen On
Win32 Apprunner (4.9.99 AM optimized build [NT 4, Service Pack 3])
Linux Apprunner (4.9.99 AM optimized build)
* STACK CRAWL
PowerPC access exception at 0B0A3680
Calling chain using A6/R1 links
Back chain ISA Caller
00000000 PPC 0B72FBF0
03AFF540 PPC 0B72EBA8 main+0053C
03AFF450 PPC 0B4F66A0 nsAppShellService::Run()+00018
03AFF410 PPC 0B096B34 nsAppShell::Run()+00038
03AFF390 PPC 0B097480 nsMacMessagePump::DoMessagePump()+0003C
03AFF340 PPC 0B0975EC nsMacMessagePump::DispatchEvent(int, EventRecord*)+
00048
03AFF2F0 PPC 0B097C74 nsMacMessagePump::DoKey(EventRecord&)+00088
03AFF2B0 PPC 0B097F1C
nsMacMessagePump::DispatchOSEventToRaptor(EventRecord&, GrafPort
*)+00044
03AFF260 PPC 0B092490 nsMacMessageSink::DispatchOSEvent(EventRecord&,
GrafPort*)+00038
03AFF220 PPC 0B08E5D8 nsMacWindow::HandleOSEvent(EventRecord&)+00020
03AFF1C0 PPC 0B08E8DC nsMacEventHandler::HandleOSEvent(EventRecord&)+0003C
03AFF180 PPC 0B08F168 nsMacEventHandler::HandleKeyEvent(EventRecord&)+
00160
03AFF0E0 PPC 0B07DF18 nsTextWidget::DispatchWindowEvent(nsGUIEvent&)+00090
03AFEFD0 PPC 0B079AB0 nsWindow::DispatchWindowEvent(nsGUIEvent&)+00018
03AFEF90 PPC 0B0799DC nsWindow::DispatchEvent(nsGUIEvent*, nsEventStatus&
)+00090
03AFEF40 PPC 0AF73C0C HandleEvent(nsGUIEvent*)+00058
03AFEEF0 PPC 0AF71550 nsViewManager::DispatchEvent(nsGUIEvent*,
nsEventStatus&)+005D0
03AFEDB0 PPC 0AF75694 nsView::HandleEvent(nsGUIEvent*, unsigned int,
nsEventStatus&)+0
0104
03AFED30 PPC 0AF6A8F4 nsScrollingView::HandleEvent(nsGUIEvent*, unsigned
int, nsEventS
tatus&)+000C4
03AFECE0 PPC 0AF75694 nsView::HandleEvent(nsGUIEvent*, unsigned int,
nsEventStatus&)+0
0104
03AFEC60 PPC 0AF75694 nsView::HandleEvent(nsGUIEvent*, unsigned int,
nsEventStatus&)+0
0104
03AFEBE0 PPC 0AF75694 nsView::HandleEvent(nsGUIEvent*, unsigned int,
nsEventStatus&)+0
0104
03AFEB60 PPC 0AF75724 nsView::HandleEvent(nsGUIEvent*, unsigned int,
nsEventStatus&)+0
0194
03AFEAE0 PPC 0B1770F0 PresShell::HandleEvent(nsIView*, nsGUIEvent*,
nsEventStatus&)+00
1A8
03AFEA70 PPC 0B263018 nsHTMLInputElement::HandleDOMEvent(nsIPresContext&,
nsEvent*, ns
IDOMEvent**, unsigned int, nsEventStatus&)+00010
03AFEA30 PPC 0B342428 nsGenericElement::HandleDOMEvent(nsIPresContext&,
nsEvent*, nsID
OMEvent**, unsigned int, nsEventStatus&)+000DC
03AFE9D0 PPC 0B1F0E00 nsEventListenerManager::HandleEvent(nsIPresContext&,
nsEvent*, n
sIDOMEvent**, unsigned int, nsEventStatus&)+00780
03AFE8E0 PPC 0B4C0FDC nsJSEventListener::HandleEvent(nsIDOMEvent*)+0015C
03AFE850 PPC 0B5810E0 JS_CallFunctionValue+00014
03AFE810 PPC 0B599528 js_CallFunctionValue+000B8
03AFE760 PPC 0B599328 js_Invoke+0057C
03AFE680 PPC 0B59F1B4 js_Interpret+055F0
03AFE460 PPC 0B599328 js_Invoke+0057C
03AFE380 PPC 0B59F1B4 js_Interpret+055F0
03AFE160 PPC 0B5992D0 js_Invoke+00524
03AFE080 PPC 0B030A60 BrowserAppCoreLoadUrl(JSContext*, JSObject*,
unsigned int, long*
, long*)+000AC
03AFDFD0 PPC 0B02A8E0 nsBrowserAppCore::LoadUrl(const nsString&)+00078
03AFDF80 PPC 0B01A7B0 nsWebShell::LoadURL(const unsigned short*,
nsIPostData*, int, ns
URLReloadType, unsigned int)+00060
03AFDF30 PPC 0B01BA58 nsWebShell::LoadURL(const unsigned short*, const
char*, nsIPostD
ata*, int, nsURLReloadType, unsigned int)+00398
03AFDDE0 PPC 0B01AAF8 nsWebShell::DoLoadURL(const nsString&, const char*,
nsIPostData*
, nsURLReloadType, unsigned int)+002DC
03AFDD00 PPC 0B0108A4 nsDocLoaderImpl::LoadDocument(const nsString&, const
char*, nsIC
ontentViewerContainer*, nsIPostData*, nsISupports*, nsIStreamObserver*,
nsURLReloadType, unsi
gned int)+001A8
03AFDC90 PPC 0B012680 nsDocumentBindInfo::Bind(const nsString&,
nsIPostData*, nsIStrea
mListener*)+00124
03AFDC40 PPC 0B01149C nsDocLoaderImpl::FireOnStartDocumentLoad(nsIURL*,
const char*)+0
0050
03AFDBF0 PPC 0B01D618 nsWebShell::OnStartDocumentLoad(nsIURL*, const char*
)+00128
03AFDB60 PPC 0B02B5B8 nsBrowserAppCore::OnStartDocumentLoad(nsIURL*, const
char*)+0003
C
03AFDB10 PPC 0B02B188 setAttribute(nsIWebShell*, const char*, const char*,
const nsStr
ing&)+00270
03AFDA30 PPC 0B43DDA4 RDFElementImpl::SetAttribute(const nsString&, const
nsString&)+0
0058
03AFD9E0 PPC 0B438480 XULDocumentImpl::OnSetAttribute(nsIDOMElement*,
const nsString&,
const nsString&)+0007C
03AFD980 PPC 0B42648C RDFXULBuilderImpl::OnSetAttribute(nsIDOMElement*,
const nsString
&, const nsString&)+0068C
03AFD7B0 PPC 0B41B9D4 CompositeDataSourceImpl::Assert(nsIRDFResource*,
nsIRDFResource*
, nsIRDFNode*, int)+00058
03AFD750 PPC 0B4687B0 LocalStoreImpl::Assert(nsIRDFResource*,
nsIRDFResource*, nsIRDFN
ode*, int)+00018
03AFD710 PPC 0B41DFE4 RDFXMLDataSourceImpl::Assert(nsIRDFResource*,
nsIRDFResource*, n
sIRDFNode*, int)+00044
03AFD6D0 PPC 0B40C020 InMemoryDataSource::Assert(nsIRDFResource*,
nsIRDFResource*, nsI
RDFNode*, int)+0006C
03AFD670 PPC 0B41C8AC CompositeDataSourceImpl::OnAssert(nsIRDFResource*,
nsIRDFResourc
e*, nsIRDFNode*)+0005C
03AFD610 PPC 0B4247D0 RDFXULBuilderImpl::OnAssert(nsIRDFResource*,
nsIRDFResource*, ns
IRDFNode*)+00360
03AFD500 PPC 0B429110 RDFXULBuilderImpl::AddAttribute(nsIContent*,
nsIRDFResource*, ns
IRDFNode*)+00260
03AFD3F0 PPC 0B4407E4 RDFElementImpl::SetAttribute(int, nsIAtom*, const
nsString&, int
)+005D0
03AFD310 PPC 0B4423E4
RDFElementImpl::ExecuteOnChangeHandler(nsIDOMElement*, const nsS
tring&)+001F0
03AFD140 PPC 0B442688 RDFElementImpl::ExecuteJSCode(nsIDOMElement*)+00190
03AFD060 PPC 0B441810 RDFElementImpl::HandleDOMEvent(nsIPresContext&,
nsEvent*, nsIDOM
Event**, unsigned int, nsEventStatus&)+00218
03AFCFC0 PPC 0B1F117C nsEventListenerManager::HandleEvent(nsIPresContext&,
nsEvent*, n
sIDOMEvent**, unsigned int, nsEventStatus&)+00AFC
03AFCED0 PPC 0B4C0FDC nsJSEventListener::HandleEvent(nsIDOMEvent*)+0015C
03AFCE40 PPC 0B5810E0 JS_CallFunctionValue+00014
03AFCE00 PPC 0B599528 js_CallFunctionValue+000B8
03AFCD50 PPC 0B599328 js_Invoke+0057C
03AFCC70 PPC 0B59F1B4 js_Interpret+055F0
03AFCA50 PPC 0B599328 js_Invoke+0057C
03AFC970 PPC 0B59F1B4 js_Interpret+055F0
03AFC750 PPC 0B5992D0 js_Invoke+00524
03AFC670 PPC 0B483364 ElementSetAttribute(JSContext*, JSObject*, unsigned
int, long*,
long*)+000C0
03AFC560 PPC 0B43DDA4 RDFElementImpl::SetAttribute(const nsString&, const
nsString&)+0
0058
03AFC510 PPC 0B438480 XULDocumentImpl::OnSetAttribute(nsIDOMElement*,
const nsString&,
const nsString&)+0007C
03AFC4B0 PPC 0B42635C RDFXULBuilderImpl::OnSetAttribute(nsIDOMElement*,
const nsString
&, const nsString&)+0055C
03AFC2E0 PPC 0B41BB1C CompositeDataSourceImpl::Unassert(nsIRDFResource*,
nsIRDFResourc
e*, nsIRDFNode*)+00098
03AFC280 PPC 0B468720 LocalStoreImpl::Unassert(nsIRDFResource*,
nsIRDFResource*, nsIRD
FNode*)+00018
03AFC240 PPC 0B41E0C4 RDFXMLDataSourceImpl::Unassert(nsIRDFResource*,
nsIRDFResource*,
nsIRDFNode*)+00044
03AFC200 PPC 0B40C38C InMemoryDataSource::Unassert(nsIRDFResource*,
nsIRDFResource*, n
sIRDFNode*)+0006C
03AFC1A0 PPC 0B41C99C CompositeDataSourceImpl::OnUnassert(nsIRDFResource*,
nsIRDFResou
rce*, nsIRDFNode*)+0005C
03AFC140 PPC 0B424CE4 RDFXULBuilderImpl::OnUnassert(nsIRDFResource*,
nsIRDFResource*,
nsIRDFNode*)+00360
03AFC030 PPC 0B429304 RDFXULBuilderImpl::RemoveAttribute(nsIContent*,
nsIRDFResource*,
nsIRDFNode*)+000F0
03AFBFB0 PPC 0B440EEC RDFElementImpl::UnsetAttribute(int, nsIAtom*, int)+
00238
03AFBEE0 PPC 0B43DE78 RDFElementImpl::RemoveAttribute(const nsString&)+
00050
03AFBE90 PPC 0B4385C0 XULDocumentImpl::OnRemoveAttribute(nsIDOMElement*,
const nsStrin
g&)+00074
03AFBE30 PPC 0B426A00 RDFXULBuilderImpl::OnRemoveAttribute(nsIDOMElement*,
const nsStr
ing&)+003A8
03AFBCC0 PPC 0B41BB1C CompositeDataSourceImpl::Unassert(nsIRDFResource*,
nsIRDFResourc
e*, nsIRDFNode*)+00098
03AFBC60 PPC 0B468720 LocalStoreImpl::Unassert(nsIRDFResource*,
nsIRDFResource*, nsIRD
FNode*)+00018
03AFBC20 PPC 0B41E0C4 RDFXMLDataSourceImpl::Unassert(nsIRDFResource*,
nsIRDFResource*,
nsIRDFNode*)+00044
03AFBBE0 PPC 0B40C38C InMemoryDataSource::Unassert(nsIRDFResource*,
nsIRDFResource*, n
sIRDFNode*)+0006C
03AFBB80 PPC 0B41C99C CompositeDataSourceImpl::OnUnassert(nsIRDFResource*,
nsIRDFResou
rce*, nsIRDFNode*)+0005C
03AFBB20 PPC 0B424CE4 RDFXULBuilderImpl::OnUnassert(nsIRDFResource*,
nsIRDFResource*,
nsIRDFNode*)+00360
03AFBA10 PPC 0B429304 RDFXULBuilderImpl::RemoveAttribute(nsIContent*,
nsIRDFResource*,
nsIRDFNode*)+000F0
03AFB990 PPC 0B440F60 RDFElementImpl::UnsetAttribute(int, nsIAtom*, int)+
002AC
03AFB8C0 PPC 0B4341F4 XULDocumentImpl::AttributeChanged(nsIContent*,
nsIAtom*, int)+00
054
03AFB860 PPC 0B175EBC PresShell::AttributeChanged(nsIDocument*,
nsIContent*, nsIAtom*,
int)+00068
03AFB810 PPC 0B173224 PresShell::ExitReflowLock()+0002C
03AFB7D0 PPC 0B174CC4 PresShell::ProcessReflowCommands()+00070
03AFB750 PPC 0B175038 PresShell::CreateRenderingContext(nsIFrame*,
nsIRenderingContext
**)+00140
03AFB6C0 PPC 0B14B9B0 DeviceContextImpl::CreateRenderingContext(nsIView*,
nsIRendering
Context*&)+0006C
03AFB660 PPC 0B14BBA0
DeviceContextImpl::InitRenderingContext(nsIRenderingContext*, ns
IWidget*)+00020
03AFB620 PPC 0B147564 nsRenderingContextMac::Init(nsIDeviceContext*,
nsIWidget*)+0009C
03AFB550 PPC 0B14F004 nsDrawingSurfaceMac::Init(nsIWidget*)+0003C
03AFB510 PPC 0B146C94 GraphicState::Init(nsIWidget*)+0002C
03AFB4D0 PPC 0B0783BC nsWindow::GetNativeData(unsigned int)+0006C
03AFB470 PPC 0B07A40C nsWindow::LocalToWindowCoordinate(nsPoint&)+00018
03AFB430 PPC 0B07A378 nsWindow::ConvertToDeviceCoordinates(int&, int&)+
00028
03AFB3E0 PPC 0B079F84 nsWindow::CalcOffset(int&, int&)+00094
Closing log
Reporter | ||
Updated•26 years ago
|
Assignee: karnaze → pinkerton
Reporter | ||
Updated•26 years ago
|
QA Contact: 4078 → 1698
Assignee | ||
Updated•26 years ago
|
Assignee: pinkerton → trudelle
Assignee | ||
Comment 1•26 years ago
|
||
why is this assigned to me?
assigning to my manager.
Comment 2•26 years ago
|
||
cc'ing sfraser. Simon, why did you think Pink should get this one?
Comment 3•26 years ago
|
||
I've seen this fairly frequently in the debugger, and seem to recall that some
null pointer is being accessed in nsWindow, so I think it's widget-related.
Updated•26 years ago
|
Assignee: trudelle → hyatt
Comment 4•26 years ago
|
||
I can't reproduce this, and I still don't see why it would be Pink's. Looks
like some XUL content stuff on the stack, maybe Hyatt has some insight.
reassigning to him as p4 for m5. Eli, it would be much better if you could find
a reproducible case for this.
Reporter | ||
Updated•26 years ago
|
Summary: Apprunner frequently crashing in CalcOffset → Apprunner frequently crashing in CalcOffset (upon closing Window)
Reporter | ||
Comment 5•26 years ago
|
||
Franz was out, so I sent Hans over to trudelle's cubicle to reproduce this.
(Needless to say, he was pumped up.)
Anyway, the reproduction steps are vaguely like:
#0. Launch Apprunner
#1. Open a second browser window
#2. Close the first browser window
(Bonus points if you move things around while the computer is trying to work, and
be sure to do step #2 while it's trying to do step #1.)
Reporter | ||
Comment 6•26 years ago
|
||
[Also, please note that I still can't reproduce this on Win32, and that the build
I reproduced it on with the aforementioned steps was the 4.12.99 AM Mac OS
build.]
Updated•26 years ago
|
Priority: P3 → P2
Target Milestone: M5
Comment 7•26 years ago
|
||
setting p2 for m5, cc'ing saari&pierre in case this is a Mac GFX thing
Comment 8•26 years ago
|
||
I have a suspicion that this is caused by timers firing after the window
has gone away, which would be another side-effect of the massive webshell
leakage (bug 4127). I've seen the progress StripTimer on the stack sometimes.
Updated•26 years ago
|
Status: NEW → ASSIGNED
Updated•26 years ago
|
Summary: Apprunner frequently crashing in CalcOffset (upon closing Window) → [PP] Apprunner frequently crashing in CalcOffset (upon closing Window)
Comment 10•26 years ago
|
||
Mac only.
Updated•26 years ago
|
Assignee: hyatt → pinkerton
Status: ASSIGNED → NEW
Priority: P2 → P1
Comment 11•26 years ago
|
||
reassigning to pinkerton as p1 for m5
Comment 12•26 years ago
|
||
There is an inconsistency in the bug report. At the top of the stack is
"nsMacMessagePump::DoKey" which shows that it crashed consecutively to a keyEvent
but nowhere in the description is a keyEvent mentioned.
Following are two very easy ways to reproduce a similar crash, which may or may
not be identical to the one described above, pending further explanations from
the reporter:
- launch AppRunner (not Viewer)
- open a second window
- click the URL field of that second window
- click the closeBox
==> crash
- launch Viewer (not AppRunner)
- click the URL field
- click the closeBox or type cmd-W
==> crash
Thanks for taking care of it, Pink. Are you taking other Widget bugs too?
Reporter | ||
Comment 13•26 years ago
|
||
Damn. Pierre discovered my secret. I actually just use a Perl script that
generates random stack crawls, and pastes them into my bug reports. I'm now
busily adapting it to generate random bug reports for me, too. ;)
---
I don't understand what the inconsistency is (or, actually, even what the
question is), so perhaps you can help me understand.
The stack crawl provided was clearly provided when I didn't know how to reproduce
the bug, so I probably pressed a key in the process of making it crash, among
lots of other things.
The reproduction steps that I subsequently at trudelle's request provided did not
contain a keystroke.
It looks like the same crash to me.
Assignee | ||
Updated•26 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 14•26 years ago
|
||
accepting bug
Assignee | ||
Comment 15•26 years ago
|
||
it looks to me like the timer that blinks the cursor is firing after the window
has been closed. Where are these timers set up and cleared? anyone know?
Assignee | ||
Comment 16•26 years ago
|
||
for the viewer case, two text widgets (url bar and status area) are being
created. only one of them (the status area) ever gets deleted. So the dstr of the
url bar text widget is never called, so it never gets the notice to stop
repeating, hence the crash after the widget goes away. I think this is totally in
viewer code. Anyone know why the url bar isn't being deleted?
I'll look into why it's crashing in apprunner next.
Comment 17•26 years ago
|
||
The caret blink timer firing after the window has been closed is long-running
issues with editor and mail compose windows, and a side-effect of the massive
memory leak bug.
As I understand it, this bug occurs when closing browser windows, for which there
should be no blinking caret.
Assignee | ||
Comment 18•26 years ago
|
||
well, there is a blinking caret in the url bar. that's what is causing the
crashes i see and how i was told to dup this bug.
The url bar not being deleted in viewer is XP (happens on linux too). Only the
status bar text widget ever gets deleted. This is not really my area of
responsibility.
Comment 19•26 years ago
|
||
Ah. The caret in the URL bar is drawn by TextEdit, and draws on calls to
IdleControls in nsTextWidget::RepeatAction(), which is called as an Idler. This
has nothing to do with the ender caret.
Assignee | ||
Comment 20•26 years ago
|
||
I just traced through apprunner and the text widget isn't getting deleted when
the main window is closed. This is on both mac and linux. That's why the repeater
crashes when the window is not there (because the url bar is still trying to
idle, but no window, so it goes boom when it tries to setup the drawing
environment to flash the caret).
This smells more and more like the web shell leaking bug that scc has (or will
have very shortly). This crash is Mac only, but the symptom is XP.
I'll hold onto this for a while longer and talk to scc about it. cc'ing him on
this bug as well.
Assignee | ||
Comment 21•26 years ago
|
||
ok, i don't know what happened, but now the bugreport is back to singlespaced,
even though i got a diff that was HUGE and looked like it deleted everything....
oh well. all looks well.
Assignee | ||
Comment 22•26 years ago
|
||
In viewer, at least, the toplevel widget is being leaked (mWindow member in
nsBrowserWindow) so every single widget under it never gets disposed.
Filed a new bug for this, #5483. Once that gets cleared up, this will get cleared
up.
Comment 23•26 years ago
|
||
Adding to QA Blocker radar.
Assignee | ||
Updated•26 years ago
|
Assignee: pinkerton → pierre
Status: ASSIGNED → NEW
Assignee | ||
Comment 24•26 years ago
|
||
I've spent about 3 hours tracing this down and I've discovered two problems. One
I have a fix for, the other I figured I'd let pierre handle because he knows the
code much much better.
The first problem (the one I have a fix for) is that in
nsBrowserWindow::CreateToolbar() we QI the text widget twice (to the same
interface, mind you) and only release it once. That is a definate memory leak and
will cause the text widget to never be deleted properly whatever we do. That one
is XP. I'll checkin a fix as soon as I get permission.
The second problem for which I have to real solution is the following: in
nsBrowserWindow::Close() we release the mWindow member. At the time (because the
event system is still holding two refs to it), the window isn't deleted. However,
later in the quit cycle, the event system releases its refs and the top level
widget is deleted (calling nsMacWindow::~nsMacWindow). For some reason, Destroy()
is never getting called on this object so the widget never releases it's children
list (stored in mChildren). This causes the text widget (and all the other
widgets, mind you) to still have a dangling reference.
I noticed that Destroy() is commented out in nsWindow::~nsWindow on MacOS. I
don't know why. It seems to do the right thing on windows, but the delete
sequence is different there. This is why I'm reassigning to pierre, because he
understands how all this stuff fits together at object destruction time.
We're so close!
Assignee | ||
Comment 25•26 years ago
|
||
Ok, i just tested this to see if it still crashe in viewer and it doesn't. The
destructors are being correctly called. I swear before I wrote that last comment
I checked and the dstr's weren't being called at all.
I'll test it in apprunner and see what happens there, but it looks like
everything is good in the world.
Assignee | ||
Updated•26 years ago
|
Assignee: pierre → pinkerton
Assignee | ||
Updated•26 years ago
|
Status: NEW → RESOLVED
Closed: 26 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 26•26 years ago
|
||
Ok, the dstr is not being called in apprunner, so we are certainly leaking the
widgets there. The actual crasher in viewer is fixed, so I'll close this one out
and keep working on 5483.
Assignee | ||
Comment 27•26 years ago
|
||
marking fixed.
Reporter | ||
Comment 28•26 years ago
|
||
I'm still seeing crashes in CalcOffset using the 4.29.99 build, but will defer
until today's build for a full verification.
Assignee | ||
Updated•26 years ago
|
Status: RESOLVED → REOPENED
Assignee | ||
Updated•26 years ago
|
Resolution: FIXED → ---
Assignee | ||
Comment 29•26 years ago
|
||
After my marathon leak correction session with scc, we identifed the real reason
for this crash (which really wasn't fixed). Once we finish with the webshell
leak, I'll get back to this one.
Reopening so I dont' forget.
Assignee | ||
Updated•26 years ago
|
Status: REOPENED → ASSIGNED
Assignee | ||
Comment 30•26 years ago
|
||
reolution cleared, marking assigned.
Reporter | ||
Comment 31•26 years ago
|
||
<thanks!>
Assignee | ||
Updated•26 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 26 years ago → 26 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 32•26 years ago
|
||
Added Destroy() method to do the same as the Repeater dtor would do but it wasn't
getting called because the timer still held a ref to the widget. Appr chofmann.
Marking as fixed.
Reporter | ||
Updated•26 years ago
|
Status: RESOLVED → VERIFIED
Reporter | ||
Comment 33•26 years ago
|
||
Using the 4.30.99 PM Mac OS build, I can't reproduce this bug anymore using the
scenarios described by Pierre, or using the one I described.
Thus, verified fixed.
Comment 34•26 years ago
|
||
Moving all Widget Set bugs, past and present, to new HTML Form Controls
component per request from karnaze. Widget Set component will be retired
shortly.
You need to log in
before you can comment on or make changes to this bug.
Description
•