You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've noticed that if I have a feature or folder beginning with the character 'x' when I try to view a html report generated on Windows nothing is displayed.
I've narrowed the problem down to be in the generation of report.js. When using Ubuntu or OS X the file separator is '/' and in the report.js there is the following for example:
Leaving the index.html displaying a blank page. It seems to be treating the "\x" as an escape sequence for URIs leading to a malformed URI exception in the browser.I also found a Stack Overflow post of someone having a similar problem with the 'u' character.
By the time writeToJsReport is called the parameter 'arg' already has the file separator for the given OS in the string so to quickly check that the backslashes are really the problem I modified the method to look like this:
Hi,
I've noticed that if I have a feature or folder beginning with the character 'x' when I try to view a html report generated on Windows nothing is displayed.
I've narrowed the problem down to be in the generation of report.js. When using Ubuntu or OS X the file separator is '/' and in the report.js there is the following for example:
formatter.uri('MavenCucumber**/**xHelloWorld.feature');
The html report displays fine. Switch over to Windows and the file separator of '' results in following ending up in report.js
formatter.uri('MavenCucumber**\x**HelloWorld.feature');
Leaving the index.html displaying a blank page. It seems to be treating the "\x" as an escape sequence for URIs leading to a malformed URI exception in the browser.I also found a Stack Overflow post of someone having a similar problem with the 'u' character.
By the time writeToJsReport is called the parameter 'arg' already has the file separator for the given OS in the string so to quickly check that the backslashes are really the problem I modified the method to look like this:
And as a result the html report displays correctly on Windows. There is probably a better place to fix this though.
The text was updated successfully, but these errors were encountered: