Named getter on Document doesn't work properly on return value of DOMParser.prototype.parseFromString
Reported by
bzbar...@mit.edu,
Mar 11 2016
|
|||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:47.0) Gecko/20100101 Firefox/47.0 Example URL: See testcase Steps to reproduce the problem: 1. Load this HTML <script> var parser = new DOMParser(); var str = '<img name="name" />'; console.log(parser.parseFromString(str, 'text/html').name); </script> What is the expected behavior? Should log the image. What went wrong? Logs undefined. Does it occur on multiple sites: N/A Is it a problem with a plugin? N/A Did this work before? N/A Does this work in other browsers? Yes Chrome version: 50.0.2661.18 (Official Build) dev (64-bit) Channel: n/a OS Version: OS X 10.10 Flash Version: Shockwave Flash 20.0 r0 This works correctly in Firefox and Safari. Haven't tested IE.
,
Mar 11 2016
You should look at the console output, not the page itself.
,
Mar 14 2016
,
Mar 16 2016
Able to reproduce the issue on Windows 7, Ubuntu 14.04 and Mac OS 10.11.3 using chrome stable M49-49.0.2623.87. Observed the log in the console displayed as undefined. This is a non-regression issue seem from M35-35.0.1851.0, Hence marking it as untriaged.
,
Mar 16 2016
,
Mar 25 2016
,
Jun 21 2016
This is because we synthesize the accessors on the Document through the Window: https://cs.chromium.org/chromium/src/third_party/WebKit/Source/bindings/core/v8/WindowProxy.cpp?sq=package:chromium&dr=C&rcl=1466464582&l=523 which we only do if the Document has a frame: https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/html/HTMLDocument.cpp?sq=package:chromium&dr=C&rcl=1466464582&l=173 Safari is actually using an interceptor here: https://github.com/WebKit/webkit/blob/421fe0035ef1cbf77d877981b1dc15505ae8ce65/Source/WebCore/bindings/js/JSHTMLDocumentCustom.cpp#L95 I don't know if we can use an interceptor on Document without slowing everything down like createElement. jochen@, verwaest@ ? Can we do what we did for .style like this? https://cs.chromium.org/chromium/src/out/Debug/gen/blink/bindings/core/v8/V8CSSStyleDeclaration.cpp?q=V8CSSStyleDeclaration.cpp&sq=package:chromium&l=348 v8::NamedPropertyHandlerConfiguration namedPropertyHandlerConfig(CSSStyleDeclarationV8Internal::namedPropertyGetterCallback, CSSStyleDeclarationV8Internal::namedPropertySetterCallback, CSSStyleDeclarationV8Internal::namedPropertyQueryCallback, 0, CSSStyleDeclarationV8Internal::namedPropertyEnumeratorCallback, v8::Local<v8::Value>(), static_cast<v8::PropertyHandlerFlags>(int(v8::PropertyHandlerFlags::kOnlyInterceptStrings) | int(v8::PropertyHandlerFlags::kNonMasking))); instanceTemplate->SetHandler(namedPropertyHandlerConfig);
,
Jun 21 2016
I think Toon has a plan to cache named properties on V8 side so that V8 doesn't need to call the interceptor every time. Once it's done, we can just add an interceptor to Document.
,
Jun 22 2016
Just FYI, peria@ once fixed this issue at https://crrev.com/1837823003 , but it got reverted due to a performance regression. As haraken@ wrote, once the performance issue will be solved, we can land a basically same fix, I think.
,
Jun 22 2016
,
Jun 22 2016
Yes, I'd like to land the CL in #10 again, if we can avoid the performance regression with Toon's plan in #9.
,
Jul 1 2016
,
Aug 28 2017
,
May 3 2018
,
May 25 2018
|
|||||||||||
►
Sign in to add a comment |
|||||||||||
Comment 1 by rnimmagadda@chromium.org
, Mar 11 2016Labels: Needs-Feedback
150 bytes
150 bytes View Download