Closed Bug 569674 Opened 10 years ago Closed 8 years ago
Rendering Context failure" with XBL, iframe, content Editable
Steps: 1. Set layout.debug.enable_data_xbl to true. 2. Load the testcase in a debug build of Firefox. ###!!! ASSERTION: CreateRenderingContext failure: 'Not Reached', file /Users/jruderman/central/layout/base/nsPresShell.cpp, line 7345 Security-sensitive because the testcase is similar to the one in bug 561981. I'm guessing this isn't a security bug itself, but please verify this!
To reproduce you may need to save the testcase locally, or load it from the command line, or somtehing.
I haven't debugged this in detail but this appears to similar to bug 561981. We call nsFrameLoader::Show and the SetDesignMode calls at the end of it flush and cause nsFrameLoader::Hide and then nsFrameLoader::Show to be called on the same frameloader. We get to a reflow somehow when we are in this weird state. I'm tempted to use smaug's idea in bug 561981, comment 12 to put a script blocker around the SetDesignMode calls in nsFrameLoader::Show to block any flushing causes us to re-enter. There are two places where nsFrameLoader::Show is called (have I missed any?), async from nsSubdocumentFrame::Init and nsSubDocumentFrame::EndSwapDocShells from nsFrameLoader::SwapWithOtherLoader. Before bug 557398 we the call from nsSubdocumentFrame::Init was always done under frame construction, so the SetDesignMode flushes were no-ops. nsFrameLoader::SwapWithOtherLoader is a relatively rarely called function.
Bug 561981 is public now, so we can probably open this up too. (The testcase is WFM in a local Linux64 debug ASAN build.)
WFM, ASan builds on OSX and Linux64.
Status: NEW → RESOLVED
Closed: 8 years ago
Depends on: 561981
Resolution: --- → WORKSFORME
Yeah, we dropped support for -moz-binding (custom XBL bindings) in content. See bug 379644.
You need to log in before you can comment on or make changes to this bug.