315541 - [FIX]Hovering over this broken image testcase makes it disappear

Status: RESOLVED FIXED

(Core :: Layout, defect, P2)

Description

[Martijn Wargers (dead)]

See upcoming testcase.
When hovering over the broken image, it disappears.
It seems to be a regression, works in 2005-09-18 build, fails in 2005-09-20, the fix for bug 11011 seems the most likely candidate.

Comment 1

[Martijn Wargers (dead)]

Attachment: testcase

Comment 2

[Martijn Wargers (dead)]

I'm also getting an assertion when hovering over the broken image:
###!!! ASSERTION: node in map twice: 'Not Reached', file c:/mozilla/mozilla/layo
ut/base/nsFrameManager.cpp, line 1632
Similar to bug 180897.

Comment 3

[Boris Zbarsky [:bzbarsky]]

Attachment: Testcase that shows the bug in builds before bug 11011

Comment 4

[Boris Zbarsky [:bzbarsky]]

So here's what's going on:

1)  Mousing over the image sends the <area> into the :hover state
2)  We check for state dependent style on the <area>.  Since <area> matches
    :link, it has state dependent style given our ua.css.  So we post a restyle
    event targeted at the <area>.
3)  We reresolve style for the <area>.  The primary frame for it is the image
    frame(!).  So we reresolve style for the <img>.  Its style hasn't actually
    changed, so we move along to dealing with kids, etc.
4)  We notice that the <img> has a :before style (in ua.css), but no before
    frame (because it's a replaced element).  So we toss in a reframe hint and
    return.
5)  Reframing removes the image frame, then calls ContentInserted on our content
    (the <area>).  Which of course doesn't do squat about the image frame
    reappearing and instead tries to create a second undisplayed entry.

Now I think I should fix step 4 here, but it feels to me like we could reproduce the same issue by just having a :hover style on <area>...  Especially if the page styles the area to not be display:none.  I'm not really sure what we can do about that.  :(

Comment 5

[Boris Zbarsky [:bzbarsky]]

Attachment: Patch

OK, looks like actually styling the area to have a frame is ok too; not sure why, but I'm not worrying about it too much.  ;)

Comment 6

[Worcester12345]

Seeing in branch also even though "Version" says trunk:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051107 Firefox/1.5 ID:2005110708

Comment 7

[Boris Zbarsky [:bzbarsky]]

Version should be the latest version that shows the bug.  In this case, that's trunk.  I'm not touching this code on branch, for what it's worth.

Comment 8

[Boris Zbarsky [:bzbarsky]]

Fixed.

Comment 9

[zug_treno]

Could it be that this patch also fixed bug 327380?

Comment 10

[Boris Zbarsky [:bzbarsky]]

No.