[jira] [Commented] (MYFACES-4498) TCK: Issue 4345 : Head Element Not Updated As Expected via Ajax Call

[Werner Punz (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17638327#comment-17638327
 ] 

Werner Punz commented on MYFACES-4498:
--

Fixed now properly for our new codebase, will add the fix as well for the old 
codebase tomorrow.

 

> TCK: Issue 4345 : Head Element Not Updated As Expected via Ajax Call
> 
>
> Key: MYFACES-4498
> URL: https://issues.apache.org/jira/browse/MYFACES-4498
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 4.0.0-RC2
>Reporter: Volodymyr Siedlecki
>    Assignee: Werner Punz
>Priority: Major
> Attachments: test-faces22-ajax.war
>
>
> Test Code: 
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/test/java/ee/jakarta/tck/faces/test/servlet30/ajax/Issue4345IT.java#L47]
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/main/webapp/issue4345result.xhtml]
>  
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/test/java/ee/jakarta/tck/faces/test/servlet30/ajax/Issue4345IT.java#L47]
> This test was created for ensure HTML is only escaped twice ([Issue 
> 4345|https://github.com/eclipse-ee4j/mojarra/issues/4345). However, MyFaces 
> is encountering two problems with this test.
> Firstly, here is the Ajax response and the updated HTML: 
> {code:java}
> 
> 
>
>   
>  
>   
>   
>  
>   
>
>  {code}
> The HTML is then set as : 
> {code:java}
> http://www.w3.org/1999/xhtml;>
>
>   @import 
> url('/test-faces22-ajax/jakarta.faces.resource/issue4345.css.xhtml?firstParam=1&secondParam=2');
>
>
> 
>  {code}
> 1) We change from a link (type/css ) to a style tag that imports the URL? 
> Should that occur?  The JavaScript in issue4345result.xhtml specifically 
> looks for a link element. 
> 2) The script tags *are not appended* to the head element, but I do see 
> network requests for them. Additionally, the scripts do run (confirmed by the 
> console: "issue4345.js loaded." ). 
> This fails on both the RC2 scripts and the new TypeScript code. 
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (MYFACES-4498) TCK: Issue 4345 : Head Element Not Updated As Expected via Ajax Call

[Werner Punz (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17637841#comment-17637841
 ] 

Werner Punz commented on MYFACES-4498:
--

Added a unit test for a more complex case as well 

 

{code:xml}
{code:java}




 {code}

> TCK: Issue 4345 : Head Element Not Updated As Expected via Ajax Call
> 
>
> Key: MYFACES-4498
> URL: https://issues.apache.org/jira/browse/MYFACES-4498
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 4.0.0-RC2
>Reporter: Volodymyr Siedlecki
>    Assignee: Werner Punz
>Priority: Major
> Attachments: test-faces22-ajax.war
>
>
> Test Code: 
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/test/java/ee/jakarta/tck/faces/test/servlet30/ajax/Issue4345IT.java#L47]
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/main/webapp/issue4345result.xhtml]
>  
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/test/java/ee/jakarta/tck/faces/test/servlet30/ajax/Issue4345IT.java#L47]
> This test was created for ensure HTML is only escaped twice ([Issue 
> 4345|https://github.com/eclipse-ee4j/mojarra/issues/4345). However, MyFaces 
> is encountering two problems with this test.
> Firstly, here is the Ajax response and the updated HTML: 
> {code:java}
> 
> 
>
>   
>  
>   
>   
>  
>   
>
>  {code}
> The HTML is then set as : 
> {code:java}
> http://www.w3.org/1999/xhtml;>
>
>   @import 
> url('/test-faces22-ajax/jakarta.faces.resource/issue4345.css.xhtml?firstParam=1&secondParam=2');
>
>
> 
>  {code}
> 1) We change from a link (type/css ) to a style tag that imports the URL? 
> Should that occur?  The JavaScript in issue4345result.xhtml specifically 
> looks for a link element. 
> 2) The script tags *are not appended* to the head element, but I do see 
> network requests for them. Additionally, the scripts do run (confirmed by the 
> console: "issue4345.js loaded." ). 
> This fails on both the RC2 scripts and the new TypeScript code. 
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (MYFACES-4498) TCK: Issue 4345 : Head Element Not Updated As Expected via Ajax Call

[Werner Punz (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17637841#comment-17637841
 ] 

Werner Punz edited comment on MYFACES-4498 at 11/23/22 3:43 PM:


Added a unit test for a more complex case as well 

 
{code:xml}




 {code}


was (Author: werpu):
Added a unit test for a more complex case as well 

 

{code:xml}
{code:java}




 {code}

> TCK: Issue 4345 : Head Element Not Updated As Expected via Ajax Call
> 
>
> Key: MYFACES-4498
> URL: https://issues.apache.org/jira/browse/MYFACES-4498
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 4.0.0-RC2
>Reporter: Volodymyr Siedlecki
>    Assignee: Werner Punz
>Priority: Major
> Attachments: test-faces22-ajax.war
>
>
> Test Code: 
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/test/java/ee/jakarta/tck/faces/test/servlet30/ajax/Issue4345IT.java#L47]
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/main/webapp/issue4345result.xhtml]
>  
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/test/java/ee/jakarta/tck/faces/test/servlet30/ajax/Issue4345IT.java#L47]
> This test was created for ensure HTML is only escaped twice ([Issue 
> 4345|https://github.com/eclipse-ee4j/mojarra/issues/4345). However, MyFaces 
> is encountering two problems with this test.
> Firstly, here is the Ajax response and the updated HTML: 
> {code:java}
> 
> 
>
>   
>  
>   
>   
>  
>   
>
>  {code}
> The HTML is then set as : 
> {code:java}
> http://www.w3.org/1999/xhtml;>
>
>   @import 
> url('/test-faces22-ajax/jakarta.faces.resource/issue4345.css.xhtml?firstParam=1&secondParam=2');
>
>
> 
>  {code}
> 1) We change from a link (type/css ) to a style tag that imports the URL? 
> Should that occur?  The JavaScript in issue4345result.xhtml specifically 
> looks for a link element. 
> 2) The script tags *are not appended* to the head element, but I do see 
> network requests for them. Additionally, the scripts do run (confirmed by the 
> console: "issue4345.js loaded." ). 
> This fails on both the RC2 scripts and the new TypeScript code. 
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (MYFACES-4498) TCK: Issue 4345 : Head Element Not Updated As Expected via Ajax Call

