When opening container assigned links via startpage.com using the right click context menu, fx will crash if the user has ADP installed with the following assertion: Assertion failure: mPresContext->mLayoutPhaseCount[eLayoutPhase_FrameC] == 0 (recurring into frame construction), at /mozilla-beta/layout/base/nsAutoLayoutPhase.cpp:55 Process 38993 stopped * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0) frame #0: 0x000000010625625c XUL`nsAutoLayoutPhase::Enter(this=0x00007fff5fbc80d0) at nsAutoLayoutPhase.cpp:54 51 "constructing frames in the middle of a paint"); 52 MOZ_ASSERT(mPresContext->mLayoutPhaseCount[eLayoutPhase_Reflow] == 0, 53 "constructing frames in the middle of reflow"); -> 54 MOZ_ASSERT(mPresContext->mLayoutPhaseCount[eLayoutPhase_FrameC] == 0, 55 "recurring into frame construction"); 56 MOZ_ASSERT(!nsContentUtils::IsSafeToRunScript(), 57 "constructing frames and scripts are not blocked"); Please see https://github.com/mozilla/testpilot-containers/issues/454 for more context if needed. STR (100% reproducible): * install fx * install the test pilot via https://testpilot.firefox.com/ and enable "Containers" * install "Adblock Plus" via about:addons * open the "Personal" container and visit github * right click and assign github to the "Personal" container via "Aways Open in This Container" * open a regular non-container tab and visit https://www.startpage.com * search for "github", right click on the first result and select "Open Link in New Tab" Results: * fx53.0, buildid: 20170413192749, changeset: d345b657d381 - Reproduced * fx54.0b1, buildid: 20170420011827, changeset: cf76e00dcd6f - Reproduced * fx54.0a2, buildid: 20170424004007, changeset: 94b7e538af7d - Reproduced * fx55.0a1, buildid: 20170424030211, changeset: 73752931e273 - Couldn't reproduce

baku, could you take a look and see if this is a container issue, or just a layout bug that's affecting the containers test pilot.

After this line the sequence of children changes. https://hg.mozilla.org/releases/mozilla-beta/file/tip/layout/base/nsCSSFrameConstructor.cpp#l8177 aEndChild is not part of the child list and we crash when child is null. Should we add the check |child != aEndChild && child| here ? if (frameItems.NotEmpty()) { for (nsIContent* child = aStartChild; child != aEndChild; child = child->GetNextSibling()){ InvalidateCanvasIfNeeded(mPresShell, child); }

(In reply to Andrea Marchesini [:baku] from comment #2) > aEndChild is not part of the child list and we crash when child is null. > Should we add the check |child != aEndChild && child| here ? Passing a frame for aEndChild that is not a child seems wrong. I think we need to know what actually fixed this since beta branched.

Because I can't reproduce this on nightly, I went through mozregression using the m-a channel and got the following results: 10:09.49 INFO: Last good revision: d097e7e8a9cba33876f067726bbd612d80277867 10:09.49 INFO: First bad revision: f6f2e2b9fa87a1cf454dec44bcf52cd4f96288a0 10:09.49 INFO: Pushlog: https://hg.mozilla.org/releases/mozilla-aurora/pushloghtml?fromchange=d097e7e8a9cba33876f067726bbd612d80277867&tochange=f6f2e2b9fa87a1cf454dec44bcf52cd4f96288a0 It looks like bug#1318800 might have something to do with this issue.

I've managed to reproduce the crash on m-c while going through mozregression and got the same result two different times. It seems like bug#1350522 introduced the fix. I'm not sure why mozregression is pointing to bug#1318800 as the cause when using the m-a channel. 18:01.60 INFO: First good revision: 31dd0a3e931a22133fe3d4e21abfc1c2e1fb891f 18:01.60 INFO: Last bad revision: f2d18607854251fc668b6e156c24282888858680 18:01.60 INFO: Pushlog: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=f2d18607854251fc668b6e156c24282888858680&tochange=31dd0a3e931a22133fe3d4e21abfc1c2e1fb891f 18:07.47 INFO: Looks like the following bug has the changes which introduced the fix: https://bugzilla.mozilla.org/show_bug.cgi?id=1350522 Baku, does any of this information help narrow down the issue? I'm not 100% sure that mozregression is pointing to the correct bugs here...

kmag, can this big a regression of bug 1350522?

I suppose it's possible. Those patches would have changed some timings, and prevented some code from being loaded that would have otherwise been loaded before it was needed. But I can't think of any obvious way it would affect this, especially if there aren't any WebExtensions installed.

When I was trying to reproduce the issue while going through mozregression, it sometimes it took me a few attempts to reproduce and other times it would reproduce instantly which definitely seemed like it was based on timing.

Kris, Kamil, this is still rated as a P1 and is not assigned to someone. Can you lower the rating or help me find an assignee if it's still a pressing issue?

I'm going to set this as P3 as there's only 16 crash reports which is a pretty small percentage. As this is only reproducible under fx54, it's probably to late to fix it under fx54 unless a fix for this rides along a dot release which is very unlikely. I'll leave this opened just incase users run into this problem and want more information. I'll retest it once fx55 is released and close it off if I can't reproduce it anymore. Results: * fx54.0, buildid: 20170608105825, changeset: e832ed037a3c - reproduced * fx55.0b3, buildid: 20170619071954, changeset: be4a0ad5d6ca - couldn't reproduce * fx56.0a1, buildid: 20170620030208, changeset: 7a6baa6cca32 - couldn't reproduce

Bulk change per https://bugzilla.mozilla.org/show_bug.cgi?id=1401020