User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a3) Gecko/20040719 Firefox/0.9.1+ Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a3) Gecko/20040719 Firefox/0.9.1+ In the page at http://home.uchicago.edu/~sbjensen/cssbug.html, a link (using fixed positioning) has a <span> child that defaults to "display: none". When the link matches A:hover, the child text is revealed ("display: inline"), and is also positioned directly below the original link. When the mouse is moved onto the newly-revealed span, page display gets stuck, and the browser crashes a few moments later. (Tested on a Mac using Firefox 0.9, 0.9.1, and a recent nightly build.) Reproducible: Always Steps to Reproduce: 1. Go to the URL above. 2. Place your mouse over the link (this will reveal more text below). 3. Move the mouse over the newly revealed text (if there is space between the two boxes, you may need to move quickly so the new text doesn't disappear). 4. Wait a moment or two (you _may_ need to move the mouse). Crash! Actual Results: The browser crashes. Expected Results: It should have just kept the text revealed until the mouse moved off of it (probably still treating it as part of the link). My most recent Talkback "Incident ID" for this issue is "TB366234K"; before that were "TB366101M" and several others, starting with "TB352808E". My PowerBook doesn't seem to give direct feedback on what module the crash occurred in.

WFM 20040718 PC/Win2000

Thanks for the Talkback ID and testcase, this seems to be dupe of bug 227344. Can you check bug 227344 and see if you get a similar stack (as in TB366101M and TB352808E), see http://talkback-public.mozilla.org/ to check your stack traces.

I wondered if bug 227344 was related, but the discussion there seemed to focus on the overflow property and I wasn't sure if this was Mac specific, so I wasn't certain that it was the same issue. (Does overflow even apply to inline elements like <span>s? I certainly haven't set it explicitly, anyway.) At any rate, I'm afraid that I haven't found a way to check my results for that bug, because the testcase URL listed there no longer seems to be valid. If there's a link or attachment that I'm just not seeing, please let me know and I'll be happy to try it out.

It looks like Olivier is right, and this is caused by the same issue as bug 227344. I still couldn't find the test case there, but I've just applied the patch mentioned there (or rather, the patch mentioned there but modified to remove what a commenter there said were redundant if statements), and the crash no longer happens. I'll attach my patch file below. (Because I don't know what I'm doing at all, I haven't even tried to figure out how to implement the "more correct" approach using "nsCOMPtr" mentioned there.) As mentioned at the other bug, this doesn't completely fix the problem: the crash is gone, but the new box disappears when the mouse moves over it rather than staying visible as it should. Still, that's a much less severe problem.

This is based directly on a patch to bug 227344 by Jerry Talkington, with redundant "if" statements removed as suggested by Mike Pinkerton. I have no idea how to do the same thing using "nsCOMPtr<nsIWidget> kungFuDeathGrip(widgetPointed)" but as Mike said that would be "more correct", I hope that someone else does!

*** This bug has been marked as a duplicate of 227344 ***