Closed Bug 88120 Opened 23 years ago Closed 23 years ago
Crash in frame code trying to book rental car via www
Crashes on all platforms. See the details below here. Lisa, I think this bug is a showstopper bug. Mac G3 laptop; OS: 9.1 (branch build: 2001-06-27-03-0.9.2) 1. Launch the browser. (It crashes in both modern and classic themes). 2. However, it crashes more in classic theme than modern theme. (assuming it's in the classic theme). 3. Type this url: http://www.travel.com 4. Notice that the "Transportation" on your left, click on the "rental cars". 5. Click on "TravelNow" on your right. 6. Click on "San Jose". 7. You would see "what kind of cars"? Under that section, click on "all available" under "Classes" section. And then click on "Search available cars". 8. It lists all kind of car, just click on the first one that saying "Book it". Note: In classic theme, it crashes immediately and sometimes it hangs there. In modern theme, it sometimes does not crash immediately, therefore, click on "back" button, and then click on "Search available cars" again, and then it crashes. Below here is the talkback report for Mac G3 laptop: Incident ID 32254362 Stack Signature 0x4ac40014 41283a62 Bug ID Trigger Time 2001-06-27 15:16:09 User Comments crash on modern theme (mac laptop G3: branch build:2001-06-27-03-0.9.2). Build ID 2001062703 Product ID Netscape6.10 Platform ID MacOS Stack Trace 0x4ac40014 ViewportFrame::Destroy() [nsViewportFrame.cpp, line 141] FrameManager::Destroy() [nsFrameManager.cpp, line 456] PresShell::~PresShell() [nsPresShell.cpp, line 1490] PresShell::Release() [nsPresShell.cpp, line 1374] nsCOMPtr_base::~nsCOMPtr_base() [nsCOMPtr.cpp, line 49] GlobalWindowImpl::Focus() [nsGlobalWindow.cpp, line 1769] nsEventStateManager::PreHandleEvent() [nsEventStateManager.cpp, line 592] ----------------------- Crashes on windows 98: (branch build: 2001-06-27-06-0.9.2) Follow the steps above how to reproduce it. Below here is the talkback report on windows 98: Incident ID 32254200 Stack Signature 0x63697026 088e497d Bug ID Trigger Time 2001-06-27 15:12:16 User Comments crashes on windows 98 , modern theme. (branch build: 2001-06-27-06-0.9.2). Build ID 2001062706 Product ID Netscape6.10 Platform ID Win32 Stack Trace 0x63697026 nsContainerFrame::Destroy [d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp, line 116] nsBoxFrame::Destroy [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBoxFrame.cpp, line 1009] nsFrameList::DestroyFrames [d:\builds\seamonkey\mozilla\layout\base\src\nsFrameList.cpp, line 116] nsContainerFrame::Destroy [d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp, line 119] nsBoxFrame::Destroy [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBoxFrame.cpp, line 1009] nsGfxScrollFrame::Destroy [d:\builds\seamonkey\mozilla\layout\html\base\src\nsGfxScrollFrame.cpp, line 446] nsFrameList::DestroyFrames [d:\builds\seamonkey\mozilla\layout\base\src\nsFrameList.cpp, line 116] nsContainerFrame::Destroy [d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp, line 119] ViewportFrame::Destroy [d:\builds\seamonkey\mozilla\layout\html\base\src\nsViewportFrame.cpp, line 142] FrameManager::Destroy [d:\builds\seamonkey\mozilla\layout\html\base\src\nsFrameManager.cpp, line 457] PresShell::~PresShell [d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 1491] PresShell::`scalar deleting destructor' nsTextInputListener::Release [d:\builds\seamonkey\mozilla\layout\html\forms\src\nsGfxTextControlFrame2.cpp, line 235] nsCOMPtr_base::~nsCOMPtr_base [d:\builds\seamonkey\mozilla\xpcom\base\nsCOMPtr.cpp, line 50] nsEventStateManager::PreHandleEvent [d:\builds\seamonkey\mozilla\content\events\src\nsEventStateManager.cpp, line 594] nsEventStateManager::PreHandleEvent [d:\builds\seamonkey\mozilla\content\events\src\nsEventStateManager.cpp, line 594] PresShell::HandleEventInternal [d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 5560] PresShell::HandleEvent [d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 5492] nsView::HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 377] nsViewManager::DispatchEvent [d:\builds\seamonkey\mozilla\view\src\nsViewManager.cpp, line 2051] HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 68] nsWindow::DispatchEvent [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 724] nsWindow::DispatchWindowEvent [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 741] nsWindow::DispatchFocus [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 4426] nsWindow::ProcessMessage [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 3345] nsWindow::WindowProc [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 989] KERNEL32.DLL + 0x363b (0xbff7363b) KERNEL32.DLL + 0x24407 (0xbff94407) ---------------------------------- Crashes on Linux(rehat 6.2): (branch build: 2001-06-27-04-0.9.2) Follow the steps above how to reproduce it. Below here is the talkback report on Linux: Incident ID 32253971 Stack Signature 0x00000050 07b2af84 Bug ID Trigger Time 2001-06-27 15:05:51 User Comments crashes on linux (branch build: 2001-06-27-04-0.9.2) Build ID 2001062706 Product ID Netscape6.10 Platform ID LinuxIntel Stack Trace 0x00000050 PresShell::Release() nsCOMPtr_base::~nsCOMPtr_base() GlobalWindowImpl::Focus() nsEventStateManager::PreHandleEvent() PresShell::HandleEventInternal() PresShell::HandleEvent() nsView::HandleEvent() nsViewManager::DispatchEvent() HandleEvent() nsWidget::DispatchEvent() nsWidget::DispatchWindowEvent() nsWidget::DispatchFocus() nsWindow::DispatchActivateEvent() nsWindow::SetFocus() GlobalWindowImpl::Focus() nsWebShellWindow::HandleEvent() nsWidget::DispatchEvent() nsWidget::DispatchWindowEvent() nsWidget::DispatchFocus() nsWindow::DispatchSetFocusEvent() nsWindow::HandleMozAreaFocusIn() handle_mozarea_focus_in() libgtk-1.2.so.0 + 0x8dac9 (0x4026dac9) libgtk-1.2.so.0 + 0xbb5fd (0x4029b5fd) libgtk-1.2.so.0 + 0xbaa42 (0x4029aa42) libgtk-1.2.so.0 + 0xb8b95 (0x40298b95) libgtk-1.2.so.0 + 0xeda3c (0x402cda3c) libgtk-1.2.so.0 + 0xf55ce (0x402d55ce) libgtk-1.2.so.0 + 0x8dac9 (0x4026dac9) libgtk-1.2.so.0 + 0xbaa7b (0x4029aa7b) libgtk-1.2.so.0 + 0xb8b95 (0x40298b95) libgtk-1.2.so.0 + 0xeda3c (0x402cda3c) libgtk-1.2.so.0 + 0x8cd1a (0x4026cd1a) handle_gdk_event() libgdk-1.2.so.0 + 0x174db (0x403184db) libglib-1.2.so.0 + 0x10186 (0x40348186) libglib-1.2.so.0 + 0x10751 (0x40348751) libglib-1.2.so.0 + 0x108f1 (0x403488f1) libgtk-1.2.so.0 + 0x8c5b9 (0x4026c5b9) nsAppShell::Run() nsAppShellService::Run() main1() main() libc.so.6 + 0x189cb (0x404419cb) -----------------------
Summary: The browser crashes on all platforms for Modern & Classic themes → The browser crashes on all platforms for Modern & Classic themes
I've verified on netscape 4.x, it did not crash but very slow to load the page.
I tried it on linux 2001062608 with the modern theme 5 times and it always worked
crashed once on my win box...0627 trunk...
Assignee: asa → karnaze
Component: Browser-General → Layout
QA Contact: doronr → petersen
pmac - do you mean that the browser crashes only when you go to that URL and perform the action in your steps right? It doesn't crash just launching with particular theme, I assume, or we'd be in big trouble :-)
Lisa, Yes, the browser crashes only when go to that URL and perform the action in my steps. I can reproduce in all platforms.
Summary: The browser crashes on all platforms for Modern & Classic themes → Crash in frame code trying to book rental car via www.travel.com
Reassigning to alexsavulov for analysis/triage.
Assignee: karnaze → alexsavulov
I can't reproduce, 2001071903 win2k moz branch.
*** Bug 88613 has been marked as a duplicate of this bug. ***
The crash is only reproductible when I build with PSM/SSL support (need to set the environment variable BUILD_PSM2=1). Does not look like a layout bug for me yet. Here is a stack of the crash: PresShell::~PresShell() line 1477 + 15 bytes PresShell::`scalar deleting destructor'() + 15 bytes PresShell::Release(PresShell * const 0x03933eb8) line 1374 + 158 bytes nsCOMPtr<nsIPresShell>::~nsCOMPtr<nsIPresShell>() line 490 GlobalWindowImpl::Focus(GlobalWindowImpl * const 0x0440fc7c) line 1782 + 14 bytes nsEventStateManager::PreHandleEvent(nsEventStateManager * const 0x03412010, nsIPresContext * 0x02916bc8, nsEvent * 0x0012cd18, nsIFrame * 0x035c43b8, nsEventStatus * 0x0012cc80, nsIView * 0x029167b8) line 594 PresShell::HandleEventInternal(nsEvent * 0x0012cd18, nsIView * 0x029167b8, unsigned int 1, nsEventStatus * 0x0012cc80) line 5558 + 43 bytes PresShell::HandleEvent(PresShell * const 0x027a3b8c, nsIView * 0x029167b8, nsGUIEvent * 0x0012cd18, nsEventStatus * 0x0012cc80, int 1, int & 1) line 5491 + 25 bytes nsView::HandleEvent(nsView * const 0x029167b8, nsGUIEvent * 0x0012cd18, unsigned int 28, nsEventStatus * 0x0012cc80, int 1, int & 1) line 377 nsViewManager::DispatchEvent(nsViewManager * const 0x027a5a68, nsGUIEvent * 0x0012cd18, nsEventStatus * 0x0012cc80) line 2056 HandleEvent(nsGUIEvent * 0x0012cd18) line 68 nsWindow::DispatchEvent(nsWindow * const 0x02916864, nsGUIEvent * 0x0012cd18, nsEventStatus & nsEventStatus_eIgnore) line 720 + 10 bytes nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012cd18) line 741 nsWindow::DispatchFocus(unsigned int 107, int 1) line 4428 + 15 bytes nsWindow::ProcessMessage(unsigned int 7, unsigned int 525570, long 0, long * 0x0012d120) line 3343 + 23 bytes nsWindow::WindowProc(HWND__ * 0x053004f8, unsigned int 7, unsigned int 525570, long 0) line 988 + 27 bytes USER32! 77e148dc() USER32! 77e163fb() USER32! 77e1643d() NTDLL! 77f9f04b() GlobalWindowImpl::Focus(GlobalWindowImpl * const 0x00def65c) line 1772 + 25 bytes nsWebShellWindow::HandleEvent(nsGUIEvent * 0x0012d38c) line 530 nsWindow::DispatchEvent(nsWindow * const 0x0280854c, nsGUIEvent * 0x0012d38c, nsEventStatus & nsEventStatus_eIgnore) line 720 + 10 bytes nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012d38c) line 741 nsWindow::DispatchFocus(unsigned int 105, int 1) line 4428 + 15 bytes nsWindow::ProcessMessage(unsigned int 7, unsigned int 395020, long 0, long * 0x0012d794) line 3340 + 23 bytes nsWindow::WindowProc(HWND__ * 0x00080502, unsigned int 7, unsigned int 395020, long 0) line 988 + 27 bytes USER32! 77e148dc() USER32! 77e163fb() USER32! 77e1643d() NTDLL! 77f9f04b() USER32! 77e15b59() USER32! 77e148dc() USER32! 77e17ef9() USER32! 77e17f75() nsWindow::WindowProc(HWND__ * 0x00080502, unsigned int 6, unsigned int 1, long 395022) line 995 + 31 bytes USER32! 77e148dc() USER32! 77e163fb() USER32! 77e1643d() NTDLL! 77f9f04b() nsXULWindow::Destroy(nsXULWindow * const 0x04713734) line 363 nsWebShellWindow::Destroy(nsWebShellWindow * const 0x04713734) line 1743 + 9 bytes nsChromeTreeOwner::Destroy(nsChromeTreeOwner * const 0x03a0701c) line 228 GlobalWindowImpl::ReallyCloseWindow(GlobalWindowImpl * const 0x04592ab4) line 2395 .....
I can repro easily with branch build from 07-23. You need to have the SSL security warning dialogs on, and it looks like the problem is in the destruction of that warning dialog...
it is the warning dialog. I cuted the stack to short but this is happening in a call to nsXULWindow::Destroy(... that's called within a nsXULWindow::ShowModal(...
Severity: critical → blocker
Component: Layout → XP Toolkit/Widgets: XUL
Target Milestone: --- → mozilla0.9.2
reassigning to XPToolkit/Widgets XUL
Assignee: alexsavulov → trudelle
QA Contact: petersen → jrgm
I think that this bug may affect a lot of sites that use SSL, HTTPS and so on...
CC'ing Stephane Saux I *think* this is an interaction with this web page doing some not-so-common focus munging, but that needs to be verified.
Assignee: trudelle → saari
I get this crash logging into my bank account on www.sdccu.com too. (I think you can get it with a bogus account number as well). If I go to https://www.sdccu.com first (forcing SSL on the login page) then I can get into the account fine - the problem only happens when I get the Secure Website dialog after pressing the sign-in button.
I created a new profile, and all of the security warning dialogs (Edit | Preferences | Privacy and Security | SSL) are enabled by default. I was able to reproduce this crash on both 98 and NT for www.travel.com. I also reproduced the crash on https://www.sdccu.com using Win98. (I had crashed enough at this point, so I didn't try on NT!)
I was able to successfully log into Schwab and Vanguard using 2001-07-24-06 commercial branch, and I did pass through security dialogs as I logged in and out.
I can reproduce the crash at travelnow, although I have not crashed on that site a couple of times. Otherwise, I could fail to login to attinasi's bank account :-) without crashing, and succeed at my own account (BofA) without crashing. I don't know if it's relevant, but the warning on travelnow is not just for SSL, but that they are using low-grade encryption.
If I turn off *only* the "Low Grade Encryption" warning in prefs (Edit | Preferences | Privacy and Security | SSL - "Entering a site that uses low-grade encryption"), I am unable to reproduce the crash.
I did a trunk commercial debug build last night (12-1am ish) and I don't seem to be able to reproduce this now. Can anyone confirm that?
I just confirmed with the nightlys, this does *not* crash on the trunk.
saari: Have you built with BUILD_PSM2=1? If not, the effect is that nothing happen. No new page is loaded, just like clicking on air. (just a reminder)
Can anyone else confirm with 2001-07-25 commercial branch that turning off the "Low Grade Encryption" warning dialog prevents the crash? Thank you.
Turning off the "Low Grade Encryption" warning dialog ahead of time prevents the crash. Tested on WinNT - 7/25 branch build.
Yes, turning off the warning prevents the crash. It fixes it for the crash on travel.com and sdccu.com (they are different dialogs, but I think it is just the fact that the dialog is coming up that is the problem - maybe). On the www.sdccu.com site, I entered the account number 140000000 and password 9999, press the GO button and I see the warning dialog about going to a secure site, then it crashes. note: that is my fake account number ;)
On travel.com If the security dialogs aren't enabled, I don't get the crash. However, I was able to reproduce the crash using yesterday's branch build on Win98 with *only* the "Entering a site that uses low grade encryption" checked. Here's the invocation to SSL: <form action="https://www.travelnow.com/itinerary/reserve.jsp" method="GET" name="frm_search" target="_top"> As you can see, the JSP (Java Server Page) is given a long name-value pair since the method is "GET" and it resides on a secure server. The "Book It" buttons each submit the form with distinct name-value pairs. This, IMHO, doesn't necessarily constitute "funny page construction" although I'm not a big fan of the tool generated markup (SoftQuad Software? Look at the doctype in www.travel.com). If someone can explain what's unusual with the page construction, this would clue me in! Otherwise, it appears that the XUL based security dialog(s) don't jive with the form post to a secure back end.
sorry, i meant form "get" not form "post." :-/
yes, I have both branch and trunk builds with PSM turned on, and it is only crashing on the branch. My first guess would be to look for changes in that dialog's XUL on the trunk but not on the branch, but I haven't investigated further yet.
I can crash using pmac's original steps to reproduce, using the 7/25 _branch_ builds, and the 7/22, 7/23, 7/24 _trunk_ builds (commercial, win2k). However, I cannot crash using the 7/25 _trunk_ build. That dialog is commonDialog.xul|js, but the only change in the past month on the trunk is Jul 09, to convert <box> into <hbox>, <box orient="vertical> into <vbox>, but that's relatively innocuous, and the changes were correct (i.e., no changes in orientation direction).
Just in case anyone is thinking of turning "off" the "Entering a site that uses low grade encryption" warning... I don't think that's a viable solution to this problem. Philosophically, it is better to crash in rare cases where this happens than to give users a false sense of security. If we can't fix the root cause, then let's ship with the crash rather than disable the warnings.
Uh, I don't agree Mitch. Crashing is not acceptable, and the warning is of "low" encryption, which is new to 6.1. All previous versions kept quiet. If you really don't want a false sense of security, list the algorithm and the key length and educate users, but of course we're getting off into the weeds real fast. Don't crash, no matter what. jrgm, cool, I'll see if I can hunt down why it doesn't crash in the 25th's build but does in the 24th's. However, I doubt it is going in 6.1 no matter what the fix is, especially with just switching off the pref as an alternative.
> Don't crash, no matter what. If this is the case, we have a lot of crashers that happen in equally rare circumstances that we can pursue without disabling a security feature. Let's spend our time on those. We cannot disable security features. The Press will attack you for turning off a security feature, but will never notice that you crash on a rare web site. Take the crash and fix it in the fall release with a real fix, dont' disable a feature in the current product.
Adding relnote keyword. This release note wording (added to relnote bug 90577) should cover bug 92291 and bug 88120. Under rare circumstances, Netscape 6.1 may crash if certain security warnings are turned on. These preferences are found under Edit, Preferences, Privacy and Security, SSL. Turning off the "Entering a site that supports encryption" and "Entering a site that uses low-grade encryption" warnings ahead of time is a workaround to preventing a crash.
I completely agree with Mitch. It's a rare crash. Let's not ship without the security warning. Release note it and find the real fix for the fall release.
cc'ing dbaron, who made some changes that may have affected this on the 24th.
*** This bug has been marked as a duplicate of 89626 ***
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
Status: RESOLVED → VERIFIED
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: jrgmorrison → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.