WDA 4.7.0 and below did not return `\n` but 4.8.0+ returned `\n` in a label

The problem

[updated] A new line in XML is expected.

<element id>/text endpoint returned line break\nline break with \n result since https://github.com/appium/WebDriverAgent/pull/596, while the same one returned line break line break without \n before the change.

@driver.find_element :xpath, "//XCUIElementTypeStaticText[@name='line break line break']" responded the element in both version, WDA 4.7.0 (before the PR) and 4.8.0 (with the PR). @driver.find_element :xpath, "//XCUIElementTypeStaticText[@name='line break\nline break']" did not even 4.8.0 since the XML source did not have \n as below.

The description format by vanilla XCTest had \n like label: 'line break\nline break' in both versions, so potentially https://github.com/appium/WebDriverAgent/pull/596 fixed this behavior(?), but in the case, our XML source did not include \n, so find an element

The below two lines line break is this issue.

The page source in JSON is below with WDA 4.7.0 and 4.8.0.

                                      {
                                        "isEnabled" : "1",
                                        "isVisible" : "1",
                                        "isAccessible" : "1",
                                        "frame" : "{{76, 402}, {238, 32}}",
                                        "rect" : {
                                          "y" : 402,
                                          "x" : 76,
                                          "width" : 238,
                                          "height" : 32
                                        },
                                        "value" : "line break line break",
                                        "label" : "line break line break",
                                        "type" : "StaticText",
                                        "name" : "line break line break",
                                        "rawIdentifier" : null
                                      }
                                    ],

NSPredicate like @driver.find_element :predicate,"label == 'line break\\nline break'" found the element in both 4.7.0 and 4.8.0, thus as iOS, with \n has been correct way, I assume. (@driver.find_element :predicate,"label == 'line break line break'" did not find the element.)

So… a text with a new line behavior changed since 4.8.0, and kind of mixed after the PR in the page source and XML stuff. I have’t still figure out the fix yet, but maybe it would be nice to follow with \n as a breaking change in the WDA to make the behavior as same as vanilla XCTest. Then, we should update the XML page source to include it properly(?).

In my investigation so far, the difference comes from self.label in https://github.com/appium/WebDriverAgent/blob/master/WebDriverAgentLib/Categories/XCUIElement%2BFBWebDriverAttributes.m#L83 . 4.7.0 returned line break line break (without \n) while 4.8.0 returned line break\nline break. po result is:

4.7.0

(lldb) po label
line break line break

4.8.0

(lldb) po label
line break
line break

Environment

• Appium version (or git revision) that exhibits the issue: WDA 4.8.0
• Last Appium version that did not exhibit the issue (if applicable): WDA 4.7.0
• Desktop OS/version used to run Appium:
• Node.js version (unless using Appium.app|exe): nodejs 16
• Npm or Yarn package manager: npm
• Mobile platform/version under test: ios 15.5 in my env, but this may happen other versions as well. Xcode was 13.4.
• Real device or emulator/simulator: both
• Appium CLI or Appium.app|exe:

Link to Appium logs

Code To Reproduce Issue [ Good To Have ]

You can find this new lines text in iOSWebView.app.zip (a sample app for simulator). SPECIAL CHARACTERS -> \n LINE BREAK -> then, the alert prepare

[mykola-mokhnach]

Should we dig deeper to see if we can preserve the previous behavior? Or - since the result is more in line with Vanilla XCTest - should we keep the change as is?

I’d say we keep it, but that should be mentioned in docs

[mykola-mokhnach]

My proposal would be to replace 0x09 with \t, 0x0A with \n and 0x0D with \r in the XML (and thus in xpath queries) to avoid unnecessary confusions

Currently these are represented as 	, 
, 
 respectively