Closed Bug 224234 Opened 21 years ago Closed 20 years ago

Dead replaced node remains in layout after replaceChild()

Categories

(Core :: Layout: Block and Inline, defect)

x86
Linux
defect
Not set
trivial

Tracking

()

RESOLVED FIXED

People

(Reporter: zack-weg, Unassigned)

References

Details

Attachments

(1 file)

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.
Attached file testcase
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Fixed by the patch in bug 237566
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: