Closed Bug 88120 Opened 24 years ago Closed 23 years ago

Crash in frame code trying to book rental car via www.travel.com

Categories

(Core :: XUL, defect)

Product:
Core
Component:
XUL
Type:
defect
Priority:
Not set
Severity:
blocker

Tracking

()

Status:
VERIFIED DUPLICATE of bug 89626
Milestone:
mozilla0.9.4

People

(Reporter: pmac, Assigned: saari)

References

(
URL
)

Details

(Keywords: crash, regression, relnote) 

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) 

-----------------------
Keywords: crash
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
Severity: normal → critical
crashed once on my win box...0627 trunk...
->layout.
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
Target Milestone: mozilla0.9.2 → mozilla0.9.4
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.
Keywords: regression, relnote
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
Verified dupe.
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.