Closed Bug 401176 Opened 14 years ago Closed 14 years ago
can end up with double frames in fancy ns
CSSFrame Constructor::Content Removed codepaths
Landing bug 321402 caused the reftest http://mxr.mozilla.org/seamonkey/source/layout/reftests/bugs/374038-2.xul to fail. (It was the last-minute change (after I'd done the full reftest run) to fix the ContentRemoved codepath that broke it, although it would also have been slightly broken without that change -- although not to cause that particular test to fail.) The problem is that we do the following: - call RecreateFramesForContent to reframe the image (processing the style change that resulted from ContentStatesChanged) - this calls ContentRemoved - this detects the need to destroy the wrapper and reframes its grandparent, which creates a frame for the image - this then calls ContentInserted, creating a *second* frame for the image (I'm also a bit puzzled by the need for both ReinsertContent and RecreateFramesForContent, with their different brokenness, and why we set PR_TRUE for aInReinsertContent to ContentRemoved only in the former.)
(Note that this bug was present in a number of existing codepaths before bug 321402 landed.)
And when this is fixed we need to remove the random marking in layout/bugs/reftest.list: random == 374038-2.xul 374038-2-ref.xul # bug 401176
14 years ago
Flags: blocking1.9? → blocking1.9+
I will fix this when merging the patch in bug 399940
Assignee: dbaron → roc
Whiteboard: [depends on 399940]
14 years ago
Priority: -- → P2
roc, reed ended up landing the fix for bug 399940 for you. Did this get fixed with it anyway?
Yeah, I added the fix needed here into the patch there. I'll verify as soon as I get a trunk build with that patch in it...
I turned the reftest back on.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Component: Layout: Misc Code → Layout
Product: Core Graveyard → Core
You need to log in before you can comment on or make changes to this bug.