302536 - crash [@ nsEventStateManager::UpdateCursor ] when visiting and/or printing a page on www.vdab.be

Status: VERIFIED FIXED

(Core :: DOM: UI Events & Focus Handling, defect, P1)

Description

[Benoît]

User-Agent:       Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.8b4) Gecko/20050727 SeaMonkey/1.0a
Build Identifier: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.8b4) Gecko/20050727 SeaMonkey/1.0a

Every day my dad would go to www.vdab.be to look for job offers. Almost every
day  SeaMonkey would crash during his visit. The visit is such a routine that he
doesn't know what he did prior to the crash. Today I noticed it crashing when
printing a page on the site. I could reproduce it. Printing Google works fine,
though. Yet when I was initially typing this bug report, SeaMonkey also crashed
by having the site in a tab.

I've included TalkBack IDs. There are a lot of them.

Reproducible: Always

Steps to Reproduce:
1. Go to http://www.vdab.be/
2. Click "Werk Zoeken"
3. Choose selections from the pulldown menus
4. Click "Zoeken"
5. Click "Toon Jobs"
6. Click on one of the offers
7. Print the page

Actual Results:  
SeaMonkey will crash a few seconds after sending the commands to the printer driver.

Expected Results:  
Not have crashed.

TB7353636Z
TB7426469Y
TB7503541E
TB7812815M
TB7885445H
TB7886042W
TB7889075K
TB7889605X

Comment 1

[OstGote!]

Stack Signature	 nsEventStateManager::UpdateCursor fc813fd9
Product ID	MozillaTrunk
Build ID	2005072705
Trigger Time	2005-07-28 08:55:52.0
Platform	Win32
Operating System	Windows 95 4.0 build 67306684
Module	GKLAYOUT.DLL + (00111f87)
URL visited	local page
User Comments	Printing.
Since Last Crash	1341 sec
Total Uptime	37173 sec
Trigger Reason	Invalid operation
Source File, Line No.
c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/content/events/src/nsEventStateManager.cpp,
line 2376
Stack Trace 	
nsEventStateManager::UpdateCursor 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/content/events/src/nsEventStateManager.cpp,
line 2376]
nsEventStateManager::PreHandleEvent 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/content/events/src/nsEventStateManager.cpp,
line 487]
PresShell::HandleEventInternal 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/base/nsPresShell.cpp,
line 6354]
PresShell::HandleEvent 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/base/nsPresShell.cpp,
line 6193]
nsViewManager::HandleEvent 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/view/src/nsViewManager.cpp,
line 2549]
nsViewManager::DispatchEvent 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/view/src/nsViewManager.cpp,
line 2236]
HandleEvent 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/view/src/nsView.cpp,
line 174]
nsWindow::DispatchEvent 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsWindow.cpp,
line 1241]
nsWindow::DispatchMouseEvent 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsWindow.cpp,
line 5930]
ChildWindow::DispatchMouseEvent 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsWindow.cpp,
line 6181]
nsWindow::WindowProc 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsWindow.cpp,
line 1418]
KERNEL32.DLL + 0x35d9 (0xbff735d9)
KERNEL32.DLL + 0x2222f (0xbff9222f)
0x00638bec

Comment 2

[Benoît]

> URL visited	local page
> User Comments	Printing.

Please pay no heed to the URL. It was a left-over from a previous crash that I
forgot to remove.

Comment 3

