Fix for WebView.EvaluateJavaScriptAsync fails to execute JavaScript containing newline characters

[praveenkumarkarunanithi]

Root Cause

The EvaluateJavaScriptAsync method did not account for multi-line JavaScript strings containing newline characters (\r\n, \r, \n). These newline characters caused script execution issues on platforms like Windows (WebView2) and iOS (WKWebView), either silently failing to execute or throwing runtime exceptions due to unprocessed newline characters in the script string.

Description of Change

The JavaScript string is now normalized by replacing all newline characters (\r\n, \r, \n) with a space before execution. This ensures consistent behavior and compatibility across platforms.

Issues Fixed

Fixes #11905

Tested the behaviour in the following platforms

• Android
• Windows
• iOS
• Mac

Screenshots

Before Issue Fix	After Issue Fix

[dotnet-policy-service]

Hey there @@praveenkumarkarunanithi! Thank you so much for your PR! Someone from the team will get assigned to your PR shortly and we'll get it reviewed.

[MartyIX]

What does happen when there is javascript code: var myString = "<NEWLINE HERE>"; console.log(myString);? It would be nice to have such a test.

[praveenkumarkarunanithi]

@MartyIX , Our fix replaces literal newline characters with spaces to ensure JavaScript executes properly across all platforms. JavaScript string escape sequences (like \n) are not affected since they're represented differently in code:
string jsWithEscapeSequence = "var myString = '\\n';";
since standard practice is to use \n escape sequences to represent newlines in strings,most real-world code won't be affected.

[MartyIX]

My point I wanted to make was simply: Your PR can modify original behavior of user's JavaScript code. I believe it should be mentioned in the PR description. If it is acceptable or not, is not up to me. I just want to make sure it's explicitly acknowledged.

[MartyIX]

btw: #29139 was merged to the inflight branch yesterday. Would it make sense to test against that branch if your workaround is still needed?

I'm basically very interested what causes that on Windows you observe "silent failure". Do you possibly know where the limitation come from? Or what is buggy?

[mattleibow]

This PR should land after #27528

But, as @MartyIX says, newlines may have meaning in the context of JS. For example, they use backtics to represent the multi line strings:

let poll = `Is .NET MAUI cool?
- Yes!
- Yes!
- Yes!
Wow, so it is!
`
console.log(poll);

as well as backslashes:

let poll = 'Is .NET MAUI cool? \n\
- Yes! \n\
- Yes! \n\
- Yes! \n\
Wow, so it is! \n\
'
console.log(poll);

We need to add tets for these as well.

[praveenkumarkarunanithi]

This PR should land after #27528

But, as @MartyIX says, newlines may have meaning in the context of JS. For example, they use backtics to represent the multi line strings:

let poll = `Is .NET MAUI cool?
- Yes!
- Yes!
- Yes!
Wow, so it is!
`
console.log(poll);

as well as backslashes:

let poll = 'Is .NET MAUI cool? \n\
- Yes! \n\
- Yes! \n\
- Yes! \n\
Wow, so it is! \n\
'
console.log(poll);

We need to add tets for these as well.

@mattleibow , I've optimized the fix to handle both scenarios you mentioned:
Template literals with backticks for multiline strings
Backslash line continuations with embedded \n escape sequences
I've added test cases for both scenarios in WebViewHelperTests.cs to verify proper handling. The implementation correctly preserves JavaScript string semantics while ensuring proper escaping for WebView evaluation.

As recommended, I've worked these changes on top of PR #27528 and updated this PR to include those changes. This approach ensures my PR can be smoothly merged after PR #27528 is completed.

[MartyIX]

FYI: I opened this issue for Windows' WebView: MicrosoftEdge/WebView2Feedback#5288. The thing is that this

maui/src/Controls/src/Core/WebView/WebView.cs

Line 136 in 5b82faa

script = "try{eval('" + script + "')}catch(e){'null'};";

should not be necessary for Windows based on WebView2 documentation:

A function that has no explicit return value returns undefined. If the script that was run throws an unhandled exception, then the result is also null. This method is applied asynchronously. If the method is run after the NavigationStarting event during a navigation, the script runs in the new document when loading it, around the time ContentLoading is run. This operation works even if IsScriptEnabled is set to false.

(Emphasis mine)

Sadly, this is not how it work in practice. Anyway, we will see what the guys will say -- either there is a bug in the documentation or in the product.