Closed Bug 461772 Opened 11 years ago Closed 11 years ago

clip-path with video crashes firefox with walnut theme [@ nsXBLBinding::InstallAnonymousContent]

Categories

(Core :: XBL, defect, critical)

x86
Linux
defect
Not set
critical

Tracking

()

VERIFIED FIXED

People

(Reporter: sky, Assigned: smaug)

References

()

Details

(Keywords: crash)

Crash Data

Attachments

(2 files, 1 obsolete file)

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1b2pre) Gecko/20081027 Minefield/3.1b2pre
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1b2pre) Gecko/20081027 Minefield/3.1b2pre

The path clipping breaks when used with video.
related to amd64 bit?

Reproducible: Always

Steps to Reproduce:
1. Goto http://www.mozbox.org/jdll/video.xhtml
2. Click 'Clip-path [1]' button
3. browser crashes.
Actual Results:  
browser crashes

Expected Results:  
pretty clipping of video
It seems running it in safe-mode fixes it.  Sorry for the false report.
Status: UNCONFIRMED → RESOLVED
Closed: 11 years ago
Resolution: --- → INVALID
if safe mode fixes it, this is probably caused by an extension, it'd be great if you could try not using safe mode and disable say half of your extensions to see if the problem is still present. if you can find a single extension which is responsible, the problem can eventually be reported to them.

we'd still like a stack trace too btw.
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
Attached file stack trace from crash
I traced it down to the Walnut theme, and reported it to the theme developer.  Stack trace attached.
My theme (Walnut) only changes the background color of the video control bar from semitransparent grey to fully transparent grey. 
Note, this demo did crash on my machine (WinXP) before, but when I test this with the current build (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2pre) Gecko/20081027 Minefield/3.1b2pre) it no longer crashes...
Even if it is something in my theme(s), the browser should never crash on it...
Attachment #345097 - Attachment mime type: text/x-log → text/plain
ok, that stack trace isn't helpful.

try installing iceweasel + iceweasel-dbg or something and crashing w/ that.

or use crash reporter....
Severity: normal → critical
Keywords: crash
Hardware: Macintosh → PC
Summary: clip-path with video crashes firefox → clip-path with video crashes firefox with walnut theme
Version: unspecified → Trunk
Crashreport submitted:
Add-ons: {fce36c1e-58d8-498a-b2a5-66ad1cedebbb}:0.76,inspector@mozilla.org:2.0.1,{D4DD63FA-01E4-46a7-B6B1-EDAB7D6AD389}:0.9.6.3,feedly@devhd:1.2,{972ce4c6-7e08-4474-a285-3208198ce6fd}:3.1b2pre,{29852C08-1E91-4889-A6BF-C77F91D6A8F3}:1.8.42,{403304EE-066A-4a2a-8F41-F12028480A0A}:1.8.42,{6C4BAFB6-2AC2-4405-A98D-546B55B3AE92}:1.8.42,{7DA90D46-1B69-4cc5-9ACE-CB64D8D85B00}:1.8.41a,{5A170DD3-63CA-4c58-93B7-DE9FF536C2FF}:1.8.42
BuildID: 20081027034233
CrashTime: 1225265157
Email: alfredkayser@gmail.com
InstallTime: 1225186428
ProductName: Firefox
SecondsSinceLastCrash: 56761
StartupTime: 1225264779
Theme: walnut
UserID: f8a627cd-f186-46d3-92c1-0b5f491f11e2
Vendor: Mozilla
Version: 3.1b2pre
The crash reporter doesn't seem to be working.  Is there something I can grep/look for in the stack trace to know whether it's 'helpful?'

The standard instructions don't seem to work.
The crashreport link:
http://crash-stats.mozilla.com/report/index/ea9eb4cf-a58a-11dd-99bb-001cc45a2ce4

