Closed Bug 42686 Opened 25 years ago Closed 25 years ago

assert opening inbox - scrollport inside a tooltip restoring state

Categories

(MailNews Core :: Backend, defect, P1)

Product:
MailNews Core
Component:
Backend
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: jeziorek, Assigned: pollmann)

References

Details

(Whiteboard: [dogfood+][nsbeta2+] fix in hand 7/19)

Attachments

(1 file)

macsbug for select IMAP inbox post-migration
31.24 KB, text/plain
Details
When in mail and you try to open the inbox it crashes 1.do ./netscape -mail 2. open your account folder 3. open inbox and it will crash comm. 2000-06-15-08-M17
Putting on dogfood+ radar.
Keywords: dogfood
Whiteboard: [dogfood+]
Change it to P1 and add smoketest to Keywords
Keywords: smoketest
Priority: P3 → P1
.
Assignee: bienvenu → mscott
*** Bug 42687 has been marked as a duplicate of this bug. ***
any stack traces in the talkback reports? Alex, are you migrating an existing profile when you ran into this or just running on the same profile you used yesterday?
Alek - what about a new profile?
Is this commercial only or can someone repro this on mozilla? BTW, Paul Chen says Mail works fine (albeit slowly) on a fresh Mac mozilla tree that he's just pulled and built.
So far, we only have Linux builds from release team and this crash is on the Linux build so we'd have to wait for a Mac build to confirm Paul Chen's findings. I'll cc: asa so he can try the mozilla Linux build.
????? I've announced mozilla and netscape builds for all platforms to build-accept, and I see them in my mailbox and on sweetlou.
Win32: Esther did not see this when using older profiles. Then she created a new profile IMAP and it did crash upon selecting the inbox. Then opening again launching, she crashed after giving login password. Then subsequent launches did not crash upon inbox selection or password. My linux experience is that I crashed the first few accesses to IMAP inbox, then I was fine after that and was able to discover folders and get mail.
Component: Mail Database → Mail Back End
OK, I tried today's build on NT and I crashed the first two times on a migrated IMAP profile and subsequently was OK. Talkback report is not good - incident #12469261
Assignee: mscott → sspitzer
Since the problem only happens on new or migrated profiles I'm going to send this over to sspitzer.
accepting. investigating now. I believe this crash is also causing #42683
Status: NEW → ASSIGNED
Could bug 42605 be the reason?
gemal I think this is a differnt problem. However what you reported in 42605 does look like the same problem in our other smoketest blocker: #42518.
here's the stack trace: #0 0x419bfbc5 in nsScrollPortView::ScrollTo (this=0x90075f8, aX=-2147483648, aY=0, aUpdateFlags=0) at nsScrollPortView.cpp:252 #1 0x41225ee1 in nsScrollPortFrame::RestoreState (this=0x8f3c5cc, aPresContext=0x86d2ec0, aState=0x9000388) at nsScrollPortFrame.cpp:583 #2 0x411d9858 in FrameManager::RestoreFrameStateFor (this=0x87799f8, aPresContext=0x86d2ec0, aFrame=0x8f3c5cc, aState=0x8cc7998, aID=eNoID) at nsFrameManager.cpp:1595 #3 0x411d9910 in FrameManager::RestoreFrameState (this=0x87799f8, aPresContext=0x86d2ec0, aFrame=0x8f3c5cc, aState=0x8cc7998) at nsFrameManager.cpp:1613 #4 0x41374d0c in nsCSSFrameConstructor::InitAndRestoreFrame (this=0x8879168, aPresContext=0x86d2ec0, aState=@0xbfffe6c4, aContent=0x8f7a670, aParentFrame=0x8f4b86c, aStyleContext=0x9007258, aPrevInFlow=0x0, aNewFrame=0x8f3c5cc) at nsCSSFrameConstructor.cpp:6974 #5 0x41373135 in nsCSSFrameConstructor::BeginBuildingScrollFrame (this=0x8879168, aPresShell=0x87819b0, aPresContext=0x86d2ec0, aState=@0xbfffe6c4, aContent=0x8f7a670, aContentStyle=0x9000e68, aParentFrame=0x8f4adf8, aScrolledPseudo=0x81810f0, aDocument=0x88148f0, aIsRoot=0, aNewFrame=@0xbfffe000, aScrolledChildStyle=@0xbfffdef8, aScrollableFrame=@0xbfffdf04) at nsCSSFrameConstructor.cpp:6208 #6 0x41373370 in nsCSSFrameConstructor::BuildScrollFrame (this=0x8879168, aPresShell=0x87819b0, aPresContext=0x86d2ec0, aState=@0xbfffe6c4, aContent=0x8f7a670, aContentStyle=0x9000e68, aScrolledFrame=0x8f4b58c, aParentFrame=0x8f4adf8, aNewFrame=@0xbfffe000, aScrolledContentStyle=@0xbfffe04c) at nsCSSFrameConstructor.cpp:6339 #7 0x41371d00 in nsCSSFrameConstructor::ConstructXULFrame (this=0x8879168, aPresShell=0x87819b0, aPresContext=0x86d2ec0, aState=@0xbfffe6c4, aContent=0x8f7a670, aParentFrame=0x8f4adf8, aTag=0x8183dd0, aNameSpaceID=6, aStyleContext=0x9000e68, aFrameItems=@0xbfffe398, aHaltProcessing=@0xbfffe0bc) at nsCSSFrameConstructor.cpp:5540 #8 0x41375508 in nsCSSFrameConstructor::ConstructFrameInternal (this=0x8879168, aPresShell=0x87819b0, aPresContext=0x86d2ec0, aState=@0xbfffe6c4, aContent=0x8f7a670, aParentFrame=0x8f4adf8, aTag=0x8183dd0, aNameSpaceID=6, aStyleContext=0x9000e68, aFrameItems=@0xbfffe398, aXBLBaseTag=0) at nsCSSFrameConstructor.cpp:7465 #9 0x41375217 in nsCSSFrameConstructor::ConstructFrame (this=0x8879168, aPresShell=0x87819b0, aPresContext=0x86d2ec0, aState=@0xbfffe6c4, aContent=0x8f7a670, aParentFrame=0x8f4adf8, aFrameItems=@0xbfffe398) at nsCSSFrameConstructor.cpp:7391 #10 0x41370b43 in nsCSSFrameConstructor::CreateAnonymousFrames (this=0x8879168, aPresShell=0x87819b0, aPresContext=0x86d2ec0, aTag=0x8183a88, aState=@0xbfffe6c4, aParent=0x8b55cd0, aNewFrame=0x8f4adf8, aChildItems=@0xbfffe398) at nsCSSFrameConstructor.cpp:5250 #11 0x41372e7d in nsCSSFrameConstructor::ConstructXULFrame (this=0x8879168, aPresShell=0x87819b0, aPresContext=0x86d2ec0, aState=@0xbfffe6c4, aContent=0x8b55cd0, aParentFrame=0x8cc8d90, aTag=0x8183a88, aNameSpaceID=6, aStyleContext=0x8f37fe8, aFrameItems=@0xbfffe6ac, aHaltProcessing=@0xbfffe47c) at nsCSSFrameConstructor.cpp:6119 #12 0x41375508 in nsCSSFrameConstructor::ConstructFrameInternal (this=0x8879168, aPresShell=0x87819b0, aPresContext=0x86d2ec0, aState=@0xbfffe6c4, aContent=0x8b55cd0, aParentFrame=0x8cc8d90, aTag=0x8183a88, aNameSpaceID=6, aStyleContext=0x8f37fe8, aFrameItems=@0xbfffe6ac, aXBLBaseTag=0) at nsCSSFrameConstructor.cpp:7465 #13 0x41375217 in nsCSSFrameConstructor::ConstructFrame (this=0x8879168, aPresShell=0x87819b0, aPresContext=0x86d2ec0, aState=@0xbfffe6c4, aContent=0x8b55cd0, aParentFrame=0x8cc8d90, aFrameItems=@0xbfffe6ac) at nsCSSFrameConstructor.cpp:7391 #14 0x41378c62 in nsCSSFrameConstructor::ContentInserted (this=0x8879168, aPresContext=0x86d2ec0, aContainer=0x8b55c50, aChild=0x8b55cd0, aIndexInContainer=0, aFrameState=0x8cc7998) at nsCSSFrameConstructor.cpp:8619 #15 0x4137fd70 in nsCSSFrameConstructor::RecreateFramesForContent (this=0x8879168, aPresContext=0x86d2ec0, aContent=0x8b55cd0) at nsCSSFrameConstructor.cpp:10877 #16 0x4137cd11 in nsCSSFrameConstructor::AttributeChanged (this=0x8879168, aPresContext=0x86d2ec0, aContent=0x8b55cd0, aNameSpaceID=0, aAttribute=0x8183ac0, aHint=2) at nsCSSFrameConstructor.cpp:9915 #17 0x414e3e01 in StyleSetImpl::AttributeChanged (this=0x89ae080, aPresContext=0x86d2ec0, aContent=0x8b55cd0, aNameSpaceID=0, aAttribute=0x8183ac0, aHint=-1) at nsStyleSet.cpp:1137 #18 0x41207015 in PresShell::AttributeChanged (this=0x87819b0, aDocument=0x88148f0, aContent=0x8b55cd0, aNameSpaceID=0, aAttribute=0x8183ac0, aHint=-1) at nsPresShell.cpp:3140 #19 0x40913850 in nsXULDocument::AttributeChanged (this=0x88148f0, aElement=0x8b55cd0, aNameSpaceID=0, aAttribute=0x8183ac0, aHint=-1) at nsXULDocument.cpp:1668 #20 0x408fa8a9 in nsXULElement::SetAttribute (this=0x8b55cd0, aNameSpaceID=0, aName=0x8183ac0, aValue=@0xbfffed70, aNotify=1) at nsXULElement.cpp:2923 #21 0x4146204a in nsPopupSetFrame::MarkAsGenerated (this=0x8cc8d90, aPopupContent=0x8b55cd0) at nsPopupSetFrame.cpp:520 #22 0x41461c78 in nsPopupSetFrame::CreatePopup (this=0x8cc8d90, aElementFrame=0x8f2d4cc, aPopupContent=0x8b55cd0, aXPos=39, aYPos=127, aPopupType=@0xbfffef68, anAnchorAlignment=@0xbfffef80, aPopupAlignment=@0xbfffef98) at nsPopupSetFrame.cpp:448 #23 0x41418884 in nsPopupSetBoxObject::CreatePopup (this=0x8fcd328, aSrcContent=0x8dd8604, aPopupContent=0x8b55cdc, aXPos=39, aYPos=127, aPopupType=0xbffff410, anAnchorAlignment=0xbffff26c, aPopupAlignment=0xbffff1d4) at nsPopupSetBoxObject.cpp:144 #24 0x409382a3 in XULPopupListenerImpl::LaunchPopup (this=0x8dd86e0, aClientX=39, aClientY=127) at nsXULPopupListener.cpp:552 #25 0x4093869f in XULPopupListenerImpl::sTooltipCallback (aTimer=0x8d329b8, aClosure=0x8dd86e0) at nsXULPopupListener.cpp:591 #26 0x41933955 in ?? () from /builds/seth/seamonkey/ns/dist/bin/components/libtimer_gtk.so #27 0x41933f0a in ?? () from /builds/seth/seamonkey/ns/dist/bin/components/libtimer_gtk.so #28 0x40c2a8a4 in ?? () from /usr/lib/libglib-1.2.so.0 #29 0x40c29a86 in ?? () from /usr/lib/libglib-1.2.so.0 #30 0x40c2a041 in ?? () from /usr/lib/libglib-1.2.so.0 #31 0x40c2a1e1 in ?? () from /usr/lib/libglib-1.2.so.0 #32 0x40b537a9 in ?? () from /usr/lib/libgtk-1.2.so.0 #33 0x40a62c0a in nsAppShell::Run (this=0x811af10) at nsAppShell.cpp:334 #34 0x4071cb44 in ?? () from /builds/seth/seamonkey/ns/dist/bin/components/libnsappshell.so #35 0x8053cd9 in main1 (argc=2, argv=0xbffff9f4, nativeApp=0x0) at nsAppRunner.cpp:906 #36 0x80543be in main (argc=2, argv=0xbffff9f4) at nsAppRunner.cpp:1092 #37 0x4056bcb3 in ?? () from /lib/libc.so.6
I've got a bullet proofing fix, that prevents the crash. =================================================================== RCS file: /cvsroot/mozilla/view/src/nsScrollPortView.cpp,v retrieving revision 3.15 diff -p -r3.15 nsScrollPortView.cpp *** nsScrollPortView.cpp 2000/05/16 11:35:00 3.15 --- nsScrollPortView.cpp 2000/06/15 20:45:21 *************** NS_IMETHODIMP nsScrollPortView::ScrollTo *** 249,254 **** --- 249,256 ---- // make sure the new position in in bounds GetScrolledView(scrolledView); + NS_ASSERTION(scrolledView, "no scrolled view"); + if (!scrolledView) return NS_ERROR_FAILURE; scrolledView->GetDimensions(&scrolledSize.width, &scrolledSize.height); nsSize portSize; I don't know what's going on.
I checked in the patch. now we just assert. since I can read mail, this is no longer a smoketest / dogfood bug. I'll go find a rightful owner for this bug.
Severity: blocker → critical
Keywords: dogfood, smoketest
Summary: Crashes when you try to open your inbox. → assert when you try to open your inbox
Whiteboard: [dogfood+]
re-assign to pinkerton. according to his message to the hook, pink is going to investigate thanks pink.
Assignee: sspitzer → pinkerton
Status: ASSIGNED → NEW
Summary: assert when you try to open your inbox → assert (used to crash) when you try to open your inbox
Just to confirm -- original crash happens with today's mac commercial m17 build. Macsbug report attached.
accepting, and nominating for beta2 i honestly have no clue what's going on here, or what changed. i didn't touch anything.
Status: NEW → ASSIGNED
Keywords: nsbeta2
i cannot reproduce this with my mac mozilla/debug build from 6/15/00 11am
cc'ing pollmann as I noticed he made a lot of changes to frame manager, scroll frames and other stuff that could be related to this crash.
this looks very much like pollmann's changes (it appears like it's trying to restore a scroll position, which doesn't exist in a tooltip). pushing to him.
Assignee: pinkerton → pollmann
Status: ASSIGNED → NEW
Thank you Seth for the fix! I'm glad that someone saw this because I was unable to reproduce it in my build. Since the crash fix is in, I am going to back out the backing out of my change I just did to compensate while a fix was worked on. thanks again!
As for a long-term fix, I'll look into this. The problem doesn't seem to be that we are trying to restore scroll position, but that we have a nsScrollPortFrame and an nsScrollPortView inside a tooltip (strange). And even if there is a good reason to have these, it's surely wrong to have them and not have a ScrollingView, which caused the crash. The fix Seth put in should take care of this very odd case. ScrollPort inside a tooltip? Downgrading to Major
Severity: critical → major
Status: NEW → ASSIGNED
Summary: assert (used to crash) when you try to open your inbox → assert opening inbox - scrollport inside a tooltip restoring state
Linux (2000-06-16-08 M17) when I start messenger using the -mail option, it crashes when I click on netscape using the POP or IMAP account. If I start browser, it hangs. Browser screen eventually got blank out. Here is the console message. This is a block to mail/news. Loading page specified via openDialog in SetSecurityButton WEBSHELL+ = 4 Document: Done (1.592 secs) *** check number of frames in content area Error loading URL http://home.netscape.com/browsers/redirect/6/start.html Document: Done (0.145 secs) Error loading URL http://home.netscape.com/browsers/6/su_setup.html Document: Done (2.284 secs) *** check number of frames in content area Document http://home.netscape.com/browsers/6/su_setup.html loaded successfully
I think this should be a blocker. I do not find any workaround for mailnews. Please advise.
Severity: major → blocker
fenella, what makes you think that you are running into this bug? everyone on the hook yesterday agreed that it was no longer the cause of any problems except for a harmless assert.
Is it possible this reopening is related to Judson's assertion fix? On Windows this morning I couldn't start up on my debug build because of what seemed like endless assertions. I don't know the result in release builds where assertions weren't getting called, but perhaps, it caused it to hang? Anyway, he checked in the fix at 9:38.
Fenella - Make sure you are not running into the bug with the start page. See bug: http://bugzilla.mozilla.org/show_bug.cgi?id=34871 . I mention this because your console display shows a link to the start page. If you open a new bug, pls downgrade the severity of this bug.
It seems running okay with Jud's fix on my linux commercial build. Fenella were running the build with Jud's fix in?
Please move the discussion to Bug 42686 which is listed as a smoketest blocker. While the symptom is the same as this regression from yesterday. Eric's crash is fixed. The problem fenella is seeing must be caused by something else. Let's use that bug to keep track of it so we don't get confused.
Ok, correcting the severity back to it's previous state.
Severity: blocker → major
> Please move the discussion to Bug 42686. Scott, this is bug 42686. So which bug you mentioned to move this discussion to? And Lisa, after I remove the default start page, I am still getting the same crash as Fenella, so this is not causing from the start page problem.....
sorry...please move the discussion to 42836 which is listed as the smoketest blocker today.
Putting on [nsbeta2+] radar for beta2 fix.
Whiteboard: [nsbeta2+]
Perhaps this is where the scroll frames/views are generated from? http://lxr.mozilla.org/seamonkey/source/xpfe/global/resources/skin/xulBindings.x ml#387 <binding id="popups"> <content> <xul:box class="popup-internal-box" orient="vertical" flex="1" style="overflow: auto"> <children/> </xul:box> </content> </binding>
Should this be: style="overflow: hidden"?
probably. i've seen bugs with tooltips getting scrollarrows (!!), so maybe this is the culprit. try it and see. eric, can you email ben goodger about this? (his name is on the blame for those lines in xulBindings and he won't notice if you just cc him on the bug)
Thanks Mike, I just sent out an email.
Per the email: overflow:auto was actually added by Eric Vaughan (rev 1.39). This was added for the case of menus that have more items that can be displayed. This automatically adds a scrollbar, which allows the additional items to be selected. Should the menu definition be split from the tooltip definition for this reason?
I am so Not a XUL guru. :) In addition to the definition in xpfe/global/resources/skin, there is a very similar *looking* definition here: http://lxr.mozilla.org/seamonkey/source/xpfe/global/resources/content/xulBinding s.xml#302 I don't know how these work - which behaviour definition is used, the one in skin or content - or both? Regardless, there are two lines in xml.css that seem to refer to the "popups" behaviour. One is "menupopup" and the other is "popup": http://lxr.mozilla.org/seamonkey/source/xpfe/global/resources/skin/xul.css#181 Would divine fortune be such that one of these (popup) could be tooltips and the other (menupopup) XUL menus and context menus? If that's the case, would it be possible to just create an additional behaviour for tooltips that is the same as menu popups except for scrolling: auto not being there? I've not played with any of this stuff, so if I'm spouting utter nonsense, would someone with XUL clue be able to help me out? :)
sounds reasonable.
You can't make assumptions about what the popup is being used for, since the same popup can be reused, i.e., the same popup could be used as a tooltip or as a context menu. There's no way to tell that a given <popup> is being used as a tooltip. Moreover, there's no reason why a tooltip shouldn't properly overflow if it doesn't fit on screen (it would be weird, sure, but it should work). So yes, it's normal and expected that the scroll frames are in a tooltip.
Okay, then, with popups definitely needing scrollbars, the problem seems to be - why was a scroll port view generated with no corresponding scroll view in this one case? (I've not yet been able to reproduce the assert.)
No idea. :) We really don't need tooltips to scroll, since it really is kind of nonsensical, but there's no way to know that a popup is a tooltip popup.
Since this bug does not cause any crashes or behavioral problems, I don't think this is serious enough to hold nsbeta2 for.
Whiteboard: [nsbeta2+]
Putting on [nsbeta2-] radar. Not critical to beta2.
Whiteboard: [nsbeta2-]
remove [nsbeta2-] from status whiteboard for reconsideration. add dogfood keyword With today's debug build on Mac, the browser is nearly impossible to use since every mouse over a link brings up a tooltip which asserts.
Keywords: dogfood
OS: Linux → All
Hardware: PC → All
Whiteboard: [nsbeta2-]
i see the assert, but not as much as kathy does. i feel dirty saying this, but the assert appears harmless and shipping bits will not see the assert...so would we pull off the wire for this? man i feel so dirty.
Kathy, I didn't realize that this bug was so reproducible on Mac - my impression from the above was that it was only occurring on Linux the first few times a profile was used to view mail. We could comment out the assert to make developers lives easier for now. Would that help?
If the assert is actually harmless (as pinkerton or others seem to believe), then we should just remove the assert and resolve this bug as "fixed." If we don't fix this (remove the assertion), then I won't be able to use the browser for dogfood.
This bug is a dogfood stopper for internal developers. The fix will have no impact at all on the shipped bits as it is simply commenting out an assert. PDT - hope this gets dogfood+ so we can get everyone using the build internally. :)
Putting on [NEED INFO] radar. Who put in the assert? Why is it there? Making [dogfood+] and [nsbeta2-] for now.
Whiteboard: [NEED INFO][dogfood+][nsbeta2-]
> Putting on [NEED INFO] radar. Who put in the assert? Why is it there? > Making [dogfood+] and [nsbeta2-] for now. I'm confused, I thought dogfood+ was higher priority than nsbeta2+ and implied approval to checkin. The nsbeta2- implies otherwise. Should I check in the fix? The assert was put in by Seth Spitzer. It was added as a placeholder because he put in a crash fix for a checkin of mine a month ago. The assert flags an illegal condition (scroll port view with no scroll view). The problem underlying the assert is not yet known - I am looking into it. However, our handling of the error (in this case, stop the operation early) is fine. In the meantime, the assert is preventing developers from doing day-to-day work in the browser. The fix is simply to remove the assert. It will not change our handling of the error (stop early) and will enable developers to use the browser. I will continue to look into the problem after the assert is removed.
Whiteboard: [NEED INFO][dogfood+][nsbeta2-] → [NEED INFO][dogfood+]
you could always change it to NS_WARNING then it won't stop in the debugger...
PDT made it dogfood+ because it stops developers from working, but since the asserts will not impact users of pr2, we also made it nsbeta2-. So if you can get rid of the assert great, but if it isn't fixed soon, we aren't going to pull pr2 off the wire. So making [nsbeta2+]to avoid further confusion.
Whiteboard: [NEED INFO][dogfood+] → [dogfood+][nsbeta2+]
Whiteboard: [dogfood+][nsbeta2+] → [dogfood+][nsbeta2+] fix in hand 7/19
I have enclosed this assertion inside #ifdef DEBUG_pollmann. Closing out the bug as that fixes the assertion problem. I will open up a new bug to investigate the problem underlying the assertion. There is no way to verify this fix in an optimized daily build, but if anyone seeing the problem in their debug build would be kind enough to verify the fix, I'd be much obliged. :)
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
New bug to investigate the underlying problem is 45954. Please add yourself to this bug if you are interested in following it. Thanks!
verifying fix
Status: RESOLVED → VERIFIED
Linux (2000-07-19-08 M17) Win32 (2000-07-19-11 M17) Mac (2000-07-19-12 M17) This problem has been fixed.
QA Contact: lchiang → fenella
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: