Reduced with m-c:
BuildID=20190702093917
SourceStamp=a15e5a44b7ed0a285c92839055efd83671b49552

Assertion failure: aNew->HasHitTestInfo(), at srcsrc/layout/painting/RetainedDisplayListBuilder.cpp:372

==87845==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7fed01403b7b bp 0x7ffd6c0e3d10 sp 0x7ffd6c0e3cf0 T0)
==87845==The signal is caused by a WRITE memory access.
==87845==Hint: address points to the zero page.
    #0 0x7fed01403b7a in CopyASR(nsDisplayItem*, nsDisplayItem*) srcsrc/layout/painting/RetainedDisplayListBuilder.cpp:375:20
    #1 0x7fed01402872 in MergeState::MergeChildLists(nsDisplayItem*, nsDisplayItem*, nsDisplayItem*) srcsrc/layout/painting/RetainedDisplayListBuilder.cpp:521:7
    #2 0x7fed0135e8ef in MergeState::ProcessItemFromNewList(nsDisplayItem*, mozilla::Maybe<Index<MergedListUnits> > const&) srcsrc/layout/painting/RetainedDisplayListBuilder.cpp:480:9
    #3 0x7fed0135def4 in RetainedDisplayListBuilder::MergeDisplayLists(nsDisplayList*, RetainedDisplayList*, RetainedDisplayList*, mozilla::Maybe<mozilla::ActiveScrolledRoot const*>&, nsDisplayItem*) srcsrc/layout/painting/RetainedDisplayListBuilder.cpp:834:31
    #4 0x7fed01361c43 in RetainedDisplayListBuilder::AttemptPartialUpdate(unsigned int, mozilla::DisplayListChecker*) srcsrc/layout/painting/RetainedDisplayListBuilder.cpp:1519:7
    #5 0x7fed00d48198 in nsLayoutUtils::PaintFrame(gfxContext*, nsIFrame*, nsRegion const&, unsigned int, nsDisplayListBuilderMode, nsLayoutUtils::PaintFrameFlags) srcsrc/layout/base/nsLayoutUtils.cpp:3970:40
    #6 0x7fed00c6b63b in mozilla::PresShell::Paint(nsView*, nsRegion const&, mozilla::PaintFlags) srcsrc/layout/base/PresShell.cpp:6149:5
    #7 0x7fed007a696e in nsViewManager::ProcessPendingUpdatesPaint(nsIWidget*) srcsrc/view/nsViewManager.cpp:461:18
    #8 0x7fed007a62d1 in nsViewManager::ProcessPendingUpdatesForView(nsView*, bool) srcsrc/view/nsViewManager.cpp:396:22
    #9 0x7fed007a84b8 in nsViewManager::ProcessPendingUpdates() srcsrc/view/nsViewManager.cpp:1019:5
    #10 0x7fed00c023b7 in nsRefreshDriver::Tick(mozilla::layers::BaseTransactionId<mozilla::VsyncIdType>, mozilla::TimeStamp) srcsrc/layout/base/nsRefreshDriver.cpp:2104:11
    #11 0x7fed00c0c6e5 in mozilla::RefreshDriverTimer::TickRefreshDrivers(mozilla::layers::BaseTransactionId<mozilla::VsyncIdType>, mozilla::TimeStamp, nsTArray<RefPtr<nsRefreshDriver> >&) srcsrc/layout/base/nsRefreshDriver.cpp:327:7
    #12 0x7fed00c0c4a4 in mozilla::RefreshDriverTimer::Tick(mozilla::layers::BaseTransactionId<mozilla::VsyncIdType>, mozilla::TimeStamp) srcsrc/layout/base/nsRefreshDriver.cpp:344:5
    #13 0x7fed00c0f3c6 in mozilla::VsyncRefreshDriverTimer::RefreshDriverVsyncObserver::TickRefreshDriver(mozilla::layers::BaseTransactionId<mozilla::VsyncIdType>, mozilla::TimeStamp) srcsrc/layout/base/nsRefreshDriver.cpp:710:16
    #14 0x7fed00c0e83e in mozilla::VsyncRefreshDriverTimer::RefreshDriverVsyncObserver::NotifyVsync(mozilla::VsyncEvent const&) srcsrc/layout/base/nsRefreshDriver.cpp:605:9
    #15 0x7fed012b197b in mozilla::layout::VsyncChild::RecvNotify(mozilla::VsyncEvent const&) srcsrc/layout/ipc/VsyncChild.cpp:65:16
    #16 0x7fecfb319909 in mozilla::layout::PVsyncChild::OnMessageReceived(IPC::Message const&) srcsrc/obj-firefox/ipc/ipdl/PVsyncChild.cpp:187:54
    #17 0x7fecfb14623b in mozilla::ipc::PBackgroundChild::OnMessageReceived(IPC::Message const&) srcsrc/obj-firefox/ipc/ipdl/PBackgroundChild.cpp:4717:32
    #18 0x7fecfad9c171 in mozilla::ipc::MessageChannel::DispatchAsyncMessage(mozilla::ipc::ActorLifecycleProxy*, IPC::Message const&) srcsrc/ipc/glue/MessageChannel.cpp:2158:25
    #19 0x7fecfad99994 in mozilla::ipc::MessageChannel::DispatchMessage(IPC::Message&&) srcsrc/ipc/glue/MessageChannel.cpp:2082:9
    #20 0x7fecfad9a68e in mozilla::ipc::MessageChannel::RunMessage(mozilla::ipc::MessageChannel::MessageTask&) srcsrc/ipc/glue/MessageChannel.cpp:1939:3
    #21 0x7fecfad9ad73 in mozilla::ipc::MessageChannel::MessageTask::Run() srcsrc/ipc/glue/MessageChannel.cpp:1970:13
    #22 0x7fecf9f6a601 in nsThread::ProcessNextEvent(bool, bool*) srcsrc/xpcom/threads/nsThread.cpp:1225:14
    #23 0x7fecf9f70d2c in NS_ProcessNextEvent(nsIThread*, bool) srcsrc/xpcom/threads/nsThreadUtils.cpp:486:10
    #24 0x7fecfada36e1 in mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) srcsrc/ipc/glue/MessagePump.cpp:110:5
    #25 0x7fecfacc568c in MessageLoop::RunInternal() srcsrc/ipc/chromium/src/base/message_loop.cc:315:10
    #26 0x7fecfacc5500 in MessageLoop::Run() srcsrc/ipc/chromium/src/base/message_loop.cc:290:3
    #27 0x7fed0082ad1a in nsBaseAppShell::Run() srcsrc/widget/nsBaseAppShell.cpp:137:27
    #28 0x7fed037f5a14 in XRE_RunAppShell() srcsrc/toolkit/xre/nsEmbedFunctions.cpp:919:20
    #29 0x7fecfada43c9 in mozilla::ipc::MessagePumpForChildProcess::Run(base::MessagePump::Delegate*) srcsrc/ipc/glue/MessagePump.cpp:238:9
    #30 0x7fecfacc568c in MessageLoop::RunInternal() srcsrc/ipc/chromium/src/base/message_loop.cc:315:10
    #31 0x7fecfacc5500 in MessageLoop::Run() srcsrc/ipc/chromium/src/base/message_loop.cc:290:3
    #32 0x7fed037f503c in XRE_InitChildProcess(int, char**, XREChildData const*) srcsrc/toolkit/xre/nsEmbedFunctions.cpp:754:34
    #33 0x56055276dd67 in content_process_main(mozilla::Bootstrap*, int, char**) srcsrc/browser/app/../../ipc/contentproc/plugin-container.cpp:56:28
    #34 0x56055276e134 in main srcsrc/browser/app/nsBrowserApp.cpp:267:18

