****Bulk Edit****

Setting as P1 for test team to prioritize in triaging.

randomnt@ Could you please provide us any sample test file or URL to triage the issue from test team end.

Thanks,

working https://jsfiddle.net/tson91ok/1/
and not https://jsfiddle.net/tson91ok/2/

Able to reproduce the issue on windows 7 , Linux Ubuntu 14.04 and Mac 10.12.2 using chrome version 56.0.2924.87 and canary 58.0.3011.0.
This is regression issue broken in M56. Please find the bisect information as below

Narrow Bisect::
Good :: 56.0.2889.0  --   (build revision 424926)
Bad :: 56.0.2900.0  --   (build revision 427219)

Change Log::
https://chromium.googlesource.com/chromium/src/+log/93612d557c57266bb656d83ceb48469cd13bef03..24536c160bde7ac77a70417a6a510b263ec1be86

Possible suspect::
https://chromium.googlesource.com/chromium/src/+/24536c160bde7ac77a70417a6a510b263ec1be86

dominicc@ Could you please look into this issue if it is related to your change,else please help us in finding the appropriate owner for this issue.

Thanks,

Thank you for the detailed bug report. The bisect is probably correct. When I run this in an ASAN build I see this log line:

runtime error: file  line 1 element variable
Internal error in xsltFlagRVTs(): Cannot retrieve the doc of a node.

Probably need to investigate what's on the stack at that point--presumably it's processing the result of node-set--and what type it thinks it is.

Here's a simpler repro. Note you can use DOMParser to parse XML on the client.

This one is "bad"; if you replace name="test"></xsl:variable with name="test">x</xsl:variable you can see the expected behavior.

Deleted: index.html 729 bytes

index.html 729 bytes View Download

Patch up at https://codereview.chromium.org/2750943004

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/3f6e482b7f13c1fc5bd68227321ef6da0ddf9937

commit 3f6e482b7f13c1fc5bd68227321ef6da0ddf9937
Author: dominicc <dominicc@chromium.org>
Date: Fri Mar 17 05:16:02 2017

node-set($x), when $x is empty, should not halt XSLT processing

node-set is polymorphic; if called with a string, it returns a
node-set containing a text node with that content. The libxslt roll in
r425586 broke this behavior because Blink's fork of the node-set
extension returned a text node without an owner document. Fix that.

BUG= 689977 

Review-Url: https://codereview.chromium.org/2750943004
Cr-Commit-Position: refs/heads/master@{#457692}

[add] https://crrev.com/3f6e482b7f13c1fc5bd68227321ef6da0ddf9937/third_party/WebKit/LayoutTests/fast/xsl/xslt-node-set-empty.html
[modify] https://crrev.com/3f6e482b7f13c1fc5bd68227321ef6da0ddf9937/third_party/WebKit/Source/core/xml/XSLTExtensions.cpp

58 as well

Your change meets the bar and is auto-approved for M58. Please go ahead and merge the CL to branch 3029 manually. Please contact milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), bhthompson@(ChromeOS), govind@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/99ead7d1564d35a70799b7ee4c3821053fb3985c

commit 99ead7d1564d35a70799b7ee4c3821053fb3985c
Author: Oliver Chang <ochang@chromium.org>
Date: Tue Mar 28 16:44:31 2017

node-set($x), when $x is empty, should not halt XSLT processing

node-set is polymorphic; if called with a string, it returns a
node-set containing a text node with that content. The libxslt roll in
r425586 broke this behavior because Blink's fork of the node-set
extension returned a text node without an owner document. Fix that.

BUG= 689977 

Review-Url: https://codereview.chromium.org/2750943004
Cr-Commit-Position: refs/heads/master@{#457692}
(cherry picked from commit 3f6e482b7f13c1fc5bd68227321ef6da0ddf9937)

Review-Url: https://codereview.chromium.org/2772323005 .
Cr-Commit-Position: refs/branch-heads/3029@{#452}
Cr-Branched-From: 939b32ee5ba05c396eef3fd992822fcca9a2e262-refs/heads/master@{#454471}

[add] https://crrev.com/99ead7d1564d35a70799b7ee4c3821053fb3985c/third_party/WebKit/LayoutTests/fast/xsl/xslt-node-set-empty.html
[modify] https://crrev.com/99ead7d1564d35a70799b7ee4c3821053fb3985c/third_party/WebKit/Source/core/xml/XSLTExtensions.cpp

+ awhalley@(Security TPM) for M57 merge review. This bug  exists on M56 (not an M57 regression) also it is not yet baked in Beta (got merged to M58 17 mins back).

I think the final M57 has sailed...

Anchors are up but it's still in port, have started a thread with the release folk.

Approved for M57 branch 2987.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/ceaae84ca2faad7f865928102a19e3f3fcf4a654

commit ceaae84ca2faad7f865928102a19e3f3fcf4a654
Author: Oliver Chang <ochang@chromium.org>
Date: Tue Mar 28 20:05:23 2017

node-set($x), when $x is empty, should not halt XSLT processing

node-set is polymorphic; if called with a string, it returns a
node-set containing a text node with that content. The libxslt roll in
r425586 broke this behavior because Blink's fork of the node-set
extension returned a text node without an owner document. Fix that.

BUG= 689977 

Review-Url: https://codereview.chromium.org/2750943004
Cr-Commit-Position: refs/heads/master@{#457692}
(cherry picked from commit 3f6e482b7f13c1fc5bd68227321ef6da0ddf9937)

Review-Url: https://codereview.chromium.org/2784623002 .
Cr-Commit-Position: refs/branch-heads/2987@{#885}
Cr-Branched-From: ad51088c0e8776e8dcd963dbe752c4035ba6dab6-refs/heads/master@{#444943}

[add] https://crrev.com/ceaae84ca2faad7f865928102a19e3f3fcf4a654/third_party/WebKit/LayoutTests/fast/xsl/xslt-node-set-empty.html
[modify] https://crrev.com/ceaae84ca2faad7f865928102a19e3f3fcf4a654/third_party/WebKit/Source/core/xml/XSLTExtensions.cpp

To test this after merging I would:

- Open the attachment on the first post of Issue 705445 and see whether it crashes.
- Run a web server in third_party/WebKit/LayoutTests and open fast/xsl/exslt-node-set.xml and see if it says "SUCCESS"

If it doesn't crash and you see SUCCESS then node-set/XML processing should be fine. HTH! I'm out today but feel free to IM, email or call--my phone number is on the intranet.

Verified fix in 57.0.2987.132 / Samsung Galaxy S7 / NRD90M. Thanks!

Vefified the issue on Windows 7 , mac os 10.12.3 and ubuntu 14.04 using chrome M58 #58.0.3029.41 as per comment #3 link "https://jsfiddle.net/tson91ok/2/" , where resultant variable is seen as " hello data ".

Attached screenshot for reference.

Adding TE-Verified labels.

Thanks!

Deleted: 689977.png 197 KB

	689977.png 197 KB View Download

Android: Verified fix in 58.0.3029.42 on Samsung Galaxy TAB 3 10.1 (GT-P5210) KOT49H. 

Verified the issue on Windows 10, MAC 10.12.3, Ubuntu 14.04 using chrome version 57.0.2987.133 using the test cases provided in comment#3 and Comment#8, "Hello data" is displayed as output using both the test cases. Fix is working as intended. On a bad build "null" was displayed.

Also as per comment#23, downloaded and launched the .html file provided in Issue 705445, no crash was observed.

Unable to execute step 2 in comment#23 as do not have permission to install a web server and execute the.xml file.

@pbomanna: Looping you, kindly take a look at step 2 as mention in comment#23.

P.S: Not adding TE-verified labels, as steps listed in comment#23 is not fully executed.

Thanks.! 

The test team had a little trouble testing this due to starting a webserver.

Here are easier instructions to test:
1) Open the attachment on the first post of Issue 705445 and see whether it crashes.
2) Open https://pr.gg/xslbug/exslt-node-set.xml and verify that it says "SUCCESS" and does not crash.

Chrome test team was able to verify "Open the attachment on the first post of Issue 705445 and see whether it crashes." but we couldn't verify "Run a web server in third_party/WebKit/LayoutTests and open fast/xsl/exslt-node-set.xml and see if it says "SUCCESS" since the URL provided by Philip(Thank you) was showing "Success" even on Chrome version(57.0.2987.110) where the fix wasn't landed.

Note : Given the crash was present seen with first testcase in 57.0.2987.110 and wasn't on 57.0.2987.133, We are moving ahead with the M57 roll out assuming that the fix is fixed. Please let us know if there are any concerns ASAP.

To briefly follow up: I picked fast/xsl/exslt-node-set.xml as a regression test, so it's expected you would see SUCCESS before and after. Sorry, I should have mentioned that, I can see how confusing it would be.

Thanks pbommana and pdr.

Verified for Android WebView 58.0.3029.42 on Galaxy S7 Edge.