Different SelectItem textContent behavior in 8.2 and 8.3

[ESherbakova]

Hi,

We observe a behavior change for calling the selenium.getText() method on the picklist record of a SelectItem in 8.2p and 8.3p. In 8.3p, we got an extra "/"(screenReaderCellSeparator?), which fails our test cases.

We are using v8.2p_2013-03-04 and v8.3p_2013-06-03. This issue can be reproduced on both IE9 and FF12 in Feature Explorer with the following code.

Steps to reproduce:

1. Click the picker icon to show the picklist of the selectItem.
2. We can check the extra "/" by either
a) directly check the html element of a record. For example if we inspect the third record "--Select One--", in 8.3p, we get "<nobr id=""> --- Select One --- <div style="overflow:hidden;width:0px;height:0px;">/</div></nobr>" while in 8.2p we only get "<nobr>--- Select One ---</nobr>"
b) calling isc.AutoTest.getElement().textContent with the locator of the picklist record in the isc console. For example, if we call "isc.AutoTest.getElement("//DynamicForm[ID=\"GridLayout_cw\"]/item[title=%3Cnobr%3ECase%20Select%20Space%26nbsp%3B%3C%24fs%24nobr%3E||index=0||Class=SelectItem]/pickList/body/row[name=Empty||2]/col[fieldName=name||0]").textContent", in 8.3 it gives "--- Select One ---/" but in 8.2 it gives "--- Select One ---".

This issue also happens on selectItem/textItem in ListGrid but we suspect it might be caused by the same reason as this example.

Thanks!

isc.screenReader = true;

isc.DynamicForm.create({
    ID:"GridLayout_cw",
    titleOrientation:"top",
    fields:
		[{title:"<nobr>Case Select Space&nbsp;<\/nobr>",
         width:"100",
         vAlign:"bottom",
         ID:"TT18510",
         allowEmptyValue:true,
         _constructor:"SelectItem",
         emptyDisplayValue:"--- Select One ---",
         valueMap: {"NormData1":"Norm Data 1","Empty":"","NormData2":"Norm Data 2","Space":"     "}}
        ]
})

[ESherbakova]

Hi,

This issue blocks our upgrade progress. Any response would be appreciated!

Thanks!

[Isomorphic]

This is currently under investigation. We'll let you know when we have more information.

Regards
Isomorphic Software

[Isomorphic]

We've made the screenReaderCellSeparator a public property, customizable at the ListGrid level.
You should be able to get things working by disabling it, via a call to

isc.ListGrid.addProperties({
    screenReaderCellSeparator:null
});

Regards
Isomorphic Software

[ESherbakova]

Thanks for the solution!

We are just wondering on which build we can apply the customization? Will it be on tonight's build? Tried on June 9th build, seems it's not been there yet. Thanks!

[Isomorphic]

Ah - it was implemented in 9.0d but not yet ported to 8.3p
We've copied it across. Please try the next nightly build

Regards
Isomorphic Software

[acarur01]

Just wondering how many more of these will need to be done? We've had to modify our code a few times now in order to get the new build running as it did with 8.2. Doesn't this show some backward compatibility issues to you? Or are these changes so small that only our team have to deal with it? Changes such as modifying the default behavior would make our customer uncomfortable with updating to the latest release of our product unless it is absolutely necessary. Not attacking, just curious. I'm sure there is a perfectly good reason why.

[acarur01]

Also, what is screenReaderCellSeparator used for? Will it break other cases if we set it to null? What was the purpose of it being set to '/' by default in the first place?

[Isomorphic]

The screenReaderCellSeparator is an accessibility feature requested by a customer. It has no effect when screenReaderMode is not enabled.
ListGrid keyboard navigation is of course per-row. ScreenReaders will read the entire focussed row when the user moves from row to row. The exact style in which the row is read can potentially vary depending on which ScreenReader you're using / configuration of the screenReader, but we have encountered the entire row being read with no break between cells, which can difficult to understand. The cellSeparator acts as a way to explicitly delimit cells with a customizeable character - by default a "/", making it obvious where one cell value ends and the next begins, even if a screenReader reads the entire row at a time.
Since your Selenium test is looking at the content text of the cell DOM element, it also picks up this separator. By disabling the feature you will get the same DOM content, and so your tests will run (but the tradeoff is that you lose the new feature). This should be fine for you since you can disable the feature in your automated tests only, if required, and leave it enabled for your deployment, if you want to take advantage of it.

In terms of your more general question about backwards compatibility - we take backwards compatibility very seriously across releases. Wherever possibly behavior will be unchanged, assuming you are using explicitly documented / supported APIs.
There may be cases where default behavior does change of course. The addition of new features may (for example) change the UI - adding elements, etc. Fixing broken behavior (bug fixes), will also change how the system behaves. These are standard considerations that would apply when upgrading versions of any software system, and we do attempt to include details of major changes in the release notes for a build. We also usually provide configuration options for most subsystems, meaning you can almost always turn off new features if so desired.

One other note: we make no guarantee of backwards compatibility for undocumented APIs, and we also don't guarantee that the DOM structure created by the framework will be unchanged.
In fact the HTML we write out varies by browser and by doctype within a release as we paper over native browser differences to give a consisten user experience.

You were somewhat unlucky to run into trouble with this particular change. It's a feature that changes the generated HTML in screenReader mode only, and in a way that is essentially invisible to end users. You happened to hit it because you're looking at the raw HTML content text within your selenium test. It's not something we'd really consider a back-compat breakage in the normal sense, but of course it broke you so when you brought it to our attention we provided a solution as quickly as we could.

Hopefully this answers your question. Upgrading any software system will of course require some testing, but in general we design SmartClient versions to be as backwards compatible as possible.

Regards
Isomorphic Software