591480 - "ASSERTION: Unexpected primary frame" [nsImageMap.cpp:474]

Status: NEW

(Core :: Layout, defect)

Description

[Jesse Ruderman]

Attachment: testcase

Comment 1

[Jesse Ruderman]

Loading the testcase:

###!!! ASSERTION: Losing track of existing primary frame: '!aFrame || !mPrimaryFrame || aFrame == mPrimaryFrame', file ../../dist/include/nsIContent.h, line 883

Unloading the testcase:

###!!! ASSERTION: Unexpected primary frame: 'area->mArea->GetPrimaryFrame() == mImageFrame', file layout/generic/nsImageMap.cpp, line 747

The second assertion is new (not covered by other bug reports).

Comment 2

[Jesse Ruderman]

Attachment: stacks

Comment 3

[Boris Zbarsky [:bzbarsky]]

What bug report covers the first assertion?  That's the one I have a fix for...

I have no idea how to fix the second without fixing bug 135040.

Comment 4

[Jesse Ruderman]

Bug 576174 covers the first assertion.

Comment 5

[Boris Zbarsky [:bzbarsky]]

No, that's a different issue.  In this case the first assertion is very much <html:map>-specific.

Comment 6

[Jesse Ruderman]

Please file a new bug and attach your patch there.

Comment 7

[Boris Zbarsky [:bzbarsky]]

On second thought, my fix (if I'm thinking of the same one) doesn't work because nsIFrame is forward-declared.  And asserting that we're not an HTML <area> won't work for consumers who can't include nsGkAtoms...

Comment 8

[Mark Hammond [:markh] [:mhammond]]

The existing test toolkit/content/tests/widgets/test_mousecapture_area.html causes 3 assertions that look alot like this:

0:28.39 ###!!! ASSERTION: Losing track of existing primary frame: '!aFrame || !mPrimaryFrame || aFrame == mPrimaryFrame', file ...dist\include\nsIContent.h, line 805
...
0:32.05 ###!!! ASSERTION: Unexpected primary frame: 'area->mArea->GetPrimaryFrame() == mImageFrame', file ...layout/generic/nsImageMap.cpp, line 703
...
0:32.08 ###!!! ASSERTION: Unexpected primary frame: 'area->mArea->GetPrimaryFrame() == mImageFrame', file .../layout/generic/nsImageMap.cpp, line 703

I'm guessing this is the same bug rather than opening a new one.

Comment 9

[Ryan VanderMeulen [:RyanVM]]

Still affects trunk (given comment 3, I guess that's to be expected, though).

Comment 10

[Firefox Bug Husbandry Bot]

https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Move_fix-optionals