[Christian :Biesinger (don't email me, ping me on IRC)]

-> me for now

Comment 4

[Christian :Biesinger (don't email me, ping me on IRC)]

is this a regression?

Comment 5

[Benoît]

It very well may be. My dad has been visiting that site for years, doing the
same things.

Comment 6

[Christian :Biesinger (don't email me, ping me on IRC)]

hmm, I don't crash... (winxp)

Comment 7

[Benoît]

SeaMonkey can still be faithfully crashed by printing a job offer on that site.
Got a crash because of that today.

TB8362878M

Comment 8

[Christian :Biesinger (don't email me, ping me on IRC)]

that points to the line:
2413 dbaron          1.582     SetCursor(cursor, container, haveHotspot,
hotspotX, hotspotY,

2414                                     aTargetFrame->GetWindow(), PR_FALSE);

Is it possible that a bad target frame pointer is passed to this function? (but
non-null, that's checked in the line above)

Comment 9

[Benoît]

TB8515736E

Comment 10

[Christian :Biesinger (don't email me, ping me on IRC)]

I don't crash here on winxp. maybe 9x specific :-/

I do get this assertion twice:
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/layout/tables/nsTableRowGroupFrame.cpp&rev=3.345&cvsroot=/cvsroot&mark=1042-1043#1040

Comment 11

[Christian :Biesinger (don't email me, ping me on IRC)]

I'm told 1.7.x doesn't crash

Comment 12

[Benoît]

Regression window:

2005063006 - works
2005070106 - broken

The IDs come from the directories I downloaded the builds from. The ID of the
actual build may vary by one hour.

Comment 13

[Christian :Biesinger (don't email me, ping me on IRC)]

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2005-06-30+05%3A00&maxdate=2005-07-01+06%3A00&cvsroot=%2Fcvsroot

I suppose bug 286303 is most likely in that range...

Comment 14

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Worksforme on Linux.

Comment 15

[Hermann Schwab]

crash Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20051012 SeaMonkey/1.1a

Talkback ID: TB10739762H

Followed steps to repeat, but did a Print Preview instead of printing.
Crashed after about five or ten seconds, just when I was thinking it is wfm :-( 

Comment 16

[Hermann Schwab]

crash Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20051012 SeaMonkey/1.1a
TB10741698M, TB10739762H

Steps to reproduce:
1. Go to http://www.vdab.be/
2. Click "Werk Zoeken"
3. Choose selections from the pulldown menus
   I selected the first entry of the first three puldown menus.
   Beroep:Bedienden
   Regio:Vlaanderen
   Diploma:Leercontract+2de grad ...

4. Click "Zoeken"
5. Click "Toon Jobs"
6. Click on one of the offers

I clicked the first offer:
http://www.vdab.be/mijnvdab/jobs/wz/jobs.jsp?ID=1384110&sess=2&action=DETAIL

7. Click File->PrintPreview

Print Preview opens, doesn't crash as long as you don't move the mouse.
There is a navigation menu with vdab Logo in the top region of the print
preview. When you hover over this menu, Seamonkey crashes.

8. Move mouse to navigation menu in the top of the page: crash

Comment 17

[Hermann Schwab]

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20051012 SeaMonkey/1.1a
TB10842033H, TB10841970W, TB10841921Z

Simple steps to reproduce:
1. load http://www.vdab.be/
2. Print Preview
3. hover over the Welkom.....VDAB heading 

Comment 18

[Hermann Schwab]

Attachment: reduced testcase

produced TB10842945X

Steps to repeat:
1. load testcase, JS enabled
2. Print-Preview
3. hover
4. if not crashing on hover, close PrintPreview

Comment 19

[Hermann Schwab]

Attachment: minimal testcase

there is a map on the banner, it crashes in Print Preview if you hover over the
unspecified areas. In the original file there are areas specified on the tabs,
you can hover over the areas, you crash when you hover over a region in the
image not specified by an <area>.

Comment 20

[Hermann Schwab]

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20051016 Firefox/1.6a1
TB10844637Y crash on URL or testcase?
TB10846011M crash on hovering minimal testcase in Print Preview
TB10846220G crash on hovering after PrintPreview

Steps to reproduce:
1. Load testcase Attachment 200070 [details]
2. open PrintPreview
3. close PrintPreview
4. hover over banner

Comment 21

[Hermann Schwab]

Attachment: reduced testcase

reduced testcase made from original URL.
Load, open&close PrintPreview, then hover over the tabs, i.e. <area>s, no
crash.
You crash when leaving the area and entering the image.

Comment 22

[Hermann Schwab]

Attachment: minimal testcase

<html><head><TITLE>302536</TITLE></head>
<body bgcolor="#ffffff">
<img src="https://bugzilla.mozilla.org/mozilla-banner.gif" alt=""
usemap="#mainmenu" border="0" height="60" width="630">
<map name="mainmenu"></map>
</body></html>

After Print or Preview hover over the banner and watch your favourite Gecko
crashing.

Comment 23

[Hermann Schwab]

WFM Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20051028 SeaMonkey/1.1a

Print Preview both testcases and URL

Comment 24

[Benoît]

Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.8) Gecko/20051030 SeaMonkey/1.0b

Still crashes on the branch.

Comment 25

[Hermann Schwab]

wfm Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8) Gecko/20051030 SeaMonkey/1.0b
tested on testcases and URL, Print Preview only
Win98SE, BuildID: 2005103012

Comment 26

[Benoît]

That's odd. I'm using the same branch build with the same build hour.
Crashed on both testcases.

Tested a latest-trunk build that happens to be of the same day. Crashed on the minimal testcase: TB11326174X

Comment 27

[Benoît]

Crash on latest Firefox branch build: TB13571401.
Only on reduced testcase.

Requesting blocking1.8.0.1 because
-crash bug
-affects Firefox and SeaMonkey

Standard8 thought this might be helpful:
http://talkback-public.mozilla.org/talkback/fastfind.jsp?
search=1&searchby=stacksig&match=contains
&searchfor=+nsEventStateManager%3A%3AUpdateCursor&vendor=MozillaOrg
&product=All&platform=All&buildid=&sdate=&stime=&edate=&etime=&sortby=bbid

Comment 28

[Daniel Veditz [:dveditz]]

Need a trunk-tested patch before we would take for the branch. If you get that you can request branch approval for the patch.

Comment 29

[Christian :Biesinger (don't email me, ping me on IRC)]

sounds like this is a floating point exception during an fstp instruction, not happening in debug builds. -> default owner

Comment 30

[Christian :Biesinger (don't email me, ping me on IRC)]

I am unable to reproduce this on a german win95b with a canon bj10e printer driver, on neither the "reduced testcase" nor the "minimal testcase". (the system configuration was a freshly installed windows 95 "with usb support", with installed vmware tools, and the mentioned printer driver).

I used SeaMonkey 1.0.

my steps to reproduce were:

- load the testcase
- hover over the banner a bit
- file|print preview
- again, hover over the banner
- click the "Close" button
- hover again over the banner

no crash.

Comment 31

[Benoît]

Did you use both debug and regular builds?

I thought of something odd: could it be related to my resolution, 640x480?

Comment 32

[Christian :Biesinger (don't email me, ping me on IRC)]

only regular builds (the official release)

hm... not impossible... what bit depth are you using?

Comment 33

[Benoît]

Regular builds? Okay then. Because as you know, debug builds didn't crash on me.

I use 24-bit colours.

Comment 34

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

It would be quite useful to have the registers for a talkback incident for this crash.  (Even the registers from one of the crash dialogs would be useful, assuming I can download the build in question afterwards.)

Or does somebody already know on which instruction it's crashing?  comment 29 suggests biesi does.

Comment 35

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: detailed analysis of TB17628451, a Windos 1.5.0.2 incident

Comment 36

[Hermann Schwab]

Attachment: TB17628451.html with working links

TB17628451 as html with bugzilla queries and bonsai links in case the talkback server is done or the record deleted like the rest of the records in this bug.

Comment 37

[Benoît]

Attachment: ZIP file of the data files that are parts of the talkback

Apparantly TalkBack requires IE, so I couldn't send my talkback to the server. That's why the ZIP file. This talkback is of the latest Firefox 1.5 from the 1.8.0 branch, running on Windows 95.

Comment 38

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

If those were attempts to answer my question, they don't help.  It's always easy to find new talkback incidents by searching, but talkback doesn't have the information I need.  (It used to, but something broke that.)  I just need the register info from the windows crash dialog that you get if you don't have talkback (or at least that you used to get) for an occurrence of this crash in Fx 1.5.0.2 release.

Comment 39

[Benoît]

Ah, you mean this?

SEAMONKEY heeft een uitzondering 10H veroorzaakt in module GKLAYOUT.DLL op 0137:6037980f.
Registers:
EAX=604a32c8 CS=0137 EIP=6037980f EFLGS=00010246
EBX=01cab934 SS=013f ESP=0065f54c EBP=0065f594
ECX=00bbfb00 DS=013f ESI=0208a528 FS=0cd7
EDX=00000000 ES=013f EDI=0208a520 GS=0000
Bytes in CS:EIP:
d9 1c 24 ff 75 ec ff 75 f8 ff 75 fc 56 ff 50 68 
Stack-dump:
00bbfb00 01c8bea4 00bbf9f4 00000000 0065f830 0208a520 0208a528 00000000 00000003 0065f5ac 00000001 01c8bea4 01aeac04 0065f5ac 00000001 01c8bea4 

Comment 40

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Yes, except that's not from the Firefox 1.5.0.2 release build, since that doesn't have a gklayout.dll.  And without the build, I can't do much with the addresses there.  How about one from the official release build?

Comment 41

[Benoît]

This is the a 1.8.0 nightly of Firefox 1.5.0.2.

FIREFOX heeft een uitzondering 10H veroorzaakt in module FIREFOX.EXE op 0137:006a19e4.
Registers:
EAX=00a07188 CS=0137 EIP=006a19e4 EFLGS=00010246
EBX=018cd040 SS=013f ESP=00d1f42c EBP=00d1f474
ECX=0285c5e0 DS=013f ESI=02852a38 FS=27a7
EDX=00000000 ES=013f EDI=02852a30 GS=0000
Bytes in CS:EIP:
d9 1c 24 ff 75 ec ff 75 f8 ff 75 fc 56 ff 50 68 
Stack-dump:
0285c5e0 018ccdd4 0285c044 00000000 00d1f710 02852a30 02852a38 00000000 00000003 00d1f48c 00000001 018ccdd4 026099e4 00d1f48c 00000001 018ccdd4

Didn't think of the release build when doing this. I'll get right on it, even though there probably hasn't been a check-in for 1.8.0 yet.

Comment 42

[Benoît]

Crash on Firefox 1.5.0.2 release build.

FIREFOX heeft een uitzondering 10H veroorzaakt in module FIREFOX.EXE op 0137:006a12c0.
Registers:
EAX=00a06178 CS=0137 EIP=006a12c0 EFLGS=00010246
EBX=018c23bc SS=013f ESP=00d1f438 EBP=00d1f480
ECX=02363b10 DS=013f ESI=0230e368 FS=0d2f
EDX=00000000 ES=013f EDI=0230e360 GS=0000
Bytes in CS:EIP:
d9 1c 24 ff 75 ec ff 75 f8 ff 75 fc 56 ff 50 68 
Stack-dump:
02363b10 018c2150 02365594 00000000 00d1f71c 0230e360 0230e368 00000000 00000003 00d1f498 00000001 018c2150 0227c6d4 00d1f498 00000001 018c2150 

Comment 43

[Hermann Schwab]

wfm Mozilla/5.0 (Windows; U; Win98; de; rv:1.8.0.2) Gecko/20060308 Firefox/1.5.0.2
and Seamonkey 1.0.1, tested on reduced and minimal testcase only, Win is win98 Standard Edition + SP1 * IE5.x +++

benoît seems to see the crash from using win95.

Comment 44

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: disassembly of nsEventStateManager::UpdateCursor

This is the disassembly from the Firefox 1.5.0.2 release.

Note where the EIP register in the info above lines up in this disassembly.

Comment 45

[Benoît]

put hotspotY into space on stack
  6a12b9:       d9 5c 24 04             fstps  0x4(%esp)

I guess this is it. :)
I'm no real developer (yet), though.

Comment 46

[[e-mail]]

(In reply to comment #44)
>Note where the EIP register in the info above lines up in this disassembly.
Well it sort of makes sense for an unmasked floating-point exception.

Comment 47

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

So, after looking at the intel docs, I think the exception is coming from the line before. (I don't remember whether things are consistent or not on whether EIP has advanced at the top of the stack; I know it always has advanced for function calls, since the saved EIP on the stack is the address to return to.  I could just check another crash, but this makes sense.)

In particular, FLD gives a floating point exception if the source operand is a denormal value, which 0x00000001 is (zero biased-exponent, nonzero fraction).  See volume 2A (instruction set reference, part 1) and Volume 1 sections 4.2.2 and 4.8 of http://developer.intel.com/design/pentium4/manuals/index_new.htm

So the question is where that value is coming from; it does appear consistently on the stack that I analyzed.

Comment 48

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(And the other coordinate doesn't look so sensible either; I'd expect integers most of the time.)

Comment 49

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

The combination of the reduced testcases and all this analysis led to the problem, which I now see:  nsImageFrame::GetCursor doesn't call FillCursorInformationFromStyle at all if map is non-null but map->IsInside returns false.

Comment 50

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: patch

Comment 51

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

So, although this patch does fix bug 177273, it isn't really right.  We should really be getting the cursor style from the area, IMO.

Comment 52

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: testcases for cursor behavior

Comment 53

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: patch

Comment 54

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 219109 [details] [diff] [review]
patch

And for reviewers I should point out that areas match the :-moz-any-link rule in ua.css that specifies cursor:pointer under the same conditions that a elements do.  (In fact, areas can sometimes be a elements.)

Comment 55

[Christian :Biesinger (don't email me, ping me on IRC)]

(In reply to comment #34)
> Or does somebody already know on which instruction it's crashing?  comment 29
> suggests biesi does.

(Benoît had this in a debugger at one point, that's where I had that information from. My x86 asm knowledge wasn't good enough to debug that further)

Comment 56

[Christian :Biesinger (don't email me, ping me on IRC)]

Comment on attachment 219109 [details] [diff] [review]
patch

I'm once again impressed with your debugging.


so is this XXX comment still correct, given that you do use the area content now:
 //XXX This will need to be rewritten once we have content for areas


I assume that this won't give any "wrong parent style context" warnings?

Comment 57

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: 1.8.0 branch patch

This is a lower risk patch for the 1.8.0 branch.

Comment 58

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: testcases for cursor behavior

Comment 59

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

So, FWIW, WinIE6 is even more broken than our old behavior: if an image is inside a link or has a cursor style, then there are no cursor changes as the user moves over imagemaps.  (That's unambiguously broken for the inside-a-link case, IMO.)  So I think the only compatibility issue posed by this (trunk) patch is compatibility with ourselves:  before the patch, the cursor style on an image with an imagemap applied only to the imagemap-active parts; now it applies to exactly the opposite parts.  But I still think it's the right thing to do.

The patch makes us significantly more compatible with Opera and Konqueror: the only difference is that they don't pick up 'cursor' on areas, but instead just forces it to the link cursor for areas that are links (i.e., what our default stylesheet does).

Comment 60

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(In reply to comment #56)
> I assume that this won't give any "wrong parent style context" warnings?

I'm pretty sure that requires creating a frame with the style context.

Comment 61

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Checked in to trunk.

Comment 62

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(In reply to comment #59)
> (That's unambiguously broken for the inside-a-link
> case, IMO.)

Er, maybe it's not so broken, but anyway...

Comment 63

[Benoît]

Just a note. I will only be able to verify this when it lands on a 1.8 branch.
Eagerly awaiting that landing. :)

Comment 64

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Fix checked in to MOZILLA_1_8_BRANCH.

Comment 65

[Justin Wood (:Callek)]

Comment on attachment 219109 [details] [diff] [review]
patch


>RCS file: /cvs/mozilla/layout/generic/nsImageFrame.cpp,v
> //XXX This will need to be rewritten once we have content for areas
> //XXXbz We have content for areas now.... 
>-NS_METHOD
>+NS_IMETHODIMP
> nsImageFrame::GetCursor(const nsPoint& aPoint,

bz, is this the re-write referenced in the XXX comment, if so, should both XXX comments be removed?

Comment 66

[Benoît]

On yesterday's late SeaMonkey "1.8 branch" build running on Windows 95, both the minimal and reduced testcases don't cause a crash anymore.

dbaron, you're my hero. :)
My dad's happy with his birthday present. It was his birthday yesterday. ;)

-> VERIFIED

Comment 67

[Daniel Veditz [:dveditz]]

Comment on attachment 219182 [details] [diff] [review]
1.8.0 branch patch

approved for 1.8.0 branch, a=dveditz for drivers

Comment 68

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Fix checked in to MOZILLA_1_8_0_BRANCH.

I'd appreciate if you could verify that it's fixed in tomorrow's 1.8.0 branch builds as well, since the fix there is different (lower-risk; no behavior changes for the cases that didn't crash).

Comment 69

[Benoît]

Sure, will do.
I have to say that I'm already compiling a 1.8.0-based build with this and other fixes, though. :)

Comment 70

[Benoît]

Sorry for being late with this, I forgot about it after waiting for a fresh nightly build with the fix.

Just tested with a fresh 1.8.0 build, and it doesn't crash on either of the two testcases. I've been using an own compiled build with the (1.8.0) patch included for weeks without a crash on this, too. No crash after printing either. I think it's safe to say this has been fixed. :)

Comment 71

[Adam Guthrie]

*** Bug 338082 has been marked as a duplicate of this bug. ***

Comment 72

[Marcia Knous [:marcia]]

verified on the 1.8.0 branch using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4. Ran both test cases with no crash. Although I didn't specifically test Win 95, Comment 70 indicates that we should be okay there.