81728 - crash after clicking on link in an Image Map - Trunk [@ NS_MakeAbsoluteURI][@ gklayout!nsQueryReferent::operator=]

Status: VERIFIED FIXED

(Core :: Layout, defect, P1)

Description

[Oliver Klee]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9+) Gecko/20010517
BuildID:    2001051720

Reproducible: Always
Steps to Reproduce:
1. visit URL
2. click on "Fach- und Führungskräfte"

Actual Results:  crash in ntdll!RtlTraceDatabaseEnumerate which is called by
gklayout!nsQueryReferent::operator=

Expected Results:  no crash

Comment 1

[Oliver Klee]

Attachment: Dr. Watson log

Comment 2

[Oliver Klee]

After I tried again, I had a different crash (in gklayout!NS_NewFrameImageLoader).

Comment 3

[Oliver Klee]

Attachment: Dr. Watson log for 2nd crash

Comment 4

[Marc Attinasi]

I'll take this for now: I can reproduce the problem, though my crash is in a
different spot, and I have a patch. I'm not at the root of the problem yet.
Basically, what I see is that the imageFrame loses it base URI after it is
clicked, and we are not checking that the base URI is null. My change is to
simply check for a base URI that is null before processing it in the mouse
handler code - this prevents the crash, but I need to figure out why this is
happening. Patch coming...

BTW: I fear that there is something more heinous happening, like maybe the
imageFrame has lost its document or something. CC'ing Pavlov in case he knows
about this.

Comment 5

[Marc Attinasi]

Attachment: Patch to stop the crash.

Comment 6

[Marc Attinasi]

Attachment: Simplified testcase that causes the bug (for me)

Comment 7

[Marc Attinasi]

Oliver, can you try the testcase I attached and tell me if it causes the same 
problem for you? Thanks.

Comment 8

[Oliver Klee]

Yep, same problem (as the 2nd stacktrace).

Comment 9

[Stuart Parmenter]

r=pavlov

Comment 10

[Marc Attinasi]

Moving this up to 0.9.1 and taking it over. This is happening in other sites too 
(click the powerbook picture at 
http://store.apple.com/1-800-MY-APPLE/WebObjects/AppleStore) - probably any 
image map...

I think the problem is simply that the mouse-move is being handled after the map 
has been partially torn down due to the click. Whenever I see the bad baseURI, 
it is on a MOUSE_MOVE not a MOUSE_UP. This is happening now because the image 
frame is now being kept around after the click has caused the navigation to the 
new page since we now hold around the frames until the new page is loaded. 
cc'ing hyatt since that is stuff he put together I think.

The fix is easy enough, safe enough, and the crash common enough to merit 
consideration for 0.9.1 (IMO).

Comment 11

[John Morrison]

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

Comment 12

[John Morrison]

Dude, that is the most brilliant test case since the one on Bug 79114 !!
  http://bugzilla.mozilla.org/showattachment.cgi?attach_id=35905

Comment 13

[Marc Attinasi]

;) - I really should search for dups before I go fixin' things...

Comment 14

[David Hyatt]

sr=hyatt

Comment 15

[Jay Patel [:jay]]

adding topcrash keyword and Trunk [@ NS_MakeAbsoluteURI] to summary for
tracking...since bug 79114 was marked a dup.

Comment 16

[Oliver Klee]

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

Comment 17

[Oliver Klee]

Copying keywords from duplicate bug 82594: dataloss, nsbeta1

Comment 18

[Asa Dotzler [:asa]]

a= [e-mail] for checkin to 0.9.1

Comment 19

[R.K.Aa.]

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

Comment 20

[John Morrison]

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

Comment 21

[Marc Attinasi]

Fix in:
/cvsroot/mozilla/layout/html/base/src/nsImageFrame.cpp,v  <--  nsImageFrame.cpp
new revision: 1.177; previous revision: 1.176
done

Comment 22

[Oliver Klee]

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

Comment 23

[Chris Petersen]

Marking verified in the May 29th build.