[Werner Punz (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17637817#comment-17637817
 ] 

Werner Punz edited comment on MYFACES-4498 at 11/23/22 3:42 PM:


Error is reproducible with following unit test
{code:java}
it("head replacement must work 
(https://issues.apache.org/jira/browse/MYFACES-4498 and TCK Issue 4345IT)", 
function(done) {

  DQ.byId("cmd_complex_resource2").click();
  this.respond(XmlResponses.HEAD_REPLACE);
  let headHTML = document.head.innerHTML;  
  
expect(headHTML.indexOf("href=\"../../../xhrCore/fixtures/addedViewHead2.css\"")).not.eq(-1);
  expect(DQ$("head 
link[rel='stylesheet'][href='../../../xhrCore/fixtures/addedViewHead2.css']").length).to.eq(1);

  // failing now, no script elements in the html head after respond!!!
  
expect(headHTML.indexOf("../../../xhrCore/fixtures/addedViewHead3.js")).not.eq(-1);
})

static HEAD_REPLACE = `







`
{code}


was (Author: werpu):
Error is reproducible with following unit test
{code:java}
it("head replacement must work 
(https://issues.apache.org/jira/browse/MYFACES-4498 and TCK Issue 4345IT)", 
function(done) {

  DQ.byId("cmd_complex_resource2").click();
  this.respond(XmlResponses.HEAD_REPLACE);
  let headHTML = document.head.innerHTML;  
  
expect(headHTML.indexOf("href=\"../../../xhrCore/fixtures/addedViewHead2.css\"")).not.eq(-1);
  expect(DQ$("head 
link[rel='stylesheet'][href='../../../xhrCore/fixtures/addedViewHead2.css']").length).to.eq(1);

  // failing now, no script elements in the html head after respond!!!
  
expect(headHTML.indexOf("../../../xhrCore/fixtures/addedViewHead3.js")).not.eq(-1);
})

static HEAD_REPLACE = `







`
{code}

> TCK: Issue 4345 : Head Element Not Updated As Expected via Ajax Call
> 
>
> Key: MYFACES-4498
> URL: https://issues.apache.org/jira/browse/MYFACES-4498
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 4.0.0-RC2
>Reporter: Volodymyr Siedlecki
>Assignee: Werner Punz
>Priority: Major
> Attachments: test-faces22-ajax.war
>
>
> Test Code: 
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/test/java/ee/jakarta/tck/faces/test/servlet30/ajax/Issue4345IT.java#L47]
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/main/webapp/issue4345result.xhtml]
>  
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/test/java/ee/jakarta/tck/faces/test/servlet30/ajax/Issue4345IT.java#L47]
> This test was created for ensure HTML is only escaped twice ([Issue 
> 4345|https://github.com/eclipse-ee4j/mojarra/issues/4345). However, MyFaces 
> is encountering two problems with this test.
> Firstly, here is the Ajax response and the updated HTML: 
> {code:java}
> 
> 
>
>   
>  
>   
>   
>  
>   
>
>  {code}
> The HTML is then set as : 
> {code:java}
> http://www.w3.org/1999/xhtml;>
>
>   @import 
> url('/test-faces22-ajax/jakarta.faces.resource/issue4345.css.xhtml?firstParam=1&secondParam=2');
>
>
> 
>  {code}
> 1) We change from a link (type/css ) to a style tag that imports the URL? 
> Should that occur?  The JavaScript in issue4345result.xhtml specifically 
> looks for a link element. 
> 2) The script tags *are not appended* to the head element, but I do see 
> network requests for them. Additionally, the scripts do run (confirmed by the 
> console: "issue4345.js loaded." ). 
> This fails on both the RC2 scripts and the new TypeScript code. 
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (MYFACES-4498) TCK: Issue 4345 : Head Element Not Updated As Expected via Ajax Call

[Werner Punz (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17637838#comment-17637838
 ] 

Werner Punz commented on MYFACES-4498:
--

Found the second issue.
The way we handle the head replace simply was false... we basically left the 
head intact and only evaluated the scripts.
The correct fix is to replace all elements on dom level. (I still do the 
deferred eval though, but with sticky scripts!)

This is an issue which has spilled over from the old codebase.


> TCK: Issue 4345 : Head Element Not Updated As Expected via Ajax Call
> 
>
> Key: MYFACES-4498
> URL: https://issues.apache.org/jira/browse/MYFACES-4498
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 4.0.0-RC2
>Reporter: Volodymyr Siedlecki
>    Assignee: Werner Punz
>Priority: Major
> Attachments: test-faces22-ajax.war
>
>
> Test Code: 
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/test/java/ee/jakarta/tck/faces/test/servlet30/ajax/Issue4345IT.java#L47]
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/main/webapp/issue4345result.xhtml]
>  
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/test/java/ee/jakarta/tck/faces/test/servlet30/ajax/Issue4345IT.java#L47]
> This test was created for ensure HTML is only escaped twice ([Issue 
> 4345|https://github.com/eclipse-ee4j/mojarra/issues/4345). However, MyFaces 
> is encountering two problems with this test.
> Firstly, here is the Ajax response and the updated HTML: 
> {code:java}
> 
> 
>
>   
>  
>   
>   
>  
>   
>
>  {code}
> The HTML is then set as : 
> {code:java}
> http://www.w3.org/1999/xhtml;>
>
>   @import 
> url('/test-faces22-ajax/jakarta.faces.resource/issue4345.css.xhtml?firstParam=1&secondParam=2');
>
>
> 
>  {code}
> 1) We change from a link (type/css ) to a style tag that imports the URL? 
> Should that occur?  The JavaScript in issue4345result.xhtml specifically 
> looks for a link element. 
> 2) The script tags *are not appended* to the head element, but I do see 
> network requests for them. Additionally, the scripts do run (confirmed by the 
> console: "issue4345.js loaded." ). 
> This fails on both the RC2 scripts and the new TypeScript code. 
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (MYFACES-4498) TCK: Issue 4345 : Head Element Not Updated As Expected via Ajax Call

[Werner Punz (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17637817#comment-17637817
 ] 

Werner Punz edited comment on MYFACES-4498 at 11/23/22 3:05 PM:


Error is reproducible with following unit test
{code:java}
it("head replacement must work 
(https://issues.apache.org/jira/browse/MYFACES-4498 and TCK Issue 4345IT)", 
function(done) {

  DQ.byId("cmd_complex_resource2").click();
  this.respond(XmlResponses.HEAD_REPLACE);
  let headHTML = document.head.innerHTML;  
  
expect(headHTML.indexOf("href=\"../../../xhrCore/fixtures/addedViewHead2.css\"")).not.eq(-1);
  expect(DQ$("head 
link[rel='stylesheet'][href='../../../xhrCore/fixtures/addedViewHead2.css']").length).to.eq(1);

  // failing now, no script elements in the html head after respond!!!
  
expect(headHTML.indexOf("../../../xhrCore/fixtures/addedViewHead3.js")).not.eq(-1);
})

static HEAD_REPLACE = `







`
{code}


was (Author: werpu):
Error is reproducible with following unit test
{code:java}
it("head replacement must work 
(https://issues.apache.org/jira/browse/MYFACES-4498 and TCK Issue 4345IT)", 
function(done) {

  DQ.byId("cmd_complex_resource2").click();
  this.respond(XmlResponses.HEAD_REPLACE);
  let headHTML = document.head.innerHTML;  
  
expect(headHTML.indexOf("href=\"../../../xhrCore/fixtures/addedViewHead2.css\"")).not.eq(-1);
 expect(DQ$("head 
link[rel='stylesheet'][href='../../../xhrCore/fixtures/addedViewHead2.css']").length).to.eq(1);

  // failing now, no script elements in the html head after respond!!!
  
expect(headHTML.indexOf("../../../xhrCore/fixtures/addedViewHead3.js")).not.eq(-1);
})

static HEAD_REPLACE = `







`
{code}

> TCK: Issue 4345 : Head Element Not Updated As Expected via Ajax Call
> 
>
> Key: MYFACES-4498
> URL: https://issues.apache.org/jira/browse/MYFACES-4498
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 4.0.0-RC2
>Reporter: Volodymyr Siedlecki
>Assignee: Werner Punz
>Priority: Major
> Attachments: test-faces22-ajax.war
>
>
> Test Code: 
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/test/java/ee/jakarta/tck/faces/test/servlet30/ajax/Issue4345IT.java#L47]
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/main/webapp/issue4345result.xhtml]
>  
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/test/java/ee/jakarta/tck/faces/test/servlet30/ajax/Issue4345IT.java#L47]
> This test was created for ensure HTML is only escaped twice ([Issue 
> 4345|https://github.com/eclipse-ee4j/mojarra/issues/4345). However, MyFaces 
> is encountering two problems with this test.
> Firstly, here is the Ajax response and the updated HTML: 
> {code:java}
> 
> 
>
>   
>  
>   
>   
>  
>   
>
>  {code}
> The HTML is then set as : 
> {code:java}
> http://www.w3.org/1999/xhtml;>
>
>   @import 
> url('/test-faces22-ajax/jakarta.faces.resource/issue4345.css.xhtml?firstParam=1&secondParam=2');
>
>
> 
>  {code}
> 1) We change from a link (type/css ) to a style tag that imports the URL? 
> Should that occur?  The JavaScript in issue4345result.xhtml specifically 
> looks for a link element. 
> 2) The script tags *are not appended* to the head element, but I do see 
> network requests for them. Additionally, the scripts do run (confirmed by the 
> console: "issue4345.js loaded." ). 
> This fails on both the RC2 scripts and the new TypeScript code. 
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (MYFACES-4498) TCK: Issue 4345 : Head Element Not Updated As Expected via Ajax Call

[Werner Punz (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17637817#comment-17637817
 ] 

Werner Punz edited comment on MYFACES-4498 at 11/23/22 3:04 PM:


Error is reproducible with following unit test
{code:java}
it("head replacement must work 
(https://issues.apache.org/jira/browse/MYFACES-4498 and TCK Issue 4345IT)", 
function(done) {

  DQ.byId("cmd_complex_resource2").click();
  this.respond(XmlResponses.HEAD_REPLACE);
  let headHTML = document.head.innerHTML;  
  
expect(headHTML.indexOf("href=\"../../../xhrCore/fixtures/addedViewHead2.css\"")).not.eq(-1);
expect(DQ$("head 
link[rel='stylesheet'][href='../../../xhrCore/fixtures/addedViewHead2.css']").length).to.eq(1);

  // failing now, no script elements in the html head after respond!!!
  
expect(headHTML.indexOf("../../../xhrCore/fixtures/addedViewHead3.js")).not.eq(-1);
})

static HEAD_REPLACE = `







`
{code}


was (Author: werpu):
Error is reproducible with following unit test
{code:java}
it("head replacement must work 
(https://issues.apache.org/jira/browse/MYFACES-4498 and TCK Issue 4345IT)", 
function(done) {

  DQ.byId("cmd_complex_resource2").click();
  this.respond(XmlResponses.HEAD_REPLACE);
  let headHTML = document.head.innerHTML;  
  
expect(headHTML.indexOf("href=\"../../../xhrCore/fixtures/addedViewHead2.css\"")).not.eq(-1);
expect(DQ$("head 
link[rel='stylesheet'][href='../../../xhrCore/fixtures/addedViewHead2.css']").length).to.eq(1);

// failing now, no script elements in the html head after respond!!!
  
expect(headHTML.indexOf("../../../xhrCore/fixtures/addedViewHead3.js")).not.eq(-1);
})

static HEAD_REPLACE = `







`
{code}

> TCK: Issue 4345 : Head Element Not Updated As Expected via Ajax Call
> 
>
> Key: MYFACES-4498
> URL: https://issues.apache.org/jira/browse/MYFACES-4498
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 4.0.0-RC2
>Reporter: Volodymyr Siedlecki
>Assignee: Werner Punz
>Priority: Major
> Attachments: test-faces22-ajax.war
>
>
> Test Code: 
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/test/java/ee/jakarta/tck/faces/test/servlet30/ajax/Issue4345IT.java#L47]
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/main/webapp/issue4345result.xhtml]
>  
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/test/java/ee/jakarta/tck/faces/test/servlet30/ajax/Issue4345IT.java#L47]
> This test was created for ensure HTML is only escaped twice ([Issue 
> 4345|https://github.com/eclipse-ee4j/mojarra/issues/4345). However, MyFaces 
> is encountering two problems with this test.
> Firstly, here is the Ajax response and the updated HTML: 
> {code:java}
> 
> 
>
>   
>  
>   
>   
>  
>   
>
>  {code}
> The HTML is then set as : 
> {code:java}
> http://www.w3.org/1999/xhtml;>
>
>   @import 
> url('/test-faces22-ajax/jakarta.faces.resource/issue4345.css.xhtml?firstParam=1&secondParam=2');
>
>
> 
>  {code}
> 1) We change from a link (type/css ) to a style tag that imports the URL? 
> Should that occur?  The JavaScript in issue4345result.xhtml specifically 
> looks for a link element. 
> 2) The script tags *are not appended* to the head element, but I do see 
> network requests for them. Additionally, the scripts do run (confirmed by the 
> console: "issue4345.js loaded." ). 
> This fails on both the RC2 scripts and the new TypeScript code. 
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (MYFACES-4498) TCK: Issue 4345 : Head Element Not Updated As Expected via Ajax Call

[Werner Punz (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17637817#comment-17637817
 ] 

Werner Punz edited comment on MYFACES-4498 at 11/23/22 3:04 PM:


Error is reproducible with following unit test
{code:java}
it("head replacement must work 
(https://issues.apache.org/jira/browse/MYFACES-4498 and TCK Issue 4345IT)", 
function(done) {

  DQ.byId("cmd_complex_resource2").click();
  this.respond(XmlResponses.HEAD_REPLACE);
  let headHTML = document.head.innerHTML;  
  
expect(headHTML.indexOf("href=\"../../../xhrCore/fixtures/addedViewHead2.css\"")).not.eq(-1);
expect(DQ$("head 
link[rel='stylesheet'][href='../../../xhrCore/fixtures/addedViewHead2.css']").length).to.eq(1);

// failing now, no script elements in the html head after respond!!!
  
expect(headHTML.indexOf("../../../xhrCore/fixtures/addedViewHead3.js")).not.eq(-1);
})

static HEAD_REPLACE = `







`
{code}


was (Author: werpu):
Error is reproducible with following unit test
{code:java}
it("head replacement must work 
(https://issues.apache.org/jira/browse/MYFACES-4498 and TCK Issue 4345IT)", 
function(done) {

  DQ.byId("cmd_complex_resource2").click();
  this.respond(XmlResponses.HEAD_REPLACE);
  let headHTML = document.head.innerHTML;  

expect(headHTML.indexOf("href=\"../../../xhrCore/fixtures/addedViewHead2.css\"")).not.eq(-1);
expect(DQ$("head 
link[rel='stylesheet'][href='../../../xhrCore/fixtures/addedViewHead2.css']").length).to.eq(1);

// failing now, no script elements in the html head after respond!!!
   
expect(headHTML.indexOf("../../../xhrCore/fixtures/addedViewHead3.js")).not.eq(-1);
})

static HEAD_REPLACE = `







`
{code}

> TCK: Issue 4345 : Head Element Not Updated As Expected via Ajax Call
> 
>
> Key: MYFACES-4498
> URL: https://issues.apache.org/jira/browse/MYFACES-4498
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 4.0.0-RC2
>Reporter: Volodymyr Siedlecki
>Assignee: Werner Punz
>Priority: Major
> Attachments: test-faces22-ajax.war
>
>
> Test Code: 
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/test/java/ee/jakarta/tck/faces/test/servlet30/ajax/Issue4345IT.java#L47]
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/main/webapp/issue4345result.xhtml]
>  
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/test/java/ee/jakarta/tck/faces/test/servlet30/ajax/Issue4345IT.java#L47]
> This test was created for ensure HTML is only escaped twice ([Issue 
> 4345|https://github.com/eclipse-ee4j/mojarra/issues/4345). However, MyFaces 
> is encountering two problems with this test.
> Firstly, here is the Ajax response and the updated HTML: 
> {code:java}
> 
> 
>
>   
>  
>   
>   
>  
>   
>
>  {code}
> The HTML is then set as : 
> {code:java}
> http://www.w3.org/1999/xhtml;>
>
>   @import 
> url('/test-faces22-ajax/jakarta.faces.resource/issue4345.css.xhtml?firstParam=1&secondParam=2');
>
>
> 
>  {code}
> 1) We change from a link (type/css ) to a style tag that imports the URL? 
> Should that occur?  The JavaScript in issue4345result.xhtml specifically 
> looks for a link element. 
> 2) The script tags *are not appended* to the head element, but I do see 
> network requests for them. Additionally, the scripts do run (confirmed by the 
> console: "issue4345.js loaded." ). 
> This fails on both the RC2 scripts and the new TypeScript code. 
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (MYFACES-4498) TCK: Issue 4345 : Head Element Not Updated As Expected via Ajax Call

[Werner Punz (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17637817#comment-17637817
 ] 

Werner Punz edited comment on MYFACES-4498 at 11/23/22 3:04 PM:


Error is reproducible with following unit test
{code:java}
it("head replacement must work 
(https://issues.apache.org/jira/browse/MYFACES-4498 and TCK Issue 4345IT)", 
function(done) {

  DQ.byId("cmd_complex_resource2").click();
  this.respond(XmlResponses.HEAD_REPLACE);
  let headHTML = document.head.innerHTML;  
  
expect(headHTML.indexOf("href=\"../../../xhrCore/fixtures/addedViewHead2.css\"")).not.eq(-1);
 expect(DQ$("head 
link[rel='stylesheet'][href='../../../xhrCore/fixtures/addedViewHead2.css']").length).to.eq(1);

  // failing now, no script elements in the html head after respond!!!
  
expect(headHTML.indexOf("../../../xhrCore/fixtures/addedViewHead3.js")).not.eq(-1);
})

static HEAD_REPLACE = `







`
{code}


was (Author: werpu):
Error is reproducible with following unit test
{code:java}
it("head replacement must work 
(https://issues.apache.org/jira/browse/MYFACES-4498 and TCK Issue 4345IT)", 
function(done) {

  DQ.byId("cmd_complex_resource2").click();
  this.respond(XmlResponses.HEAD_REPLACE);
  let headHTML = document.head.innerHTML;  
  
expect(headHTML.indexOf("href=\"../../../xhrCore/fixtures/addedViewHead2.css\"")).not.eq(-1);
expect(DQ$("head 
link[rel='stylesheet'][href='../../../xhrCore/fixtures/addedViewHead2.css']").length).to.eq(1);

  // failing now, no script elements in the html head after respond!!!
  
expect(headHTML.indexOf("../../../xhrCore/fixtures/addedViewHead3.js")).not.eq(-1);
})

static HEAD_REPLACE = `







`
{code}

> TCK: Issue 4345 : Head Element Not Updated As Expected via Ajax Call
> 
>
> Key: MYFACES-4498
> URL: https://issues.apache.org/jira/browse/MYFACES-4498
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 4.0.0-RC2
>Reporter: Volodymyr Siedlecki
>Assignee: Werner Punz
>Priority: Major
> Attachments: test-faces22-ajax.war
>
>
> Test Code: 
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/test/java/ee/jakarta/tck/faces/test/servlet30/ajax/Issue4345IT.java#L47]
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/main/webapp/issue4345result.xhtml]
>  
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/test/java/ee/jakarta/tck/faces/test/servlet30/ajax/Issue4345IT.java#L47]
> This test was created for ensure HTML is only escaped twice ([Issue 
> 4345|https://github.com/eclipse-ee4j/mojarra/issues/4345). However, MyFaces 
> is encountering two problems with this test.
> Firstly, here is the Ajax response and the updated HTML: 
> {code:java}
> 
> 
>
>   
>  
>   
>   
>  
>   
>
>  {code}
> The HTML is then set as : 
> {code:java}
> http://www.w3.org/1999/xhtml;>
>
>   @import 
> url('/test-faces22-ajax/jakarta.faces.resource/issue4345.css.xhtml?firstParam=1&secondParam=2');
>
>
> 
>  {code}
> 1) We change from a link (type/css ) to a style tag that imports the URL? 
> Should that occur?  The JavaScript in issue4345result.xhtml specifically 
> looks for a link element. 
> 2) The script tags *are not appended* to the head element, but I do see 
> network requests for them. Additionally, the scripts do run (confirmed by the 
> console: "issue4345.js loaded." ). 
> This fails on both the RC2 scripts and the new TypeScript code. 
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (MYFACES-4498) TCK: Issue 4345 : Head Element Not Updated As Expected via Ajax Call

[Werner Punz (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17637817#comment-17637817
 ] 

Werner Punz edited comment on MYFACES-4498 at 11/23/22 3:04 PM:


Error is reproducible with following unit test
{code:java}
it("head replacement must work 
(https://issues.apache.org/jira/browse/MYFACES-4498 and TCK Issue 4345IT)", 
function(done) {

  DQ.byId("cmd_complex_resource2").click();
  this.respond(XmlResponses.HEAD_REPLACE);
  let headHTML = document.head.innerHTML;  

expect(headHTML.indexOf("href=\"../../../xhrCore/fixtures/addedViewHead2.css\"")).not.eq(-1);
expect(DQ$("head 
link[rel='stylesheet'][href='../../../xhrCore/fixtures/addedViewHead2.css']").length).to.eq(1);

// failing now, no script elements in the html head after respond!!!
   
expect(headHTML.indexOf("../../../xhrCore/fixtures/addedViewHead3.js")).not.eq(-1);
})

static HEAD_REPLACE = `







`
{code}


was (Author: werpu):
Error is reproducible with following unit test
{code:java}
it("head replacement must work 
(https://issues.apache.org/jira/browse/MYFACES-4498 and TCK Issue 4345IT)", 
function(done) {

  DQ.byId("cmd_complex_resource2").click();
  this.respond(XmlResponses.HEAD_REPLACE);
  let headHTML = document.head.innerHTML;  
expect(headHTML.indexOf("href=\"../../../xhrCore/fixtures/addedViewHead2.css\"")).not.eq(-1);
expect(DQ$("head 
link[rel='stylesheet'][href='../../../xhrCore/fixtures/addedViewHead2.css']").length).to.eq(1);

// failing now, no script elements in the html head after respond!!!
   
expect(headHTML.indexOf("../../../xhrCore/fixtures/addedViewHead3.js")).not.eq(-1);
})

static HEAD_REPLACE = `







`
{code}

> TCK: Issue 4345 : Head Element Not Updated As Expected via Ajax Call
> 
>
> Key: MYFACES-4498
> URL: https://issues.apache.org/jira/browse/MYFACES-4498
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 4.0.0-RC2
>Reporter: Volodymyr Siedlecki
>Assignee: Werner Punz
>Priority: Major
> Attachments: test-faces22-ajax.war
>
>
> Test Code: 
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/test/java/ee/jakarta/tck/faces/test/servlet30/ajax/Issue4345IT.java#L47]
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/main/webapp/issue4345result.xhtml]
>  
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/test/java/ee/jakarta/tck/faces/test/servlet30/ajax/Issue4345IT.java#L47]
> This test was created for ensure HTML is only escaped twice ([Issue 
> 4345|https://github.com/eclipse-ee4j/mojarra/issues/4345). However, MyFaces 
> is encountering two problems with this test.
> Firstly, here is the Ajax response and the updated HTML: 
> {code:java}
> 
> 
>
>   
>  
>   
>   
>  
>   
>
>  {code}
> The HTML is then set as : 
> {code:java}
> http://www.w3.org/1999/xhtml;>
>
>   @import 
> url('/test-faces22-ajax/jakarta.faces.resource/issue4345.css.xhtml?firstParam=1&secondParam=2');
>
>
> 
>  {code}
> 1) We change from a link (type/css ) to a style tag that imports the URL? 
> Should that occur?  The JavaScript in issue4345result.xhtml specifically 
> looks for a link element. 
> 2) The script tags *are not appended* to the head element, but I do see 
> network requests for them. Additionally, the scripts do run (confirmed by the 
> console: "issue4345.js loaded." ). 
> This fails on both the RC2 scripts and the new TypeScript code. 
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (MYFACES-4498) TCK: Issue 4345 : Head Element Not Updated As Expected via Ajax Call

[Werner Punz (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17637817#comment-17637817
 ] 

Werner Punz edited comment on MYFACES-4498 at 11/23/22 3:03 PM:


Error is reproducible with following unit test
{code:java}
it("head replacement must work 
(https://issues.apache.org/jira/browse/MYFACES-4498 and TCK Issue 4345IT)", 
function(done) {

  DQ.byId("cmd_complex_resource2").click();
  this.respond(XmlResponses.HEAD_REPLACE);
  let headHTML = document.head.innerHTML;
expect(headHTML.indexOf("href=\"../../../xhrCore/fixtures/addedViewHead2.css\"")).not.eq(-1);
expect(DQ$("head 
link[rel='stylesheet'][href='../../../xhrCore/fixtures/addedViewHead2.css']").length).to.eq(1);

// failing now, no script elements in the html head after respond!!!
   
expect(headHTML.indexOf("../../../xhrCore/fixtures/addedViewHead3.js")).not.eq(-1);
})

static HEAD_REPLACE = `







`
{code}


was (Author: werpu):
Error is reproducible with following unit test
{code:java}
it("head replacement must work 
(https://issues.apache.org/jira/browse/MYFACES-4498 and TCK Issue 4345IT)", 
function(done) {

  DQ.byId("cmd_complex_resource2").click();
  this.respond(XmlResponses.HEAD_REPLACE);
  let headHTML = document.head.innerHTML;

expect(headHTML.indexOf("href=\"../../../xhrCore/fixtures/addedViewHead2.css\"")).not.eq(-1);
expect(DQ$("head 
link[rel='stylesheet'][href='../../../xhrCore/fixtures/addedViewHead2.css']").length).to.eq(1);

// failing now, no script elements in the html head after respond!!!
   
expect(headHTML.indexOf("../../../xhrCore/fixtures/addedViewHead3.js")).not.eq(-1);
})

static HEAD_REPLACE = `







`
{code}

> TCK: Issue 4345 : Head Element Not Updated As Expected via Ajax Call
> 
>
> Key: MYFACES-4498
> URL: https://issues.apache.org/jira/browse/MYFACES-4498
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 4.0.0-RC2
>Reporter: Volodymyr Siedlecki
>Assignee: Werner Punz
>Priority: Major
> Attachments: test-faces22-ajax.war
>
>
> Test Code: 
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/test/java/ee/jakarta/tck/faces/test/servlet30/ajax/Issue4345IT.java#L47]
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/main/webapp/issue4345result.xhtml]
>  
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/test/java/ee/jakarta/tck/faces/test/servlet30/ajax/Issue4345IT.java#L47]
> This test was created for ensure HTML is only escaped twice ([Issue 
> 4345|https://github.com/eclipse-ee4j/mojarra/issues/4345). However, MyFaces 
> is encountering two problems with this test.
> Firstly, here is the Ajax response and the updated HTML: 
> {code:java}
> 
> 
>
>   
>  
>   
>   
>  
>   
>
>  {code}
> The HTML is then set as : 
> {code:java}
> http://www.w3.org/1999/xhtml;>
>
>   @import 
> url('/test-faces22-ajax/jakarta.faces.resource/issue4345.css.xhtml?firstParam=1&secondParam=2');
>
>
> 
>  {code}
> 1) We change from a link (type/css ) to a style tag that imports the URL? 
> Should that occur?  The JavaScript in issue4345result.xhtml specifically 
> looks for a link element. 
> 2) The script tags *are not appended* to the head element, but I do see 
> network requests for them. Additionally, the scripts do run (confirmed by the 
> console: "issue4345.js loaded." ). 
> This fails on both the RC2 scripts and the new TypeScript code. 
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (MYFACES-4498) TCK: Issue 4345 : Head Element Not Updated As Expected via Ajax Call

[Werner Punz (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17637817#comment-17637817
 ] 

Werner Punz edited comment on MYFACES-4498 at 11/23/22 3:03 PM:


Error is reproducible with following unit test
{code:java}
it("head replacement must work 
(https://issues.apache.org/jira/browse/MYFACES-4498 and TCK Issue 4345IT)", 
function(done) {

  DQ.byId("cmd_complex_resource2").click();
  this.respond(XmlResponses.HEAD_REPLACE);
  let headHTML = document.head.innerHTML;  
expect(headHTML.indexOf("href=\"../../../xhrCore/fixtures/addedViewHead2.css\"")).not.eq(-1);
expect(DQ$("head 
link[rel='stylesheet'][href='../../../xhrCore/fixtures/addedViewHead2.css']").length).to.eq(1);

// failing now, no script elements in the html head after respond!!!
   
expect(headHTML.indexOf("../../../xhrCore/fixtures/addedViewHead3.js")).not.eq(-1);
})

static HEAD_REPLACE = `







`
{code}


was (Author: werpu):
Error is reproducible with following unit test
{code:java}
it("head replacement must work 
(https://issues.apache.org/jira/browse/MYFACES-4498 and TCK Issue 4345IT)", 
function(done) {

  DQ.byId("cmd_complex_resource2").click();
  this.respond(XmlResponses.HEAD_REPLACE);
  let headHTML = document.head.innerHTML;
expect(headHTML.indexOf("href=\"../../../xhrCore/fixtures/addedViewHead2.css\"")).not.eq(-1);
expect(DQ$("head 
link[rel='stylesheet'][href='../../../xhrCore/fixtures/addedViewHead2.css']").length).to.eq(1);

// failing now, no script elements in the html head after respond!!!
   
expect(headHTML.indexOf("../../../xhrCore/fixtures/addedViewHead3.js")).not.eq(-1);
})

static HEAD_REPLACE = `







`
{code}

> TCK: Issue 4345 : Head Element Not Updated As Expected via Ajax Call
> 
>
> Key: MYFACES-4498
> URL: https://issues.apache.org/jira/browse/MYFACES-4498
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 4.0.0-RC2
>Reporter: Volodymyr Siedlecki
>Assignee: Werner Punz
>Priority: Major
> Attachments: test-faces22-ajax.war
>
>
> Test Code: 
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/test/java/ee/jakarta/tck/faces/test/servlet30/ajax/Issue4345IT.java#L47]
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/main/webapp/issue4345result.xhtml]
>  
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/test/java/ee/jakarta/tck/faces/test/servlet30/ajax/Issue4345IT.java#L47]
> This test was created for ensure HTML is only escaped twice ([Issue 
> 4345|https://github.com/eclipse-ee4j/mojarra/issues/4345). However, MyFaces 
> is encountering two problems with this test.
> Firstly, here is the Ajax response and the updated HTML: 
> {code:java}
> 
> 
>
>   
>  
>   
>   
>  
>   
>
>  {code}
> The HTML is then set as : 
> {code:java}
> http://www.w3.org/1999/xhtml;>
>
>   @import 
> url('/test-faces22-ajax/jakarta.faces.resource/issue4345.css.xhtml?firstParam=1&secondParam=2');
>
>
> 
>  {code}
> 1) We change from a link (type/css ) to a style tag that imports the URL? 
> Should that occur?  The JavaScript in issue4345result.xhtml specifically 
> looks for a link element. 
> 2) The script tags *are not appended* to the head element, but I do see 
> network requests for them. Additionally, the scripts do run (confirmed by the 
> console: "issue4345.js loaded." ). 
> This fails on both the RC2 scripts and the new TypeScript code. 
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (MYFACES-4498) TCK: Issue 4345 : Head Element Not Updated As Expected via Ajax Call

[Werner Punz (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17637817#comment-17637817
 ] 

Werner Punz edited comment on MYFACES-4498 at 11/23/22 3:03 PM:


Error is reproducible with following unit test
{code:java}
it("head replacement must work 
(https://issues.apache.org/jira/browse/MYFACES-4498 and TCK Issue 4345IT)", 
function(done) {

  DQ.byId("cmd_complex_resource2").click();
  this.respond(XmlResponses.HEAD_REPLACE);
  let headHTML = document.head.innerHTML;

expect(headHTML.indexOf("href=\"../../../xhrCore/fixtures/addedViewHead2.css\"")).not.eq(-1);
expect(DQ$("head 
link[rel='stylesheet'][href='../../../xhrCore/fixtures/addedViewHead2.css']").length).to.eq(1);

// failing now, no script elements in the html head after respond!!!
   
expect(headHTML.indexOf("../../../xhrCore/fixtures/addedViewHead3.js")).not.eq(-1);
})

static HEAD_REPLACE = `







`
{code}


was (Author: werpu):
Error is reproducible with following unit test
{code:java}
it("head replacement must work 
(https://issues.apache.org/jira/browse/MYFACES-4498 and TCK Issue 4345IT)", 
function(done) {

DQ.byId("cmd_complex_resource2").click();
this.respond(XmlResponses.HEAD_REPLACE);
let headHTML = document.head.innerHTML;

expect(headHTML.indexOf("href=\"../../../xhrCore/fixtures/addedViewHead2.css\"")).not.eq(-1);
expect(DQ$("head 
link[rel='stylesheet'][href='../../../xhrCore/fixtures/addedViewHead2.css']").length).to.eq(1);

// failing now, no script elements in the html head after respond!!!
   
expect(headHTML.indexOf("../../../xhrCore/fixtures/addedViewHead3.js")).not.eq(-1);
})

static HEAD_REPLACE = `







`
{code}

> TCK: Issue 4345 : Head Element Not Updated As Expected via Ajax Call
> 
>
> Key: MYFACES-4498
> URL: https://issues.apache.org/jira/browse/MYFACES-4498
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 4.0.0-RC2
>Reporter: Volodymyr Siedlecki
>Assignee: Werner Punz
>Priority: Major
> Attachments: test-faces22-ajax.war
>
>
> Test Code: 
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/test/java/ee/jakarta/tck/faces/test/servlet30/ajax/Issue4345IT.java#L47]
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/main/webapp/issue4345result.xhtml]
>  
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/test/java/ee/jakarta/tck/faces/test/servlet30/ajax/Issue4345IT.java#L47]
> This test was created for ensure HTML is only escaped twice ([Issue 
> 4345|https://github.com/eclipse-ee4j/mojarra/issues/4345). However, MyFaces 
> is encountering two problems with this test.
> Firstly, here is the Ajax response and the updated HTML: 
> {code:java}
> 
> 
>
>   
>  
>   
>   
>  
>   
>
>  {code}
> The HTML is then set as : 
> {code:java}
> http://www.w3.org/1999/xhtml;>
>
>   @import 
> url('/test-faces22-ajax/jakarta.faces.resource/issue4345.css.xhtml?firstParam=1&secondParam=2');
>
>
> 
>  {code}
> 1) We change from a link (type/css ) to a style tag that imports the URL? 
> Should that occur?  The JavaScript in issue4345result.xhtml specifically 
> looks for a link element. 
> 2) The script tags *are not appended* to the head element, but I do see 
> network requests for them. Additionally, the scripts do run (confirmed by the 
> console: "issue4345.js loaded." ). 
> This fails on both the RC2 scripts and the new TypeScript code. 
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (MYFACES-4498) TCK: Issue 4345 : Head Element Not Updated As Expected via Ajax Call

[Werner Punz (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17637817#comment-17637817
 ] 

Werner Punz edited comment on MYFACES-4498 at 11/23/22 3:02 PM:


Error is reproducible with following unit test
{code:java}
it("head replacement must work 
(https://issues.apache.org/jira/browse/MYFACES-4498 and TCK Issue 4345IT)", 
function(done) {

DQ.byId("cmd_complex_resource2").click();
this.respond(XmlResponses.HEAD_REPLACE);
let headHTML = document.head.innerHTML;

expect(headHTML.indexOf("href=\"../../../xhrCore/fixtures/addedViewHead2.css\"")).not.eq(-1);
expect(DQ$("head 
link[rel='stylesheet'][href='../../../xhrCore/fixtures/addedViewHead2.css']").length).to.eq(1);

// failing now, no escript lements in the html head after respond!!!
   
expect(headHTML.indexOf("../../../xhrCore/fixtures/addedViewHead3.js")).not.eq(-1);
})

static HEAD_REPLACE = `







`
{code}


was (Author: werpu):
Error is reproducible with following unit test
{code:java}
it("head replacement must work 
(https://issues.apache.org/jira/browse/MYFACES-4498 and TCK Issue 4345IT)", 
function(done) {

DQ.byId("cmd_complex_resource2").click();
this.respond(XmlResponses.HEAD_REPLACE);
let headHTML = document.head.innerHTML;


expect(headHTML.indexOf("href=\"../../../xhrCore/fixtures/addedViewHead2.css\"")).not.eq(-1);
expect(DQ$("head 
link[rel='stylesheet'][href='../../../xhrCore/fixtures/addedViewHead2.css']").length).to.eq(1);

// failing now, no escript lements in the html head after respond!!!
   
expect(headHTML.indexOf("../../../xhrCore/fixtures/addedViewHead3.js")).not.eq(-1);
})

static HEAD_REPLACE = `







`
{code}

> TCK: Issue 4345 : Head Element Not Updated As Expected via Ajax Call
> 
>
> Key: MYFACES-4498
> URL: https://issues.apache.org/jira/browse/MYFACES-4498
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 4.0.0-RC2
>Reporter: Volodymyr Siedlecki
>Assignee: Werner Punz
>Priority: Major
> Attachments: test-faces22-ajax.war
>
>
> Test Code: 
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/test/java/ee/jakarta/tck/faces/test/servlet30/ajax/Issue4345IT.java#L47]
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/main/webapp/issue4345result.xhtml]
>  
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/test/java/ee/jakarta/tck/faces/test/servlet30/ajax/Issue4345IT.java#L47]
> This test was created for ensure HTML is only escaped twice ([Issue 
> 4345|https://github.com/eclipse-ee4j/mojarra/issues/4345). However, MyFaces 
> is encountering two problems with this test.
> Firstly, here is the Ajax response and the updated HTML: 
> {code:java}
> 
> 
>
>   
>  
>   
>   
>  
>   
>
>  {code}
> The HTML is then set as : 
> {code:java}
> http://www.w3.org/1999/xhtml;>
>
>   @import 
> url('/test-faces22-ajax/jakarta.faces.resource/issue4345.css.xhtml?firstParam=1&secondParam=2');
>
>
> 
>  {code}
> 1) We change from a link (type/css ) to a style tag that imports the URL? 
> Should that occur?  The JavaScript in issue4345result.xhtml specifically 
> looks for a link element. 
> 2) The script tags *are not appended* to the head element, but I do see 
> network requests for them. Additionally, the scripts do run (confirmed by the 
> console: "issue4345.js loaded." ). 
> This fails on both the RC2 scripts and the new TypeScript code. 
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (MYFACES-4498) TCK: Issue 4345 : Head Element Not Updated As Expected via Ajax Call

[Werner Punz (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17637817#comment-17637817
 ] 

Werner Punz edited comment on MYFACES-4498 at 11/23/22 3:02 PM:


Error is reproducible with following unit test
{code:java}
it("head replacement must work 
(https://issues.apache.org/jira/browse/MYFACES-4498 and TCK Issue 4345IT)", 
function(done) {

DQ.byId("cmd_complex_resource2").click();
this.respond(XmlResponses.HEAD_REPLACE);
let headHTML = document.head.innerHTML;

expect(headHTML.indexOf("href=\"../../../xhrCore/fixtures/addedViewHead2.css\"")).not.eq(-1);
expect(DQ$("head 
link[rel='stylesheet'][href='../../../xhrCore/fixtures/addedViewHead2.css']").length).to.eq(1);

// failing now, no script elements in the html head after respond!!!
   
expect(headHTML.indexOf("../../../xhrCore/fixtures/addedViewHead3.js")).not.eq(-1);
})

static HEAD_REPLACE = `







`
{code}


was (Author: werpu):
Error is reproducible with following unit test
{code:java}
it("head replacement must work 
(https://issues.apache.org/jira/browse/MYFACES-4498 and TCK Issue 4345IT)", 
function(done) {

DQ.byId("cmd_complex_resource2").click();
this.respond(XmlResponses.HEAD_REPLACE);
let headHTML = document.head.innerHTML;

expect(headHTML.indexOf("href=\"../../../xhrCore/fixtures/addedViewHead2.css\"")).not.eq(-1);
expect(DQ$("head 
link[rel='stylesheet'][href='../../../xhrCore/fixtures/addedViewHead2.css']").length).to.eq(1);

// failing now, no escript lements in the html head after respond!!!
   
expect(headHTML.indexOf("../../../xhrCore/fixtures/addedViewHead3.js")).not.eq(-1);
})

static HEAD_REPLACE = `







`
{code}

> TCK: Issue 4345 : Head Element Not Updated As Expected via Ajax Call
> 
>
> Key: MYFACES-4498
> URL: https://issues.apache.org/jira/browse/MYFACES-4498
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 4.0.0-RC2
>Reporter: Volodymyr Siedlecki
>Assignee: Werner Punz
>Priority: Major
> Attachments: test-faces22-ajax.war
>
>
> Test Code: 
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/test/java/ee/jakarta/tck/faces/test/servlet30/ajax/Issue4345IT.java#L47]
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/main/webapp/issue4345result.xhtml]
>  
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/test/java/ee/jakarta/tck/faces/test/servlet30/ajax/Issue4345IT.java#L47]
> This test was created for ensure HTML is only escaped twice ([Issue 
> 4345|https://github.com/eclipse-ee4j/mojarra/issues/4345). However, MyFaces 
> is encountering two problems with this test.
> Firstly, here is the Ajax response and the updated HTML: 
> {code:java}
> 
> 
>
>   
>  
>   
>   
>  
>   
>
>  {code}
> The HTML is then set as : 
> {code:java}
> http://www.w3.org/1999/xhtml;>
>
>   @import 
> url('/test-faces22-ajax/jakarta.faces.resource/issue4345.css.xhtml?firstParam=1&secondParam=2');
>
>
> 
>  {code}
> 1) We change from a link (type/css ) to a style tag that imports the URL? 
> Should that occur?  The JavaScript in issue4345result.xhtml specifically 
> looks for a link element. 
> 2) The script tags *are not appended* to the head element, but I do see 
> network requests for them. Additionally, the scripts do run (confirmed by the 
> console: "issue4345.js loaded." ). 
> This fails on both the RC2 scripts and the new TypeScript code. 
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (MYFACES-4498) TCK: Issue 4345 : Head Element Not Updated As Expected via Ajax Call

[Werner Punz (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17637817#comment-17637817
 ] 

Werner Punz edited comment on MYFACES-4498 at 11/23/22 3:01 PM:


Error is reproducible with following unit test
{code:java}
it("head replacement must work 
(https://issues.apache.org/jira/browse/MYFACES-4498 and TCK Issue 4345IT)", 
function(done) {

DQ.byId("cmd_complex_resource2").click();
this.respond(XmlResponses.HEAD_REPLACE);
let headHTML = document.head.innerHTML;


expect(headHTML.indexOf("href=\"../../../xhrCore/fixtures/addedViewHead2.css\"")).not.eq(-1);
expect(DQ$("head 
link[rel='stylesheet'][href='../../../xhrCore/fixtures/addedViewHead2.css']").length).to.eq(1);

// failing now, no escript lements in the html head after respond!!!
   
expect(headHTML.indexOf("../../../xhrCore/fixtures/addedViewHead3.js")).not.eq(-1);
})

static HEAD_REPLACE = `







`
{code}


was (Author: werpu):
Error is reproducible with following unit test
{code:java}
it("head replacement must work 
(https://issues.apache.org/jira/browse/MYFACES-4498 and TCK Issue 4345IT)", 
function(done) {

DQ.byId("cmd_complex_resource2").click();
this.respond(XmlResponses.HEAD_REPLACE);
let headHTML = document.head.innerHTML;

//failing now, no elements in the html head after respond!!!

expect(headHTML.indexOf("href=\"../../../xhrCore/fixtures/addedViewHead2.css\"")).not.eq(-1);
expect(DQ$("head 
link[rel='stylesheet'][href='../../../xhrCore/fixtures/addedViewHead2.css']").length).to.eq(1);
// Failing here!
expect(headHTML.indexOf("../../../xhrCore/fixtures/addedViewHead3.js")).not.eq(-1);
})

static HEAD_REPLACE = `







`
{code}

> TCK: Issue 4345 : Head Element Not Updated As Expected via Ajax Call
> 
>
> Key: MYFACES-4498
> URL: https://issues.apache.org/jira/browse/MYFACES-4498
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 4.0.0-RC2
>Reporter: Volodymyr Siedlecki
>Assignee: Werner Punz
>Priority: Major
> Attachments: test-faces22-ajax.war
>
>
> Test Code: 
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/test/java/ee/jakarta/tck/faces/test/servlet30/ajax/Issue4345IT.java#L47]
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/main/webapp/issue4345result.xhtml]
>  
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/test/java/ee/jakarta/tck/faces/test/servlet30/ajax/Issue4345IT.java#L47]
> This test was created for ensure HTML is only escaped twice ([Issue 
> 4345|https://github.com/eclipse-ee4j/mojarra/issues/4345). However, MyFaces 
> is encountering two problems with this test.
> Firstly, here is the Ajax response and the updated HTML: 
> {code:java}
> 
> 
>
>   
>  
>   
>   
>  
>   
>
>  {code}
> The HTML is then set as : 
> {code:java}
> http://www.w3.org/1999/xhtml;>
>
>   @import 
> url('/test-faces22-ajax/jakarta.faces.resource/issue4345.css.xhtml?firstParam=1&secondParam=2');
>
>
> 
>  {code}
> 1) We change from a link (type/css ) to a style tag that imports the URL? 
> Should that occur?  The JavaScript in issue4345result.xhtml specifically 
> looks for a link element. 
> 2) The script tags *are not appended* to the head element, but I do see 
> network requests for them. Additionally, the scripts do run (confirmed by the 
> console: "issue4345.js loaded." ). 
> This fails on both the RC2 scripts and the new TypeScript code. 
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (MYFACES-4498) TCK: Issue 4345 : Head Element Not Updated As Expected via Ajax Call

[Werner Punz (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17637817#comment-17637817
 ] 

Werner Punz edited comment on MYFACES-4498 at 11/23/22 3:00 PM:


Error is reproducible with following unit test
{code:java}
it("head replacement must work 
(https://issues.apache.org/jira/browse/MYFACES-4498 and TCK Issue 4345IT)", 
function(done) {

DQ.byId("cmd_complex_resource2").click();
this.respond(XmlResponses.HEAD_REPLACE);
let headHTML = document.head.innerHTML;

//failing now, no elements in the html head after respond!!!

expect(headHTML.indexOf("href=\"../../../xhrCore/fixtures/addedViewHead2.css\"")).not.eq(-1);
expect(DQ$("head 
link[rel='stylesheet'][href='../../../xhrCore/fixtures/addedViewHead2.css']").length).to.eq(1);
// Failing here!
expect(headHTML.indexOf("../../../xhrCore/fixtures/addedViewHead3.js")).not.eq(-1);
})

static HEAD_REPLACE = `







`
{code}


was (Author: werpu):
Error is reproducible with following unit test
{code:java}
it("head replacement must work 
(https://issues.apache.org/jira/browse/MYFACES-4498 and TCK Issue 4345IT)", 
function(done) {

DQ.byId("cmd_complex_resource2").click();
this.respond(XmlResponses.HEAD_REPLACE);
let headHTML = document.head.innerHTML;

//failing now, no elements in the html head after respond!!!

expect(headHTML.indexOf("href=\"../../../xhrCore/fixtures/addedViewHead2.css\"")).not.eq(-1);
expect(DQ$("head 
link[rel='stylesheet'][href='../../../xhrCore/fixtures/addedViewHead2.css']").length).to.eq(1);

expect(headHTML.indexOf("../../../xhrCore/fixtures/addedViewHead3.js")).not.eq(-1);
})

static HEAD_REPLACE = `







`
{code}

> TCK: Issue 4345 : Head Element Not Updated As Expected via Ajax Call
> 
>
> Key: MYFACES-4498
> URL: https://issues.apache.org/jira/browse/MYFACES-4498
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 4.0.0-RC2
>Reporter: Volodymyr Siedlecki
>Assignee: Werner Punz
>Priority: Major
> Attachments: test-faces22-ajax.war
>
>
> Test Code: 
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/test/java/ee/jakarta/tck/faces/test/servlet30/ajax/Issue4345IT.java#L47]
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/main/webapp/issue4345result.xhtml]
>  
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/test/java/ee/jakarta/tck/faces/test/servlet30/ajax/Issue4345IT.java#L47]
> This test was created for ensure HTML is only escaped twice ([Issue 
> 4345|https://github.com/eclipse-ee4j/mojarra/issues/4345). However, MyFaces 
> is encountering two problems with this test.
> Firstly, here is the Ajax response and the updated HTML: 
> {code:java}
> 
> 
>
>   
>  
>   
>   
>  
>   
>
>  {code}
> The HTML is then set as : 
> {code:java}
> http://www.w3.org/1999/xhtml;>
>
>   @import 
> url('/test-faces22-ajax/jakarta.faces.resource/issue4345.css.xhtml?firstParam=1&secondParam=2');
>
>
> 
>  {code}
> 1) We change from a link (type/css ) to a style tag that imports the URL? 
> Should that occur?  The JavaScript in issue4345result.xhtml specifically 
> looks for a link element. 
> 2) The script tags *are not appended* to the head element, but I do see 
> network requests for them. Additionally, the scripts do run (confirmed by the 
> console: "issue4345.js loaded." ). 
> This fails on both the RC2 scripts and the new TypeScript code. 
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (MYFACES-4498) TCK: Issue 4345 : Head Element Not Updated As Expected via Ajax Call

[Werner Punz (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17637817#comment-17637817
 ] 

Werner Punz edited comment on MYFACES-4498 at 11/23/22 2:59 PM:


Error is reproducible with following unit test
{code}
it("head replacement must work 
(https://issues.apache.org/jira/browse/MYFACES-4498 and TCK Issue 4345IT)", 
function(done) {

DQ.byId("cmd_complex_resource2").click();
this.respond(XmlResponses.HEAD_REPLACE);
let headHTML = document.head.innerHTML;

//failing now, no elements in the html head after respond!!!

expect(headHTML.indexOf("href=\"../../../xhrCore/fixtures/addedViewHead2.css\"")).not.eq(-1);
expect(DQ$("head 
link[rel='stylesheet'][href='../../../xhrCore/fixtures/addedViewHead2.css']").length).to.eq(1);

expect(headHTML.indexOf("../../../xhrCore/fixtures/addedViewHead3.js")).not.eq(-1);
})

  static HEAD_REPLACE = `





`
{code}


was (Author: werpu):
Error is reproducible with following unit test

{code:typescript}
 it("head replacement must work 
(https://issues.apache.org/jira/browse/MYFACES-4498 and TCK Issue 4345IT)", 
function(done) {

DQ.byId("cmd_complex_resource2").click();
this.respond(XmlResponses.HEAD_REPLACE);
let headHTML = document.head.innerHTML;

//failing now, no elements in the html head after respond!!!

expect(headHTML.indexOf("href=\"../../../xhrCore/fixtures/addedViewHead2.css\"")).not.eq(-1);
expect(DQ$("head 
link[rel='stylesheet'][href='../../../xhrCore/fixtures/addedViewHead2.css']").length).to.eq(1);

expect(headHTML.indexOf("../../../xhrCore/fixtures/addedViewHead3.js")).not.eq(-1);
})

  static HEAD_REPLACE = `





`
{code}

> TCK: Issue 4345 : Head Element Not Updated As Expected via Ajax Call
> 
>
> Key: MYFACES-4498
> URL: https://issues.apache.org/jira/browse/MYFACES-4498
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 4.0.0-RC2
>Reporter: Volodymyr Siedlecki
>Assignee: Werner Punz
>Priority: Major
> Attachments: test-faces22-ajax.war
>
>
> Test Code: 
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/test/java/ee/jakarta/tck/faces/test/servlet30/ajax/Issue4345IT.java#L47]
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/main/webapp/issue4345result.xhtml]
>  
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/test/java/ee/jakarta/tck/faces/test/servlet30/ajax/Issue4345IT.java#L47]
> This test was created for ensure HTML is only escaped twice ([Issue 
> 4345|https://github.com/eclipse-ee4j/mojarra/issues/4345). However, MyFaces 
> is encountering two problems with this test.
> Firstly, here is the Ajax response and the updated HTML: 
> {code:java}
> 
> 
>
>   
>  
>   
>   
>  
>   
>
>  {code}
> The HTML is then set as : 
> {code:java}
> http://www.w3.org/1999/xhtml;>
>
>   @import 
> url('/test-faces22-ajax/jakarta.faces.resource/issue4345.css.xhtml?firstParam=1&secondParam=2');
>
>
> 
>  {code}
> 1) We change from a link (type/css ) to a style tag that imports the URL? 
> Should that occur?  The JavaScript in issue4345result.xhtml specifically 
> looks for a link element. 
> 2) The script tags *are not appended* to the head element, but I do see 
> network requests for them. Additionally, the scripts do run (confirmed by the 
> console: "issue4345.js loaded." ). 
> This fails on both the RC2 scripts and the new TypeScript code. 
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (MYFACES-4498) TCK: Issue 4345 : Head Element Not Updated As Expected via Ajax Call

[Werner Punz (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17637817#comment-17637817
 ] 

Werner Punz edited comment on MYFACES-4498 at 11/23/22 2:59 PM:


Error is reproducible with following unit test
{code}
it("head replacement must work 
(https://issues.apache.org/jira/browse/MYFACES-4498 and TCK Issue 4345IT)", 
function(done) {

DQ.byId("cmd_complex_resource2").click();
this.respond(XmlResponses.HEAD_REPLACE);
let headHTML = document.head.innerHTML;

//failing now, no elements in the html head after respond!!!

expect(headHTML.indexOf("href=\"../../../xhrCore/fixtures/addedViewHead2.css\"")).not.eq(-1);
expect(DQ$("head 
link[rel='stylesheet'][href='../../../xhrCore/fixtures/addedViewHead2.css']").length).to.eq(1);

expect(headHTML.indexOf("../../../xhrCore/fixtures/addedViewHead3.js")).not.eq(-1);
})

  static HEAD_REPLACE = `





`
{code}


was (Author: werpu):
Error is reproducible with following unit test
{code}
it("head replacement must work 
(https://issues.apache.org/jira/browse/MYFACES-4498 and TCK Issue 4345IT)", 
function(done) {

DQ.byId("cmd_complex_resource2").click();
this.respond(XmlResponses.HEAD_REPLACE);
let headHTML = document.head.innerHTML;

//failing now, no elements in the html head after respond!!!

expect(headHTML.indexOf("href=\"../../../xhrCore/fixtures/addedViewHead2.css\"")).not.eq(-1);
expect(DQ$("head 
link[rel='stylesheet'][href='../../../xhrCore/fixtures/addedViewHead2.css']").length).to.eq(1);

expect(headHTML.indexOf("../../../xhrCore/fixtures/addedViewHead3.js")).not.eq(-1);
})

  static HEAD_REPLACE = `





`
{code}

> TCK: Issue 4345 : Head Element Not Updated As Expected via Ajax Call
> 
>
> Key: MYFACES-4498
> URL: https://issues.apache.org/jira/browse/MYFACES-4498
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 4.0.0-RC2
>Reporter: Volodymyr Siedlecki
>Assignee: Werner Punz
>Priority: Major
> Attachments: test-faces22-ajax.war
>
>
> Test Code: 
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/test/java/ee/jakarta/tck/faces/test/servlet30/ajax/Issue4345IT.java#L47]
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/main/webapp/issue4345result.xhtml]
>  
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/test/java/ee/jakarta/tck/faces/test/servlet30/ajax/Issue4345IT.java#L47]
> This test was created for ensure HTML is only escaped twice ([Issue 
> 4345|https://github.com/eclipse-ee4j/mojarra/issues/4345). However, MyFaces 
> is encountering two problems with this test.
> Firstly, here is the Ajax response and the updated HTML: 
> {code:java}
> 
> 
>
>   
>  
>   
>   
>  
>   
>
>  {code}
> The HTML is then set as : 
> {code:java}
> http://www.w3.org/1999/xhtml;>
>
>   @import 
> url('/test-faces22-ajax/jakarta.faces.resource/issue4345.css.xhtml?firstParam=1&secondParam=2');
>
>
> 
>  {code}
> 1) We change from a link (type/css ) to a style tag that imports the URL? 
> Should that occur?  The JavaScript in issue4345result.xhtml specifically 
> looks for a link element. 
> 2) The script tags *are not appended* to the head element, but I do see 
> network requests for them. Additionally, the scripts do run (confirmed by the 
> console: "issue4345.js loaded." ). 
> This fails on both the RC2 scripts and the new TypeScript code. 
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (MYFACES-4498) TCK: Issue 4345 : Head Element Not Updated As Expected via Ajax Call

[Werner Punz (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17637817#comment-17637817
 ] 

Werner Punz edited comment on MYFACES-4498 at 11/23/22 2:59 PM:


Error is reproducible with following unit test
{code:java}
it("head replacement must work 
(https://issues.apache.org/jira/browse/MYFACES-4498 and TCK Issue 4345IT)", 
function(done) {

DQ.byId("cmd_complex_resource2").click();
this.respond(XmlResponses.HEAD_REPLACE);
let headHTML = document.head.innerHTML;

//failing now, no elements in the html head after respond!!!

expect(headHTML.indexOf("href=\"../../../xhrCore/fixtures/addedViewHead2.css\"")).not.eq(-1);
expect(DQ$("head 
link[rel='stylesheet'][href='../../../xhrCore/fixtures/addedViewHead2.css']").length).to.eq(1);

expect(headHTML.indexOf("../../../xhrCore/fixtures/addedViewHead3.js")).not.eq(-1);
})

static HEAD_REPLACE = `







`
{code}


was (Author: werpu):
Error is reproducible with following unit test
{code:java}
it("head replacement must work 
(https://issues.apache.org/jira/browse/MYFACES-4498 and TCK Issue 4345IT)", 
function(done) {

DQ.byId("cmd_complex_resource2").click();
this.respond(XmlResponses.HEAD_REPLACE);
let headHTML = document.head.innerHTML;

//failing now, no elements in the html head after respond!!!

expect(headHTML.indexOf("href=\"../../../xhrCore/fixtures/addedViewHead2.css\"")).not.eq(-1);
expect(DQ$("head 
link[rel='stylesheet'][href='../../../xhrCore/fixtures/addedViewHead2.css']").length).to.eq(1);

expect(headHTML.indexOf("../../../xhrCore/fixtures/addedViewHead3.js")).not.eq(-1);
})

static HEAD_REPLACE = `





`
{code}

> TCK: Issue 4345 : Head Element Not Updated As Expected via Ajax Call
> 
>
> Key: MYFACES-4498
> URL: https://issues.apache.org/jira/browse/MYFACES-4498
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 4.0.0-RC2
>Reporter: Volodymyr Siedlecki
>Assignee: Werner Punz
>Priority: Major
> Attachments: test-faces22-ajax.war
>
>
> Test Code: 
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/test/java/ee/jakarta/tck/faces/test/servlet30/ajax/Issue4345IT.java#L47]
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/main/webapp/issue4345result.xhtml]
>  
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/test/java/ee/jakarta/tck/faces/test/servlet30/ajax/Issue4345IT.java#L47]
> This test was created for ensure HTML is only escaped twice ([Issue 
> 4345|https://github.com/eclipse-ee4j/mojarra/issues/4345). However, MyFaces 
> is encountering two problems with this test.
> Firstly, here is the Ajax response and the updated HTML: 
> {code:java}
> 
> 
>
>   
>  
>   
>   
>  
>   
>
>  {code}
> The HTML is then set as : 
> {code:java}
> http://www.w3.org/1999/xhtml;>
>
>   @import 
> url('/test-faces22-ajax/jakarta.faces.resource/issue4345.css.xhtml?firstParam=1&secondParam=2');
>
>
> 
>  {code}
> 1) We change from a link (type/css ) to a style tag that imports the URL? 
> Should that occur?  The JavaScript in issue4345result.xhtml specifically 
> looks for a link element. 
> 2) The script tags *are not appended* to the head element, but I do see 
> network requests for them. Additionally, the scripts do run (confirmed by the 
> console: "issue4345.js loaded." ). 
> This fails on both the RC2 scripts and the new TypeScript code. 
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (MYFACES-4498) TCK: Issue 4345 : Head Element Not Updated As Expected via Ajax Call

[Werner Punz (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17637817#comment-17637817
 ] 

Werner Punz edited comment on MYFACES-4498 at 11/23/22 2:59 PM:


Error is reproducible with following unit test
{code:java}
it("head replacement must work 
(https://issues.apache.org/jira/browse/MYFACES-4498 and TCK Issue 4345IT)", 
function(done) {

DQ.byId("cmd_complex_resource2").click();
this.respond(XmlResponses.HEAD_REPLACE);
let headHTML = document.head.innerHTML;

//failing now, no elements in the html head after respond!!!

expect(headHTML.indexOf("href=\"../../../xhrCore/fixtures/addedViewHead2.css\"")).not.eq(-1);
expect(DQ$("head 
link[rel='stylesheet'][href='../../../xhrCore/fixtures/addedViewHead2.css']").length).to.eq(1);

expect(headHTML.indexOf("../../../xhrCore/fixtures/addedViewHead3.js")).not.eq(-1);
})

static HEAD_REPLACE = `





`
{code}


was (Author: werpu):
Error is reproducible with following unit test
{code}
it("head replacement must work 
(https://issues.apache.org/jira/browse/MYFACES-4498 and TCK Issue 4345IT)", 
function(done) {

DQ.byId("cmd_complex_resource2").click();
this.respond(XmlResponses.HEAD_REPLACE);
let headHTML = document.head.innerHTML;

//failing now, no elements in the html head after respond!!!

expect(headHTML.indexOf("href=\"../../../xhrCore/fixtures/addedViewHead2.css\"")).not.eq(-1);
expect(DQ$("head 
link[rel='stylesheet'][href='../../../xhrCore/fixtures/addedViewHead2.css']").length).to.eq(1);

expect(headHTML.indexOf("../../../xhrCore/fixtures/addedViewHead3.js")).not.eq(-1);
})

  static HEAD_REPLACE = `





`
{code}

> TCK: Issue 4345 : Head Element Not Updated As Expected via Ajax Call
> 
>
> Key: MYFACES-4498
> URL: https://issues.apache.org/jira/browse/MYFACES-4498
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 4.0.0-RC2
>Reporter: Volodymyr Siedlecki
>Assignee: Werner Punz
>Priority: Major
> Attachments: test-faces22-ajax.war
>
>
> Test Code: 
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/test/java/ee/jakarta/tck/faces/test/servlet30/ajax/Issue4345IT.java#L47]
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/main/webapp/issue4345result.xhtml]
>  
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/test/java/ee/jakarta/tck/faces/test/servlet30/ajax/Issue4345IT.java#L47]
> This test was created for ensure HTML is only escaped twice ([Issue 
> 4345|https://github.com/eclipse-ee4j/mojarra/issues/4345). However, MyFaces 
> is encountering two problems with this test.
> Firstly, here is the Ajax response and the updated HTML: 
> {code:java}
> 
> 
>
>   
>  
>   
>   
>  
>   
>
>  {code}
> The HTML is then set as : 
> {code:java}
> http://www.w3.org/1999/xhtml;>
>
>   @import 
> url('/test-faces22-ajax/jakarta.faces.resource/issue4345.css.xhtml?firstParam=1&secondParam=2');
>
>
> 
>  {code}
> 1) We change from a link (type/css ) to a style tag that imports the URL? 
> Should that occur?  The JavaScript in issue4345result.xhtml specifically 
> looks for a link element. 
> 2) The script tags *are not appended* to the head element, but I do see 
> network requests for them. Additionally, the scripts do run (confirmed by the 
> console: "issue4345.js loaded." ). 
> This fails on both the RC2 scripts and the new TypeScript code. 
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (MYFACES-4498) TCK: Issue 4345 : Head Element Not Updated As Expected via Ajax Call

[Werner Punz (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17637817#comment-17637817
 ] 

Werner Punz edited comment on MYFACES-4498 at 11/23/22 2:58 PM:


Error is reproducible with following unit test

{code:typescript}
 it("head replacement must work 
(https://issues.apache.org/jira/browse/MYFACES-4498 and TCK Issue 4345IT)", 
function(done) {

DQ.byId("cmd_complex_resource2").click();
this.respond(XmlResponses.HEAD_REPLACE);
let headHTML = document.head.innerHTML;

//failing now, no elements in the html head after respond!!!

expect(headHTML.indexOf("href=\"../../../xhrCore/fixtures/addedViewHead2.css\"")).not.eq(-1);
expect(DQ$("head 
link[rel='stylesheet'][href='../../../xhrCore/fixtures/addedViewHead2.css']").length).to.eq(1);

expect(headHTML.indexOf("../../../xhrCore/fixtures/addedViewHead3.js")).not.eq(-1);
})

  static HEAD_REPLACE = `





`
{code}


was (Author: werpu):
Error is reproducible with following unit test

```typescript
 it("head replacement must work 
(https://issues.apache.org/jira/browse/MYFACES-4498 and TCK Issue 4345IT)", 
function(done) {

DQ.byId("cmd_complex_resource2").click();
this.respond(XmlResponses.HEAD_REPLACE);
let headHTML = document.head.innerHTML;

//failing now, no elements in the html head after respond!!!

expect(headHTML.indexOf("href=\"../../../xhrCore/fixtures/addedViewHead2.css\"")).not.eq(-1);
expect(DQ$("head 
link[rel='stylesheet'][href='../../../xhrCore/fixtures/addedViewHead2.css']").length).to.eq(1);

expect(headHTML.indexOf("../../../xhrCore/fixtures/addedViewHead3.js")).not.eq(-1);
})

  static HEAD_REPLACE = `





`
```

> TCK: Issue 4345 : Head Element Not Updated As Expected via Ajax Call
> 
>
> Key: MYFACES-4498
> URL: https://issues.apache.org/jira/browse/MYFACES-4498
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 4.0.0-RC2
>Reporter: Volodymyr Siedlecki
>Assignee: Werner Punz
>Priority: Major
> Attachments: test-faces22-ajax.war
>
>
> Test Code: 
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/test/java/ee/jakarta/tck/faces/test/servlet30/ajax/Issue4345IT.java#L47]
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/main/webapp/issue4345result.xhtml]
>  
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/test/java/ee/jakarta/tck/faces/test/servlet30/ajax/Issue4345IT.java#L47]
> This test was created for ensure HTML is only escaped twice ([Issue 
> 4345|https://github.com/eclipse-ee4j/mojarra/issues/4345). However, MyFaces 
> is encountering two problems with this test.
> Firstly, here is the Ajax response and the updated HTML: 
> {code:java}
> 
> 
>
>   
>  
>   
>   
>  
>   
>
>  {code}
> The HTML is then set as : 
> {code:java}
> http://www.w3.org/1999/xhtml;>
>
>   @import 
> url('/test-faces22-ajax/jakarta.faces.resource/issue4345.css.xhtml?firstParam=1&secondParam=2');
>
>
> 
>  {code}
> 1) We change from a link (type/css ) to a style tag that imports the URL? 
> Should that occur?  The JavaScript in issue4345result.xhtml specifically 
> looks for a link element. 
> 2) The script tags *are not appended* to the head element, but I do see 
> network requests for them. Additionally, the scripts do run (confirmed by the 
> console: "issue4345.js loaded." ). 
> This fails on both the RC2 scripts and the new TypeScript code. 
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (MYFACES-4498) TCK: Issue 4345 : Head Element Not Updated As Expected via Ajax Call

[Werner Punz (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17637817#comment-17637817
 ] 

Werner Punz commented on MYFACES-4498:
--

Error is reproducible with following unit test

```typescript
 it("head replacement must work 
(https://issues.apache.org/jira/browse/MYFACES-4498 and TCK Issue 4345IT)", 
function(done) {

DQ.byId("cmd_complex_resource2").click();
this.respond(XmlResponses.HEAD_REPLACE);
let headHTML = document.head.innerHTML;

//failing now, no elements in the html head after respond!!!

expect(headHTML.indexOf("href=\"../../../xhrCore/fixtures/addedViewHead2.css\"")).not.eq(-1);
expect(DQ$("head 
link[rel='stylesheet'][href='../../../xhrCore/fixtures/addedViewHead2.css']").length).to.eq(1);

expect(headHTML.indexOf("../../../xhrCore/fixtures/addedViewHead3.js")).not.eq(-1);
})

  static HEAD_REPLACE = `





`
```

> TCK: Issue 4345 : Head Element Not Updated As Expected via Ajax Call
> 
>
> Key: MYFACES-4498
> URL: https://issues.apache.org/jira/browse/MYFACES-4498
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 4.0.0-RC2
>Reporter: Volodymyr Siedlecki
>Assignee: Werner Punz
>Priority: Major
> Attachments: test-faces22-ajax.war
>
>
> Test Code: 
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/test/java/ee/jakarta/tck/faces/test/servlet30/ajax/Issue4345IT.java#L47]
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/main/webapp/issue4345result.xhtml]
>  
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/test/java/ee/jakarta/tck/faces/test/servlet30/ajax/Issue4345IT.java#L47]
> This test was created for ensure HTML is only escaped twice ([Issue 
> 4345|https://github.com/eclipse-ee4j/mojarra/issues/4345). However, MyFaces 
> is encountering two problems with this test.
> Firstly, here is the Ajax response and the updated HTML: 
> {code:java}
> 
> 
>
>   
>  
>   
>   
>  
>   
>
>  {code}
> The HTML is then set as : 
> {code:java}
> http://www.w3.org/1999/xhtml;>
>
>   @import 
> url('/test-faces22-ajax/jakarta.faces.resource/issue4345.css.xhtml?firstParam=1&secondParam=2');
>
>
> 
>  {code}
> 1) We change from a link (type/css ) to a style tag that imports the URL? 
> Should that occur?  The JavaScript in issue4345result.xhtml specifically 
> looks for a link element. 
> 2) The script tags *are not appended* to the head element, but I do see 
> network requests for them. Additionally, the scripts do run (confirmed by the 
> console: "issue4345.js loaded." ). 
> This fails on both the RC2 scripts and the new TypeScript code. 
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (MYFACES-4498) TCK: Issue 4345 : Head Element Not Updated As Expected via Ajax Call

[Werner Punz (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17637706#comment-17637706
 ] 

Werner Punz edited comment on MYFACES-4498 at 11/23/22 1:48 PM:


The link style  change is a bug in our codebase... will be fixed
The script disappearing already documented above. 
I will fix it for the new codebase first where I can set dedicated unit tests 
for this case and then fix it 
for our old codebase if requested/needed.
Reedit:
The Link stylesheet bug is a bug in the mona-dish codebase very likely carried 
over from the old myfaces codebas where this transformation was needed to apply 
styles in IE6 as far as I recall, but definitely obsolete now!

Not having the script elements being sticky in a head replace is clearly a bug, 
I already have the sticky flag in the codebase for script evaluation, it very 
likely is not used for this case.




was (Author: werpu):
The link style  change is a bug in our codebase... will be fixed
The script disappearing already documented above. 
I will fix it for the new codebase first where I can set dedicated unit tests 
for this case and then fix it 
for our old codebase if requested/needed.
Reedit:
The Link stylesheet bug is a bug in the mona-dish codebase very likely carried 
over from the old myfaces codebas where this transformation was needed to apply 
styles in IE6!

Not having the script elements being sticky in a head replace is clearly a bug, 
I already have the sticky flag in the codebase for script evaluation, it very 
likely is not used for this case.



> TCK: Issue 4345 : Head Element Not Updated As Expected via Ajax Call
> 
>
> Key: MYFACES-4498
> URL: https://issues.apache.org/jira/browse/MYFACES-4498
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 4.0.0-RC2
>Reporter: Volodymyr Siedlecki
>    Assignee: Werner Punz
>Priority: Major
> Attachments: test-faces22-ajax.war
>
>
> Test Code: 
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/test/java/ee/jakarta/tck/faces/test/servlet30/ajax/Issue4345IT.java#L47]
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/main/webapp/issue4345result.xhtml]
>  
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/test/java/ee/jakarta/tck/faces/test/servlet30/ajax/Issue4345IT.java#L47]
> This test was created for ensure HTML is only escaped twice ([Issue 
> 4345|https://github.com/eclipse-ee4j/mojarra/issues/4345). However, MyFaces 
> is encountering two problems with this test.
> Firstly, here is the Ajax response and the updated HTML: 
> {code:java}
> 
> 
>
>   
>  
>   
>   
>  
>   
>
>  {code}
> The HTML is then set as : 
> {code:java}
> http://www.w3.org/1999/xhtml;>
>
>   @import 
> url('/test-faces22-ajax/jakarta.faces.resource/issue4345.css.xhtml?firstParam=1&secondParam=2');
>
>
> 
>  {code}
> 1) We change from a link (type/css ) to a style tag that imports the URL? 
> Should that occur?  The JavaScript in issue4345result.xhtml specifically 
> looks for a link element. 
> 2) The script tags *are not appended* to the head element, but I do see 
> network requests for them. Additionally, the scripts do run (confirmed by the 
> console: "issue4345.js loaded." ). 
> This fails on both the RC2 scripts and the new TypeScript code. 
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (MYFACES-4498) TCK: Issue 4345 : Head Element Not Updated As Expected via Ajax Call

[Werner Punz (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17637706#comment-17637706
 ] 

Werner Punz edited comment on MYFACES-4498 at 11/23/22 1:47 PM:


The link style  change is a bug in our codebase... will be fixed
The script disappearing already documented above. 
I will fix it for the new codebase first where I can set dedicated unit tests 
for this case and then fix it 
for our old codebase if requested/needed.
Reedit:
The Link stylesheet bug is a bug in the mona-dish codebase very likely carried 
over from the old myfaces codebas where this transformation was needed to apply 
styles in IE6!

Not having the script elements being sticky in a head replace is clearly a bug, 
I already have the sticky flag in the codebase for script evaluation, it very 
likely is not used for this case.




was (Author: werpu):
The link style  change is a bug in our codebase... will be fixed
The script disappearing already documented above. 
I will fix it for the new codebase first where I can set dedicated unit tests 
for this case and then fix it 
for our old codebase if requested/needed.


> TCK: Issue 4345 : Head Element Not Updated As Expected via Ajax Call
> 
>
> Key: MYFACES-4498
> URL: https://issues.apache.org/jira/browse/MYFACES-4498
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 4.0.0-RC2
>Reporter: Volodymyr Siedlecki
>    Assignee: Werner Punz
>Priority: Major
> Attachments: test-faces22-ajax.war
>
>
> Test Code: 
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/test/java/ee/jakarta/tck/faces/test/servlet30/ajax/Issue4345IT.java#L47]
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/main/webapp/issue4345result.xhtml]
>  
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/test/java/ee/jakarta/tck/faces/test/servlet30/ajax/Issue4345IT.java#L47]
> This test was created for ensure HTML is only escaped twice ([Issue 
> 4345|https://github.com/eclipse-ee4j/mojarra/issues/4345). However, MyFaces 
> is encountering two problems with this test.
> Firstly, here is the Ajax response and the updated HTML: 
> {code:java}
> 
> 
>
>   
>  
>   
>   
>  
>   
>
>  {code}
> The HTML is then set as : 
> {code:java}
> http://www.w3.org/1999/xhtml;>
>
>   @import 
> url('/test-faces22-ajax/jakarta.faces.resource/issue4345.css.xhtml?firstParam=1&secondParam=2');
>
>
> 
>  {code}
> 1) We change from a link (type/css ) to a style tag that imports the URL? 
> Should that occur?  The JavaScript in issue4345result.xhtml specifically 
> looks for a link element. 
> 2) The script tags *are not appended* to the head element, but I do see 
> network requests for them. Additionally, the scripts do run (confirmed by the 
> console: "issue4345.js loaded." ). 
> This fails on both the RC2 scripts and the new TypeScript code. 
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (MYFACES-4498) TCK: Issue 4345 : Head Element Not Updated As Expected via Ajax Call

[Werner Punz (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17637706#comment-17637706
 ] 

Werner Punz commented on MYFACES-4498:
--

The link style  change is a bug in our codebase... will be fixed
The script disappearing already documented above. 
I will fix it for the new codebase first where I can set dedicated unit tests 
for this case and then fix it 
for our old codebase if requested/needed.


> TCK: Issue 4345 : Head Element Not Updated As Expected via Ajax Call
> 
>
> Key: MYFACES-4498
> URL: https://issues.apache.org/jira/browse/MYFACES-4498
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 4.0.0-RC2
>Reporter: Volodymyr Siedlecki
>    Assignee: Werner Punz
>Priority: Major
> Attachments: test-faces22-ajax.war
>
>
> Test Code: 
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/test/java/ee/jakarta/tck/faces/test/servlet30/ajax/Issue4345IT.java#L47]
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/main/webapp/issue4345result.xhtml]
>  
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/test/java/ee/jakarta/tck/faces/test/servlet30/ajax/Issue4345IT.java#L47]
> This test was created for ensure HTML is only escaped twice ([Issue 
> 4345|https://github.com/eclipse-ee4j/mojarra/issues/4345). However, MyFaces 
> is encountering two problems with this test.
> Firstly, here is the Ajax response and the updated HTML: 
> {code:java}
> 
> 
>
>   
>  
>   
>   
>  
>   
>
>  {code}
> The HTML is then set as : 
> {code:java}
> http://www.w3.org/1999/xhtml;>
>
>   @import 
> url('/test-faces22-ajax/jakarta.faces.resource/issue4345.css.xhtml?firstParam=1&secondParam=2');
>
>
> 
>  {code}
> 1) We change from a link (type/css ) to a style tag that imports the URL? 
> Should that occur?  The JavaScript in issue4345result.xhtml specifically 
> looks for a link element. 
> 2) The script tags *are not appended* to the head element, but I do see 
> network requests for them. Additionally, the scripts do run (confirmed by the 
> console: "issue4345.js loaded." ). 
> This fails on both the RC2 scripts and the new TypeScript code. 
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (MYFACES-4498) TCK: Issue 4345 : Head Element Not Updated As Expected via Ajax Call

[Werner Punz (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17637704#comment-17637704
 ] 

Werner Punz commented on MYFACES-4498:
--

Taking over this now, should the fix also go into 2.3 Next?


> TCK: Issue 4345 : Head Element Not Updated As Expected via Ajax Call
> 
>
> Key: MYFACES-4498
> URL: https://issues.apache.org/jira/browse/MYFACES-4498
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 4.0.0-RC2
>Reporter: Volodymyr Siedlecki
>    Assignee: Werner Punz
>Priority: Major
> Attachments: test-faces22-ajax.war
>
>
> Test Code: 
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/test/java/ee/jakarta/tck/faces/test/servlet30/ajax/Issue4345IT.java#L47]
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/main/webapp/issue4345result.xhtml]
>  
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/test/java/ee/jakarta/tck/faces/test/servlet30/ajax/Issue4345IT.java#L47]
> This test was created for ensure HTML is only escaped twice ([Issue 
> 4345|https://github.com/eclipse-ee4j/mojarra/issues/4345). However, MyFaces 
> is encountering two problems with this test.
> Firstly, here is the Ajax response and the updated HTML: 
> {code:java}
> 
> 
>
>   
>  
>   
>   
>  
>   
>
>  {code}
> The HTML is then set as : 
> {code:java}
> http://www.w3.org/1999/xhtml;>
>
>   @import 
> url('/test-faces22-ajax/jakarta.faces.resource/issue4345.css.xhtml?firstParam=1&secondParam=2');
>
>
> 
>  {code}
> 1) We change from a link (type/css ) to a style tag that imports the URL? 
> Should that occur?  The JavaScript in issue4345result.xhtml specifically 
> looks for a link element. 
> 2) The script tags *are not appended* to the head element, but I do see 
> network requests for them. Additionally, the scripts do run (confirmed by the 
> console: "issue4345.js loaded." ). 
> This fails on both the RC2 scripts and the new TypeScript code. 
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (MYFACES-4499) TCK: Issue3020IT: testDelayNegative Fails

[Werner Punz (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17637703#comment-17637703
 ] 

Werner Punz commented on MYFACES-4499:
--

Fixed for 2.3 Next, Master and our new codebase!


> TCK: Issue3020IT: testDelayNegative Fails
> -
>
> Key: MYFACES-4499
> URL: https://issues.apache.org/jira/browse/MYFACES-4499
> Project: MyFaces Core
>  Issue Type: Bug
>Reporter: Volodymyr Siedlecki
>    Assignee: Werner Punz
>Priority: Major
> Fix For: 2.3-next-M8, 4.0.0-RC3
>
> Attachments: test-faces22-ajax.war
>
>
> App Code: 
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/main/webapp/issue3020Negative.xhtml#L35]
>  
> Unit Test: 
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/test/java/ee/jakarta/tck/faces/test/servlet30/ajax/Issue3020IT.java#L49-L54]
>  
> The test verifies that a delay on the f:ajax is a valid input.  The test uses 
> "NaN" and the implementation is expected to throw an exception to stop the 
> request from occurring. 
> Our RC2 code appears to be here: 
> [https://github.com/apache/myfaces/blob/89c747e85615e3f33265e664c8361789f38ea7db/api/src/main/javascript/META-INF/resources/myfaces/_impl/core/Impl.js#L311-L314]
> I've attached the TCK application (with Mojarra) to this issue.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (MYFACES-4499) TCK: Issue3020IT: testDelayNegative Fails

[Werner Punz (Jira)]

 [ 
https://issues.apache.org/jira/browse/MYFACES-4499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Werner Punz resolved MYFACES-4499.
--
Fix Version/s: 2.3-next-M8
   4.0.0-RC3
   Resolution: Fixed

> TCK: Issue3020IT: testDelayNegative Fails
> -
>
> Key: MYFACES-4499
> URL: https://issues.apache.org/jira/browse/MYFACES-4499
> Project: MyFaces Core
>  Issue Type: Bug
>Reporter: Volodymyr Siedlecki
>    Assignee: Werner Punz
>Priority: Major
> Fix For: 2.3-next-M8, 4.0.0-RC3
>
> Attachments: test-faces22-ajax.war
>
>
> App Code: 
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/main/webapp/issue3020Negative.xhtml#L35]
>  
> Unit Test: 
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/test/java/ee/jakarta/tck/faces/test/servlet30/ajax/Issue3020IT.java#L49-L54]
>  
> The test verifies that a delay on the f:ajax is a valid input.  The test uses 
> "NaN" and the implementation is expected to throw an exception to stop the 
> request from occurring. 
> Our RC2 code appears to be here: 
> [https://github.com/apache/myfaces/blob/89c747e85615e3f33265e664c8361789f38ea7db/api/src/main/javascript/META-INF/resources/myfaces/_impl/core/Impl.js#L311-L314]
> I've attached the TCK application (with Mojarra) to this issue.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (MYFACES-4499) TCK: Issue3020IT: testDelayNegative Fails

[Werner Punz (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17637661#comment-17637661
 ] 

Werner Punz commented on MYFACES-4499:
--

Started to work on it, issue is reproducible. Will fix it for the old and new 
codebase.


> TCK: Issue3020IT: testDelayNegative Fails
> -
>
> Key: MYFACES-4499
> URL: https://issues.apache.org/jira/browse/MYFACES-4499
> Project: MyFaces Core
>  Issue Type: Bug
>Reporter: Volodymyr Siedlecki
>    Assignee: Werner Punz
>Priority: Major
> Attachments: test-faces22-ajax.war
>
>
> App Code: 
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/main/webapp/issue3020Negative.xhtml#L35]
>  
> Unit Test: 
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/test/java/ee/jakarta/tck/faces/test/servlet30/ajax/Issue3020IT.java#L49-L54]
>  
> The test verifies that a delay on the f:ajax is a valid input.  The test uses 
> "NaN" and the implementation is expected to throw an exception to stop the 
> request from occurring. 
> Our RC2 code appears to be here: 
> [https://github.com/apache/myfaces/blob/89c747e85615e3f33265e664c8361789f38ea7db/api/src/main/javascript/META-INF/resources/myfaces/_impl/core/Impl.js#L311-L314]
> I've attached the TCK application (with Mojarra) to this issue.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (MYFACES-4498) TCK: Issue 4345 : Head Element Not Updated As Expected via Ajax Call

[Werner Punz (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17635675#comment-17635675
 ] 

Werner Punz commented on MYFACES-4498:
--

Yes.. I was too vague, I meant did you run the TCK against the new codebase, I 
just was wondering, because the TCK is using HTMLUnit and by my testing and 
knowledge it should not work against the new codebase.

And yes the new codebase has exactly the same behavior it removes the script 
elements after a short eval period.
Again a mild bug, more a deviation from what is expected.


> TCK: Issue 4345 : Head Element Not Updated As Expected via Ajax Call
> 
>
> Key: MYFACES-4498
> URL: https://issues.apache.org/jira/browse/MYFACES-4498
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 4.0.0-RC2
>Reporter: Volodymyr Siedlecki
>    Assignee: Werner Punz
>Priority: Major
> Attachments: test-faces22-ajax.war
>
>
> Test Code: 
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/test/java/ee/jakarta/tck/faces/test/servlet30/ajax/Issue4345IT.java#L47]
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/main/webapp/issue4345result.xhtml]
>  
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/test/java/ee/jakarta/tck/faces/test/servlet30/ajax/Issue4345IT.java#L47]
> This test was created for ensure HTML is only escaped twice ([Issue 
> 4345|https://github.com/eclipse-ee4j/mojarra/issues/4345). However, MyFaces 
> is encountering two problems with this test.
> Firstly, here is the Ajax response and the updated HTML: 
> {code:java}
> 
> 
>
>   
>  
>   
>   
>  
>   
>
>  {code}
> The HTML is then set as : 
> {code:java}
> http://www.w3.org/1999/xhtml;>
>
>   @import 
> url('/test-faces22-ajax/jakarta.faces.resource/issue4345.css.xhtml?firstParam=1&secondParam=2');
>
>
> 
>  {code}
> 1) We change from a link (type/css ) to a style tag that imports the URL? 
> Should that occur?  The JavaScript in issue4345result.xhtml specifically 
> looks for a link element. 
> 2) The script tags *are not appended* to the head element, but I do see 
> network requests for them. Additionally, the scripts do run (confirmed by the 
> console: "issue4345.js loaded." ). 
> This fails on both the RC2 scripts and the new TypeScript code. 
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (MYFACES-4498) TCK: Issue 4345 : Head Element Not Updated As Expected via Ajax Call

[Werner Punz (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17635675#comment-17635675
 ] 

Werner Punz edited comment on MYFACES-4498 at 11/18/22 6:17 AM:


Yes.. I was too vague, sorry for that, I meant did you run the TCK against the 
new codebase, I just was wondering, because the TCK is using HTMLUnit and by my 
testing and knowledge it should not work against the new codebase. I guess you 
just replicated the testcase into the new codebase and examined the dom, right?

And yes the new codebase has exactly the same behavior it removes the script 
elements after a short eval period.
Again a mild bug, more a deviation from what is expected.



was (Author: werpu):
Yes.. I was too vague, I meant did you run the TCK against the new codebase, I 
just was wondering, because the TCK is using HTMLUnit and by my testing and 
knowledge it should not work against the new codebase.

And yes the new codebase has exactly the same behavior it removes the script 
elements after a short eval period.
Again a mild bug, more a deviation from what is expected.


> TCK: Issue 4345 : Head Element Not Updated As Expected via Ajax Call
> 
>
> Key: MYFACES-4498
> URL: https://issues.apache.org/jira/browse/MYFACES-4498
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 4.0.0-RC2
>Reporter: Volodymyr Siedlecki
>    Assignee: Werner Punz
>Priority: Major
> Attachments: test-faces22-ajax.war
>
>
> Test Code: 
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/test/java/ee/jakarta/tck/faces/test/servlet30/ajax/Issue4345IT.java#L47]
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/main/webapp/issue4345result.xhtml]
>  
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/test/java/ee/jakarta/tck/faces/test/servlet30/ajax/Issue4345IT.java#L47]
> This test was created for ensure HTML is only escaped twice ([Issue 
> 4345|https://github.com/eclipse-ee4j/mojarra/issues/4345). However, MyFaces 
> is encountering two problems with this test.
> Firstly, here is the Ajax response and the updated HTML: 
> {code:java}
> 
> 
>
>   
>  
>   
>   
>  
>   
>
>  {code}
> The HTML is then set as : 
> {code:java}
> http://www.w3.org/1999/xhtml;>
>
>   @import 
> url('/test-faces22-ajax/jakarta.faces.resource/issue4345.css.xhtml?firstParam=1&secondParam=2');
>
>
> 
>  {code}
> 1) We change from a link (type/css ) to a style tag that imports the URL? 
> Should that occur?  The JavaScript in issue4345result.xhtml specifically 
> looks for a link element. 
> 2) The script tags *are not appended* to the head element, but I do see 
> network requests for them. Additionally, the scripts do run (confirmed by the 
> console: "issue4345.js loaded." ). 
> This fails on both the RC2 scripts and the new TypeScript code. 
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (MYFACES-4499) TCK: Issue3020IT: testDelayNegative Fails

[Werner Punz (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17635425#comment-17635425
 ] 

Werner Punz commented on MYFACES-4499:
--

I have to postpone both fixes until tomorrow, because I was busy with porting 
the TCK, my preference would be anyway, to get this fixed when I have the TCKs 
fully ported to Selenium (which should be sometime next week). Does anyone have 
objections, or can we wait with the fixes until then?
Then I can run a full TCK ajax test against the new codebase anyway (and 
against the old one)


> TCK: Issue3020IT: testDelayNegative Fails
> -
>
> Key: MYFACES-4499
> URL: https://issues.apache.org/jira/browse/MYFACES-4499
> Project: MyFaces Core
>  Issue Type: Bug
>Reporter: Volodymyr Siedlecki
>    Assignee: Werner Punz
>Priority: Major
> Attachments: test-faces22-ajax.war
>
>
> App Code: 
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/main/webapp/issue3020Negative.xhtml#L35]
>  
> Unit Test: 
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/test/java/ee/jakarta/tck/faces/test/servlet30/ajax/Issue3020IT.java#L49-L54]
>  
> The test verifies that a delay on the f:ajax is a valid input.  The test uses 
> "NaN" and the implementation is expected to throw an exception to stop the 
> request from occurring. 
> Our RC2 code appears to be here: 
> [https://github.com/apache/myfaces/blob/89c747e85615e3f33265e664c8361789f38ea7db/api/src/main/javascript/META-INF/resources/myfaces/_impl/core/Impl.js#L311-L314]
> I've attached the TCK application (with Mojarra) to this issue.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (MYFACES-4499) TCK: Issue3020IT: testDelayNegative Fails

[Werner Punz (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17635151#comment-17635151
 ] 

Werner Punz edited comment on MYFACES-4499 at 11/17/22 6:00 AM:


Yes this is a simple one, thanks for reporting, one of those corner cases I 
have missed in both implementations, will get a fix today together with the 
script tag removal issue. Expect a fix later today with a new RC of my 
reimplementation.


was (Author: werpu):
Yes this is a simple one, thanks for reporting, one of those corner cases I 
have missing in my reimplementation, will get a fix today together with the 
script tag removal issue. Expect a fix later today with a new RC of my 
reimplementation.

> TCK: Issue3020IT: testDelayNegative Fails
> -
>
> Key: MYFACES-4499
> URL: https://issues.apache.org/jira/browse/MYFACES-4499
> Project: MyFaces Core
>  Issue Type: Bug
>Reporter: Volodymyr Siedlecki
>    Assignee: Werner Punz
>Priority: Major
> Attachments: test-faces22-ajax.war
>
>
> App Code: 
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/main/webapp/issue3020Negative.xhtml#L35]
>  
> Unit Test: 
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/test/java/ee/jakarta/tck/faces/test/servlet30/ajax/Issue3020IT.java#L49-L54]
>  
> The test verifies that a delay on the f:ajax is a valid input.  The test uses 
> "NaN" and the implementation is expected to throw an exception to stop the 
> request from occurring. 
> Our RC2 code appears to be here: 
> [https://github.com/apache/myfaces/blob/89c747e85615e3f33265e664c8361789f38ea7db/api/src/main/javascript/META-INF/resources/myfaces/_impl/core/Impl.js#L311-L314]
> I've attached the TCK application (with Mojarra) to this issue.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (MYFACES-4499) TCK: Issue3020IT: testDelayNegative Fails

[Werner Punz (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17635151#comment-17635151
 ] 

Werner Punz commented on MYFACES-4499:
--

Yes this is a simple one, thanks for reporting, one of those corner cases I 
have missing in my reimplementation, will get a fix today together with the 
script tag removal issue. Expect a fix later today with a new RC of my 
reimplementation.

> TCK: Issue3020IT: testDelayNegative Fails
> -
>
> Key: MYFACES-4499
> URL: https://issues.apache.org/jira/browse/MYFACES-4499
> Project: MyFaces Core
>  Issue Type: Bug
>Reporter: Volodymyr Siedlecki
>Priority: Major
> Attachments: test-faces22-ajax.war
>
>
> App Code: 
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/main/webapp/issue3020Negative.xhtml#L35]
>  
> Unit Test: 
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/test/java/ee/jakarta/tck/faces/test/servlet30/ajax/Issue3020IT.java#L49-L54]
>  
> The test verifies that a delay on the f:ajax is a valid input.  The test uses 
> "NaN" and the implementation is expected to throw an exception to stop the 
> request from occurring. 
> Our RC2 code appears to be here: 
> [https://github.com/apache/myfaces/blob/89c747e85615e3f33265e664c8361789f38ea7db/api/src/main/javascript/META-INF/resources/myfaces/_impl/core/Impl.js#L311-L314]
> I've attached the TCK application (with Mojarra) to this issue.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (MYFACES-4498) TCK: Issue 4345 : Head Element Not Updated As Expected via Ajax Call

[Werner Punz (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17635150#comment-17635150
 ] 

Werner Punz edited comment on MYFACES-4498 at 11/17/22 5:57 AM:


Yes please assign it to me. The script tags in fact are appended but then 
removed, this is the standard way on how you evaluate them.
(call to eval are basically forbidden, an eval is done by swiftly appending a 
script tag and then remove it)
I probably have to remove the removal for the head update case.
So is it a bug, if yes a mild one, but definitely a deviation from the expected 
behavior which needs a fix.

Btw. did the TCK code work on the new codebase? Or did you just a check whether 
the new codebase exposes the same behavior.

It normally should not since the test uses HTMLUnit, it is in fact one of those 
cases I have ported already to Webdrivers! If the TCK ran, than I probably can 
stop my work on the porting process and have to check what they did with HTML 
unit that this test runs (and also I can pull my challenge on this one), I 
might have missed something.



was (Author: werpu):
Yes please assign it to me. The script tags in fact are appended but then 
removed, this is the standard way on how you evaluate them.
(call to eval are basically forbidden, an eval is done by swiftly appending a 
script tag and then remove it)
I probably have to remove the removal for the head update case.
Btw. did the TCK code work on the new codebase, or did you just a check whether 
the new codebase exposes the same behavior.

It normally should not since the test uses HTMLUnit, it is in fact one of those 
cases I have ported already to Webdrivers!


> TCK: Issue 4345 : Head Element Not Updated As Expected via Ajax Call
> 
>
> Key: MYFACES-4498
> URL: https://issues.apache.org/jira/browse/MYFACES-4498
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 4.0.0-RC2
>Reporter: Volodymyr Siedlecki
>    Assignee: Werner Punz
>Priority: Major
> Attachments: test-faces22-ajax.war
>
>
> Test Code: 
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/test/java/ee/jakarta/tck/faces/test/servlet30/ajax/Issue4345IT.java#L47]
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/main/webapp/issue4345result.xhtml]
>  
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/test/java/ee/jakarta/tck/faces/test/servlet30/ajax/Issue4345IT.java#L47]
> This test was created for ensure HTML is only escaped twice ([Issue 
> 4345|https://github.com/eclipse-ee4j/mojarra/issues/4345). However, MyFaces 
> is encountering two problems with this test.
> Firstly, here is the Ajax response and the updated HTML: 
> {code:java}
> 
> 
>
>   
>  
>   
>   
>  
>   
>
>  {code}
> The HTML is then set as : 
> {code:java}
> http://www.w3.org/1999/xhtml;>
>
>   @import 
> url('/test-faces22-ajax/jakarta.faces.resource/issue4345.css.xhtml?firstParam=1&secondParam=2');
>
>
> 
>  {code}
> 1) We change from a link (type/css ) to a style tag that imports the URL? 
> Should that occur?  The JavaScript in issue4345result.xhtml specifically 
> looks for a link element. 
> 2) The script tags *are not appended* to the head element, but I do see 
> network requests for them. Additionally, the scripts do run (confirmed by the 
> console: "issue4345.js loaded." ). 
> This fails on both the RC2 scripts and the new TypeScript code. 
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (MYFACES-4498) TCK: Issue 4345 : Head Element Not Updated As Expected via Ajax Call

[Werner Punz (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17635150#comment-17635150
 ] 

Werner Punz edited comment on MYFACES-4498 at 11/17/22 5:56 AM:


Yes please assign it to me. The script tags in fact are appended but then 
removed, this is the standard way on how you evaluate them.
(call to eval are basically forbidden, an eval is done by swiftly appending a 
script tag and then remove it)
I probably have to remove the removal for the head update case.
Btw. did the TCK code work on the new codebase, or did you just a check whether 
the new codebase exposes the same behavior.

It normally should not since the test uses HTMLUnit, it is in fact one of those 
cases I have ported already to Webdrivers!



was (Author: werpu):
Yes please assign it to me. The script tags in fact are appended but then 
removed, this is the standard way on how you evaluate them.
(call to eval are basically forbidden, an eval is done by swiftly appending a 
script tag and then remove it)
I probably have to remove the removal for the head update case.


> TCK: Issue 4345 : Head Element Not Updated As Expected via Ajax Call
> 
>
> Key: MYFACES-4498
> URL: https://issues.apache.org/jira/browse/MYFACES-4498
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 4.0.0-RC2
>Reporter: Volodymyr Siedlecki
>Priority: Major
> Attachments: test-faces22-ajax.war
>
>
> Test Code: 
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/test/java/ee/jakarta/tck/faces/test/servlet30/ajax/Issue4345IT.java#L47]
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/main/webapp/issue4345result.xhtml]
>  
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/test/java/ee/jakarta/tck/faces/test/servlet30/ajax/Issue4345IT.java#L47]
> This test was created for ensure HTML is only escaped twice ([Issue 
> 4345|https://github.com/eclipse-ee4j/mojarra/issues/4345). However, MyFaces 
> is encountering two problems with this test.
> Firstly, here is the Ajax response and the updated HTML: 
> {code:java}
> 
> 
>
>   
>  
>   
>   
>  
>   
>
>  {code}
> The HTML is then set as : 
> {code:java}
> http://www.w3.org/1999/xhtml;>
>
>   @import 
> url('/test-faces22-ajax/jakarta.faces.resource/issue4345.css.xhtml?firstParam=1&secondParam=2');
>
>
> 
>  {code}
> 1) We change from a link (type/css ) to a style tag that imports the URL? 
> Should that occur?  The JavaScript in issue4345result.xhtml specifically 
> looks for a link element. 
> 2) The script tags *are not appended* to the head element, but I do see 
> network requests for them. Additionally, the scripts do run (confirmed by the 
> console: "issue4345.js loaded." ). 
> This fails on both the RC2 scripts and the new TypeScript code. 
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (MYFACES-4498) TCK: Issue 4345 : Head Element Not Updated As Expected via Ajax Call

[Werner Punz (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17635150#comment-17635150
 ] 

Werner Punz commented on MYFACES-4498:
--

Yes please assign it to me. The script tags in fact are appended but then 
removed, this is the standard way on how you evaluate them.
(call to eval are basically forbidden, an eval is done by swiftly appending a 
script tag and then remove it)
I probably have to remove the removal for the head update case.


> TCK: Issue 4345 : Head Element Not Updated As Expected via Ajax Call
> 
>
> Key: MYFACES-4498
> URL: https://issues.apache.org/jira/browse/MYFACES-4498
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 4.0.0-RC2
>Reporter: Volodymyr Siedlecki
>Priority: Major
> Attachments: test-faces22-ajax.war
>
>
> Test Code: 
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/test/java/ee/jakarta/tck/faces/test/servlet30/ajax/Issue4345IT.java#L47]
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/main/webapp/issue4345result.xhtml]
>  
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/test/java/ee/jakarta/tck/faces/test/servlet30/ajax/Issue4345IT.java#L47]
> This test was created for ensure HTML is only escaped twice ([Issue 
> 4345|https://github.com/eclipse-ee4j/mojarra/issues/4345). However, MyFaces 
> is encountering two problems with this test.
> Firstly, here is the Ajax response and the updated HTML: 
> {code:java}
> 
> 
>
>   
>  
>   
>   
>  
>   
>
>  {code}
> The HTML is then set as : 
> {code:java}
> http://www.w3.org/1999/xhtml;>
>
>   @import 
> url('/test-faces22-ajax/jakarta.faces.resource/issue4345.css.xhtml?firstParam=1&secondParam=2');
>
>
> 
>  {code}
> 1) We change from a link (type/css ) to a style tag that imports the URL? 
> Should that occur?  The JavaScript in issue4345result.xhtml specifically 
> looks for a link element. 
> 2) The script tags *are not appended* to the head element, but I do see 
> network requests for them. Additionally, the scripts do run (confirmed by the 
> console: "issue4345.js loaded." ). 
> This fails on both the RC2 scripts and the new TypeScript code. 
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: tck legal question

[Werner Punz]

Great, I just gave an answer and will start porting the Ajax tcks tomorrow.

Thanks for the clarification

Werner


Am Di., 15. Nov. 2022 um 17:35 Uhr schrieb Melloware :

> Yep just submit a PR on the Faces github and let them respond.
>
> BalusC and Arjim Tims are involved now and its open and run by Eclipse
> foundation so a lot has changed.
>
>
> On 11/15/2022 5:36 AM, Werner Punz wrote:
> > Hi, there is a legal question I am not sure about.
> >
> > Back in the day, when Oracle was at the helm we had a strict policy
> > of not touching the mojarra code in any way whatsoever, the TCK back
> > then was closed source anyway and in the beginning so was mojarra.
> >
> > Now that I have to challenge the TCK for reasons that they are stuck
> > on html unit and hence are stuck on ES5 on javascript level
> > I would like to provide a pull request so that I can attach that one
> > with the TCK challenge.
> >
> > Is this still an issue, or is it now possible to touch the other
> > implementation one way or the other given the changes are clearly
> > coming from our side as long as the code is strictly not shared except
> > for being under ASL2 license.
> >
> > Can anyone shed some insight on this.
> > To challenge the Faces TCK and write a pull request, I have to clone
> > the RI into my own github workspace (which hosts the TCK). I only can
> > do that if it is safe from a legal point of view.
> >
> >
> >
> >
> >
> >
>

tck legal question

[Werner Punz]

Hi, there is a legal question I am not sure about.

Back in the day, when Oracle was at the helm we had a strict policy
of not touching the mojarra code in any way whatsoever, the TCK back then
was closed source anyway and in the beginning so was mojarra.

Now that I have to challenge the TCK for reasons that they are stuck on
html unit and hence are stuck on ES5 on javascript level
I would like to provide a pull request so that I can attach that one with
the TCK challenge.

Is this still an issue, or is it now possible to touch the other
implementation one way or the other given the changes are clearly coming
from our side as long as the code is strictly not shared except for being
under ASL2 license.

Can anyone shed some insight on this.
To challenge the Faces TCK and write a pull request, I have to clone the RI
into my own github workspace (which hosts the TCK). I only can do that if
it is safe from a legal point of view.

[jira] [Comment Edited] (MYFACES-4481) HTML event handlers don't work without 'unsafe-inline'

[Werner Punz (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17634224#comment-17634224
 ] 

Werner Punz edited comment on MYFACES-4481 at 11/15/22 9:38 AM:


Yes, unfortunately what [~melloware] wrote is absolutely correct.

With higher CSP  security levels, you will get those errors, because inline 
events are then banned due to XSS concerns.

With standard JSF, because the scripts are not externalized, you will get 
errors. The fix is exactly like [~melloware] posted.

Unfortunately as of now, standard jsf does not do it that way and this might 
have to be challenged in a future spec (or maybe an implementation fix, I am 
probably the wrong person to be asked about this). 

So what is the workaround.
 * You can use a library which does it
 * You can use a combination of direct ajax calls jsf.ajax.request, data 
attributes or class markers and querySelectorall and/or h:link. Note, *f:ajax* 
is out then, so is direct navigation via h:commandLink which also uses inline 
event handlers for triggering
 * Or you can lower the nonce based security to unsafe-inline and make sure 
that you fortify on other levels
 * Or you can move the rendered inline event handlers to CSP fortified inline 
scripts and override the original ones

 

here is the idea:


{code:html}


{code}


would become

{code:html}






   let commandLink = document.querySelector("#doSubmit");
   commandLink.onclick = (evt) => myfaces.oam.submitForm('form1','doSubmit');;


{code}

So bascially what happens. The inline script throws the error at the time we 
click on the element.  So in the first case

the page is rendered just fine. But as soon as the user clicks onclick, the CSP 
error is thrown. 

In the second case we just pushed whatever was rendered (a submitForm call) 
into a CSP fortified inline script

and have overridden the onclick handler thus erasing the originally unsafe 
rendered one. Now if we press the submit

works just as expected.

 Unfortunately you cannot automate this over javascript because you are not 
allowed to read in the unsecured onclick attribute on js level in the CSP 
fortified inline script part.
So theoretically a you can fix this in an automated manner on renderer level, 
but not on javascript level. Otherwise you do it by hand on a case by case base.



was (Author: werpu):
Yes, unfortunately what [~melloware] wrote is absolutely correct.

With higher CSP  security levels, you will get those errors, because inline 
events are then banned due to XSS concerns.

With standard JSF, because the scripts are not externalized, you will get 
errors. The fix is exactly like [~melloware] posted.

Unfortunately as of now, standard jsf does not do it that way and this might 
have to be challenged in a future spec (or maybe an implementation fix, I am 
probably the wrong person to be asked about this). 

So what is the workaround.
 * You can use a library which does it
 * You can use a combination of direct ajax calls jsf.ajax.request, data 
attributes or class markers and querySelectorall and/or h:link. Note, *f:ajax* 
is out then, so is direct navigation via h:commandLink which also uses inline 
event handlers for triggering
 * Or you can lower the nonce based security to unsafe-inline and make sure 
that you fortify on other levels
 * Or you can move the rendered inline event handlers to CSP fortified inline 
scripts and override the original ones

 

here is the idea:


{code:html}


{code}


would become

{code:html}






   let commandLink = document.querySelector("#doSubmit");
   commandLink.onclick = (evt) => myfaces.oam.submitForm('form1','doSubmit');;


{code}

So bascially what happens. The inline script throws the error at the time we 
click on the element.  So in the first case

the page is rendered just fine. But as soon as the user clicks onclick, the CSP 
error is thrown.

In the second case we just pushed whatever was rendered (a submitForm call) 
into a CSP fortified inline script

and have overridden the onclick handlerd thus erasing the originally unsafe 
rendered one. Now if we press the submit

works just as expected.

 

> HTML event handlers don't work without 'unsafe-inline'
> --
>
> Key: MYFACES-4481
> URL: https://issues.apache.org/jira/browse/MYFACES-4481
> Project: MyFaces Core
>  Issue Type: Bug
>  Components: General
>Affects Versions: 2.3-next-M7
> Environment: Chrome: 106.0.5249.103
>Reporter: Vitaly Sidorov
>Priority: Major
>
> HTML event handlers don't work without 'unsafe-inline' in 
> 'Content-Security-Policy' header.
> Steps to reproduce:
>  - use jsf-2.3-next with fixed bug MYFACES-4479
>  - set header Content-Secur

[jira] [Comment Edited] (MYFACES-4481) HTML event handlers don't work without 'unsafe-inline'

[Werner Punz (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17634224#comment-17634224
 ] 

Werner Punz edited comment on MYFACES-4481 at 11/15/22 8:21 AM:


Yes, unfortunately what [~melloware] wrote is absolutely correct.

With higher CSP  security levels, you will get those errors, because inline 
events are then banned due to XSS concerns.

With standard JSF, because the scripts are not externalized, you will get 
errors. The fix is exactly like [~melloware] posted.

Unfortunately as of now, standard jsf does not do it that way and this might 
have to be challenged in a future spec (or maybe an implementation fix, I am 
probably the wrong person to be asked about this). 

So what is the workaround.
 * You can use a library which does it
 * You can use a combination of direct ajax calls jsf.ajax.request, data 
attributes or class markers and querySelectorall and/or h:link. Note, *f:ajax* 
is out then, so is direct navigation via h:commandLink which also uses inline 
event handlers for triggering
 * Or you can lower the nonce based security to unsafe-inline and make sure 
that you fortify on other levels
 * Or you can move the rendered inline event handlers to CSP fortified inline 
scripts and override the original ones

 

here is the idea:


{code:html}


{code}


would become

{code:html}






   let commandLink = document.querySelector("#doSubmit");
   commandLink.onclick = (evt) => myfaces.oam.submitForm('form1','doSubmit');;


{code}

So bascially what happens. The inline script throws the error at the time we 
click on the element.  So in the first case

the page is rendered just fine. But as soon as the user clicks onclick, the CSP 
error is thrown.

In the second case we just pushed whatever was rendered (a submitForm call) 
into a CSP fortified inline script

and have overridden the onclick handlerd thus erasing the originally unsafe 
rendered one. Now if we press the submit

works just as expected.

 


was (Author: werpu):
Yes, unfortunately what [~melloware] wrote is absolutely correct.

With higher CSP  security levels, you will get those errors, because inline 
events are then banned due to XSS concerns.

With standard JSF, because the scripts are not externalized, you will get 
errors. The fix is exactly like [~melloware] posted.

Unfortunately as of now, standard jsf does not do it that way and this might 
have to be challenged in a future spec (or maybe an implementation fix, I am 
probably the wrong person to be asked about this). 

So what is the workaround.
 * You can use a library which does it
 * You can use a combination of direct ajax calls jsf.ajax.request, data 
attributes or class markers and querySelectorall and/or h:link. Note, *f:ajax* 
is out then, so is direct navigation via h:commandLink which also uses inline 
event handlers for triggering
 * Or you can lower the nonce based security to unsafe-inline and make sure 
that you fortify on other levels
 * Or you can move the rendered inline event handlers to CSP fortified inline 
scripts and override the original ones

 

here is the idea:


{code:html}


{code}


would become

{code:html}






   let commandLink = document.querySelector("#doSubmit");
   commandLink.onclick = (evt) => myfaces.oam.submitForm('form1','doSubmit');;


{code}

So bascially what happens. The inline script throws the error at the time we 
click on the element.  So in the first case

the page is rendered just fine. But as soon as the user clicks onclick, the CSP 
error is thrown.

In the second case we just pushed whatever was rendered (a submitForm call) 
into a CSP fortified inline script

and have overridden the onclick handlerd thus erasing the originally unsafe 
rendered one. Now if we press the submit

works just as expected.

 

> HTML event handlers don't work without 'unsafe-inline'
> --
>
> Key: MYFACES-4481
> URL: https://issues.apache.org/jira/browse/MYFACES-4481
> Project: MyFaces Core
>  Issue Type: Bug
>  Components: General
>Affects Versions: 2.3-next-M7
> Environment: Chrome: 106.0.5249.103
>Reporter: Vitaly Sidorov
>Priority: Major
>
> HTML event handlers don't work without 'unsafe-inline' in 
> 'Content-Security-Policy' header.
> Steps to reproduce:
>  - use jsf-2.3-next with fixed bug MYFACES-4479
>  - set header Content-Security-Policy: script-src 'self' 'nonce-test123'
>  - set  target="head"/>
>  - add h:commandLink inside h:form
>  - set parameters 
> org.apache.myfaces.USE_MULTIPLE_JS_FILES_FOR_JSF_UNCOMPRESSED_JS=false and 
> javax.faces.PROJECT_STAGE=Developement
>  - open page in browser and click to link
>  - get error in

[jira] [Comment Edited] (MYFACES-4481) HTML event handlers don't work without 'unsafe-inline'

[Werner Punz (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17634224#comment-17634224
 ] 

Werner Punz edited comment on MYFACES-4481 at 11/15/22 8:20 AM:


Yes, unfortunately what [~melloware] wrote is absolutely correct.

With higher CSP  security levels, you will get those errors, because inline 
events are then banned due to XSS concerns.

With standard JSF, because the scripts are not externalized, you will get 
errors. The fix is exactly like [~melloware] posted.

Unfortunately as of now, standard jsf does not do it that way and this might 
have to be challenged in a future spec (or maybe an implementation fix, I am 
probably the wrong person to be asked about this). 

So what is the workaround.
 * You can use a library which does it
 * You can use a combination of direct ajax calls jsf.ajax.request, data 
attributes or class markers and querySelectorall and/or h:link. Note, *f:ajax* 
is out then, so is direct navigation via h:commandLink which also uses inline 
event handlers for triggering
 * Or you can lower the nonce based security to unsafe-inline and make sure 
that you fortify on other levels
 * Or you can move the rendered inline event handlers to CSP fortified inline 
scripts and override the original ones

 

here is the idea:


{code:html}


{code}


would become

{code:html}






   let commandLink = document.querySelector("#doSubmit");
   commandLink.onclick = (evt) => myfaces.oam.submitForm('form1','doSubmit');;


{code}

So bascially what happens. The inline script throws the error at the time we 
click on the element.  So in the first case

the page is rendered just fine. But as soon as the user clicks onclick, the CSP 
error is thrown.

In the second case we just pushed whatever was rendered (a submitForm call) 
into a CSP fortified inline script

and have overridden the onclick handlerd thus erasing the originally unsafe 
rendered one. Now if we press the submit

works just as expected.

 


was (Author: werpu):
Yes, unfortunately what [~melloware] wrote is absolutely correct.

With higher CSP  security levels, you will get those errors, because inline 
events are then banned due to XSS concerns.

With standard JSF, because the scripts are not externalized, you will get 
errors. The fix is exactly like [~melloware] posted.

Unfortunately as of now, standard jsf does not do it that way and this might 
have to be challenged in a future spec (or maybe an implementation fix, I am 
probably the wrong person to be asked about this). 

So what is the workaround.
 * You can use a library which does it
 * You can use a combination of direct ajax calls jsf.ajax.request, data 
attributes or class markers and querySelectorall and/or h:link. Note, *f:ajax* 
is out then, so is direct navigation via h:commandLink which also uses inline 
event handlers for triggering
 * Or you can lower the nonce based security to unsafe-inline and make sure 
that you fortify on other levels
 * Or you can move the rendered inline event handlers to CSP fortified inline 
scripts and override the original ones

 

here is the idea:


{code:html}


{code}


would become

{code:html}






   let commandLink = document.querySelector("#doSubmit");
   commandLink.onclick = (evt) => myfaces.oam.submitForm('form1','doSubmit');;


{code}

So bascially what happens. The inline script throws the error at the time we 
click on the element.  So in the first case

the page is rendered just fine. But as soon as the user clicks onclick, the CSP 
error is thrown.

In the second case we just pushed whatever was rendered (a submitForm call) 
into a CSP fortified inline script

and have overridden the onclick handlerd thus erasing the originally unsafe 
rendered one. Now if we press the submit

works just as expected.

 

> HTML event handlers don't work without 'unsafe-inline'
> --
>
> Key: MYFACES-4481
> URL: https://issues.apache.org/jira/browse/MYFACES-4481
> Project: MyFaces Core
>  Issue Type: Bug
>  Components: General
>Affects Versions: 2.3-next-M7
> Environment: Chrome: 106.0.5249.103
>Reporter: Vitaly Sidorov
>Priority: Major
>
> HTML event handlers don't work without 'unsafe-inline' in 
> 'Content-Security-Policy' header.
> Steps to reproduce:
>  - use jsf-2.3-next with fixed bug MYFACES-4479
>  - set header Content-Security-Policy: script-src 'self' 'nonce-test123'
>  - set  target="head"/>
>  - add h:commandLink inside h:form
>  - set parameters 
> org.apache.myfaces.USE_MULTIPLE_JS_FILES_FOR_JSF_UNCOMPRESSED_JS=false and 
> javax.faces.PROJECT_STAGE=Developement
>  - open page in browser and click to link
>  - get error in

[jira] [Comment Edited] (MYFACES-4481) HTML event handlers don't work without 'unsafe-inline'

[Werner Punz (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17634224#comment-17634224
 ] 

Werner Punz edited comment on MYFACES-4481 at 11/15/22 8:19 AM:


Yes, unfortunately what [~melloware] wrote is absolutely correct.

With higher CSP  security levels, you will get those errors, because inline 
events are then banned due to XSS concerns.

With standard JSF, because the scripts are not externalized, you will get 
errors. The fix is exactly like [~melloware] posted.

Unfortunately as of now, standard jsf does not do it that way and this might 
have to be challenged in a future spec (or maybe an implementation fix, I am 
probably the wrong person to be asked about this). 

So what is the workaround.
 * You can use a library which does it
 * You can use a combination of direct ajax calls jsf.ajax.request, data 
attributes or class markers and querySelectorall and/or h:link. Note, *f:ajax* 
is out then, so is direct navigation via h:commandLink which also uses inline 
event handlers for triggering
 * Or you can lower the nonce based security to unsafe-inline and make sure 
that you fortify on other levels
 * Or you can move the rendered inline event handlers to CSP fortified inline 
scripts and override the original ones

 

here is the idea:


{code:html}


{code}


would become

{code:html}






   let commandLink = document.querySelector("#doSubmit");
   commandLink.onclick = (evt) => myfaces.oam.submitForm('form1','doSubmit');;


{code}

So bascially what happens. The inline script throws the error at the time we 
click on the element.  So in the first case

the page is rendered just fine. But as soon as the user clicks onclick, the CSP 
error is thrown.

In the second case we just pushed whatever was rendered (a submitForm call) 
into a CSP fortified inline script

and have overridden the onclick handlerd thus erasing the originally unsafe 
rendered one. Now if we press the submit

works just as expected.

 


was (Author: werpu):
Yes, unfortunately what [~melloware] wrote is absolutely correct.

With higher CSP  security levels, you will get those errors, because inline 
events are then banned due to XSS concerns.

With standard JSF, because the scripts are not externalized, you will get 
errors. The fix is exactly like [~melloware] posted.

Unfortunately as of now, standard jsf does not do it that way and this might 
have to be challenged in a future spec (or maybe an implementation fix, I am 
probably the wrong person to be asked about this). 

So what is the workaround.
 * You can use a library which does it
 * You can use a combination of direct ajax calls jsf.ajax.request, data 
attributes or class markers and querySelectorall and/or h:link. Note, *f:ajax* 
is out then, so is direct navigation via h:commandLink which also uses inline 
event handlers for triggering
 * Or you can lower the nonce based security to unsafe-inline and make sure 
that you fortify on other levels
 * Or you can move the rendered inline event handlers to CSP fortified inline 
scripts and override the original ones

 

here is the idea:

```html




```

would become

```html






   let commandLink = document.querySelector("#doSubmit");
   commandLink.onclick = (evt) => myfaces.oam.submitForm('form1','doSubmit');;


```

So bascially what happens. The inline script throws the error at the time we 
click on the element.  So in the first case

the page is rendered just fine. But as soon as the user clicks onclick, the CSP 
error is thrown.

In the second case we just pushed whatever was rendered (a submitForm call) 
into a CSP fortified inline script

and have overridden the onclick handlerd thus erasing the originally unsafe 
rendered one. Now if we press the submit

works just as expected.

 

> HTML event handlers don't work without 'unsafe-inline'
> --
>
> Key: MYFACES-4481
> URL: https://issues.apache.org/jira/browse/MYFACES-4481
> Project: MyFaces Core
>  Issue Type: Bug
>  Components: General
>Affects Versions: 2.3-next-M7
> Environment: Chrome: 106.0.5249.103
>Reporter: Vitaly Sidorov
>Priority: Major
>
> HTML event handlers don't work without 'unsafe-inline' in 
> 'Content-Security-Policy' header.
> Steps to reproduce:
>  - use jsf-2.3-next with fixed bug MYFACES-4479
>  - set header Content-Security-Policy: script-src 'self' 'nonce-test123'
>  - set  target="head"/>
>  - add h:commandLink inside h:form
>  - set parameters 
> org.apache.myfaces.USE_MULTIPLE_JS_FILES_FOR_JSF_UNCOMPRESSED_JS=false and 
> javax.faces.PROJECT_STAGE=Developement
>  - open page in browser and click to link
>  - get error in console:
> {{Refuse

[jira] [Commented] (MYFACES-4481) HTML event handlers don't work without 'unsafe-inline'

[Werner Punz (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17634224#comment-17634224
 ] 

Werner Punz commented on MYFACES-4481:
--

Yes, unfortunately what [~melloware] wrote is absolutely correct.

With higher CSP  security levels, you will get those errors, because inline 
events are then banned due to XSS concerns.

With standard JSF, because the scripts are not externalized, you will get 
errors. The fix is exactly like [~melloware] posted.

Unfortunately as of now, standard jsf does not do it that way and this might 
have to be challenged in a future spec (or maybe an implementation fix, I am 
probably the wrong person to be asked about this). 

So what is the workaround.
 * You can use a library which does it
 * You can use a combination of direct ajax calls jsf.ajax.request, data 
attributes or class markers and querySelectorall and/or h:link. Note, *f:ajax* 
is out then, so is direct navigation via h:commandLink which also uses inline 
event handlers for triggering
 * Or you can lower the nonce based security to unsafe-inline and make sure 
that you fortify on other levels
 * Or you can move the rendered inline event handlers to CSP fortified inline 
scripts and override the original ones

 

here is the idea:

```html




```

would become

```html






   let commandLink = document.querySelector("#doSubmit");
   commandLink.onclick = (evt) => myfaces.oam.submitForm('form1','doSubmit');;


```

So bascially what happens. The inline script throws the error at the time we 
click on the element.  So in the first case

the page is rendered just fine. But as soon as the user clicks onclick, the CSP 
error is thrown.

In the second case we just pushed whatever was rendered (a submitForm call) 
into a CSP fortified inline script

and have overridden the onclick handlerd thus erasing the originally unsafe 
rendered one. Now if we press the submit

works just as expected.

 

> HTML event handlers don't work without 'unsafe-inline'
> --
>
> Key: MYFACES-4481
> URL: https://issues.apache.org/jira/browse/MYFACES-4481
> Project: MyFaces Core
>  Issue Type: Bug
>  Components: General
>Affects Versions: 2.3-next-M7
> Environment: Chrome: 106.0.5249.103
>Reporter: Vitaly Sidorov
>Priority: Major
>
> HTML event handlers don't work without 'unsafe-inline' in 
> 'Content-Security-Policy' header.
> Steps to reproduce:
>  - use jsf-2.3-next with fixed bug MYFACES-4479
>  - set header Content-Security-Policy: script-src 'self' 'nonce-test123'
>  - set  target="head"/>
>  - add h:commandLink inside h:form
>  - set parameters 
> org.apache.myfaces.USE_MULTIPLE_JS_FILES_FOR_JSF_UNCOMPRESSED_JS=false and 
> javax.faces.PROJECT_STAGE=Developement
>  - open page in browser and click to link
>  - get error in console:
> {{Refused to execute inline event handler because it violates the following 
> Content Security Policy directive: "script-src 'self' 'nonce-test123'". 
> Either the 'unsafe-inline' keyword, a hash ('sha256-...'), or a nonce 
> ('nonce-...') is required to enable inline execution. Note that hashes do not 
> apply to event handlers, style attributes and javascript: navigations unless 
> the 'unsafe-hashes' keyword is present.}}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (MYFACES-4496) Server side Websocket/Push Implementation not working

[Werner Punz (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17631148#comment-17631148
 ] 

Werner Punz commented on MYFACES-4496:
--

Error was on my side, I was using the javax namespace accidentally instead of 
the jakarta namespace for the context param change.

 

> Server side Websocket/Push Implementation not working 
> --
>
> Key: MYFACES-4496
> URL: https://issues.apache.org/jira/browse/MYFACES-4496
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 4.0.0-RC2
>    Reporter: Werner Punz
>Priority: Blocker
>
> While fixing several reported bugs in the new faces.js code I ran against a 
> non working push implementation on the 4.0.0-RC2 codebase.
> Problem was a simple new WebSocket() could not 
> establish a working connection.
> The problem is definitely somewhere in the server, either not registering the 
> Websocket endpoint or delivering the wrong connection token.
> A example implemented via the Websocket servlet api and plain html works in 
> the same configuration, se we can rule out the server environment (Embedded 
> Tomcat 10). You can use straight the code from master to replicate this 
> problem (I have decorated the faces.js api accordingly just to try a 
> connection on the jsf side instead of going into the code)
>  
> An example can be found at: [https://github.com/werpu/websocketproblem]
> Run instructions are included in the integrated readme, it uses an embedded 
> tomcat/openwebbeans/myfaces 4.0.0 stack so a simple
> mvn clean clean install -DskipTests exec:java -Pstandalone -f pom.xml starts 
> the server and installs all libraries, the rest is documented in the github 
> repo readme.
>  
>  
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (MYFACES-4496) Server side Websocket/Push Implementation not working

[Werner Punz (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17631069#comment-17631069
 ] 

Werner Punz edited comment on MYFACES-4496 at 11/9/22 1:18 PM:
---

Apparently the entire push api now is getting a refactoring: 
[https://github.com/apache/myfaces/pull/327]

I will retest the issue once the pull request is merged.

 


was (Author: werpu):
Apparently the entire push api now gets a refactoring: 
[https://github.com/apache/myfaces/pull/327]

I will retest the issue once the pull request is merged.

 

> Server side Websocket/Push Implementation not working 
> --
>
> Key: MYFACES-4496
> URL: https://issues.apache.org/jira/browse/MYFACES-4496
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 4.0.0-RC2
>    Reporter: Werner Punz
>Priority: Blocker
>
> While fixing several reported bugs in the new faces.js code I ran against a 
> non working push implementation on the 4.0.0-RC2 codebase.
> Problem was a simple new WebSocket() could not 
> establish a working connection.
> The problem is definitely somewhere in the server, either not registering the 
> Websocket endpoint or delivering the wrong connection token.
> A example implemented via the Websocket servlet api and plain html works in 
> the same configuration, se we can rule out the server environment (Embedded 
> Tomcat 10). You can use straight the code from master to replicate this 
> problem (I have decorated the faces.js api accordingly just to try a 
> connection on the jsf side instead of going into the code)
>  
> An example can be found at: [https://github.com/werpu/websocketproblem]
> Run instructions are included in the integrated readme, it uses an embedded 
> tomcat/openwebbeans/myfaces 4.0.0 stack so a simple
> mvn clean clean install -DskipTests exec:java -Pstandalone -f pom.xml starts 
> the server and installs all libraries, the rest is documented in the github 
> repo readme.
>  
>  
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (MYFACES-4496) Server side Websocket/Push Implementation not working

[Werner Punz (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17631069#comment-17631069
 ] 

Werner Punz commented on MYFACES-4496:
--

Apparently the entire push api now gets a refactoring: 
[https://github.com/apache/myfaces/pull/327]

I will retest the issue once the pull request is merged.

 

> Server side Websocket/Push Implementation not working 
> --
>
> Key: MYFACES-4496
> URL: https://issues.apache.org/jira/browse/MYFACES-4496
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 4.0.0-RC2
>    Reporter: Werner Punz
>Priority: Blocker
>
> While fixing several reported bugs in the new faces.js code I ran against a 
> non working push implementation on the 4.0.0-RC2 codebase.
> Problem was a simple new WebSocket() could not 
> establish a working connection.
> The problem is definitely somewhere in the server, either not registering the 
> Websocket endpoint or delivering the wrong connection token.
> A example implemented via the Websocket servlet api and plain html works in 
> the same configuration, se we can rule out the server environment (Embedded 
> Tomcat 10). You can use straight the code from master to replicate this 
> problem (I have decorated the faces.js api accordingly just to try a 
> connection on the jsf side instead of going into the code)
>  
> An example can be found at: [https://github.com/werpu/websocketproblem]
> Run instructions are included in the integrated readme, it uses an embedded 
> tomcat/openwebbeans/myfaces 4.0.0 stack so a simple
> mvn clean clean install -DskipTests exec:java -Pstandalone -f pom.xml starts 
> the server and installs all libraries, the rest is documented in the github 
> repo readme.
>  
>  
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (MYFACES-4496) Server side Websocket/Push Implementation not working

[Werner Punz (Jira)]

Werner Punz created MYFACES-4496:


 Summary: Server side Websocket/Push Implementation not working 
 Key: MYFACES-4496
 URL: https://issues.apache.org/jira/browse/MYFACES-4496
 Project: MyFaces Core
  Issue Type: Bug
Affects Versions: 4.0.0-RC2
Reporter: Werner Punz


While fixing several reported bugs in the new faces.js code I ran against a non 
working push implementation on the 4.0.0-RC2 codebase.

Problem was a simple new WebSocket() could not 
establish a working connection.

The problem is definitely somewhere in the server, either not registering the 
Websocket endpoint or delivering the wrong connection token.

A example implemented via the Websocket servlet api and plain html works in the 
same configuration, se we can rule out the server environment (Embedded Tomcat 
10). You can use straight the code from master to replicate this problem (I 
have decorated the faces.js api accordingly just to try a connection on the jsf 
side instead of going into the code)

 

An example can be found at: [https://github.com/werpu/websocketproblem]

Run instructions are included in the integrated readme, it uses an embedded 
tomcat/openwebbeans/myfaces 4.0.0 stack so a simple

mvn clean clean install -DskipTests exec:java -Pstandalone -f pom.xml starts 
the server and installs all libraries, the rest is documented in the github 
repo readme.

 

 

 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [VOTE] Release Tobago 4.6.0

[Werner Punz]

+1

Werner


Am Fr., 4. Nov. 2022 um 09:01 Uhr schrieb Henning Nöth <
henning.no...@irian.eu>:

> +1
>
> Am 03.11.22 um 16:17 schrieb Udo Schnurpfeil:
> > Hello,
> >
> > we would like to release:
> > * Tobago 4.6.0
> >
> > The artifacts were deployed on nexus repository for binary and source
> > packages:
> > * Tobago 4.6.0 [1]
> >
> > The release notes are in Jira:
> > * Tobago 4.6.0 [2]
> >
> > The artifacts are available at the staging repository (Nexus) at:
> >
> > * Tobago 4.6.0 [3] (sha-256
> > 81a4128b4043c8f56752547e122e03978f270e341f3a925ef03ad814b0caffa7)
> >
> > Please vote now! (The vote is open for 72h.)
> >
> > [ ] +1
> > [ ] +0
> > [ ] -1
> >
> > Regards,
> >
> > Udo
> >
> > [1]
> > https://repository.apache.org/content/repositories/orgapachemyfaces-1214
> > [2] https://issues.apache.org/jira/projects/TOBAGO/versions/12352084
> > [3]
> >
> https://repository.apache.org/content/repositories/orgapachemyfaces-1214/org/apache/myfaces/tobago/tobago/4.6.0/tobago-4.6.0-source-release.zip
> >
> >
> >
>

Re: New faces.js/ts code ready for merge

[Werner Punz]

Bug is fixed, I also added 3 unit tests to cover this part of the spec on
unit test level on our side.

Please test, if everything is ok we can start to merge.

Cheers and happy evening

Werner


Am Mi., 2. Nov. 2022 um 10:31 Uhr schrieb Werner Punz :

> HI I just got a small bug report in via a comment, I must have missed this
> morning (thanks for pointing me towards it)
> I just need to fix this (it is a small protocol part which is rarely used
> which needs implementation)
> I also will add the missing test.
>
> Once I am done with it I will wait a little bit for further comments and
> objections and then go ahead.
>
> Am Mi., 2. Nov. 2022 um 10:27 Uhr schrieb Bernd Bohmann  >:
>
>> Thanks Werner
>>
>> please go ahead. I will do some testing in the next 2 weeks as well. I
>> think minor issues can be solved after the merge
>>
>> Regards
>>
>> Bernd
>>
>> On Wed, Nov 2, 2022 at 9:35 AM Werner Punz  wrote:
>> >
>> > Hello
>> >
>> > I am back from my vacation, following. In my opinion the code is ready
>> for merge and the target has been RC3 which would be, now.
>> > Given I still have one pending review, did anyone test already, are
>> there any objections to do so?
>> >
>> > I just wanted to ask before I go ahead with it.
>> >
>> > Werner
>> >
>> > PS: The integration testsuite will follow once the core code is in,
>> because I have to retarget the tests then towards the implementation instead
>> > of the embedded faces.js coming from my github package.
>> >
>>
>

Re: New faces.js/ts code ready for merge

[Werner Punz]

HI I just got a small bug report in via a comment, I must have missed this
morning (thanks for pointing me towards it)
I just need to fix this (it is a small protocol part which is rarely used
which needs implementation)
I also will add the missing test.

Once I am done with it I will wait a little bit for further comments and
objections and then go ahead.

Am Mi., 2. Nov. 2022 um 10:27 Uhr schrieb Bernd Bohmann :

> Thanks Werner
>
> please go ahead. I will do some testing in the next 2 weeks as well. I
> think minor issues can be solved after the merge
>
> Regards
>
> Bernd
>
> On Wed, Nov 2, 2022 at 9:35 AM Werner Punz  wrote:
> >
> > Hello
> >
> > I am back from my vacation, following. In my opinion the code is ready
> for merge and the target has been RC3 which would be, now.
> > Given I still have one pending review, did anyone test already, are
> there any objections to do so?
> >
> > I just wanted to ask before I go ahead with it.
> >
> > Werner
> >
> > PS: The integration testsuite will follow once the core code is in,
> because I have to retarget the tests then towards the implementation instead
> > of the embedded faces.js coming from my github package.
> >
>

New faces.js/ts code ready for merge

[Werner Punz]

Hello

I am back from my vacation, following. In my opinion the code is ready for
merge and the target has been RC3 which would be, now.
Given I still have one pending review, did anyone test already, are there
any objections to do so?

I just wanted to ask before I go ahead with it.

Werner

PS: The integration testsuite will follow once the core code is in, because
I have to retarget the tests then towards the implementation instead
of the embedded faces.js coming from my github package.

typescript sources merge

[Werner Punz]

Hi

Now that we will have released RC2 soon,
I just wanted to ask, if following timetable is ok.

I am atm on vacation so I cannot merge this week.
Wednesday next week, I will be out of my vacation and could perform the
merge
for the scripts and the new integration test suite.

In the meantime I have to ask for a favor, please test if possible the new
scripts properly
in your projects before the merge. This is a major change in the codebase
and we are basically going
to drop the old scripts.

So from my side unless a big bug crawls up, Wednesday next week, it would
be, if everyone is ok with it.
I can postpone it, if someone has a problem with it.



Werner

Re: [VOTE] Release of MyFaces Core 4.0.0-RC2

[Werner Punz]

+1

Werner


Am Do., 20. Okt. 2022 um 18:11 Uhr schrieb Volodymyr Siedlecki <
volos...@apache.org>:

> Hi,
>
> I was running the needed tasks to get the 4.0.0-RC2 release of Apache
> MyFaces core out.
>
> Please note that this vote concerns all of the following parts:
>1. Maven artifact group "org.apache.myfaces.core" v4.0.0-RC2  [1]
>
> The artifacts were deployed on nexus repo [1] for binary and source
> packages.
>
> The release notes could be found at [4].
>
> The japicmp tool shows some binary incompatibilities with 4.0.0-RC2 and
> the jakarta.faces-api-4.0.1.jar. Please take a look at the attached
> results.html.
>
> This release has not yet been run against the TCK.
>
> Please take a look at the "4.0.0-RC2" artifacts and vote! (see [3])
>
> Please note: This vote is "majority approval" with a minimum of three +1
> votes (see [2]).
>
> 
> [ ] +1 for community members who have reviewed the bits
> [ ] +0
> [ ] -1 for fatal flaws that should cause these bits not to be released,
> and why.
> 
>
> Thanks,
>
> Volodymyr
>
> [1]
> https://repository.apache.org/content/repositories/orgapachemyfaces-1213/org/apache/myfaces/core/
> [2] http://www.apache.org/foundation/voting.html#ReleaseVotes
> [3]
> https://repository.apache.org/content/repositories/orgapachemyfaces-1213/org/apache/myfaces/core/myfaces-core-assembly/
> [4]
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12351839=10600
>

[jira] [Commented] (MYFACES-4487) faces.js/ts new codebase, improve mapping handling

[Werner Punz (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17621124#comment-17621124
 ] 

Werner Punz commented on MYFACES-4487:
--

Fixed in the branch by adding another chained resource loader

the map file transformation is only active on the faces.js resource and only in 
development mode

> faces.js/ts new codebase, improve mapping handling
> --
>
> Key: MYFACES-4487
> URL: https://issues.apache.org/jira/browse/MYFACES-4487
> Project: MyFaces Core
>  Issue Type: New Feature
>    Reporter: Werner Punz
>    Assignee: Werner Punz
>Priority: Major
> Fix For: 4.0.0-RC3
>
>
> In our git pull request we use a specialized Faces servlet mapping jsf_map to 
> enable the mapping functionality.
> Now this is suboptimal, if we do not enable this mapping we still get errors 
> in the browser log that a mapping file could not be loaded.
> A better way would be to provide the functionality probably is a switchable 
> resource handler, wich adds the mapping info depending on the request data.
> This must be documented one way or the other that we have this functionality 
> once merged.
> (Impl functionality)



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (MYFACES-4487) faces.js/ts new codebase, improve mapping handling

[Werner Punz (Jira)]

 [ 
https://issues.apache.org/jira/browse/MYFACES-4487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Werner Punz resolved MYFACES-4487.
--
Resolution: Fixed

> faces.js/ts new codebase, improve mapping handling
> --
>
> Key: MYFACES-4487
> URL: https://issues.apache.org/jira/browse/MYFACES-4487
> Project: MyFaces Core
>  Issue Type: New Feature
>    Reporter: Werner Punz
>    Assignee: Werner Punz
>Priority: Major
> Fix For: 4.0.0-RC3
>
>
> In our git pull request we use a specialized Faces servlet mapping jsf_map to 
> enable the mapping functionality.
> Now this is suboptimal, if we do not enable this mapping we still get errors 
> in the browser log that a mapping file could not be loaded.
> A better way would be to provide the functionality probably is a switchable 
> resource handler, wich adds the mapping info depending on the request data.
> This must be documented one way or the other that we have this functionality 
> once merged.
> (Impl functionality)



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (MYFACES-4487) faces.js/ts new codebase, improve mapping handling

[Werner Punz (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17620973#comment-17620973
 ] 

Werner Punz edited comment on MYFACES-4487 at 10/20/22 9:58 AM:


I have the resource wrapper now working in my github project which does the 
mapping file remapping. We probably do not even have to document it. As far as 
I recall there already is a chain active in the impl code where we can add the 
wrapper for dev mode (prod mode for now will not get any mapping file support, 
probably unwanted for prod due to causing extra requests)

 


was (Author: werpu):
I have the resource wrapper now working which does the mapping file remapping. 
We probably do not even have to document it. As far as I recall there already 
is a chain active in the impl code where we can add the wrapper for dev mode 
(prod mode for now will not get any mapping file support, probably unwanted for 
prod due to causing extra requests)

 

> faces.js/ts new codebase, improve mapping handling
> --
>
> Key: MYFACES-4487
> URL: https://issues.apache.org/jira/browse/MYFACES-4487
> Project: MyFaces Core
>  Issue Type: New Feature
>    Reporter: Werner Punz
>Priority: Major
>
> In our git pull request we use a specialized Faces servlet mapping jsf_map to 
> enable the mapping functionality.
> Now this is suboptimal, if we do not enable this mapping we still get errors 
> in the browser log that a mapping file could not be loaded.
> A better way would be to provide the functionality probably is a switchable 
> resource handler, wich adds the mapping info depending on the request data.
> This must be documented one way or the other that we have this functionality 
> once merged.
> (Impl functionality)



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (MYFACES-4487) faces.js/ts new codebase, improve mapping handling

[Werner Punz (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17620973#comment-17620973
 ] 

Werner Punz commented on MYFACES-4487:
--

I have the resource wrapper now working which does the mapping file remapping. 
We probably do not even have to document it. As far as I recall there already 
is a chain active in the impl code where we can add the wrapper for dev mode 
(prod mode for now will not get any mapping file support, probably unwanted for 
prod due to causing extra requests)

 

> faces.js/ts new codebase, improve mapping handling
> --
>
> Key: MYFACES-4487
> URL: https://issues.apache.org/jira/browse/MYFACES-4487
> Project: MyFaces Core
>  Issue Type: New Feature
>    Reporter: Werner Punz
>Priority: Major
>
> In our git pull request we use a specialized Faces servlet mapping jsf_map to 
> enable the mapping functionality.
> Now this is suboptimal, if we do not enable this mapping we still get errors 
> in the browser log that a mapping file could not be loaded.
> A better way would be to provide the functionality probably is a switchable 
> resource handler, wich adds the mapping info depending on the request data.
> This must be documented one way or the other that we have this functionality 
> once merged.
> (Impl functionality)



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (MYFACES-4487) faces.js/ts new codebase, improve mapping handling

[Werner Punz (Jira)]

Werner Punz created MYFACES-4487:


 Summary: faces.js/ts new codebase, improve mapping handling
 Key: MYFACES-4487
 URL: https://issues.apache.org/jira/browse/MYFACES-4487
 Project: MyFaces Core
  Issue Type: New Feature
Reporter: Werner Punz


In our git pull request we use a specialized Faces servlet mapping jsf_map to 
enable the mapping functionality.

Now this is suboptimal, if we do not enable this mapping we still get errors in 
the browser log that a mapping file could not be loaded.

A better way would be to provide the functionality probably is a switchable 
resource handler, wich adds the mapping info depending on the request data.

This must be documented one way or the other that we have this functionality 
once merged.

(Impl functionality)



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: Plan 4.0.0 RC2

[Werner Punz]

No rush, I was just wondering, and great! I will be on vacation next week,
but I can perform the Ajax scripts merge post RC2 of the new scripts after
that.
(or during my vacation, given it is a 5 minutes job)
I can ask everyone, please test the new Ajax scripts as thoroughly as
possible.
I did everything I could, to provide well working scripts, but they need
more real world
tests outside of Tobago.
I am not a big fan of doing such big changes in an RC (by definition, not
even beta), but sometimes you cannot avoid it.

Werner


Am Mi., 19. Okt. 2022 um 23:36 Uhr schrieb Volodymyr Siedlecki <
volodymyr.siedle...@ibm.com>:

> Hi,
>
> Sorry for the delay.
>
> I will get started on a RC2 tomorrow (Oct 20th).
>
> Thanks,
> Volodymyr
>
>
>
> *From: *Werner Punz 
> *Date: *Wednesday, October 19, 2022 at 2:28 AM
> *To: *MyFaces Development 
> *Subject: *[EXTERNAL] Plan 4.0.0 RC2
>
> Hi, I am wondering What are the release plans for 4. 0. 0 RC2? Any
> specific date already set? Or is it ready, when it´s ready? Werner ‍ ‍ ‍ ‍
> ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍
> ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍
> ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍
>
> ZjQcmQRYFpfptBannerStart
>
> *This Message Is From an External Sender *
>
> This message came from outside your organization.
>
> ZjQcmQRYFpfptBannerEnd
>
> Hi, I am wondering
>
>
>
> What are the release plans for 4.0.0 RC2?
>
> Any specific date already set?
>
> Or is it ready, when it´s ready?
>
>
>
> Werner
>
>
>

[jira] [Resolved] (MYFACES-4482) jsf.js and faces.js old codebase fails on my decorator integration test

[Werner Punz (Jira)]

 [ 
https://issues.apache.org/jira/browse/MYFACES-4482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Werner Punz resolved MYFACES-4482.
--
Fix Version/s: 2.3-next-M8
   4.0.0-RC3
   Resolution: Fixed

was a test issue

 

> jsf.js and faces.js old codebase fails on my decorator integration test
> ---
>
> Key: MYFACES-4482
> URL: https://issues.apache.org/jira/browse/MYFACES-4482
> Project: MyFaces Core
>  Issue Type: Bug
>  Components: General
>Affects Versions: 4.0.0-RC1
>    Reporter: Werner Punz
>Assignee: Werner Punz
>Priority: Minor
> Fix For: 2.3-next-M8, 4.0.0-RC3
>
>
> I have a set of integration tests which are currently hosted in a pull 
> request for 4.0
> While the tests pass for the new codebase entirely, for the old one they fail 
> on
> test-12 decoration, which tests whether the decorated apis are called 
> correctly.
> This could be an issue with the testcases, but more likely we have a small 
> bug in the old implementation which bypasses the api for one of the testcases 
> and calls the impl directly. 
> We had several bugs in this area in the past, when people started to decorate 
> the apis. Hence I wrote this test to begin with.
> I will work on this issue on monday and get this fixed either in the test or 
> in the old soon to be legacy codebase.
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Plan 4.0.0 RC2

[Werner Punz]

Hi, I am wondering

What are the release plans for 4.0.0 RC2?
Any specific date already set?
Or is it ready, when it´s ready?

Werner

[jira] [Comment Edited] (MYFACES-4482) jsf.js and faces.js old codebase fails on my decorator integration test

[Werner Punz (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17618728#comment-17618728
 ] 

Werner Punz edited comment on MYFACES-4482 at 10/17/22 8:51 AM:


Turned out to be a small bug in the test codebase.

The getViewState decoration, did not return a value.

The new codebase seems to be more forgiving regarding an empty viewstate than 
the old one.

Both are valid implementations, this is just a slight variation in how to 
handle the case of an undefined viewstate (which should not happen anyway)

Will fix this for the pull request 4476, given it only affects the codebase for 
the integration tests not the implementation itself

 

 

 


was (Author: werpu):
Turned out to be a small bug in the test codebase.

The getViewState decoration, did not return a value.

The new codebase seems to be more forgiving regarding an empty viewstate than 
the old one.

Both are valid implementations, this is just a slight variation in how to 
handle the case of an undefined viewstate (which should not happen anyway)

 

> jsf.js and faces.js old codebase fails on my decorator integration test
> ---
>
> Key: MYFACES-4482
> URL: https://issues.apache.org/jira/browse/MYFACES-4482
> Project: MyFaces Core
>  Issue Type: Bug
>  Components: General
>Affects Versions: 4.0.0-RC1, 2.3-next-M7
>    Reporter: Werner Punz
>Assignee: Werner Punz
>Priority: Minor
>
> I have a set of integration tests which are currently hosted in a pull 
> request for 4.0
> While the tests pass for the new codebase entirely, for the old one they fail 
> on
> test-12 decoration, which tests whether the decorated apis are called 
> correctly.
> This could be an issue with the testcases, but more likely we have a small 
> bug in the old implementation which bypasses the api for one of the testcases 
> and calls the impl directly. 
> We had several bugs in this area in the past, when people started to decorate 
> the apis. Hence I wrote this test to begin with.
> I will work on this issue on monday and get this fixed either in the test or 
> in the old soon to be legacy codebase.
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (MYFACES-4482) jsf.js and faces.js old codebase fails on my decorator integration test

[Werner Punz (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17618728#comment-17618728
 ] 

Werner Punz commented on MYFACES-4482:
--

Turned out to be a small bug in the test codebase.

The getViewState decoration, did not return a value.

The new codebase seems to be more forgiving regarding an empty viewstate than 
the old one.

Both are valid implementations, this is just a slight variation in how to 
handle the case of an undefined viewstate (which should not happen anyway)

 

> jsf.js and faces.js old codebase fails on my decorator integration test
> ---
>
> Key: MYFACES-4482
> URL: https://issues.apache.org/jira/browse/MYFACES-4482
> Project: MyFaces Core
>  Issue Type: Bug
>  Components: General
>Affects Versions: 4.0.0-RC1, 2.3-next-M7
>    Reporter: Werner Punz
>Assignee: Werner Punz
>Priority: Minor
>
> I have a set of integration tests which are currently hosted in a pull 
> request for 4.0
> While the tests pass for the new codebase entirely, for the old one they fail 
> on
> test-12 decoration, which tests whether the decorated apis are called 
> correctly.
> This could be an issue with the testcases, but more likely we have a small 
> bug in the old implementation which bypasses the api for one of the testcases 
> and calls the impl directly. 
> We had several bugs in this area in the past, when people started to decorate 
> the apis. Hence I wrote this test to begin with.
> I will work on this issue on monday and get this fixed either in the test or 
> in the old soon to be legacy codebase.
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (MYFACES-4482) jsf.js and faces.js old codebase fails on my decorator integration test

[Werner Punz (Jira)]

Werner Punz created MYFACES-4482:


 Summary: jsf.js and faces.js old codebase fails on my decorator 
integration test
 Key: MYFACES-4482
 URL: https://issues.apache.org/jira/browse/MYFACES-4482
 Project: MyFaces Core
  Issue Type: Bug
  Components: General
Affects Versions: 2.3-next-M7, 4.0.0-RC1
Reporter: Werner Punz
Assignee: Werner Punz


I have a set of integration tests which are currently hosted in a pull request 
for 4.0

While the tests pass for the new codebase entirely, for the old one they fail on

test-12 decoration, which tests whether the decorated apis are called correctly.

This could be an issue with the testcases, but more likely we have a small bug 
in the old implementation which bypasses the api for one of the testcases and 
calls the impl directly. 

We had several bugs in this area in the past, when people started to decorate 
the apis. Hence I wrote this test to begin with.

I will work on this issue on monday and get this fixed either in the test or in 
the old soon to be legacy codebase.

 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (MYFACES-4479) The jsf.js script does not read the nonce correctly in modern browsers.

[Werner Punz (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17617690#comment-17617690
 ] 

Werner Punz commented on MYFACES-4479:
--

Done and fixed for main as well, which means it should go into the next rc!

I am closing the issue now.

 

> The jsf.js script does not read the nonce correctly in modern browsers.
> ---
>
> Key: MYFACES-4479
> URL: https://issues.apache.org/jira/browse/MYFACES-4479
> Project: MyFaces Core
>  Issue Type: Bug
>  Components: General
>Affects Versions: 4.0.0-RC1, 2.3.10, 2.3-next-M7
> Environment: Myfaces 2.3-next-M7
> Chrome: 106.0.5249.103
>Reporter: Vitaly Sidorov
>Assignee: Werner Punz
>Priority: Major
>
> In Chrome it is no longer possible to get a nonce with getAttribute("nonce").
> You can only use HTMLElement.nonce (see: 
> [https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/nonce)]
> Steps to reproduce:
> - set header Content-Security-Policy: script-src 'self' 'nonce-test123'
> - set  target="head"/>
> - set parameters 
> org.apache.myfaces.USE_MULTIPLE_JS_FILES_FOR_JSF_UNCOMPRESSED_JS=false and 
> javax.faces.PROJECT_STAGE=Developement
> - open page in browser and get multiple errors in console: 
> {{jsf.js.jsf?ln=javax.faces=Development:93 Refused to execute inline 
> script because it violates the following Content Security Policy directive: 
> "script-src 'self' 'nonce=test123'". Either the 'unsafe-inline' keyword, a 
> hash ('sha256-Xu6aRWi9bDVg9FaanKbn/uUSQUCsJ5g+bPB5SUYUIfk='), or a nonce 
> ('nonce-...') is required to enable inline execution.}}
> The reason:
> The error falls on .appendChild(element) in code
> {{var htmlScriptElement = document.head.appendChild(element);}}
> {{document.head.removeChild(htmlScriptElement);}}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (MYFACES-4479) The jsf.js script does not read the nonce correctly in modern browsers.

[Werner Punz (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17617650#comment-17617650
 ] 

Werner Punz edited comment on MYFACES-4479 at 10/14/22 12:00 PM:
-

The fix is in for 2.3 next and the new 4.0RC3 codebase, please test it.

I will also crossport the fix for RC2

 


was (Author: werpu):
The fix is in for 2.3 next and the new 4.0RC3 codebase, please test it.

Question is are we going to take the fix in also for RC2 or are we going to 
wait for RC3 to have it automatically with the new scripts?

 

> The jsf.js script does not read the nonce correctly in modern browsers.
> ---
>
> Key: MYFACES-4479
> URL: https://issues.apache.org/jira/browse/MYFACES-4479
> Project: MyFaces Core
>  Issue Type: Bug
>  Components: General
>Affects Versions: 4.0.0-RC1, 2.3.10, 2.3-next-M7
> Environment: Myfaces 2.3-next-M7
> Chrome: 106.0.5249.103
>Reporter: Vitaly Sidorov
>Assignee: Werner Punz
>Priority: Major
>
> In Chrome it is no longer possible to get a nonce with getAttribute("nonce").
> You can only use HTMLElement.nonce (see: 
> [https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/nonce)]
> Steps to reproduce:
> - set header Content-Security-Policy: script-src 'self' 'nonce-test123'
> - set  target="head"/>
> - set parameters 
> org.apache.myfaces.USE_MULTIPLE_JS_FILES_FOR_JSF_UNCOMPRESSED_JS=false and 
> javax.faces.PROJECT_STAGE=Developement
> - open page in browser and get multiple errors in console: 
> {{jsf.js.jsf?ln=javax.faces=Development:93 Refused to execute inline 
> script because it violates the following Content Security Policy directive: 
> "script-src 'self' 'nonce=test123'". Either the 'unsafe-inline' keyword, a 
> hash ('sha256-Xu6aRWi9bDVg9FaanKbn/uUSQUCsJ5g+bPB5SUYUIfk='), or a nonce 
> ('nonce-...') is required to enable inline execution.}}
> The reason:
> The error falls on .appendChild(element) in code
> {{var htmlScriptElement = document.head.appendChild(element);}}
> {{document.head.removeChild(htmlScriptElement);}}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (MYFACES-4479) The jsf.js script does not read the nonce correctly in modern browsers.

[Werner Punz (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17617650#comment-17617650
 ] 

Werner Punz commented on MYFACES-4479:
--

The fix is in for 2.3 next and the new 4.0RC3 codebase, please test it.

Question is are we going to take the fix in also for RC2 or are we going to 
wait for RC3 to have it automatically with the new scripts?

 

> The jsf.js script does not read the nonce correctly in modern browsers.
> ---
>
> Key: MYFACES-4479
> URL: https://issues.apache.org/jira/browse/MYFACES-4479
> Project: MyFaces Core
>  Issue Type: Bug
>  Components: General
>Affects Versions: 4.0.0-RC1, 2.3.10, 2.3-next-M7
> Environment: Myfaces 2.3-next-M7
> Chrome: 106.0.5249.103
>Reporter: Vitaly Sidorov
>Assignee: Werner Punz
>Priority: Major
>
> In Chrome it is no longer possible to get a nonce with getAttribute("nonce").
> You can only use HTMLElement.nonce (see: 
> [https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/nonce)]
> Steps to reproduce:
> - set header Content-Security-Policy: script-src 'self' 'nonce-test123'
> - set  target="head"/>
> - set parameters 
> org.apache.myfaces.USE_MULTIPLE_JS_FILES_FOR_JSF_UNCOMPRESSED_JS=false and 
> javax.faces.PROJECT_STAGE=Developement
> - open page in browser and get multiple errors in console: 
> {{jsf.js.jsf?ln=javax.faces=Development:93 Refused to execute inline 
> script because it violates the following Content Security Policy directive: 
> "script-src 'self' 'nonce=test123'". Either the 'unsafe-inline' keyword, a 
> hash ('sha256-Xu6aRWi9bDVg9FaanKbn/uUSQUCsJ5g+bPB5SUYUIfk='), or a nonce 
> ('nonce-...') is required to enable inline execution.}}
> The reason:
> The error falls on .appendChild(element) in code
> {{var htmlScriptElement = document.head.appendChild(element);}}
> {{document.head.removeChild(htmlScriptElement);}}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (MYFACES-4479) The jsf.js script does not read the nonce correctly in modern browsers.

[Werner Punz (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17617529#comment-17617529
 ] 

Werner Punz edited comment on MYFACES-4479 at 10/14/22 7:23 AM:


I have added the tests and fixes to my pull requests for the integrationtests 
and the new typescript scripts (all in the pull requests which are pending for 
RC3).

I will now tackle the old codebase.

When fixing this on my new code, I noticed that the fixes proposed in the patch 
do not suffice entirely, because "nonce" is not handled properly for embedded 
scripts (which are concatenated and then executed as once via the global nonce 
we have for jsf.jsf

This works, if the embedded script is not "nonced" but if there is a nonce flag 
we have to pull out of this scheme and eval with the nonce it has (and eval the 
concatenated scripts before)

I added 4 cases to my tests to handle the 4 possible scenarii
 * failing nonce, for script src,
 * non failing nonce for script src,
 * and the same for embedded scripts

So my plan for today is:

I will backport my intrgration tests to JSF 2.3 and then will take the patches 
in and fix the eval behavior as well.

The 4.0 codebase is working already and committed, you can get the code from 
the pull request.

Question is, since we are going to migrate the code anyway for 4.0 RC3 to the 
new Typescript code, are we going to fix this for 4.0RC2 on the old codebase as 
well?

There is not too much sense to perform this extra work in this case given that 
the code soon will be dropped anyway.

2.3 is out of the question we are not going to migrate despite having the 
possibility (I have a working 2.3 version of my new code in my github project)

 


was (Author: werpu):
I have added the tests and fixes to my pull requests for the integrationtests 
and the new scripts.

I will now tackle the old codebase.

When fixing this on my new code, I noticed that the fixes proposed in the patch 
do not suffice entirely, because nonce is not handled properly for embedded 
scripts (which are concatenated and then executed as once via the global nonce 
we have for jsf.js)

This works, if the embedded script is not "nonced" but if there is a nonce flag 
we have to pull out of this scheme and eval with the nonce it has (and eval the 
concatenated scripts before)

I added 4 cases to my tests to handle the 4 possible scenarii
 * failing nonce, for script src,
 * non failing nonce for script src,
 * and the same for embedded scripts

So my plan for today is:

I will backport my intrgration tests to JSF 2.3 and then will take the patches 
in and fix the eval behavior as well.

The 4.0 codebase is working already and committed, you can get the code from 
the pull request.

Question is, since we are going to migrate the code anyway for 4.0 RC3 to the 
new Typescript code, are we going to fix this for 4.0RC2 on the old codebase as 
well?

There is not too much sense to perform this extra work in this case given that 
the code soon will be dropped anyway.

2.3 is out of the question we are not going to migrate despite having the 
possibility (I have a working 2.3 version of my new code in my github project)

 

> The jsf.js script does not read the nonce correctly in modern browsers.
> ---
>
> Key: MYFACES-4479
> URL: https://issues.apache.org/jira/browse/MYFACES-4479
> Project: MyFaces Core
>  Issue Type: Bug
>  Components: General
>Affects Versions: 4.0.0-RC1, 2.3.10, 2.3-next-M7
> Environment: Myfaces 2.3-next-M7
> Chrome: 106.0.5249.103
>    Reporter: Vitaly Sidorov
>Assignee: Werner Punz
>Priority: Major
>
> In Chrome it is no longer possible to get a nonce with getAttribute("nonce").
> You can only use HTMLElement.nonce (see: 
> [https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/nonce)]
> Steps to reproduce:
> - set header Content-Security-Policy: script-src 'self' 'nonce-test123'
> - set  target="head"/>
> - set parameters 
> org.apache.myfaces.USE_MULTIPLE_JS_FILES_FOR_JSF_UNCOMPRESSED_JS=false and 
> javax.faces.PROJECT_STAGE=Developement
> - open page in browser and get multiple errors in console: 
> {{jsf.js.jsf?ln=javax.faces=Development:93 Refused to execute inline 
> script because it violates the following Content Security Policy directive: 
> "script-src 'self' 'nonce=test123'". Either the 'unsafe-inline' keyword, a 
> hash ('sha256-Xu6aRWi9bDVg9FaanKbn/uUSQUCsJ5g+bPB5SUYUIfk='), or a nonce 
> ('nonce-...') is required to enable inline execution.}}
> The reason:
> The error falls on .appendChild(element) in code
> {{var htmlScriptElement = document.head.appendChild(element);}}
> {{document.head.removeChild(htmlScriptElement);}}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (MYFACES-4479) The jsf.js script does not read the nonce correctly in modern browsers.

[Werner Punz (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17617529#comment-17617529
 ] 

Werner Punz edited comment on MYFACES-4479 at 10/14/22 7:22 AM:


I have added the tests and fixes to my pull requests for the integrationtests 
and the new scripts.

I will now tackle the old codebase.

When fixing this on my new code, I noticed that the fixes proposed in the patch 
do not suffice entirely, because nonce is not handled properly for embedded 
scripts (which are concatenated and then executed as once via the global nonce 
we have for jsf.js)

This works, if the embedded script is not "nonced" but if there is a nonce flag 
we have to pull out of this scheme and eval with the nonce it has (and eval the 
concatenated scripts before)

I added 4 cases to my tests to handle the 4 possible scenarii
 * failing nonce, for script src,
 * non failing nonce for script src,
 * and the same for embedded scripts

So my plan for today is:

I will backport my intrgration tests to JSF 2.3 and then will take the patches 
in and fix the eval behavior as well.

The 4.0 codebase is working already and committed, you can get the code from 
the pull request.

Question is, since we are going to migrate the code anyway for 4.0 RC3 to the 
new Typescript code, are we going to fix this for 4.0RC2 on the old codebase as 
well?

There is not too much sense to perform this extra work in this case given that 
the code soon will be dropped anyway.

2.3 is out of the question we are not going to migrate despite having the 
possibility (I have a working 2.3 version of my new code in my github project)

 


was (Author: werpu):
I have added the tests and fixes to my pull requests for the integrationtests 
and the new scripts.

I will now tackle the old codebase. When fixing this on my new code, I noticed 
that the fixes proposed in the patch do not suffice entirely, because nonce is 
not handled properly for embedded scripts (which are concatenated and then 
executed as once via the global nonce we have for jsf.js)

This works if the embedded script is not "nonced" but if there is a nonce flag 
we have to pull out of this scheme and eval with the nonce it has (and eval the 
concatenated scripts before)

I added 4 cases to my tests to handle the 4 possible scenarii

(failing nonce, for script src, non failing nonce for script src, and the same 
for embedded scripts)

So my plan for today is, I will backport my intrgration tests to jsf 2.3 and 
then will take the patches in and fix the eval behavior as well.

The 4.0 codebase is working already and comitted, you can get the code from the 
pull request. Question is, since we are going to migrate the code anyway for 
4.0 RC3 to the new typescript code, are we going to fix this for 4.0RC2 on the 
old codebase?

There is not too much sense to perform this extra work in this case.

2.3 is out of the question we are not going to migrate despite having the 
possibility (I have a working 2.3 version of my new code in my github project)

 

> The jsf.js script does not read the nonce correctly in modern browsers.
> ---
>
> Key: MYFACES-4479
> URL: https://issues.apache.org/jira/browse/MYFACES-4479
> Project: MyFaces Core
>  Issue Type: Bug
>  Components: General
>Affects Versions: 4.0.0-RC1, 2.3.10, 2.3-next-M7
> Environment: Myfaces 2.3-next-M7
> Chrome: 106.0.5249.103
>    Reporter: Vitaly Sidorov
>Assignee: Werner Punz
>Priority: Major
>
> In Chrome it is no longer possible to get a nonce with getAttribute("nonce").
> You can only use HTMLElement.nonce (see: 
> [https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/nonce)]
> Steps to reproduce:
> - set header Content-Security-Policy: script-src 'self' 'nonce-test123'
> - set  target="head"/>
> - set parameters 
> org.apache.myfaces.USE_MULTIPLE_JS_FILES_FOR_JSF_UNCOMPRESSED_JS=false and 
> javax.faces.PROJECT_STAGE=Developement
> - open page in browser and get multiple errors in console: 
> {{jsf.js.jsf?ln=javax.faces=Development:93 Refused to execute inline 
> script because it violates the following Content Security Policy directive: 
> "script-src 'self' 'nonce=test123'". Either the 'unsafe-inline' keyword, a 
> hash ('sha256-Xu6aRWi9bDVg9FaanKbn/uUSQUCsJ5g+bPB5SUYUIfk='), or a nonce 
> ('nonce-...') is required to enable inline execution.}}
> The reason:
> The error falls on .appendChild(element) in code
> {{var htmlScriptElement = document.head.appendChild(element);}}
> {{document.head.removeChild(htmlScriptElement);}}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (MYFACES-4479) The jsf.js script does not read the nonce correctly in modern browsers.

[Werner Punz (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17617529#comment-17617529
 ] 

Werner Punz edited comment on MYFACES-4479 at 10/14/22 7:19 AM:


I have added the tests and fixes to my pull requests for the integrationtests 
and the new scripts.

I will now tackle the old codebase. When fixing this on my new code, I noticed 
that the fixes proposed in the patch do not suffice entirely, because nonce is 
not handled properly for embedded scripts (which are concatenated and then 
executed as once via the global nonce we have for jsf.js)

This works if the embedded script is not "nonced" but if there is a nonce flag 
we have to pull out of this scheme and eval with the nonce it has (and eval the 
concatenated scripts before)

I added 4 cases to my tests to handle the 4 possible scenarii

(failing nonce, for script src, non failing nonce for script src, and the same 
for embedded scripts)

So my plan for today is, I will backport my intrgration tests to jsf 2.3 and 
then will take the patches in and fix the eval behavior as well.

The 4.0 codebase is working already and comitted, you can get the code from the 
pull request. Question is, since we are going to migrate the code anyway for 
4.0 RC3 to the new typescript code, are we going to fix this for 4.0RC2 on the 
old codebase?

There is not too much sense to perform this extra work in this case.

2.3 is out of the question we are not going to migrate despite having the 
possibility (I have a working 2.3 version of my new code in my github project)

 


was (Author: werpu):
I have added the tests and fixes to my pull requests for the integrationtests 
and the new scripts.

I will now tackle the old codebase. When fixing this on my new code, I noticed 
that the fixes proposed in the patch do not suffice entirely, because nonce is 
not handled properly for embedded scripts (which are concatenated and then 
executed as once via the global nonce we have for jsf.js)

This works if the embedded script is not "nonced" but if there is a nonce flag 
we have to pull out of this scheme and eval with the nonce it has (and eval the 
concatenated scripts before)

I added 4 cases to my tests to handle the 4 possible scenarii

(failing nonce, for script src, non failing nonce for script src, and the same 
for embedded scripts)

 

So my plan for today is, I will backport my intrgration tests to jsf 2.3 and 
then will take the patches in and fix the eval behavior as well.

The 4.0 codebase is working already and comitted, you can get the code from the 
pull request. Question is, since we are going to migrate the code anyway for 
4.0 RC3 to the new typescript code, are we going to fix this for 4.0RC2 on the 
old codebase?

There is not too much sense to perform this extra work in this case.

 

> The jsf.js script does not read the nonce correctly in modern browsers.
> ---
>
> Key: MYFACES-4479
> URL: https://issues.apache.org/jira/browse/MYFACES-4479
> Project: MyFaces Core
>  Issue Type: Bug
>  Components: General
>Affects Versions: 4.0.0-RC1, 2.3.10, 2.3-next-M7
> Environment: Myfaces 2.3-next-M7
> Chrome: 106.0.5249.103
>    Reporter: Vitaly Sidorov
>Assignee: Werner Punz
>Priority: Major
>
> In Chrome it is no longer possible to get a nonce with getAttribute("nonce").
> You can only use HTMLElement.nonce (see: 
> [https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/nonce)]
> Steps to reproduce:
> - set header Content-Security-Policy: script-src 'self' 'nonce-test123'
> - set  target="head"/>
> - set parameters 
> org.apache.myfaces.USE_MULTIPLE_JS_FILES_FOR_JSF_UNCOMPRESSED_JS=false and 
> javax.faces.PROJECT_STAGE=Developement
> - open page in browser and get multiple errors in console: 
> {{jsf.js.jsf?ln=javax.faces=Development:93 Refused to execute inline 
> script because it violates the following Content Security Policy directive: 
> "script-src 'self' 'nonce=test123'". Either the 'unsafe-inline' keyword, a 
> hash ('sha256-Xu6aRWi9bDVg9FaanKbn/uUSQUCsJ5g+bPB5SUYUIfk='), or a nonce 
> ('nonce-...') is required to enable inline execution.}}
> The reason:
> The error falls on .appendChild(element) in code
> {{var htmlScriptElement = document.head.appendChild(element);}}
> {{document.head.removeChild(htmlScriptElement);}}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (MYFACES-4479) The jsf.js script does not read the nonce correctly in modern browsers.

[Werner Punz (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17617529#comment-17617529
 ] 

Werner Punz commented on MYFACES-4479:
--

I have added the tests and fixes to my pull requests for the integrationtests 
and the new scripts.

I will now tackle the old codebase. When fixing this on my new code, I noticed 
that the fixes proposed in the patch do not suffice entirely, because nonce is 
not handled properly for embedded scripts (which are concatenated and then 
executed as once via the global nonce we have for jsf.js)

This works if the embedded script is not "nonced" but if there is a nonce flag 
we have to pull out of this scheme and eval with the nonce it has (and eval the 
concatenated scripts before)

I added 4 cases to my tests to handle the 4 possible scenarii

(failing nonce, for script src, non failing nonce for script src, and the same 
for embedded scripts)

 

So my plan for today is, I will backport my intrgration tests to jsf 2.3 and 
then will take the patches in and fix the eval behavior as well.

The 4.0 codebase is working already and comitted, you can get the code from the 
pull request. Question is, since we are going to migrate the code anyway for 
4.0 RC3 to the new typescript code, are we going to fix this for 4.0RC2 on the 
old codebase?

There is not too much sense to perform this extra work in this case.

 

> The jsf.js script does not read the nonce correctly in modern browsers.
> ---
>
> Key: MYFACES-4479
> URL: https://issues.apache.org/jira/browse/MYFACES-4479
> Project: MyFaces Core
>  Issue Type: Bug
>  Components: General
>Affects Versions: 4.0.0-RC1, 2.3.10, 2.3-next-M7
> Environment: Myfaces 2.3-next-M7
> Chrome: 106.0.5249.103
>Reporter: Vitaly Sidorov
>Assignee: Werner Punz
>Priority: Major
>
> In Chrome it is no longer possible to get a nonce with getAttribute("nonce").
> You can only use HTMLElement.nonce (see: 
> [https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/nonce)]
> Steps to reproduce:
> - set header Content-Security-Policy: script-src 'self' 'nonce-test123'
> - set  target="head"/>
> - set parameters 
> org.apache.myfaces.USE_MULTIPLE_JS_FILES_FOR_JSF_UNCOMPRESSED_JS=false and 
> javax.faces.PROJECT_STAGE=Developement
> - open page in browser and get multiple errors in console: 
> {{jsf.js.jsf?ln=javax.faces=Development:93 Refused to execute inline 
> script because it violates the following Content Security Policy directive: 
> "script-src 'self' 'nonce=test123'". Either the 'unsafe-inline' keyword, a 
> hash ('sha256-Xu6aRWi9bDVg9FaanKbn/uUSQUCsJ5g+bPB5SUYUIfk='), or a nonce 
> ('nonce-...') is required to enable inline execution.}}
> The reason:
> The error falls on .appendChild(element) in code
> {{var htmlScriptElement = document.head.appendChild(element);}}
> {{document.head.removeChild(htmlScriptElement);}}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (MYFACES-4479) The jsf.js script does not read the nonce correctly in modern browsers.

[Werner Punz (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17617180#comment-17617180
 ] 

Werner Punz edited comment on MYFACES-4479 at 10/13/22 4:38 PM:


Thanks for changing the versions, I already have the fix working for the 4.0 
scripts and

a set of tests on top of it.

Will cross check the old codebase tomorrow.

Expect both to be fixed sometime tomorrow and a set of new tests in the 
integration testsuite.

 

 

 


was (Author: werpu):
Thanks for changing the versions, I already have the fix working for the 4.0 
scripts and

a set of tests on top of it.

Will cross check the old codebase tomorrow.

Expect both to be fixed sometime tomorrow.

 

 

> The jsf.js script does not read the nonce correctly in modern browsers.
> ---
>
> Key: MYFACES-4479
> URL: https://issues.apache.org/jira/browse/MYFACES-4479
> Project: MyFaces Core
>  Issue Type: Bug
>  Components: General
>Affects Versions: 4.0.0-RC1, 2.3.10, 2.3-next-M7
> Environment: Myfaces 2.3-next-M7
> Chrome: 106.0.5249.103
>Reporter: Vitaly Sidorov
>Assignee: Werner Punz
>Priority: Major
>
> In Chrome it is no longer possible to get a nonce with getAttribute("nonce").
> You can only use HTMLElement.nonce (see: 
> [https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/nonce)]
> Steps to reproduce:
> - set header Content-Security-Policy: script-src 'self' 'nonce-test123'
> - set  target="head"/>
> - set parameters 
> org.apache.myfaces.USE_MULTIPLE_JS_FILES_FOR_JSF_UNCOMPRESSED_JS=false and 
> javax.faces.PROJECT_STAGE=Developement
> - open page in browser and get multiple errors in console: 
> {{jsf.js.jsf?ln=javax.faces=Development:93 Refused to execute inline 
> script because it violates the following Content Security Policy directive: 
> "script-src 'self' 'nonce=test123'". Either the 'unsafe-inline' keyword, a 
> hash ('sha256-Xu6aRWi9bDVg9FaanKbn/uUSQUCsJ5g+bPB5SUYUIfk='), or a nonce 
> ('nonce-...') is required to enable inline execution.}}
> The reason:
> The error falls on .appendChild(element) in code
> {{var htmlScriptElement = document.head.appendChild(element);}}
> {{document.head.removeChild(htmlScriptElement);}}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (MYFACES-4479) The jsf.js script does not read the nonce correctly in modern browsers.

[Werner Punz (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17617180#comment-17617180
 ] 

Werner Punz commented on MYFACES-4479:
--

Thanks for changing the versions, I already have the fix working for the 4.0 
scripts and

a set of tests on top of it.

Will cross check the old codebase tomorrow.

Expect both to be fixed sometime tomorrow.

 

 

> The jsf.js script does not read the nonce correctly in modern browsers.
> ---
>
> Key: MYFACES-4479
> URL: https://issues.apache.org/jira/browse/MYFACES-4479
> Project: MyFaces Core
>  Issue Type: Bug
>  Components: General
>Affects Versions: 4.0.0-RC1, 2.3.10, 2.3-next-M7
> Environment: Myfaces 2.3-next-M7
> Chrome: 106.0.5249.103
>Reporter: Vitaly Sidorov
>Assignee: Werner Punz
>Priority: Major
>
> In Chrome it is no longer possible to get a nonce with getAttribute("nonce").
> You can only use HTMLElement.nonce (see: 
> [https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/nonce)]
> Steps to reproduce:
> - set header Content-Security-Policy: script-src 'self' 'nonce-test123'
> - set  target="head"/>
> - set parameters 
> org.apache.myfaces.USE_MULTIPLE_JS_FILES_FOR_JSF_UNCOMPRESSED_JS=false and 
> javax.faces.PROJECT_STAGE=Developement
> - open page in browser and get multiple errors in console: 
> {{jsf.js.jsf?ln=javax.faces=Development:93 Refused to execute inline 
> script because it violates the following Content Security Policy directive: 
> "script-src 'self' 'nonce=test123'". Either the 'unsafe-inline' keyword, a 
> hash ('sha256-Xu6aRWi9bDVg9FaanKbn/uUSQUCsJ5g+bPB5SUYUIfk='), or a nonce 
> ('nonce-...') is required to enable inline execution.}}
> The reason:
> The error falls on .appendChild(element) in code
> {{var htmlScriptElement = document.head.appendChild(element);}}
> {{document.head.removeChild(htmlScriptElement);}}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (MYFACES-4479) The jsf.js script does not read the nonce correctly in modern browsers.

[Werner Punz (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17617048#comment-17617048
 ] 

Werner Punz edited comment on MYFACES-4479 at 10/13/22 1:24 PM:


So first of all thanks for reporting the bug, this went under my radar.

I have a small testcase working, which needs to be fleshed out more., following,

at the first look, I have to run the tests, your patch seems valid

 

item.getAttribute("nonce") does not work anymore

but item.nonce still returns the nonce value.

I have the same issue in my new code, respectively its underlying baselib.

I will test your pull request once my new testcase is properly integrated and 
if all is well, I will merge it tomorrow.

I also have to fix the faces_ts nextgen codebase for 4.0.

Either way I expect the api to still change in this area probably again, 
because for me moving item.getAttribute("nonce") to item.nonce is only half a 
fix, you cannot see the nonce anymore in the browser dom but you still can 
reach it on dom level via a small issued js element.nonce.

 

 

 

 


was (Author: werpu):
So first of all thanks for reporting the bug, this went under my radar.

I have a small testcase working, which needs to be fleshed out more., following,

at the first look, I have to run the tests, your patch seems valid

 

item.getAttribute("nonce") does not work anymore

but item.nonce still returns the nonce value.

I have the same issue in my new code, respectively its underlying baselib.

I will test your pull request once my new testcase is properly integrated and 
if all is well, I will merge it tomorrow.

I also have to fix the faces_ts nextgen codebase for 4.0.

 

 

> The jsf.js script does not read the nonce correctly in modern browsers.
> ---
>
> Key: MYFACES-4479
> URL: https://issues.apache.org/jira/browse/MYFACES-4479
> Project: MyFaces Core
>  Issue Type: Bug
>  Components: General
>Affects Versions: 2.3-next-M7
> Environment: Myfaces 2.3-next-M7
> Chrome: 106.0.5249.103
>    Reporter: Vitaly Sidorov
>Assignee: Werner Punz
>Priority: Major
>
> In Chrome it is no longer possible to get a nonce with getAttribute("nonce").
> You can only use HTMLElement.nonce (see: 
> [https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/nonce)]
> Steps to reproduce:
> - set header Content-Security-Policy: script-src 'self' 'nonce-test123'
> - set  target="head"/>
> - set parameters 
> org.apache.myfaces.USE_MULTIPLE_JS_FILES_FOR_JSF_UNCOMPRESSED_JS=false and 
> javax.faces.PROJECT_STAGE=Developement
> - open page in browser and get multiple errors in console: 
> {{jsf.js.jsf?ln=javax.faces=Development:93 Refused to execute inline 
> script because it violates the following Content Security Policy directive: 
> "script-src 'self' 'nonce=test123'". Either the 'unsafe-inline' keyword, a 
> hash ('sha256-Xu6aRWi9bDVg9FaanKbn/uUSQUCsJ5g+bPB5SUYUIfk='), or a nonce 
> ('nonce-...') is required to enable inline execution.}}
> The reason:
> The error falls on .appendChild(element) in code
> {{var htmlScriptElement = document.head.appendChild(element);}}
> {{document.head.removeChild(htmlScriptElement);}}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (MYFACES-4479) The jsf.js script does not read the nonce correctly in modern browsers.

[Werner Punz (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17617048#comment-17617048
 ] 

Werner Punz edited comment on MYFACES-4479 at 10/13/22 1:22 PM:


So first of all thanks for reporting the bug, this went under my radar.

I have a small testcase working, which needs to be fleshed out more., following,

at the first look, I have to run the tests, your patch seems valid

 

item.getAttribute("nonce") does not work anymore

but item.nonce still returns the nonce value.

I have the same issue in my new code, respectively its underlying baselib.

I will test your pull request once my new testcase is properly integrated and 
if all is well, I will merge it tomorrow.

I also have to fix the faces_ts nextgen codebase for 4.0.

 

 


was (Author: werpu):
I have a small testcase working, which needs to be fleshed out more., following,

at the first look, I have to run the tests, your patch seems valid

 

item.getAttribute("nonce") does not work anymore

but item.nonce still returns the nonce value.

I have the same issue in my new code, respectively its underlying baselib.

I will test your pull request once my new testcase is properly integrated and 
if all is well, I will merge it tomorrow.

I also have to fix the faces_ts nextgen codebase for 4.0.

So first of all thanks for reporting the bug, this went under my radar.

 

> The jsf.js script does not read the nonce correctly in modern browsers.
> ---
>
> Key: MYFACES-4479
> URL: https://issues.apache.org/jira/browse/MYFACES-4479
> Project: MyFaces Core
>  Issue Type: Bug
>  Components: General
>Affects Versions: 2.3-next-M7
> Environment: Myfaces 2.3-next-M7
> Chrome: 106.0.5249.103
>    Reporter: Vitaly Sidorov
>Assignee: Werner Punz
>Priority: Major
>
> In Chrome it is no longer possible to get a nonce with getAttribute("nonce").
> You can only use HTMLElement.nonce (see: 
> [https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/nonce)]
> Steps to reproduce:
> - set header Content-Security-Policy: script-src 'self' 'nonce-test123'
> - set  target="head"/>
> - set parameters 
> org.apache.myfaces.USE_MULTIPLE_JS_FILES_FOR_JSF_UNCOMPRESSED_JS=false and 
> javax.faces.PROJECT_STAGE=Developement
> - open page in browser and get multiple errors in console: 
> {{jsf.js.jsf?ln=javax.faces=Development:93 Refused to execute inline 
> script because it violates the following Content Security Policy directive: 
> "script-src 'self' 'nonce=test123'". Either the 'unsafe-inline' keyword, a 
> hash ('sha256-Xu6aRWi9bDVg9FaanKbn/uUSQUCsJ5g+bPB5SUYUIfk='), or a nonce 
> ('nonce-...') is required to enable inline execution.}}
> The reason:
> The error falls on .appendChild(element) in code
> {{var htmlScriptElement = document.head.appendChild(element);}}
> {{document.head.removeChild(htmlScriptElement);}}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (MYFACES-4479) The jsf.js script does not read the nonce correctly in modern browsers.

[Werner Punz (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17617048#comment-17617048
 ] 

Werner Punz commented on MYFACES-4479:
--

I have a small testcase working, which needs to be fleshed out more., following,

at the first look, I have to run the tests, your patch seems valid

 

item.getAttribute("nonce") does not work anymore

but item.nonce still returns the nonce value.

I have the same issue in my new code, respectively its underlying baselib.

I will test your pull request once my new testcase is properly integrated and 
if all is well, I will merge it tomorrow.

I also have to fix the faces_ts nextgen codebase for 4.0.

So first of all thanks for reporting the bug, this went under my radar.

 

> The jsf.js script does not read the nonce correctly in modern browsers.
> ---
>
> Key: MYFACES-4479
> URL: https://issues.apache.org/jira/browse/MYFACES-4479
> Project: MyFaces Core
>  Issue Type: Bug
>  Components: General
>Affects Versions: 2.3-next-M7
> Environment: Myfaces 2.3-next-M7
> Chrome: 106.0.5249.103
>Reporter: Vitaly Sidorov
>Assignee: Werner Punz
>Priority: Major
>
> In Chrome it is no longer possible to get a nonce with getAttribute("nonce").
> You can only use HTMLElement.nonce (see: 
> [https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/nonce)]
> Steps to reproduce:
> - set header Content-Security-Policy: script-src 'self' 'nonce-test123'
> - set  target="head"/>
> - set parameters 
> org.apache.myfaces.USE_MULTIPLE_JS_FILES_FOR_JSF_UNCOMPRESSED_JS=false and 
> javax.faces.PROJECT_STAGE=Developement
> - open page in browser and get multiple errors in console: 
> {{jsf.js.jsf?ln=javax.faces=Development:93 Refused to execute inline 
> script because it violates the following Content Security Policy directive: 
> "script-src 'self' 'nonce=test123'". Either the 'unsafe-inline' keyword, a 
> hash ('sha256-Xu6aRWi9bDVg9FaanKbn/uUSQUCsJ5g+bPB5SUYUIfk='), or a nonce 
> ('nonce-...') is required to enable inline execution.}}
> The reason:
> The error falls on .appendChild(element) in code
> {{var htmlScriptElement = document.head.appendChild(element);}}
> {{document.head.removeChild(htmlScriptElement);}}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (MYFACES-4479) The jsf.js script does not read the nonce correctly in modern browsers.

[Werner Punz (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17617036#comment-17617036
 ] 

Werner Punz commented on MYFACES-4479:
--

I will check it once I have my testcase in place.

So expect an answer from me tomorrow.

 

> The jsf.js script does not read the nonce correctly in modern browsers.
> ---
>
> Key: MYFACES-4479
> URL: https://issues.apache.org/jira/browse/MYFACES-4479
> Project: MyFaces Core
>  Issue Type: Bug
>  Components: General
>Affects Versions: 2.3-next-M7
> Environment: Myfaces 2.3-next-M7
> Chrome: 106.0.5249.103
>Reporter: Vitaly Sidorov
>Assignee: Werner Punz
>Priority: Major
>
> In Chrome it is no longer possible to get a nonce with getAttribute("nonce").
> You can only use HTMLElement.nonce (see: 
> [https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/nonce)]
> Steps to reproduce:
> - set header Content-Security-Policy: script-src 'self' 'nonce-test123'
> - set  target="head"/>
> - set parameters 
> org.apache.myfaces.USE_MULTIPLE_JS_FILES_FOR_JSF_UNCOMPRESSED_JS=false and 
> javax.faces.PROJECT_STAGE=Developement
> - open page in browser and get multiple errors in console: 
> {{jsf.js.jsf?ln=javax.faces=Development:93 Refused to execute inline 
> script because it violates the following Content Security Policy directive: 
> "script-src 'self' 'nonce=test123'". Either the 'unsafe-inline' keyword, a 
> hash ('sha256-Xu6aRWi9bDVg9FaanKbn/uUSQUCsJ5g+bPB5SUYUIfk='), or a nonce 
> ('nonce-...') is required to enable inline execution.}}
> The reason:
> The error falls on .appendChild(element) in code
> {{var htmlScriptElement = document.head.appendChild(element);}}
> {{document.head.removeChild(htmlScriptElement);}}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (MYFACES-4479) The jsf.js script does not read the nonce correctly in modern browsers.

[Werner Punz (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17617011#comment-17617011
 ] 

Werner Punz commented on MYFACES-4479:
--

I also will add a testcase for this in our integration testsuite, which is 
pending for merge.

Seems like this spec is changing a lot.

And yes newer browsers seem to break the nonce handling for security reasons, 
we probably have to take special care for that during our script evaluation.

 

> The jsf.js script does not read the nonce correctly in modern browsers.
> ---
>
> Key: MYFACES-4479
> URL: https://issues.apache.org/jira/browse/MYFACES-4479
> Project: MyFaces Core
>  Issue Type: Bug
>  Components: General
>Affects Versions: 2.3-next-M7
> Environment: Myfaces 2.3-next-M7
> Chrome: 106.0.5249.103
>Reporter: Vitaly Sidorov
>Assignee: Werner Punz
>Priority: Major
>
> In Chrome it is no longer possible to get a nonce with getAttribute("nonce").
> You can only use HTMLElement.nonce (see: 
> [https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/nonce)]
> Steps to reproduce:
> - set header Content-Security-Policy: script-src 'self' 'nonce-test123'
> - set  target="head"/>
> - set parameters 
> org.apache.myfaces.USE_MULTIPLE_JS_FILES_FOR_JSF_UNCOMPRESSED_JS=false and 
> javax.faces.PROJECT_STAGE=Developement
> - open page in browser and get multiple errors in console: 
> {{jsf.js.jsf?ln=javax.faces=Development:93 Refused to execute inline 
> script because it violates the following Content Security Policy directive: 
> "script-src 'self' 'nonce=test123'". Either the 'unsafe-inline' keyword, a 
> hash ('sha256-Xu6aRWi9bDVg9FaanKbn/uUSQUCsJ5g+bPB5SUYUIfk='), or a nonce 
> ('nonce-...') is required to enable inline execution.}}
> The reason:
> The error falls on .appendChild(element) in code
> {{var htmlScriptElement = document.head.appendChild(element);}}
> {{document.head.removeChild(htmlScriptElement);}}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (MYFACES-4479) The jsf.js script does not read the nonce correctly in modern browsers.

[Werner Punz (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17616988#comment-17616988
 ] 

Werner Punz edited comment on MYFACES-4479 at 10/13/22 12:22 PM:
-

I will have a look at it, both for the old and for the 4.0 scripts.

A fix will be available probably by tomorrow.

 


was (Author: werpu):
I will have a look at it, both for the old and for the 4.0 scripts.

 

A fix will be available probably by tomorrow.

 

> The jsf.js script does not read the nonce correctly in modern browsers.
> ---
>
> Key: MYFACES-4479
> URL: https://issues.apache.org/jira/browse/MYFACES-4479
> Project: MyFaces Core
>  Issue Type: Bug
>  Components: General
>Affects Versions: 2.3-next-M7
> Environment: Myfaces 2.3-next-M7
> Chrome: 106.0.5249.103
>Reporter: Vitaly Sidorov
>Assignee: Werner Punz
>Priority: Major
>
> In Chrome it is no longer possible to get a nonce with getAttribute("nonce").
> You can only use HTMLElement.nonce (see: 
> [https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/nonce)]
> Steps to reproduce:
> - set header Content-Security-Policy: script-src 'self' 'nonce-test123'
> - set  target="head"/>
> - set parameters 
> org.apache.myfaces.USE_MULTIPLE_JS_FILES_FOR_JSF_UNCOMPRESSED_JS=false and 
> javax.faces.PROJECT_STAGE=Developement
> - open page in browser and get multiple errors in console: 
> {{jsf.js.jsf?ln=javax.faces=Development:93 Refused to execute inline 
> script because it violates the following Content Security Policy directive: 
> "script-src 'self' 'nonce=test123'". Either the 'unsafe-inline' keyword, a 
> hash ('sha256-Xu6aRWi9bDVg9FaanKbn/uUSQUCsJ5g+bPB5SUYUIfk='), or a nonce 
> ('nonce-...') is required to enable inline execution.}}
> The reason:
> The error falls on .appendChild(element) in code
> {{var htmlScriptElement = document.head.appendChild(element);}}
> {{document.head.removeChild(htmlScriptElement);}}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (MYFACES-4479) The jsf.js script does not read the nonce correctly in modern browsers.

[Werner Punz (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17616988#comment-17616988
 ] 

Werner Punz edited comment on MYFACES-4479 at 10/13/22 11:59 AM:
-

I will have a look at it, both for the old and for the 4.0 scripts.

 

A fix will be available probably by tomorrow.

 


was (Author: werpu):
I will have a look at it, both for the old and for the 4.0 scripts.

I remember we had a similar issue before, might have been a regression which 
went in.

A fix will be available probably by tomorrow.

 

> The jsf.js script does not read the nonce correctly in modern browsers.
> ---
>
> Key: MYFACES-4479
> URL: https://issues.apache.org/jira/browse/MYFACES-4479
> Project: MyFaces Core
>  Issue Type: Bug
>  Components: General
>Affects Versions: 2.3-next-M7
> Environment: Myfaces 2.3-next-M7
> Chrome: 106.0.5249.103
>Reporter: Vitaly Sidorov
>Assignee: Werner Punz
>Priority: Major
>
> In Chrome it is no longer possible to get a nonce with getAttribute("nonce").
> You can only use HTMLElement.nonce (see: 
> [https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/nonce)]
> Steps to reproduce:
> - set header Content-Security-Policy: script-src 'self' 'nonce-test123'
> - set  target="head"/>
> - set parameters 
> org.apache.myfaces.USE_MULTIPLE_JS_FILES_FOR_JSF_UNCOMPRESSED_JS=false and 
> javax.faces.PROJECT_STAGE=Developement
> - open page in browser and get multiple errors in console: 
> {{jsf.js.jsf?ln=javax.faces=Development:93 Refused to execute inline 
> script because it violates the following Content Security Policy directive: 
> "script-src 'self' 'nonce=test123'". Either the 'unsafe-inline' keyword, a 
> hash ('sha256-Xu6aRWi9bDVg9FaanKbn/uUSQUCsJ5g+bPB5SUYUIfk='), or a nonce 
> ('nonce-...') is required to enable inline execution.}}
> The reason:
> The error falls on .appendChild(element) in code
> {{var htmlScriptElement = document.head.appendChild(element);}}
> {{document.head.removeChild(htmlScriptElement);}}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (MYFACES-4479) The jsf.js script does not read the nonce correctly in modern browsers.

[Werner Punz (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17616988#comment-17616988
 ] 

Werner Punz commented on MYFACES-4479:
--

I will have a look at it, both for the old and for the 4.0 scripts.

I remember we had a similar issue before, might have been a regression which 
went in.

A fix will be available probably by tomorrow.

 

> The jsf.js script does not read the nonce correctly in modern browsers.
> ---
>
> Key: MYFACES-4479
> URL: https://issues.apache.org/jira/browse/MYFACES-4479
> Project: MyFaces Core
>  Issue Type: Bug
>  Components: General
>Affects Versions: 2.3-next-M7
> Environment: Myfaces 2.3-next-M7
> Chrome: 106.0.5249.103
>Reporter: Vitaly Sidorov
>Priority: Major
>
> In Chrome it is no longer possible to get a nonce with getAttribute("nonce").
> You can only use HTMLElement.nonce (see: 
> [https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/nonce)]
> Steps to reproduce:
> - set header Content-Security-Policy: script-src 'self' 'nonce-test123'
> - set  target="head"/>
> - set parameters 
> org.apache.myfaces.USE_MULTIPLE_JS_FILES_FOR_JSF_UNCOMPRESSED_JS=false and 
> javax.faces.PROJECT_STAGE=Developement
> - open page in browser and get multiple errors in console: 
> {{jsf.js.jsf?ln=javax.faces=Development:93 Refused to execute inline 
> script because it violates the following Content Security Policy directive: 
> "script-src 'self' 'nonce=test123'". Either the 'unsafe-inline' keyword, a 
> hash ('sha256-Xu6aRWi9bDVg9FaanKbn/uUSQUCsJ5g+bPB5SUYUIfk='), or a nonce 
> ('nonce-...') is required to enable inline execution.}}
> The reason:
> The error falls on .appendChild(element) in code
> {{var htmlScriptElement = document.head.appendChild(element);}}
> {{document.head.removeChild(htmlScriptElement);}}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: faces_ts integration tests

[Werner Punz]

Regarding my mail, never mind, I now have write access. I missed the
linking step of linking both accounts, when I registered
into id.apache.org

Problem solved now.

Werner


Am Mi., 12. Okt. 2022 um 08:23 Uhr schrieb Werner Punz <
werner.p...@gmail.com>:

> Hi regarding the plan.
> Following: I would merge those tests the same time I will merge the new
> scripts which will be around RC3 as current status.
> The reason is, one of the tests (the api decoration test) fails on the old
> codebase after the namespace renaming.
>
> Given we are on our way out regarding the old codebase, it does not make
> sense to fix this anymore.
> If there is a need for it for the RC2 then I can do it, but as you can
> guess, I could spend the time elsewhere better.
>
> For now the tests run against the github version of the Ajax code (via npm
> include)
> but at the final merge I will target it towards our embedded scripts.
> (imports.xhtml, has the includes, you can redirect it yourself, have been
> testing the embedded version constantly via custom builds
> from my 4456 feature branch)
>
> I did this so that the build is not broken if the integration tests are
> triggered.
> If that is ok with you guys, we will postpone the merge until we take
> everything in.
>
> Also, I have a small infrastructural problem. I usually committed over
> Gitlab, I cannot see a merge button for my pull requests on github, despite
> having my username entered into my github settings on my apache account.
> Does anyone know what the problem could be?
> (my github account does not target my apache address, but my normal mail,
> so I thought, adding it in the apache account settings should suffice)
>
>
>
> Am Di., 11. Okt. 2022 um 11:34 Uhr schrieb Werner Punz <
> werner.p...@gmail.com>:
>
>> I just dropped a pull request on the 20 integration tests:
>> https://github.com/apache/myfaces/pull/331
>>
>> The tests run automatically from the maven build as usual, but thing is,
>> 19 tests more than before but no aquilian (mocha and and embedded tomcat is
>> used now)
>>
>> I pulled the old ajax tests, because there was nothing, which is not
>> covered by the new tests.
>> Also it is now way easier to write tests, with less code.
>> readme.md is included which explains everything in more detail
>>
>>
>> Am Fr., 7. Okt. 2022 um 13:23 Uhr schrieb Melloware <
>> melloware...@gmail.com>:
>>
>>> For me the more unit tests the better no matter what the technology :)
>>>
>>>
>>> On 10/7/2022 7:15 AM, Werner Punz wrote:
>>>
>>> Hi thanks, then I will prepare a pull request. Expect it early/mid next
>>> week.
>>> You still can decide whether you want to take it in or not, then.
>>>
>>> Werner
>>>
>>>
>>>
>>> Am Fr., 7. Okt. 2022 um 13:04 Uhr schrieb Melloware <
>>> melloware...@gmail.com>:
>>>
>>>> I am totally find without Arquillian as well.
>>>>
>>>>
>>>> On 10/7/2022 6:54 AM, Udo Schnurpfeil wrote:
>>>>
>>>> For me it's fine without Arquilian
>>>>
>>>> Udo
>>>> Am 07.10.22 um 09:56 schrieb Werner Punz:
>>>>
>>>> Hi, given I have not gotten any answer!
>>>> Do you guys want the tests within MyFaces or is Arquilian an absolute
>>>> must?
>>>>
>>>>
>>>> Werner
>>>>
>>>>
>>>> Am Do., 6. Okt. 2022 um 16:22 Uhr schrieb Werner Punz <
>>>> werner.p...@gmail.com>:
>>>>
>>>>> Hi,
>>>>> I just wanted to get feedback on the following:
>>>>> Atm we have a barebones Ajax integration test in our integration test
>>>>> system, derived from my github based integration testsuite.
>>>>> Problem is
>>>>> a) It is barebones, and basically just the basic tests, which is
>>>>> mostly test 1 of my suite, also it needs lots of code for maintenance.
>>>>> b) The current aquilian installation makes problems ( have not spent
>>>>> too much time fixing this, i just filed a bugreport for now)
>>>>> c) The new codebase uses already a ton of mocha based unit tests on ts
>>>>> level
>>>>>
>>>>> I have my own set of atm 19 integration tests, which I run against my
>>>>> codebase. The issue is, that this testcase uses mocha in the pages to
>>>>> collect the test data and to run the tests with a well known api.
>>>>> And in the backend

Re: faces_ts integration tests

[Werner Punz]

Hi regarding the plan.
Following: I would merge those tests the same time I will merge the new
scripts which will be around RC3 as current status.
The reason is, one of the tests (the api decoration test) fails on the old
codebase after the namespace renaming.

Given we are on our way out regarding the old codebase, it does not make
sense to fix this anymore.
If there is a need for it for the RC2 then I can do it, but as you can
guess, I could spend the time elsewhere better.

For now the tests run against the github version of the Ajax code (via npm
include)
but at the final merge I will target it towards our embedded scripts.
(imports.xhtml, has the includes, you can redirect it yourself, have been
testing the embedded version constantly via custom builds
from my 4456 feature branch)

I did this so that the build is not broken if the integration tests are
triggered.
If that is ok with you guys, we will postpone the merge until we take
everything in.

Also, I have a small infrastructural problem. I usually committed over
Gitlab, I cannot see a merge button for my pull requests on github, despite
having my username entered into my github settings on my apache account.
Does anyone know what the problem could be?
(my github account does not target my apache address, but my normal mail,
so I thought, adding it in the apache account settings should suffice)



Am Di., 11. Okt. 2022 um 11:34 Uhr schrieb Werner Punz <
werner.p...@gmail.com>:

> I just dropped a pull request on the 20 integration tests:
> https://github.com/apache/myfaces/pull/331
>
> The tests run automatically from the maven build as usual, but thing is,
> 19 tests more than before but no aquilian (mocha and and embedded tomcat is
> used now)
>
> I pulled the old ajax tests, because there was nothing, which is not
> covered by the new tests.
> Also it is now way easier to write tests, with less code.
> readme.md is included which explains everything in more detail
>
>
> Am Fr., 7. Okt. 2022 um 13:23 Uhr schrieb Melloware <
> melloware...@gmail.com>:
>
>> For me the more unit tests the better no matter what the technology :)
>>
>>
>> On 10/7/2022 7:15 AM, Werner Punz wrote:
>>
>> Hi thanks, then I will prepare a pull request. Expect it early/mid next
>> week.
>> You still can decide whether you want to take it in or not, then.
>>
>> Werner
>>
>>
>>
>> Am Fr., 7. Okt. 2022 um 13:04 Uhr schrieb Melloware <
>> melloware...@gmail.com>:
>>
>>> I am totally find without Arquillian as well.
>>>
>>>
>>> On 10/7/2022 6:54 AM, Udo Schnurpfeil wrote:
>>>
>>> For me it's fine without Arquilian
>>>
>>> Udo
>>> Am 07.10.22 um 09:56 schrieb Werner Punz:
>>>
>>> Hi, given I have not gotten any answer!
>>> Do you guys want the tests within MyFaces or is Arquilian an absolute
>>> must?
>>>
>>>
>>> Werner
>>>
>>>
>>> Am Do., 6. Okt. 2022 um 16:22 Uhr schrieb Werner Punz <
>>> werner.p...@gmail.com>:
>>>
>>>> Hi,
>>>> I just wanted to get feedback on the following:
>>>> Atm we have a barebones Ajax integration test in our integration test
>>>> system, derived from my github based integration testsuite.
>>>> Problem is
>>>> a) It is barebones, and basically just the basic tests, which is mostly
>>>> test 1 of my suite, also it needs lots of code for maintenance.
>>>> b) The current aquilian installation makes problems ( have not spent
>>>> too much time fixing this, i just filed a bugreport for now)
>>>> c) The new codebase uses already a ton of mocha based unit tests on ts
>>>> level
>>>>
>>>> I have my own set of atm 19 integration tests, which I run against my
>>>> codebase. The issue is, that this testcase uses mocha in the pages to
>>>> collect the test data and to run the tests with a well known api.
>>>> And in the backend a server is running providing beans and response.
>>>> The test results are collected client side.
>>>>
>>>> Given the troubles I had with Aquilian, I have extended my codebase on
>>>> Github so that the tests automatically run with an embedded chrome via the
>>>> maven frontend plugin
>>>> and also the frontend plugin hooks the test results into the maven build
>>>> So basically internally maven starts an embedded tomcat viay the exec
>>>> plugin and the frontend plugin pushes an embedded windowless chrome against
>>>> this code to run the tests and collect the results, and

[jira] [Commented] (MYFACES-4478) namespace bug for faces 4.0 and composite components

[Werner Punz (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17615709#comment-17615709
 ] 

Werner Punz commented on MYFACES-4478:
--

Reproducible example: Checkout 
[https://github.com/werpu/myfaces-js-integrationtests/tree/MYFACES-4478]

 

and run the server via: clean clean install -DskipTests exec:java -Pstandalone 
-f pom.xml

You can expose the bug via: 
[http://localhost:8080/IntegrationJSTest/integrationtestsjasmine/test1-protocol-4478.jsf]

while calling: 
[http://localhost:8080/IntegrationJSTest/integrationtestsjasmine/test1-protocol.jsf]
 works.

The first case uses the faces namespace to reference the composite component, 
the second case uses the jcp namespace.

 

> namespace bug for faces 4.0 and composite components
> 
>
> Key: MYFACES-4478
> URL: https://issues.apache.org/jira/browse/MYFACES-4478
> Project: MyFaces Core
>  Issue Type: Bug
>  Components: General
>Affects Versions: 3.0.0-RC1
> Environment: normal servlet environment
>Reporter: Werner Punz
>Priority: Minor
>
> Composite Components atm only work in the 
> [http://xmlns.jcp.org/jsf/composite/] namespace but not in the 
> jakarta.faces.composite namespace, as required per Faces 4.0 spec.
>  
> I will link an example in a later comment once setup which shows this behavior
> a composite component hostet under webapp/resources is found in the jcp 
> namespace but not in the new jakarta faces namespace, so: 
> components="jakarta.faces.composite/components" produces following error:
>  * Warning: The page /integrationtestsjasmine/test1-protocol.xhtml declares 
> namespace jakarta.faces.composite/components and uses the tag 
> components:jasmineTest , but no TagLibrary associated to namespace.
> on
>  
> http://www.w3.org/1999/xhtml;
> xmlns:h="jakarta.faces.html"
> xmlns:ui="jakarta.faces.facelets"
> xmlns:components="jakarta.faces.composite/components"
> >
>  
> 
> The namespace 
> http://www.w3.org/1999/xhtml;
> xmlns:h="jakarta.faces.html"
> xmlns:ui="jakarta.faces.facelets"
> xmlns:components="http://xmlns.jcp.org/jsf/composite/components;
> >
>  
> Produces no error.
>  
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (MYFACES-4478) namespace bug for faces 4.0 and composite components

[Werner Punz (Jira)]

Werner Punz created MYFACES-4478:


 Summary: namespace bug for faces 4.0 and composite components
 Key: MYFACES-4478
 URL: https://issues.apache.org/jira/browse/MYFACES-4478
 Project: MyFaces Core
  Issue Type: Bug
  Components: General
Affects Versions: 3.0.0-RC1
 Environment: normal servlet environment
Reporter: Werner Punz


Composite Components atm only work in the 

[http://xmlns.jcp.org/jsf/composite/] namespace but not in the 

jakarta.faces.composite namespace, as required per Faces 4.0 spec.

 

I will link an example in a later comment once setup which shows this behavior


a composite component hostet under webapp/resources is found in the jcp 
namespace but not in the new jakarta faces namespace, so: 

components="jakarta.faces.composite/components" produces following error:
 * Warning: The page /integrationtestsjasmine/test1-protocol.xhtml declares 
namespace jakarta.faces.composite/components and uses the tag 
components:jasmineTest , but no TagLibrary associated to namespace.

on

 

http://www.w3.org/1999/xhtml;
xmlns:h="jakarta.faces.html"
xmlns:ui="jakarta.faces.facelets"
xmlns:components="jakarta.faces.composite/components"
>

 



The namespace 

http://www.w3.org/1999/xhtml;
xmlns:h="jakarta.faces.html"
xmlns:ui="jakarta.faces.facelets"
xmlns:components="http://xmlns.jcp.org/jsf/composite/components;
>

 

Produces no error.

 

 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: faces_ts integration tests

[Werner Punz]

I just dropped a pull request on the 20 integration tests:
https://github.com/apache/myfaces/pull/331

The tests run automatically from the maven build as usual, but thing is, 19
tests more than before but no aquilian (mocha and and embedded tomcat is
used now)

I pulled the old ajax tests, because there was nothing, which is not
covered by the new tests.
Also it is now way easier to write tests, with less code.
readme.md is included which explains everything in more detail


Am Fr., 7. Okt. 2022 um 13:23 Uhr schrieb Melloware :

> For me the more unit tests the better no matter what the technology :)
>
>
> On 10/7/2022 7:15 AM, Werner Punz wrote:
>
> Hi thanks, then I will prepare a pull request. Expect it early/mid next
> week.
> You still can decide whether you want to take it in or not, then.
>
> Werner
>
>
>
> Am Fr., 7. Okt. 2022 um 13:04 Uhr schrieb Melloware <
> melloware...@gmail.com>:
>
>> I am totally find without Arquillian as well.
>>
>>
>> On 10/7/2022 6:54 AM, Udo Schnurpfeil wrote:
>>
>> For me it's fine without Arquilian
>>
>> Udo
>> Am 07.10.22 um 09:56 schrieb Werner Punz:
>>
>> Hi, given I have not gotten any answer!
>> Do you guys want the tests within MyFaces or is Arquilian an absolute
>> must?
>>
>>
>> Werner
>>
>>
>> Am Do., 6. Okt. 2022 um 16:22 Uhr schrieb Werner Punz <
>> werner.p...@gmail.com>:
>>
>>> Hi,
>>> I just wanted to get feedback on the following:
>>> Atm we have a barebones Ajax integration test in our integration test
>>> system, derived from my github based integration testsuite.
>>> Problem is
>>> a) It is barebones, and basically just the basic tests, which is mostly
>>> test 1 of my suite, also it needs lots of code for maintenance.
>>> b) The current aquilian installation makes problems ( have not spent too
>>> much time fixing this, i just filed a bugreport for now)
>>> c) The new codebase uses already a ton of mocha based unit tests on ts
>>> level
>>>
>>> I have my own set of atm 19 integration tests, which I run against my
>>> codebase. The issue is, that this testcase uses mocha in the pages to
>>> collect the test data and to run the tests with a well known api.
>>> And in the backend a server is running providing beans and response.
>>> The test results are collected client side.
>>>
>>> Given the troubles I had with Aquilian, I have extended my codebase on
>>> Github so that the tests automatically run with an embedded chrome via the
>>> maven frontend plugin
>>> and also the frontend plugin hooks the test results into the maven build
>>> So basically internally maven starts an embedded tomcat viay the exec
>>> plugin and the frontend plugin pushes an embedded windowless chrome against
>>> this code to run the tests and collect the results, and reports them back
>>> to Maven
>>> in the integration test phase
>>> ...
>>> [INFO]
>>> http://localhost:8080/IntegrationJSTest/integrationtestsjasmine/test10-doubleeval.jsf
>>> [INFO] Page test10-doubleeval Successes:
>>> [INFO] => Regression test for double eval on a single script element
>>> [INFO] => Runs the double eval test
>>> [INFO] ✔ double evaluation of embedded scripts testcase (281ms)
>>> [INFO]
>>> http://localhost:8080/IntegrationJSTest/integrationtestsjasmine/test11-scriptblocks.jsf
>>> [INFO] Page test11-scriptblocks Successes:
>>> [INFO] => Script blocks in various formats
>>> [INFO] => Performs a script bloc test
>>> ...
>>>
>>> [INFO] => Execute none handling
>>> [INFO] => SPEC HAS NO EXPECTATIONS runs an execute request with execute
>>> @none
>>> [INFO] ✔ execute parameter test (281ms)
>>> [INFO]
>>> [INFO]
>>> [INFO]   19 passing (23s)
>>> [INFO]
>>> [INFO]
>>> [INFO] --- maven-failsafe-plugin:2.12:verify (default) @
>>> IntegrationJSTest ---
>>>
>>> This how it looks if all tests have passed
>>>
>>> or in case of a failure:
>>> [INFO]   18 passing (23s)
>>> [INFO]   1 failing
>>> [INFO]
>>> [INFO]   1) Integration Testsuite MyFaces
>>> [INFO]testing viewRoot:
>>> [INFO]
>>> [INFO]   AssertionError: expected false to be true
>>> [INFO]   + expected - actual
>>> [INFO]
>>> [INFO]   -false
>>> [INFO]   +true
>>> [INFO]
>>> [INFO]   at Context.

[jira] [Created] (MYFACES-4476) Integration of the full integration testsuite for faces.js from github

[Werner Punz (Jira)]

Werner Punz created MYFACES-4476:


 Summary: Integration of the full integration testsuite for 
faces.js from github
 Key: MYFACES-4476
 URL: https://issues.apache.org/jira/browse/MYFACES-4476
 Project: MyFaces Core
  Issue Type: New Feature
  Components: General
Affects Versions: 4.0.0-RC2
Reporter: Werner Punz
Assignee: Werner Punz


We have a set of 20 integration tests against the faces.js codebase on github.

This testuite was one of my cornerstones for fortifying the old and new 
implementation.

The problem was it used homegrown testing frameworks. I now have moved all the 
tests to npm and mocha with an embedded chrome as testrunner. The project on 
github has everything integrated into maven and starts its own embedded tomcat 
during testing.

It bypasses Arquilian entirely (results in less code because less java code is 
involved).

After questioning the mailing list whether myfaces wants the test suite, they 
agreed to wanting them.

I will move the code over to myfaces and then issue a pull request for further 
discussion.

 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [VOTE] Release Tobago 5.3.0 and checkstyle-rules 19

[Werner Punz]

+1

Werner


Am Mo., 10. Okt. 2022 um 12:06 Uhr schrieb Henning Nöth <
henning.no...@irian.eu>:

> +1
>
> Am 07.10.22 um 17:35 schrieb Udo Schnurpfeil:
> > Hello,
> >
> > we would like to release:
> > * Tobago 5.3.0
> > * checkstyle-rules 19
> >
> > The artifacts were deployed on nexus repository for binary and source
> > packages:
> > * Tobago 5.3.0 & checkstyle-rules 19 [1]
> >
> > The release notes are in Jira:
> > * Tobago 5.3.0 [2]
> >
> > The artifacts are available at the staging repository (Nexus) at:
> >
> > * Tobago 5.3.0 [3] (sha-256
> > 689f3bd11deef4e758d5c07f7eaa78bba93192a64b5d8f06c61af52d0fe2e83c)
> > * checkstyle-rules 19 [4] (sha-256
> > fd086c62bfecc5dd41ae7ef76e97907c7dace35c4984ece9bd1db194971176af)
> >
> > Please vote now! (The vote is open for 72h.)
> >
> > [ ] +1
> > [ ] +0
> > [ ] -1
> >
> > Regards,
> >
> > Udo
> >
> > [1]
> > https://repository.apache.org/content/repositories/orgapachemyfaces-1212
> > [2] https://issues.apache.org/jira/projects/TOBAGO/versions/12350747
> > [3]
> >
> https://repository.apache.org/content/repositories/orgapachemyfaces-1212/org/apache/myfaces/tobago/tobago/5.3.0/tobago-5.3.0-source-release.zip
> > [4]
> >
> https://repository.apache.org/content/repositories/orgapachemyfaces-1212/org/apache/myfaces/buildtools/checkstyle-rules/19/checkstyle-rules-19-source-release.zip
> >
>

Re: faces_ts integration tests

[Werner Punz]

Hi thanks, then I will prepare a pull request. Expect it early/mid next
week.
You still can decide whether you want to take it in or not, then.

Werner



Am Fr., 7. Okt. 2022 um 13:04 Uhr schrieb Melloware :

> I am totally find without Arquillian as well.
>
>
> On 10/7/2022 6:54 AM, Udo Schnurpfeil wrote:
>
> For me it's fine without Arquilian
>
> Udo
> Am 07.10.22 um 09:56 schrieb Werner Punz:
>
> Hi, given I have not gotten any answer!
> Do you guys want the tests within MyFaces or is Arquilian an absolute must?
>
>
> Werner
>
>
> Am Do., 6. Okt. 2022 um 16:22 Uhr schrieb Werner Punz <
> werner.p...@gmail.com>:
>
>> Hi,
>> I just wanted to get feedback on the following:
>> Atm we have a barebones Ajax integration test in our integration test
>> system, derived from my github based integration testsuite.
>> Problem is
>> a) It is barebones, and basically just the basic tests, which is mostly
>> test 1 of my suite, also it needs lots of code for maintenance.
>> b) The current aquilian installation makes problems ( have not spent too
>> much time fixing this, i just filed a bugreport for now)
>> c) The new codebase uses already a ton of mocha based unit tests on ts
>> level
>>
>> I have my own set of atm 19 integration tests, which I run against my
>> codebase. The issue is, that this testcase uses mocha in the pages to
>> collect the test data and to run the tests with a well known api.
>> And in the backend a server is running providing beans and response.
>> The test results are collected client side.
>>
>> Given the troubles I had with Aquilian, I have extended my codebase on
>> Github so that the tests automatically run with an embedded chrome via the
>> maven frontend plugin
>> and also the frontend plugin hooks the test results into the maven build
>> So basically internally maven starts an embedded tomcat viay the exec
>> plugin and the frontend plugin pushes an embedded windowless chrome against
>> this code to run the tests and collect the results, and reports them back
>> to Maven
>> in the integration test phase
>> ...
>> [INFO]
>> http://localhost:8080/IntegrationJSTest/integrationtestsjasmine/test10-doubleeval.jsf
>> [INFO] Page test10-doubleeval Successes:
>> [INFO] => Regression test for double eval on a single script element
>> [INFO] => Runs the double eval test
>> [INFO] ✔ double evaluation of embedded scripts testcase (281ms)
>> [INFO]
>> http://localhost:8080/IntegrationJSTest/integrationtestsjasmine/test11-scriptblocks.jsf
>> [INFO] Page test11-scriptblocks Successes:
>> [INFO] => Script blocks in various formats
>> [INFO] => Performs a script bloc test
>> ...
>>
>> [INFO] => Execute none handling
>> [INFO] => SPEC HAS NO EXPECTATIONS runs an execute request with execute
>> @none
>> [INFO] ✔ execute parameter test (281ms)
>> [INFO]
>> [INFO]
>> [INFO]   19 passing (23s)
>> [INFO]
>> [INFO]
>> [INFO] --- maven-failsafe-plugin:2.12:verify (default) @
>> IntegrationJSTest ---
>>
>> This how it looks if all tests have passed
>>
>> or in case of a failure:
>> [INFO]   18 passing (23s)
>> [INFO]   1 failing
>> [INFO]
>> [INFO]   1) Integration Testsuite MyFaces
>> [INFO]testing viewRoot:
>> [INFO]
>> [INFO]   AssertionError: expected false to be true
>> [INFO]   + expected - actual
>> [INFO]
>> [INFO]   -false
>> [INFO]   +true
>> [INFO]
>> [INFO]   at Context.
>> (src/main/webapp/resources/myfaces.testscripts/integrationtestrunner_frontend/integrationtests.spec.js:75:28)
>> [INFO]   at processTicksAndRejections
>> (node:internal/process/task_queues:96:5)
>> [INFO]
>> [INFO]
>> [INFO]
>> [INFO]
>> 
>> [INFO] BUILD FAILURE
>> [INFO]
>> 
>>
>> The config is as follows:
>>
>> The advantage is that the tests are now way easier to write and hook
>> themselves perfectly into the client side unit test system.
>>
>> Next advantage you also can run the tests directly in your browser and
>> you also can show a browser instead of an headless embedded chrome.
>>
>> We also would get 17-18 additional integration tests "for free" in the
>> myfaces codebase, simply because I have them already written a long time
>> ago.
>> The disadvantage is (whether this really is one) we bypass Aqulian in
>> favor of the frontend plugin node and mocha.
>>
>> I have this system working now, but as usual would perform another round
>> of cleanups before merging it into myfaces, after the RC3 jsf_ts merge.
>> So what´s your opinion, shall we add those tests to the codebase? I do
>> not have any problem, to leave them where they are, they work fine for my
>> purposes.
>>
>>
>> Werner
>>
>>
>>

Re: faces_ts integration tests

[Werner Punz]

Hi, given I have not gotten any answer!
Do you guys want the tests within MyFaces or is Arquilian an absolute must?


Werner


Am Do., 6. Okt. 2022 um 16:22 Uhr schrieb Werner Punz :

> Hi,
> I just wanted to get feedback on the following:
> Atm we have a barebones Ajax integration test in our integration test
> system, derived from my github based integration testsuite.
> Problem is
> a) It is barebones, and basically just the basic tests, which is mostly
> test 1 of my suite, also it needs lots of code for maintenance.
> b) The current aquilian installation makes problems ( have not spent too
> much time fixing this, i just filed a bugreport for now)
> c) The new codebase uses already a ton of mocha based unit tests on ts
> level
>
> I have my own set of atm 19 integration tests, which I run against my
> codebase. The issue is, that this testcase uses mocha in the pages to
> collect the test data and to run the tests with a well known api.
> And in the backend a server is running providing beans and response.
> The test results are collected client side.
>
> Given the troubles I had with Aquilian, I have extended my codebase on
> Github so that the tests automatically run with an embedded chrome via the
> maven frontend plugin
> and also the frontend plugin hooks the test results into the maven build
> So basically internally maven starts an embedded tomcat viay the exec
> plugin and the frontend plugin pushes an embedded windowless chrome against
> this code to run the tests and collect the results, and reports them back
> to Maven
> in the integration test phase
> ...
> [INFO]
> http://localhost:8080/IntegrationJSTest/integrationtestsjasmine/test10-doubleeval.jsf
> [INFO] Page test10-doubleeval Successes:
> [INFO] => Regression test for double eval on a single script element
> [INFO] => Runs the double eval test
> [INFO] ✔ double evaluation of embedded scripts testcase (281ms)
> [INFO]
> http://localhost:8080/IntegrationJSTest/integrationtestsjasmine/test11-scriptblocks.jsf
> [INFO] Page test11-scriptblocks Successes:
> [INFO] => Script blocks in various formats
> [INFO] => Performs a script bloc test
> ...
>
> [INFO] => Execute none handling
> [INFO] => SPEC HAS NO EXPECTATIONS runs an execute request with execute
> @none
> [INFO] ✔ execute parameter test (281ms)
> [INFO]
> [INFO]
> [INFO]   19 passing (23s)
> [INFO]
> [INFO]
> [INFO] --- maven-failsafe-plugin:2.12:verify (default) @ IntegrationJSTest
> ---
>
> This how it looks if all tests have passed
>
> or in case of a failure:
> [INFO]   18 passing (23s)
> [INFO]   1 failing
> [INFO]
> [INFO]   1) Integration Testsuite MyFaces
> [INFO]testing viewRoot:
> [INFO]
> [INFO]   AssertionError: expected false to be true
> [INFO]   + expected - actual
> [INFO]
> [INFO]   -false
> [INFO]   +true
> [INFO]
> [INFO]   at Context.
> (src/main/webapp/resources/myfaces.testscripts/integrationtestrunner_frontend/integrationtests.spec.js:75:28)
> [INFO]   at processTicksAndRejections
> (node:internal/process/task_queues:96:5)
> [INFO]
> [INFO]
> [INFO]
> [INFO]
> 
> [INFO] BUILD FAILURE
> [INFO]
> 
>
> The config is as follows:
>
> The advantage is that the tests are now way easier to write and hook
> themselves perfectly into the client side unit test system.
>
> Next advantage you also can run the tests directly in your browser and you
> also can show a browser instead of an headless embedded chrome.
>
> We also would get 17-18 additional integration tests "for free" in the
> myfaces codebase, simply because I have them already written a long time
> ago.
> The disadvantage is (whether this really is one) we bypass Aqulian in
> favor of the frontend plugin node and mocha.
>
> I have this system working now, but as usual would perform another round
> of cleanups before merging it into myfaces, after the RC3 jsf_ts merge.
> So what´s your opinion, shall we add those tests to the codebase? I do not
> have any problem, to leave them where they are, they work fine for my
> purposes.
>
>
> Werner
>
>
>

faces_ts integration tests

[Werner Punz]

Hi,
I just wanted to get feedback on the following:
Atm we have a barebones Ajax integration test in our integration test
system, derived from my github based integration testsuite.
Problem is
a) It is barebones, and basically just the basic tests, which is mostly
test 1 of my suite, also it needs lots of code for maintenance.
b) The current aquilian installation makes problems ( have not spent too
much time fixing this, i just filed a bugreport for now)
c) The new codebase uses already a ton of mocha based unit tests on ts level

I have my own set of atm 19 integration tests, which I run against my
codebase. The issue is, that this testcase uses mocha in the pages to
collect the test data and to run the tests with a well known api.
And in the backend a server is running providing beans and response.
The test results are collected client side.

Given the troubles I had with Aquilian, I have extended my codebase on
Github so that the tests automatically run with an embedded chrome via the
maven frontend plugin
and also the frontend plugin hooks the test results into the maven build
So basically internally maven starts an embedded tomcat viay the exec
plugin and the frontend plugin pushes an embedded windowless chrome against
this code to run the tests and collect the results, and reports them back
to Maven
in the integration test phase
...
[INFO]
http://localhost:8080/IntegrationJSTest/integrationtestsjasmine/test10-doubleeval.jsf
[INFO] Page test10-doubleeval Successes:
[INFO] => Regression test for double eval on a single script element
[INFO] => Runs the double eval test
[INFO] ✔ double evaluation of embedded scripts testcase (281ms)
[INFO]
http://localhost:8080/IntegrationJSTest/integrationtestsjasmine/test11-scriptblocks.jsf
[INFO] Page test11-scriptblocks Successes:
[INFO] => Script blocks in various formats
[INFO] => Performs a script bloc test
...

[INFO] => Execute none handling
[INFO] => SPEC HAS NO EXPECTATIONS runs an execute request with execute
@none
[INFO] ✔ execute parameter test (281ms)
[INFO]
[INFO]
[INFO]   19 passing (23s)
[INFO]
[INFO]
[INFO] --- maven-failsafe-plugin:2.12:verify (default) @ IntegrationJSTest
---

This how it looks if all tests have passed

or in case of a failure:
[INFO]   18 passing (23s)
[INFO]   1 failing
[INFO]
[INFO]   1) Integration Testsuite MyFaces
[INFO]testing viewRoot:
[INFO]
[INFO]   AssertionError: expected false to be true
[INFO]   + expected - actual
[INFO]
[INFO]   -false
[INFO]   +true
[INFO]
[INFO]   at Context.
(src/main/webapp/resources/myfaces.testscripts/integrationtestrunner_frontend/integrationtests.spec.js:75:28)
[INFO]   at processTicksAndRejections
(node:internal/process/task_queues:96:5)
[INFO]
[INFO]
[INFO]
[INFO]

[INFO] BUILD FAILURE
[INFO]


The config is as follows:

The advantage is that the tests are now way easier to write and hook
themselves perfectly into the client side unit test system.

Next advantage you also can run the tests directly in your browser and you
also can show a browser instead of an headless embedded chrome.

We also would get 17-18 additional integration tests "for free" in the
myfaces codebase, simply because I have them already written a long time
ago.
The disadvantage is (whether this really is one) we bypass Aqulian in favor
of the frontend plugin node and mocha.

I have this system working now, but as usual would perform another round of
cleanups before merging it into myfaces, after the RC3 jsf_ts merge.
So what´s your opinion, shall we add those tests to the codebase? I do not
have any problem, to leave them where they are, they work fine for my
purposes.


Werner

Re: JSF.js TS commit ready in myfaces 4.0

[Werner Punz]

Hi just some updates, I have check the integration tests, they do not work
atm infrastructurewise, however
they should work theoretically once the test infrastructure is debugged
(aquilian seems to have some issues atm)
https://issues.apache.org/jira/browse/MYFACES-4473

The thing is, I just ran a test against our node based unit tests and they
seem to run fine. The maven frontend plugin seems to terminate correctly
on failures in unit tests:
here is an example:

it('initializable', () => {
const lang = Lang;
expect(false).to.be.true('must be true');
expect(lang).to.exist;
});


As result i get from the maven build:
NFO]   135 passing (2s)
[INFO]   1 failing
[INFO]
[INFO]   1) Lang tests
[INFO]initializable:
[INFO]
[INFO]   AssertionError: expected false to be true
[INFO]   + expected - actual

INFO]

[INFO] BUILD FAILURE
[INFO]

[INFO] Total time:  30.855 s
[INFO] Finished at: 2022-10-05T15:16:47+02:00
[INFO]

[ERROR] Failed to execute goal
com.github.eirslett:frontend-maven-plugin:1.12.1:npm (npm run test) on
project myfaces-api: Failed to run task: 'npm run test' failed.
org.apache.commons.exec.ExecuteException: Process exited with an error: 1
(Exit value: 1) -> [Help 1]

So I am positively surprised.

The aquilian tests for ajax basically do not really trigger our
implementation, they return a fake response from a servlet but cause a ton
of java code to produce the response xml.
It is easy just to proxy the response and let everything run on the client.

Either way, Just wanted to open a discussion here.


Werner




Am Fr., 30. Sept. 2022 um 08:08 Uhr schrieb Werner Punz <
werner.p...@gmail.com>:

> So next steps: While you guys now can review the code and test it.
>
> I will overhaul my internal integration tests to reduce the remnants of
> the old framework code and make the code better.
>
> After that I will tackle the internal myfaces js integration tests which
> atm are defunct.
> For now not having integration tests are safe, because we test with Tobago
> and, I now have 136 unit tests in place in conjunction with my own publicly
> github hosted integration tests, but this should not be a permanent
> solution.
>
> Werner
>
>
> Am Do., 29. Sept. 2022 um 14:00 Uhr schrieb Werner Punz <
> werner.p...@gmail.com>:
>
>> Thanks, pull request is now in place,
>> https://github.com/apache/myfaces/pull/325
>> please review and test!
>>
>>
>> Werner
>>
>>
>> Am Do., 29. Sept. 2022 um 13:33 Uhr schrieb Werner Punz <
>> werner.p...@gmail.com>:
>>
>>> Yes thats even better.
>>> I will issue a pull request, I think thats the best idea for now.
>>> I will go this route then.
>>>
>>> Werner
>>>
>>>
>>> Am Do., 29. Sept. 2022 um 13:31 Uhr schrieb Melloware <
>>> melloware...@gmail.com>:
>>>
>>>> Yep why not just submit a PR in a feature branch so we can code review
>>>> it on GitHub like a normal PR?
>>>>
>>>> On 9/29/2022 5:57 AM, Werner Punz wrote:
>>>> > Hi I wrote it before, but in the never ending list of replies it went
>>>> > under.
>>>> > I am basically commit-ready for the updated code. I will skip the
>>>> work
>>>> > on the integration tests now
>>>> > given they do not work atm anyway due to dependency issues and they
>>>> > are based on my working github ones anyway.
>>>> > (I will revisit this part next week)
>>>> >
>>>> > However, given that I did a ton of changes in the resource loaders,
>>>> > dropped literally all old files, changed the pom quite a bit and
>>>> > introduced
>>>> > the maven client plugin which triggers node, instead of running
>>>> > straight maven plugins, I would love to have a proper review and
>>>> > testing from the community, before merging.
>>>> > So my proposal is, I will push the changes for now into a feature
>>>> > branch, if possible, so that anyone can test the build and the new
>>>> > codebase who wants to, and after a period of feedback time when
>>>> > everyone is happy we merge it into the 4.0 release candidates.
>>>> >
>>>> >
>>>> > Any comments on that?
>>>> >
>>>> > Werner
>>>> >
>>>> >
>>>>
>>>
Am Fr., 30. Sept. 2022 um 08:08 Uh

[jira] [Created] (MYFACES-4473) Integration Tests dependency issue

[Werner Punz (Jira)]

Werner Punz created MYFACES-4473:


 Summary: Integration Tests dependency issue
 Key: MYFACES-4473
 URL: https://issues.apache.org/jira/browse/MYFACES-4473
 Project: MyFaces Core
  Issue Type: Bug
Affects Versions: 4.0.0-RC1
 Environment: Java 11
Reporter: Werner Punz


The integration tests atm, have a problem with a servlet implementation coming 
in, not reflecting the actual layer.

SCHWERWIEGEND: Servlet.service() for servlet [FacesServlet] in context with 
path [/ajax-4.0.0-SNAPSHOT] threw exception ['java.lang.String 
jakarta.servlet.SessionCookieConfig.getAttribute(java.lang.String)'] with root 
cause
java.lang.NoSuchMethodError: 'java.lang.String 
jakarta.servlet.SessionCookieConfig.getAttribute(java.lang.String)'
    at 
org.apache.myfaces.context.flash.FlashImpl._createFlashCookie(FlashImpl.java:1194)
    at 
org.apache.myfaces.context.flash.FlashImpl._saveRenderFlashMapTokenForNextRequest(FlashImpl.java:774)
    at 
org.apache.myfaces.context.flash.FlashImpl._manageFlashMapTokens(FlashImpl.java:889)
    at 
org.apache.myfaces.context.flash.FlashImpl.doPrePhaseActions(FlashImpl.java:197)
    at 
org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:155)
    at 
org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:125)
    at jakarta.faces.webapp.FacesServlet.service(FacesServlet.java:223)

 

The called api is present, but somewhere still an old servlet impl is pushed 
into the container.

I have tried to upgrade to tomcat embedded 10, no dice. The api is correctly 
referenced though and I can see it from the ide.

My idea is that Aquilian might push an old servlet definition in during runtime.

Also the currently used Aquilian is incompatible with the latest jdks. (Proxy 
mechanism, which is used causes errors on the latest jdk)

I am still searching where the issue stems from, but so far no luck on my side.

 

 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (MYFACES-4471) java.lang.NullPointerException at org.apache.myfaces.cdi.util.AbstractContextualStorageHolder.destroyAll(AbstractContextualStorageHolder.java:201)

[Werner Punz (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17612584#comment-17612584
 ] 

Werner Punz edited comment on MYFACES-4471 at 10/4/22 12:13 PM:


For this issue, no.

Some else can take over it. I never did anything in the ViewState handling area.

A simple check for an incoming null fixed it, but given that probably a wrong 
state internally is referenced, this needs to be fixed on a higher level.

(aka a state number was coming in, wich did not exist anymore)


was (Author: werpu):
For this issue, no.

Some else can take over it. I never did anything in the ViewState handling area.

 

> java.lang.NullPointerException at 
> org.apache.myfaces.cdi.util.AbstractContextualStorageHolder.destroyAll(AbstractContextualStorageHolder.java:201)
> --
>
> Key: MYFACES-4471
> URL: https://issues.apache.org/jira/browse/MYFACES-4471
> Project: MyFaces Core
>  Issue Type: Bug
>  Components: General
>Affects Versions: 4.0.0-RC2
> Environment: Java 9 or higher, MyFaces 4.0 main branch (snapshot) 
> before RC2
>Reporter: Werner Punz
>Priority: Major
>
> During my integration testing for the new scripts I ran into this issue.
> It seems that some viewstate "pointers" are not cleared up properly in my 
> test case, and reference after a while state entries which have dropped out 
> of the state history.
> The problem is not related to my scripts, because the same test works for jsf 
> 2.3 flawlessly with the same scripts and a 2.3 shim. So the Javascript code 
> executed is the same.
> Reproducible: 
> [https://github.com/werpu/myfaces-js-integrationtests/tree/faces_40_viestate_bug]
> then run the project via  mvn clean clean install exec:java -f pom.xml
> then point your browser to: 
> [http://localhost:8080/IntegrationJSTest/loop/test8-navcase1.jsf?autoTest=true]
>  
>  
> or follow the link to the loop navigation test in the index.html
> The test case performs an implicit Ajax navigation by sending a faces.request 
> execute on a command link, which triggers the navigation.
> Note, only the command link is sent as execute not the entire form, but the 
> entire form is refreshed.
>  
> Let it run, after roughly a minute you should get following error:
>  
> java.lang.NullPointerException
> viewId=/loop/test8-navcase1.xhtml
> location=/Users/werpu2/development/workspace/myfaces-js-integrationtests/src/main/webapp/loop/test8-navcase1.xhtml
> phaseId=RENDER_RESPONSE(6)
> Caused by:
> java.lang.NullPointerException
> at 
> org.apache.myfaces.cdi.util.AbstractContextualStorageHolder.destroyAll(AbstractContextualStorageHolder.java:201)
>  
> Stack Trace:
> {{java.lang.NullPointerException
> at 
> org.apache.myfaces.cdi.util.AbstractContextualStorageHolder.destroyAll(AbstractContextualStorageHolder.java:201)
> at 
> org.apache.myfaces.cdi.util.AbstractContextualStorageHolder.destroyAll(AbstractContextualStorageHolder.java:242)
> at 
> org.apache.myfaces.cdi.view.ViewScopeContextualStorageHolder$Proxy$_$$_WeldClientProxy.destroyAll(Unknown
>  Source)
> at 
> org.apache.myfaces.cdi.view.ViewScopeContext.destroyAll(ViewScopeContext.java:202)
> at 
> org.apache.myfaces.application.viewstate.SerializedViewCollection.lambda$put$1(SerializedViewCollection.java:71)
> at 
> org.apache.myfaces.application.viewstate.SerializedViewCollection.put(SerializedViewCollection.java:228)
> at 
> org.apache.myfaces.application.viewstate.SerializedViewCollection.put(SerializedViewCollection.java:70)
> at 
> org.apache.myfaces.application.viewstate.StateCacheServerSide.saveSerializedViewInSession(StateCacheServerSide.java:196)
> at 
> org.apache.myfaces.application.viewstate.StateCacheServerSide.saveSerializedView(StateCacheServerSide.java:465)
> at 
> org.apache.myfaces.renderkit.html.HtmlResponseStateManager.saveState(HtmlResponseStateManager.java:107)
> at 
> org.apache.myfaces.view.facelets.PartialStateManagementStrategy.saveView(PartialStateManagementStrategy.java:794)
> at 
> org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage.renderView(FaceletViewDeclarationLanguage.java:1854)
> at 
> org.apache.myfaces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:316)
> at 
> jakarta.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:74)
> at 
> org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:122)
> a

[jira] [Commented] (MYFACES-4471) java.lang.NullPointerException at org.apache.myfaces.cdi.util.AbstractContextualStorageHolder.destroyAll(AbstractContextualStorageHolder.java:201)

[Werner Punz (Jira)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17612584#comment-17612584
 ] 

Werner Punz commented on MYFACES-4471:
--

For this issue, no.

Some else can take over it. I never did anything in the ViewState handling area.

 

> java.lang.NullPointerException at 
> org.apache.myfaces.cdi.util.AbstractContextualStorageHolder.destroyAll(AbstractContextualStorageHolder.java:201)
> --
>
> Key: MYFACES-4471
> URL: https://issues.apache.org/jira/browse/MYFACES-4471
> Project: MyFaces Core
>  Issue Type: Bug
>  Components: General
>Affects Versions: 4.0.0-RC2
> Environment: Java 9 or higher, MyFaces 4.0 main branch (snapshot) 
> before RC2
>Reporter: Werner Punz
>Priority: Major
>
> During my integration testing for the new scripts I ran into this issue.
> It seems that some viewstate "pointers" are not cleared up properly in my 
> test case, and reference after a while state entries which have dropped out 
> of the state history.
> The problem is not related to my scripts, because the same test works for jsf 
> 2.3 flawlessly with the same scripts and a 2.3 shim. So the Javascript code 
> executed is the same.
> Reproducible: 
> [https://github.com/werpu/myfaces-js-integrationtests/tree/faces_40_viestate_bug]
> then run the project via  mvn clean clean install exec:java -f pom.xml
> then point your browser to: 
> [http://localhost:8080/IntegrationJSTest/loop/test8-navcase1.jsf?autoTest=true]
>  
>  
> or follow the link to the loop navigation test in the index.html
> The test case performs an implicit Ajax navigation by sending a faces.request 
> execute on a command link, which triggers the navigation.
> Note, only the command link is sent as execute not the entire form, but the 
> entire form is refreshed.
>  
> Let it run, after roughly a minute you should get following error:
>  
> java.lang.NullPointerException
> viewId=/loop/test8-navcase1.xhtml
> location=/Users/werpu2/development/workspace/myfaces-js-integrationtests/src/main/webapp/loop/test8-navcase1.xhtml
> phaseId=RENDER_RESPONSE(6)
> Caused by:
> java.lang.NullPointerException
> at 
> org.apache.myfaces.cdi.util.AbstractContextualStorageHolder.destroyAll(AbstractContextualStorageHolder.java:201)
>  
> Stack Trace:
> {{java.lang.NullPointerException
> at 
> org.apache.myfaces.cdi.util.AbstractContextualStorageHolder.destroyAll(AbstractContextualStorageHolder.java:201)
> at 
> org.apache.myfaces.cdi.util.AbstractContextualStorageHolder.destroyAll(AbstractContextualStorageHolder.java:242)
> at 
> org.apache.myfaces.cdi.view.ViewScopeContextualStorageHolder$Proxy$_$$_WeldClientProxy.destroyAll(Unknown
>  Source)
> at 
> org.apache.myfaces.cdi.view.ViewScopeContext.destroyAll(ViewScopeContext.java:202)
> at 
> org.apache.myfaces.application.viewstate.SerializedViewCollection.lambda$put$1(SerializedViewCollection.java:71)
> at 
> org.apache.myfaces.application.viewstate.SerializedViewCollection.put(SerializedViewCollection.java:228)
> at 
> org.apache.myfaces.application.viewstate.SerializedViewCollection.put(SerializedViewCollection.java:70)
> at 
> org.apache.myfaces.application.viewstate.StateCacheServerSide.saveSerializedViewInSession(StateCacheServerSide.java:196)
> at 
> org.apache.myfaces.application.viewstate.StateCacheServerSide.saveSerializedView(StateCacheServerSide.java:465)
> at 
> org.apache.myfaces.renderkit.html.HtmlResponseStateManager.saveState(HtmlResponseStateManager.java:107)
> at 
> org.apache.myfaces.view.facelets.PartialStateManagementStrategy.saveView(PartialStateManagementStrategy.java:794)
> at 
> org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage.renderView(FaceletViewDeclarationLanguage.java:1854)
> at 
> org.apache.myfaces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:316)
> at 
> jakarta.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:74)
> at 
> org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:122)
> at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:241)
> at jakarta.faces.webapp.FacesServlet.service(FacesServlet.java:225)
> at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:223)
> at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:158)
> at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:

[jira] [Commented] (TOBAGO-2158) Use jsf-development.js in development environments

[Werner Punz (Jira)]

[ 
https://issues.apache.org/jira/browse/TOBAGO-2158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17612578#comment-17612578
 ] 

Werner Punz commented on TOBAGO-2158:
-

Already implemented for MyFaces in my pull request. Also i enabled the mapping 
files accordingly, see my pull request comments, you might take an idea or 2 
from there.

 

> Use jsf-development.js in development environments
> --
>
> Key: TOBAGO-2158
> URL: https://issues.apache.org/jira/browse/TOBAGO-2158
> Project: MyFaces Tobago
>  Issue Type: Improvement
>  Components: Themes
>Affects Versions: 5.2.0
>Reporter: Henning Nöth
>Assignee: Henning Nöth
>Priority: Minor
>
> The "jsf.js_next_gen" Dependency provide a "jsf.js" and a 
> "jsf-development.js".
> We should use the "jsf-development.js" in development environments.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: Bug?

[Werner Punz]

Bugreport filed against RC2, thanks everyone for answering.


Am Di., 4. Okt. 2022 um 11:55 Uhr schrieb Werner Punz :

> Good news is, all my other tests seem to run stable in an endless loop. So
> I must have triggered an absolute corner case here.
>
> Werner
>
>
> Am Di., 4. Okt. 2022 um 11:53 Uhr schrieb Werner Punz <
> werner.p...@gmail.com>:
>
>> So I have finally narrowed down the issue.
>>
>> I am issuing an implicit nav case via faces.ajax and an execute on the
>> command link triggering it, which seems to make the viewstate go haywire,
>> my assumption is that the viewscope references are not properly cleared up
>> and then after some repetitions we run out of the view history and
>> reference data which has dropped out already.
>>
>> I will file a bugreport once I have the testcase fully isolated. Btw. in
>> myfaces 2.3 the problem does not occur with the same ajax script base (jsf
>> 2.3 shim on top of the faces 4.0 scripts), so I can rule out my script
>> doing something nasty with the viewstates.
>>
>>
>>
>> Am Mo., 3. Okt. 2022 um 16:28 Uhr schrieb Werner Punz <
>> werner.p...@gmail.com>:
>>
>>> Seems like one of my tests is triggering this race condition (have been
>>> running 4 tests in an endless loop without geting it). I will try to narrow
>>> it down tomorrow and then will issue a bugreport.
>>> My guess is we have a corner condition where the viewstate might not get
>>> cleaned up entirely.
>>>
>>>
>>> Am Mo., 3. Okt. 2022 um 15:08 Uhr schrieb Werner Punz <
>>> werner.p...@gmail.com>:
>>>
>>>> I am trying but the error is very erratic unfortunately.
>>>>
>>>>
>>>> Am Mo., 3. Okt. 2022 um 15:05 Uhr schrieb Melloware <
>>>> melloware...@gmail.com>:
>>>>
>>>>> Werner, if you can isolate it please open a JIRA ticket with the stack
>>>>> trace and the info please!
>>>>>
>>>>>
>>>>> On 10/3/2022 8:59 AM, Werner Punz wrote:
>>>>>
>>>>> Got a little bit further, the null stems from a referenced viewstate
>>>>> id, which does not exist anymore in the viewstate map.
>>>>> The thing is, that when I trigger the page sequence manually I do not
>>>>> run into this. With automation i run into it on a random scale.
>>>>> This looks almost like some kind of race condition to me.
>>>>>
>>>>> I have a problem giving a testreport on it, given i cannot fully
>>>>> isolate the issue for now to a reproducible case.
>>>>>
>>>>>
>>>>> Am Mo., 3. Okt. 2022 um 14:07 Uhr schrieb Werner Punz <
>>>>> werner.p...@gmail.com>:
>>>>>
>>>>>> Hi I am running into a weird bug in my integration testing.
>>>>>> Following I have built a stack of MyFaces 4.0 with weld as beans
>>>>>> provider and I am getting an NPE sometimes (not reproducible after a
>>>>>> refresh in) AbstractContext.destroyAll(contextualStorage, facesStorage)
>>>>>>
>>>>>> The problem seems to be that that contextualStorage comes in as null
>>>>>> and there is no null check. The weird thing is, that after a full page
>>>>>> reload the error is gone.
>>>>>> I suspect a bug on the myfaces or Weld side for this case.
>>>>>> I null check would fix this, but I am not sure whether there is a
>>>>>> deeper bug in there.
>>>>>>
>>>>>> Can anyone who has more insight in this area comment?
>>>>>>
>>>>>> Cheers
>>>>>>
>>>>>> Werner
>>>>>>
>>>>>>

[jira] [Created] (MYFACES-4471) java.lang.NullPointerException at org.apache.myfaces.cdi.util.AbstractContextualStorageHolder.destroyAll(AbstractContextualStorageHolder.java:201)

[Werner Punz (Jira)]

Werner Punz created MYFACES-4471:


 Summary: java.lang.NullPointerException at 
org.apache.myfaces.cdi.util.AbstractContextualStorageHolder.destroyAll(AbstractContextualStorageHolder.java:201)
 Key: MYFACES-4471
 URL: https://issues.apache.org/jira/browse/MYFACES-4471
 Project: MyFaces Core
  Issue Type: Bug
  Components: General
Affects Versions: 4.0.0-RC2
 Environment: Java 9 or higher, MyFaces 4.0 main branch (snapshot) 
before RC2
Reporter: Werner Punz


During my integration testing for the new scripts I ran into this issue.

It seems that some context "pointers" are not cleared up properly in my 
testcase and reference after a while context entries which have dropped out of 
the state history.

The problem is not related to my scripts, because the same test works for jsf 
2.3 flawlessly with the same scripts and a 2.3 shim. So the javascript code 
executed is the same.

Reproducible: 

https://github.com/werpu/myfaces-js-integrationtests/tree/faces_40_viestate_bug

then run the project via  mvn clean clean install exec:java -f pom.xml

then point your browser to: 
[http://localhost:8080/IntegrationJSTest/loop/test8-navcase1.jsf?autoTest=true]

 

or follow the link to the loop navigation test in the index.html

Let it run, after roughly a minute you should get following error:

 

java.lang.NullPointerException

viewId=/loop/test8-navcase1.xhtml
location=/Users/werpu2/development/workspace/myfaces-js-integrationtests/src/main/webapp/loop/test8-navcase1.xhtml
phaseId=RENDER_RESPONSE(6)

Caused by:
java.lang.NullPointerException
at 
org.apache.myfaces.cdi.util.AbstractContextualStorageHolder.destroyAll(AbstractContextualStorageHolder.java:201)

 

Stack Trace:

{{java.lang.NullPointerException
at 
org.apache.myfaces.cdi.util.AbstractContextualStorageHolder.destroyAll(AbstractContextualStorageHolder.java:201)
at 
org.apache.myfaces.cdi.util.AbstractContextualStorageHolder.destroyAll(AbstractContextualStorageHolder.java:242)
at 
org.apache.myfaces.cdi.view.ViewScopeContextualStorageHolder$Proxy$_$$_WeldClientProxy.destroyAll(Unknown
 Source)
at 
org.apache.myfaces.cdi.view.ViewScopeContext.destroyAll(ViewScopeContext.java:202)
at 
org.apache.myfaces.application.viewstate.SerializedViewCollection.lambda$put$1(SerializedViewCollection.java:71)
at 
org.apache.myfaces.application.viewstate.SerializedViewCollection.put(SerializedViewCollection.java:228)
at 
org.apache.myfaces.application.viewstate.SerializedViewCollection.put(SerializedViewCollection.java:70)
at 
org.apache.myfaces.application.viewstate.StateCacheServerSide.saveSerializedViewInSession(StateCacheServerSide.java:196)
at 
org.apache.myfaces.application.viewstate.StateCacheServerSide.saveSerializedView(StateCacheServerSide.java:465)
at 
org.apache.myfaces.renderkit.html.HtmlResponseStateManager.saveState(HtmlResponseStateManager.java:107)
at 
org.apache.myfaces.view.facelets.PartialStateManagementStrategy.saveView(PartialStateManagementStrategy.java:794)
at 
org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage.renderView(FaceletViewDeclarationLanguage.java:1854)
at 
org.apache.myfaces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:316)
at 
jakarta.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:74)
at 
org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:122)
at 
org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:241)
at jakarta.faces.webapp.FacesServlet.service(FacesServlet.java:225)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:223)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:158)
at 
org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:53)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:185)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:158)
at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:197)
at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:97)
at 
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:542)
at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:119)
at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:92)
at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:78)
at 
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:357)
at 
org.apache.coyote.http11.Http11Process