795923 - setting display:none sometimes causes crash - [@ nsDisplayList::HitTest(nsDisplayListBuilder*, nsRect const&, nsDisplayItem::HitTestState*, nsTArray<nsIFrame*, nsTArrayDefaultAllocator>*) ]

Status: RESOLVED WORKSFORME

(Core :: Layout, defect)

Description

[trjh2k2]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20100101 Firefox/15.0.1
Build ID: 20120905151427

Steps to reproduce:

Setting display:none via element.setAttribute('style', 'display:none'), or using jQuery - $(elem).hide()


Actual results:

Sometimes Crash, happens seemingly at random.
report here: https://crash-stats.mozilla.com/report/index/cc26a06f-0337-4585-b434-6877a2120928


Expected results:

Not crash, div becomes hidden

Comment 1

[Scoobidiver (away)]

Does it happen in Safe Mode (see https://support.mozilla.org/kb/troubleshoot-firefox-issues-using-safe-mode)?
Does it happen in Nightly to download from http://nightly.mozilla.org?

Comment 2

[trjh2k2]

It does happen in safe mode, and it happens in "Aurora".  I'll try nightly in a moment.

Comment 3

[trjh2k2]

It happens in nightly too, but crashes in a slightly different place, this time at GetMouseThrough().

New crash report: https://crash-stats.mozilla.com/report/index/bp-80733413-d241-4807-bc5f-3b1662121001

I'm working on trying to recreate the crash on another page so it'll have just the part that crashes on it.

Comment 4

[prosp4300]

Similar issue I encountered in both Firefox 17 and Firefox 16
https://crash-stats.mozilla.com/report/index/d99764b5-d146-40dc-9b07-237bb2121121

I'm wonder about the workaround, is element.style.display="none" can avoid this crash

Thanks

Comment 5

[prosp4300]

All the crash reports point to 
layout/base/nsDisplayList.cpp:1186
f->GetStyleVisibility()->mPointerEvents != NS_STYLE_POINTER_EVENTS_NONE) {

This code is added for bug 508179, which mainly for SVG

The page I encounter this crash does contain SVG graph based on Raphael JS

CC jwatt to see any idea to get workaround

Comment 6

[prosp4300]

Seems this crash can be reproduced always if I hover my mouse on SVG content before page fully loaded

So this issue definitely caused by mouse event for SVG

I not able to reproduce it for static SVG content, instead, our SVG is based on ajax callback data to draw completely while page load

Comment 7

[Robert Kaiser]

(In reply to prosp4300 from comment #6)
> I not able to reproduce it for static SVG content, instead, our SVG is based
> on ajax callback data to draw completely while page load

Is some SVG content that can reproduce this public? If so, can you point us to it so we can have a developer look into reproducing and debugging?

Comment 8

[Jonathan Watt [:jwatt]]

Yeah, we need a testcase here in order to debug the issue (and potentially suggest workarounds while we fix the issue).

Comment 9

[Jonathan Watt [:jwatt]]

trjh2k2, prosp4300, we need you to point us to an example of some SVG that causes this crash before we can make any progress here.

Comment 10

[prosp4300]

Our application is commercial one and not available publicly, so I'll try to collect all the conditions that together cause the crash, then I can create a simple page that can reproduce it consistently and easily and provide the source code here for you to debug

This progress may take some time, the conditions I collect currently doesn't reproduce it in another page with simple SVG. Those conditions include following:

1. switch between display:none and display:block at least 3 times(similar as loadsign behaviour for 3 ajax requests)
2. mouse hover on SVG graph

Comment 11

[Wayne Mery (:wsmwk)]

testcase still needed ...
(In reply to prosp4300 from comment #10)
> Our application is commercial one and not available publicly, so I'll try to
> collect all the conditions that together cause the crash, then I can create
> a simple page that can reproduce it consistently and easily and provide the
> source code here for you to debug
> 
> This progress may take some time, the conditions I collect currently doesn't
> reproduce it in another page with simple SVG. Those conditions include
> following:
> 
> 1. switch between display:none and display:block at least 3 times(similar as
> loadsign behaviour for 3 ajax requests)
> 2. mouse hover on SVG graph

I wonder if this might the the same as bug 617753. Although I no longer find examples of its signature in crash-stats, the stack for bp-38ae-419f-8d8f-cfd992130605 matches this bug report. signature nsTArray_base<nsTArrayFallibleAllocator>::~nsTArray_base<nsTArrayFallibleAllocator>() | nsDisplayList::HitTest(nsDisplayListBuilder*, nsRect const&, nsDisplayItem::HitTestState*, nsTArray<nsIFrame*, nsTArrayDefaultAllocator>*)

Comment 12

[prosp4300]

From my testing, seems the problem has gone from firefox 20, below is the crash report links for firefox 17, 18, 19

So I think this issue has been fixed.


Firefox 19.0.2 Crash Report [@ GetMouseThrough ]
https://crash-stats.mozilla.com/report/index/20c5bf78-969d-4371-949a-fd4612130910

Firefox 18.0.2 Crash Report [@ nsDisplayList::HitTest(nsDisplayListBuilder*, nsRect const&, nsDisplayItem::HitTestState*, nsTArray<nsIFrame*, nsTArrayDefaultAllocator>*) ]
https://crash-stats.mozilla.com/report/index/26376281-6227-411a-b056-9f9962130910

Firefox 17.0.5esr Crash Report [@ nsDisplayList::HitTest(nsDisplayListBuilder*, nsRect const&, nsDisplayItem::HitTestState*, nsTArray<nsIFrame*, nsTArrayDefaultAllocator>*) ]
https://crash-stats.mozilla.com/report/index/cd99e220-ab4f-40f1-96e0-bd8c42130910

Comment 13

[Mats Palmgren (inactive)]

Still occurs in low volume in Firefox 37/38/40 according to crash-stats.

Comment 14

[Mats Palmgren (inactive)]

It's unclear whether the current crop of nsDisplayList::HitTest crashes
has anything to do with the original problem though and since the
reporter said he couldn't reproduce this bug in FF20 (in comment 12)
it seems not worth tracking.

[e-mail], please reopen if it occurs again in a recent
version of Firefox.  Thanks for your report.