[TIMOB-26791] Windows: Ti.UI.View reports top/left/bottom/right values as Strings always
| GitHub Issue | n/a |
| Type | Bug |
| Priority | Medium |
| Status | Closed |
| Resolution | Fixed |
| Resolution Date | 2019-05-09T01:36:08.000+0000 |
| Affected Version/s | Release 8.0.0 |
| Fix Version/s | Release 8.1.0 |
| Components | Windows |
| Labels | n/a |
| Reporter | Christopher Williams |
| Assignee | Kota Iguchi |
| Created | 2019-02-01T18:57:56.000+0000 |
| Updated | 2019-05-09T01:36:08.000+0000 |
Description
I'm in the process of updating our test suite to use the latest should.js library, which now uses a stricter equality check. As a result, the tests are now flagging a number of windows UI tests as failing due to comparisons against expected numeric values. (the comparison used to do == but now do === so won't coerce to Number)
Turns out we're reporting string values for top/left/right/bottom always on Windows where we report Numbers on Android/iOS. The properties themselves are Number or String, so Strings can be valid but would typically be reported when followed by the "unit" (i.e. "px", "em", "%").
For parity's sake, I think it'd be good to report the values as Numbers when they're purely numeric/have no units explicitly attached.
Attachments
so far, looks like these properties have this issue: - Ti.UI.View.top - Ti.UI.View.left - Ti.UI.View.right - Ti.UI.View.bottom - Ti.UI.View.center.x - Ti.UI.View.center.y - Ti.UI.View.height - Font.fontSize I assume Ti.UI.View.width also has this issue? Note that Ti.UI.rect properties are Numbers correctly.
https://github.com/appcelerator/titanium_mobile_windows/pull/1370
FR Passed, waiting on Jenkins.
Merged to master.