<html>
<head>
<base href="https://bugs.webkit.org/" />
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - jQuery 'is' implementation causes exception to be thrown"
href="https://bugs.webkit.org/show_bug.cgi?id=151165#c3">Comment # 3</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - jQuery 'is' implementation causes exception to be thrown"
href="https://bugs.webkit.org/show_bug.cgi?id=151165">bug 151165</a>
from <span class="vcard"><a class="email" href="mailto:cdumez@apple.com" title="Chris Dumez <cdumez@apple.com>"> <span class="fn">Chris Dumez</span></a>
</span></b>
<pre>(In reply to <a href="show_bug.cgi?id=151165#c0">comment #0</a>)
<span class="quote">> Created <span class=""><a href="attachment.cgi?id=265332" name="attach_265332" title="Example that triggers the issue.">attachment 265332</a> <a href="attachment.cgi?id=265332&action=edit" title="Example that triggers the issue.">[details]</a></span>
> Example that triggers the issue.
>
> While debugging another issue, I noticed that exceptions were being thrown
> inside JSC in a fairly simple jQuery test page. These 'exceptions' are not
> catchable in script, and seem to be consumed inside WebKit without
> triggering any external exception handling behavior. Perhaps this is normal
> and expected, but I'm writing this bug up so we can make that decision.
>
> Consider the following code:
>
> if (!elem.is(":visible")) {
> ... do something
> }
>
> When this code is executed (at least in jQuery 2.1.4), we are encountering a
> DOMError 12 (Syntax Error) being generated in the
> WebCore::JsElementPrototypeFunctionMatches method.
>
> + 377024 ( 408808 - 31784) 373 allocsBackTrace175CD6B0
> + 344 ( 373 - 29)BackTrace175CD6B0allocations
>
> ntdll!RtlpCallInterceptRoutine+26
> ntdll!RtlReAllocateHeap+3E7B1
> WTF!realloc+43 (f:\dd\vctools\crt\crtw32\heap\realloc.c, 85)
> WTF!WTF::fastRealloc+E (c:\bwa\wtf-7601.2.3\srcroot\wtf\fastmalloc.cpp,
> 155)
> WTF!WTF::StringImpl::reallocateInternal<unsigned char>+72
> (c:\bwa\wtf-7601.2.3\srcroot\wtf\text\stringimpl.cpp, 224)
> WTF!WTF::StringImpl::reallocate+23
> (c:\bwa\wtf-7601.2.3\srcroot\wtf\text\stringimpl.cpp, 231)
> WTF!WTF::StringBuilder::reallocateBuffer<unsigned char>+4F
> (c:\bwa\wtf-7601.2.3\srcroot\wtf\text\stringbuilder.cpp, 150)
> WTF!WTF::StringBuilder::appendUninitializedSlow<unsigned char>+3C
> (c:\bwa\wtf-7601.2.3\srcroot\wtf\text\stringbuilder.cpp, 235)
> WTF!WTF::StringBuilder::append+73
> (c:\bwa\wtf-7601.2.3\srcroot\wtf\text\stringbuilder.cpp, 283)
> JavaScriptCore!JSC::Interpreter::stackTraceAsString+C5
> (c:\bwa\javascriptcore-7601.2.3\srcroot\interpreter\interpreter.cpp, 580)
> JavaScriptCore!JSC::addErrorInfoAndGetBytecodeOffset+2D2
> (c:\bwa\javascriptcore-7601.2.3\srcroot\runtime\error.cpp, 179)
> JavaScriptCore!JSC::addErrorInfo+39
> (c:\bwa\javascriptcore-7601.2.3\srcroot\runtime\error.cpp, 190)
> WebKit!WebCore::createDOMException+273
> WebKit!WebCore::setDOMException+4B
> WebKit!WebCore::jsElementPrototypeFunctionMatches+12A
>
> The jsElementPrototypeFunctionMatches implementation calls the
> Element::matches method, which eventually takes us to
> SelectorQueryCache::add:
>
> SelectorQuery* SelectorQueryCache::add(const String& selectors,
> Document& document, ExceptionCode& ec)
> SelectorQuery* Document::selectorQueryForString(const String&
> selectorString, ExceptionCode& ec)
> bool Element::matches(const String& selector, ExceptionCode& ec)
>
> When SelectorQueryCache::add parses the document looking for selectors, and
> does not find a match the exception code is set to 12 (SYNTAX_ERR) and it
> does an early return.
>
> This returns a false value, and everyone is happy. Except, the presence of
> the SYNTAX_ERR code causes us to generate an exception objects:
>
> JSValue result = jsBoolean(impl.matches(selectors, ec));
>
> setDOMException(state, ec);
> return JSValue::encode(result);
>
> The call to 'setDOMException' creates an exception object, which lives in
> the JSC heap until it gets cleaned up. The exception object is fairly
> heavy-weight, since it contains a call stack and other information about the
> error location. In some jQuery applications we measured, this can produce a
> few Megabytes of memory use within a short period.
>
> I'm wondering if we really do want to be treating this 'normal' matches case
> as an exception.</span >
If we throw, this likely means that we were unable to parse this selector. Throwing in such case is as per the spec. However, I am not familiar enough with this selector to know if it is valid.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>