When visiting http://vraptor.jpl.nasa.gov/voyager/press-r.html, I noticed that whenever mousing over the second link, a link just like it was generated below it; new links are being spawned with every mouseover. I would have categorized this as more severe than minor, but then I noticed what causes this behavior. Basically, Mozilla is not very tolerant (in this case at least) of faulty HTML. My understanding has always been that a browser ignores a tag it does not recognize; this is not what Mozilla is doing here. Witness the snippet of code for that site that is causing the problem: <UL> <L1><A HREF="http://vraptor.jpl.nasa.gov/voyager/pressrel/vgr217.html"> Voyager 1, Now Most Distant Human-made Object in Space, February 1998</A><P> <L1><A HREF="http://vraptor.jpl.nasa.gov/voyager/pressrel/vg981117.html"> Voyager 2, Back to Normal Flight Operations After Communications Black-out , November 1998</A><P> </UL> <P> In case you didn't catch it, the list item tags, which should be LI tags, are mistyped as L1 (one, not I) tags. I tried this variant too: <BLAH><a href="http://www.cnn.com">CNN</a><P> <BLAH><a href="http://www.yahoo.com">Yahoo</a><P> This coding produced the same error. Apparently, the tag that Mozilla doesn't recognize (<BLAH>) is throwing off the layout engine, but only when the last <P> tag is there! That is, this variant doesn't cause the error to occur: <BLAH><a href="http://www.cnn.com">CNN</a><P> <BLAH><a href="http://www.yahoo.com">Yahoo</a> In any event, I doubt this error will qualify as a beta-stopper, but it might be a symptom of a larger problem. It would be nice, also, if Mozilla would be a little more tolerant of faulty HTML - not in the sense that IE is, in that the bad coding often works anyhow, but at least in ignoring tags that aren't recognized.

Sorry I seem to have reported this already but it is still in the unconfirmed state! The number of the previous one is 28652.

Ignore that comment about the dup. That comment was because of a bug in Mozilla (bug 30466). Pretty nasty bug here. Confirmed on Win2000 2000030608.

This is the same problem as bug #28553. There is a block-level element inside of an inline-level element and we're not finding the frame in FindPrimaryFrameFor() and so we end up recreating the frame and that's why we a new one each time we mouse over the link *** This bug has been marked as a duplicate of 28553 ***

Marking verified dup of 228553.