1394630 - stylo: Print preview with Twitter profile page crashes on debug build with "Assertion failure: mOwner == ExpectedOwnerForChild(aFrame) (Missed some frame in the hierarchy?)"

Status: RESOLVED DUPLICATE of bug 1390951

(Core :: CSS Parsing and Computation, defect, P3)

Description

[Xidorn Quan [:xidorn] UTC+10]

Steps to reproduce:
1. open a Twitter profile, e.g. https://twitter.com/FirefoxNightly
2. open File / Print Preview

It would crash with the following stack:
> #01: mozilla::ServoRestyleManager::ProcessPostTraversal (\layout\base\servorestylemanager.cpp:768)
> #02: mozilla::ServoRestyleManager::ProcessPostTraversal (\layout\base\servorestylemanager.cpp:914)
> #03: mozilla::ServoRestyleManager::ProcessPostTraversal (\layout\base\servorestylemanager.cpp:914)
> #04: mozilla::ServoRestyleManager::ProcessPostTraversal (\layout\base\servorestylemanager.cpp:914)
> #05: mozilla::ServoRestyleManager::ProcessPostTraversal (\layout\base\servorestylemanager.cpp:914)
> #06: mozilla::ServoRestyleManager::ProcessPostTraversal (\layout\base\servorestylemanager.cpp:914)
> #07: mozilla::ServoRestyleManager::ProcessPostTraversal (\layout\base\servorestylemanager.cpp:914)
> #08: mozilla::ServoRestyleManager::ProcessPostTraversal (\layout\base\servorestylemanager.cpp:914)
> #09: mozilla::ServoRestyleManager::ProcessPostTraversal (\layout\base\servorestylemanager.cpp:914)
> #10: mozilla::ServoRestyleManager::ProcessPostTraversal (\layout\base\servorestylemanager.cpp:914)
> #11: mozilla::ServoRestyleManager::DoProcessPendingRestyles (\layout\base\servorestylemanager.cpp:1115)
> #12: mozilla::PresShell::DoFlushPendingNotifications (\layout\base\presshell.cpp:4183)
> #13: nsRefreshDriver::Tick (\layout\base\nsrefreshdriver.cpp:1925)
> #14: mozilla::RefreshDriverTimer::TickDriver (\layout\base\nsrefreshdriver.cpp:338)
> #15: mozilla::RefreshDriverTimer::TickRefreshDrivers (\layout\base\nsrefreshdriver.cpp:309)
> #16: mozilla::RefreshDriverTimer::Tick (\layout\base\nsrefreshdriver.cpp:331)
> #17: mozilla::VsyncRefreshDriverTimer::RunRefreshDrivers (\layout\base\nsrefreshdriver.cpp:771)
> #18: mozilla::VsyncRefreshDriverTimer::RefreshDriverVsyncObserver::TickRefreshDriver (\layout\base\nsrefreshdriver.cpp:686)
> #19: mozilla::VsyncRefreshDriverTimer::RefreshDriverVsyncObserver::NotifyVsync (\layout\base\nsrefreshdriver.cpp:587)
> #20: mozilla::layout::VsyncChild::RecvNotify (\layout\ipc\vsyncchild.cpp:70)
> #21: mozilla::layout::PVsyncChild::OnMessageReceived (\obj-firefox-stylo\ipc\ipdl\pvsyncchild.cpp:155)
> #22: mozilla::ipc::PBackgroundChild::OnMessageReceived (\obj-firefox-stylo\ipc\ipdl\pbackgroundchild.cpp:1716)
> #23: mozilla::ipc::MessageChannel::DispatchAsyncMessage (\ipc\glue\messagechannel.cpp:2111)
> #24: mozilla::ipc::MessageChannel::DispatchMessageW (\ipc\glue\messagechannel.cpp:2038)
> #25: mozilla::ipc::MessageChannel::RunMessage (\ipc\glue\messagechannel.cpp:1883)
> #26: mozilla::ipc::MessageChannel::MessageTask::Run (\ipc\glue\messagechannel.cpp:1916)
> #27: nsThread::ProcessNextEvent (\xpcom\threads\nsthread.cpp:1040)
> #28: NS_ProcessNextEvent (\xpcom\threads\nsthreadutils.cpp:521)
> #29: mozilla::ipc::MessagePump::Run (\ipc\glue\messagepump.cpp:97)
> #30: mozilla::ipc::MessagePumpForChildProcess::Run (\ipc\glue\messagepump.cpp:301)
> #31: MessageLoop::RunHandler (\ipc\chromium\src\base\message_loop.cc:320)
> #32: MessageLoop::Run (\ipc\chromium\src\base\message_loop.cc:300)
> #33: nsBaseAppShell::Run (\widget\nsbaseappshell.cpp:160)
> #34: nsAppShell::Run (\widget\windows\nsappshell.cpp:212)
> #35: XRE_RunAppShell (\toolkit\xre\nsembedfunctions.cpp:866)
> #36: mozilla::ipc::MessagePumpForChildProcess::Run (\ipc\glue\messagepump.cpp:269)
> #37: MessageLoop::RunHandler (\ipc\chromium\src\base\message_loop.cc:320)
> #38: MessageLoop::Run (\ipc\chromium\src\base\message_loop.cc:300)
> #39: XRE_InitChildProcess (\toolkit\xre\nsembedfunctions.cpp:695)
> #40: content_process_main (\ipc\contentproc\plugin-container.cpp:64)
> #41: NS_internal_main (\browser\app\nsbrowserapp.cpp:288)
> #42: wmain (\toolkit\xre\nswindowswmain.cpp:118)
> #43: __scrt_common_main_seh (f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl:283)
> #44: BaseThreadInitThunk[C:\WINDOWS\System32\KERNEL32.DLL +0x12774]
> #45: RtlUserThreadStart[C:\WINDOWS\SYSTEM32\ntdll.dll +0x70d51]