As that report is still being processed, here one that is probably also this video crash:
http://crash-stats.mozilla.com/report/index/89e1c4b8-9ead-11dd-ae93-001cc4e2bf68
Signature	nsXBLBinding::InstallAnonymousContent(nsIContent*, nsIContent*)
UUID	ea9eb4cf-a58a-11dd-99bb-001cc45a2ce4
Time	2008-10-29 00:25:57-07
Uptime	378
Product	Firefox
Version	3.1b2pre
Build ID	20081027034233
OS	Windows NT
OS Version	5.1.2600 Service Pack 3
CPU	x86
CPU Info	GenuineIntel family 6 model 15 stepping 11
Crash Reason	EXCEPTION_ACCESS_VIOLATION
Crash Address	0x0
Comments	Video crashing with clip in my Walnut theme.
Crashing Thread
Frame 	Module 	Signature 	Source
0 	xul.dll 	nsXBLBinding::InstallAnonymousContent 	content/xbl/src/nsXBLBinding.cpp:350
1 	xul.dll 	nsXBLBinding::GenerateAnonymousContent 	content/xbl/src/nsXBLBinding.cpp:661
2 	xul.dll 	nsXBLService::LoadBindings 	content/xbl/src/nsXBLService.cpp:628
3 	xul.dll 	nsCSSFrameConstructor::ConstructFrameInternal 	layout/base/nsCSSFrameConstructor.cpp:7444
4 	xul.dll 	nsCSSFrameConstructor::ConstructFrame 	layout/base/nsCSSFrameConstructor.cpp:7399
5 	xul.dll 	nsCSSFrameConstructor::ProcessChildren 	layout/base/nsCSSFrameConstructor.cpp:11262
6 	xul.dll 	nsCSSFrameConstructor::ConstructXULFrame 	layout/base/nsCSSFrameConstructor.cpp:6203
7 	xul.dll 	nsCSSFrameConstructor::ConstructFrameInternal 	layout/base/nsCSSFrameConstructor.cpp:7539
8 	xul.dll 	nsCSSFrameConstructor::ConstructFrame 	layout/base/nsCSSFrameConstructor.cpp:7399
9 	xul.dll 	nsCSSFrameConstructor::CreateAnonymousFrames 	layout/base/nsCSSFrameConstructor.cpp:5725
10 	xul.dll 	nsCSSFrameConstructor::BeginBuildingScrollFrame 	layout/base/nsCSSFrameConstructor.cpp:6331
11 	xul.dll 	nsCSSFrameConstructor::ConstructRootFrame 	layout/base/nsCSSFrameConstructor.cpp:4578
12 	xul.dll 	PresShell::InitialReflow 	layout/base/nsPresShell.cpp:2417
13 	xul.dll 	nsContentSink::StartLayout 	content/base/src/nsContentSink.cpp:1283
14 	xul.dll 	nsXMLContentSink::MaybeStartLayout 	content/xml/document/src/nsXMLContentSink.cpp:945
15 	xul.dll 	nsXMLContentSink::HandleStartElement 	content/xml/document/src/nsXMLContentSink.cpp:1098
16 	xul.dll 	nsXMLContentSink::HandleStartElement 	content/xml/document/src/nsXMLContentSink.cpp:996
17 	xul.dll 	Driver_HandleStartElement 	parser/htmlparser/src/nsExpatDriver.cpp:97
18 	xul.dll 	doContent 	parser/expat/lib/xmlparse.c:2439
19 	xul.dll 	doProlog 	parser/expat/lib/xmlparse.c:4075
20 	xul.dll 	prologInitProcessor 	parser/expat/lib/xmlparse.c:3626
21 	xul.dll 	MOZ_XML_Parse 	parser/expat/lib/xmlparse.c:1528
22 	xul.dll 	nsExpatDriver::ConsumeToken 	parser/htmlparser/src/nsExpatDriver.cpp:1128
23 	xul.dll 	nsParser::Tokenize 	parser/htmlparser/src/nsParser.cpp:3012
24 	xul.dll 	nsParser::ResumeParse 	parser/htmlparser/src/nsParser.cpp:2219
25 	xul.dll 	nsParser::OnDataAvailable 	parser/htmlparser/src/nsParser.cpp:2870
26 	xul.dll 	nsExternalResourceMap::PendingLoad::OnDataAvailable 	content/base/src/nsDocument.cpp:1064
27 	xul.dll 	nsStreamListenerTee::OnDataAvailable 	netwerk/base/src/nsStreamListenerTee.cpp:97
28 	xul.dll 	nsHttpChannel::OnDataAvailable 	netwerk/protocol/http/src/nsHttpChannel.cpp:4858
29 	xul.dll 	nsInputStreamPump::OnStateTransfer 	netwerk/base/src/nsInputStreamPump.cpp:508

the other one is a vlc bug - bug 462157
Component: Video/Audio → XBL
QA Contact: video.audio → xbl
Summary: clip-path with video crashes firefox with walnut theme → clip-path with video crashes firefox with walnut theme [@ nsXBLBinding::InstallAnonymousContent]
InstallAnonymousContent is crashes on a null param aContent...
Blocks: 456271
Assignee: nobody → Olli.Pettay
Status: UNCONFIRMED → NEW
Ever confirmed: true
Because of bug 456271 we can backout (XBL part of) bug 451037.
Blocks: 451037
Attached patch possible patch (obsolete) — Splinter Review
This way XBL can be used in external docs.
I need to write some testcase.
Attachment #345306 - Flags: superreview?(bzbarsky)
Attachment #345306 - Flags: review?(jonas)
So what's this patch actually doing, and why does it fix this bug?
For some reason (overflow, whatever) scrollbar is attached to the external
document. That document doesn't have object for script handling, so
cloning XBL (in which event handling is current disabled) element to that
document
doesn't work.
Because bug 456271 protects "non-scriptabable" nodes not to be used in content
scripts, the safety fix for bug 451037 can be backed out.
When you say "external" document do you mean the XBL binding document?

Shouldn't whatever code is involved handle cloning failure?
(In reply to comment #19)
> When you say "external" document do you mean the XBL binding document?
I mean the external svg document which is used to add the effects.
Oh, I see.  But we're cloning from a document with no script handling object (the XBL proto doc) to one without a script handling object (the external resource document).  That should work, no?
That should work, but ClearScriptHandlingObject marks document to have had
a script handling object. So that is why the patch removes those calls.
Can we fix ClearScriptHandlingObject to not do said flagging if there wasn't a script handling object already, in addition to this change?
This backouts Bug 451037.
Attachment #345306 - Attachment is obsolete: true
Attachment #345346 - Flags: superreview?(bzbarsky)
Attachment #345346 - Flags: review?(bzbarsky)
Attachment #345306 - Flags: superreview?(bzbarsky)
Attachment #345306 - Flags: review?(jonas)
Attachment #345346 - Flags: superreview?(bzbarsky)
Attachment #345346 - Flags: superreview+
Attachment #345346 - Flags: review?(bzbarsky)
Attachment #345346 - Flags: review+
Checked in. Will write some testcases asap!
Status: NEW → RESOLVED
Closed: 11 years ago11 years ago
Flags: in-testsuite?
Resolution: --- → FIXED
v=ak!
Status: RESOLVED → VERIFIED
Crash Signature: [@ nsXBLBinding::InstallAnonymousContent]
Flags: in-testsuite? → in-testsuite-
You need to log in before you can comment on or make changes to this bug.