I think this assertion is bogus. In this testcase, there is an SVG animation that changes pointer-events from "4" to "none", so in the resulting display list, the item should not have hit test info set.
Another case that I can think of is that if we rebuild display items for the parent frame that now has hit test info as the "old" child item, the "new" child item can reuse the parent frame hit test info.

(In reply to Miko Mynttinen [:miko] from comment #1)

I think this assertion is bogus. In this testcase, there is an SVG animation that changes pointer-events from "4" to "none", so in the resulting display list, the item should not have hit test info set.
Another case that I can think of is that if we rebuild display items for the parent frame that now has hit test info as the "old" child item, the "new" child item can reuse the parent frame hit test info.

I don't entirely understand this. Shouldn't the CopyASR code only be running if we didn't invalidate? I'd expect changing pointer-events to invalidate, so we should just have new items without hit-test information and not be copying things around.

fyi, bughunter has seen this in the wild on 17 urls in the last 2 months on Linux and Windows. The most recent two which I've reproduced on Fedora 30 and Ubuntu 19.10 are:

• https://toptoon.com/
• https://www.digikala.com/

There's a r+ patch which didn't land and no activity in this bug for 2 weeks.
:miko, could you have a look please?
For more information, please visit auto_nag documentation.

(In reply to Release mgmt bot [:sylvestre / :calixte / :marco for bugbug] from comment #5)

There's a r+ patch which didn't land and no activity in this bug for 2 weeks.
:miko, could you have a look please?
For more information, please visit auto_nag documentation.

Comment 3 made me question my assumptions, and it should be verified that we are not just papering over an invalidation issue.

This code no longer exists.