User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6a) Gecko/20031030 If you replace an inline element containing a block element by a block element, the replaced element remains in layout, but behaves like a ghost of the new element. It isn't in the DOM, just in layout. Reproducible: Always Steps to Reproduce: 1. Load the testcase. 2. Click the "test" button. 3. Doubleclick the upper text. 4. Select all text and view the selection source (context menu). Actual Results: "text" appears twice. If you try to select the upper one, the lower one is selected. In the DOM source you see the correct DOM tree, however. Expected Results: No visual change, just an additional level of <div> inserted. Note that an inline element containing a block element is not a normal case (I found nothing in the spec about this case), but it occurs on real web pages (e.g. <b><center>...</center></b>) and interferes with my bookmarklet trying to prettify those pages. Bug 197427 is quite similar, but probably not the same.

The problem here is that various nsCSSFrameConstructor methods use ContentReplaced to regenerate frames for things.... Therefore, when ContentReplaced calls ContentRemoved it passes a boolean saying not to check for {ib} situations; hence this bug (see line 9427, checking aInContentReplaced inside ContentRemoved). The solution (short of fixing {ib} in general) is to separate out "real" ContentReplaced calls and the "fake" ones we create ourselves. Perhaps the boolean should be hoisted up to ContentReplaced and all the CSSFrameConstructor callers should pass true while presshell/styleset/whatever passes false? Or we should have a ContentReplacedInternal (probably with a better name like CreateNewFrame (not to be confused with RecreateFramesForContent... <sigh>)) which is called internally by the "real" ContentReplaced and by all the current "fake" callers.

Fixed by the patch in bug 237566