Bug 994357 makes use of the <template> element to create inert DOM fragments, sanitize it and insert into the document's DOM. However, neither appendChild nor importNode methods work with template.content in the Gaia build system, which uses DOMParser to parse HTML into 'document' objects. The error is: Exception: [Exception... "Unexpected error" nsresult: "0x8000ffff (NS_ERROR_UNEXPECTED)" location: "JS frame :: resource://gre/modules/commonjs/toolkit/loader.js -> file:///srv/moz/gaia/build/utils-xpc.js -> file:///srv/moz/gaia/shared/js/l10n.js?d=1413568450327 :: overlayElement :: line 1867" data: no] I'm filing this in Gaia::Build, but it's likely that it belongs in one of the platform components.

A minimal testcase can be found on my branch: https://github.com/stasm/gaia/tree/1084502-unexpected Simply run: make bug1084502

Here's a small testcase which one can be used to reproduce the problem. I built Firefox with --enable-debug and ran it with: LD_LIBRARY_PATH=/home/stas/moz/gecko-dev/obj-x86_64-unknown-linux-gnu/dist/bin/ ~/moz/gecko-dev/obj-x86_64-unknown-linux-gnu/dist/bin/xpcshell -f ~/tmp/bug1084502.js Following is the output that I'm getting: -- tmpl.content is: [object DocumentFragment] -- Trying appendChild(tmpl.content) [25959] WARNING: NS_ENSURE_TRUE((nsContentUtils::IsChromeDoc(currentDoc) || (!currentDoc->GetScriptHandlingObject(hasHadScriptHandlingObject) && !hasHadScriptHandlingObject))) failed: file /srv/moz/gecko-dev/content/base/src/nsNodeUtils.cpp, line 347 [25959] WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x8000FFFF: file /srv/moz/gecko-dev/content/base/src/nsINode.cpp, line 1455 [Exception... "Unexpected error" nsresult: "0x8000ffff (NS_ERROR_UNEXPECTED)" location: "JS frame :: /home/stas/tmp/bug1084502.js :: <TOP_LEVEL> :: line 48" data: no] -- Trying importNode(tmpl.content) [25959] WARNING: NS_ENSURE_TRUE((nsContentUtils::IsChromeDoc(currentDoc) || (!currentDoc->GetScriptHandlingObject(hasHadScriptHandlingObject) && !hasHadScriptHandlingObject))) failed: file /srv/moz/gecko-dev/content/base/src/nsNodeUtils.cpp, line 347 [Exception... "Unexpected error" nsresult: "0x8000ffff (NS_ERROR_UNEXPECTED)" location: "JS frame :: /home/stas/tmp/bug1084502.js :: <TOP_LEVEL> :: line 56" data: no] -- Testcase EOF. [25959] WARNING: XPCOM objects created/destroyed from static ctor/dtor: file /srv/moz/gecko-dev/xpcom/base/nsTraceRefcnt.cpp, line 144 [25959] WARNING: XPCOM objects created/destroyed from static ctor/dtor: file /srv/moz/gecko-dev/xpcom/base/nsTraceRefcnt.cpp, line 144 nsStringStats => mAllocCount: 2838 => mReallocCount: 445 => mFreeCount: 2838 => mShareCount: 3564 => mAdoptCount: 70 => mAdoptFreeCount: 70 => Process ID: 25959, Thread ID: 140447887297088

This is not really a DOM bug, since everything works as expected from browser point of view. Whether or not we could or should have less strict security checks in xpcshell is a different question. But looking.

Aha, there is a bug. bug 820170 made us default to JunkScope for Documents and Bug 1017896 made us set mHasHadScriptHandlingObject rather unusual way.

This makes us copy the behavior of the original document to the template doc.

Comment on attachment 8508980 [details] [diff] [review] patch [Approval Request Comment] Bug caused by (feature/regressing bug #): I originally filed this bug to unblock me in bug 994357 which is about adding a method to sanitize translations in Gaia. Unfortunately, it turned out Gaia uses B2G 34 for building. I tried to switch Gaia to using a newer version of Gecko (bug 1089710) but this attempt hasn't been successful so far due to some obscure Mac packaging problems (bug 1101331). It seems that we're stuck with Gecko 34 for building Gaia for now. Given the minimal impact this bug has, would it be possible to uplift it to b2g34? This would unblock me again in bug 994357 without my having to wait for Gecko to be upgraded in bug 1089710. Please note that I only need this for building Gaia. User impact if declined: I can't implement HTML sanitization in bug 994357 for Gaia master. Testing completed: I tested with a custom build of Gecko 34. Also, this has been shipped in Gecko 36 and there haven't been any problems for past 4 months. Risk to taking this patch (and alternatives if risky): low String or UUID changes made by this patch: none

Comment on attachment 8508980 [details] [diff] [review] patch Removing the approval request because bug 1089710 was fixed :)