Comment 1

[Xidorn Quan [:xidorn] UTC+10]

This happens on Youtube homepage as well.

Not sure how important is this assertion, though.

Comment 2

[Emilio Cobos Álvarez (:emilio)]

Not too much, but we're probably mis-restyling some page frame or what not, or need to adjust the assertion. If you have it handy, do you know what kind of frames are mOwner, and the frame / elements that are on scope during ProcessPostTraversal?

Comment 3

[Xidorn Quan [:xidorn] UTC+10]

So, in the Twitter profile case, mOwner is a block frame, and aFrame is a block frame as well. mContent of aFrame's parent is the same as mOwner, but mOwner's mNextContinuation seems to be null.

Comment 4

[Bobby Holley (:bholley)]

Is this related to the issue we were discussing today, or is it separate?

Comment 5

[Xidorn Quan [:xidorn] UTC+10]

It is related to the topic about print preview, but it has nothing to do with XBL, I believe.

My guess is that the assertion in question needs to be adjusted to be aware of the block split for print preview.

Comment 6

[Ting-Yu Lin [:TYLin] (PST, UTC-8)]

I'm with xidorn's comment 5. BTW, I cannot reproduce this on Linux ...

Comment 7

[Brad Werth [:bradwerth] | Out until Feb 2025]

I can't exactly reproduce this on macOS, though there are some other issues. macOS doesn't have a File -> Print Preview menu item. Triggering PDF generation from File -> Print -> Open PDF in Preview triggers a few non-fatal assertions...

###!!! ASSERTION: Cannot bind twice, need to unbind first: '!mBoundFrame', file /Users/brad/repos/stylo/dom/html/nsTextEditorState.cpp, line 1309
###!!! ASSERTION: no page sequence frame: 'nullptr != pageSequence', file /Users/brad/repos/stylo/layout/printing/nsPrintEngine.cpp, line 2585

I'll check those out and if they are serious, open a new bug on them.  I'll try a few other methods to get to a Print Preview directly on macOS (an add-on? print media emulation via devtools?) and replicate this stack. If I can't replicate it, I'll take myself back off the bug.

Comment 8

[Bobby Holley (:bholley)]

I'm pretty sure I've got the print preview issue nailed down in bug 1390951. Probably not worth investigating the assertions in comment 7, I doubt they're important or related to stylo.

Comment 9

[Brad Werth [:bradwerth] | Out until Feb 2025]

Indeed, I can't replicate this on macOS.

Comment 10

[Bobby Holley (:bholley)]

I'm going to optimistically assume this was resolved by bug 1390951. Xidorn, can you check whether this still reproduces for you, and reopen if so?

Comment 11

[Xidorn Quan [:xidorn] UTC+10]

It doesn't seem to happen anymore.

(Interestingly, when I used non-stylo backend, it crashed...)