[jira] [Updated] (WEEX-217) WXTransform should not crash while parsing 'translate(0)' on iOS
[ https://issues.apache.org/jira/browse/WEEX-217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gabriel Li updated WEEX-217: Description: According to the latest published W3C specification about [CSS Transforms|https://www.w3.org/TR/css-transforms-1/)]: {code:java} translate() = translate( [, ]? ) specifies a 2D translation by the vector [tx, ty], where tx is the first translation-value parameter and ty is the optional second translation-value parameter. If is not provided, ty has zero as a value. {code} , _translate(tx)_ is equal to _translate(tx, 0)_. In the previous _version of Weex_, we removed the array length check in method [WXTransform parseTranslate:] {code:java} - (void)parseTranslate:(NSArray *)value { [self parseTranslatex:@[value[0]]]; [self parseTranslatey:@[value[1]]]; }{code} so if the parser encounters a '_translate(0)_', the array contains only one single value inside, parseTranslate will fetch the element at index 1 from the array, which causes a typical _out-of-bounds_ exception, and lead to an app crash eventually. As we known in many js packing procedures, '_translate(x, 0)_' will be compressed/minified to the form 'translate\(x\)', Weex should avoid such inconsistent implementations and conforms the W3C specifications. was: According to the latest published W3C specification about [CSS Transforms|https://www.w3.org/TR/css-transforms-1/)]: {code:java} translate() = translate( [, ]? ) specifies a 2D translation by the vector [tx, ty], where tx is the first translation-value parameter and ty is the optional second translation-value parameter. If is not provided, ty has zero as a value. {code} , _translate(tx)_ is equal to _translate(tx, 0)_. In the previous _version of Weex_, we removed the array length check in method [WXTransform parseTranslate:] {code:java} - (void)parseTranslate:(NSArray *)value { [self parseTranslatex:@[value[0]]]; [self parseTranslatey:@[value[1]]]; }{code} so if the parser encounters a '_translate(0)_', the array contains only one single value inside, parseTranslate will fetch the element at index 1 from the array, which causes a typical _out-of-bounds_ exception, and lead to an app crash eventually. As we known in many js packing procedures, '_translate(x, 0)_' will be compressed/minified to the form 'translate(x)', Weex should avoid such inconsistent implementations and conforms the W3C specifications. > WXTransform should not crash while parsing 'translate(0)' on iOS > > > Key: WEEX-217 > URL: https://issues.apache.org/jira/browse/WEEX-217 > Project: Weex > Issue Type: Bug > Components: iOS >Reporter: Gabriel Li >Assignee: Adam Feng >Priority: Major > Labels: crash, css, translate > Original Estimate: 1h > Remaining Estimate: 1h > > According to the latest published W3C specification about [CSS > Transforms|https://www.w3.org/TR/css-transforms-1/)]: > {code:java} > translate() = translate( [, ]? ) > specifies a 2D translation by the vector [tx, ty], where tx is the first > translation-value parameter and ty is the optional second translation-value > parameter. If is not provided, ty has zero as a value. > {code} > , _translate(tx)_ is equal to _translate(tx, 0)_. In the previous _version of > Weex_, we removed the array length check in method [WXTransform > parseTranslate:] > {code:java} > - (void)parseTranslate:(NSArray *)value > { > [self parseTranslatex:@[value[0]]]; > [self parseTranslatey:@[value[1]]]; > }{code} > so if the parser encounters a '_translate(0)_', the array contains only one > single value inside, parseTranslate will fetch the element at index 1 from > the array, which causes a typical _out-of-bounds_ exception, and lead to an > app crash eventually. > As we known in many js packing procedures, '_translate(x, 0)_' will be > compressed/minified to the form 'translate\(x\)', Weex should avoid such > inconsistent implementations and conforms the W3C specifications. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (WEEX-217) WXTransform should not crash while parsing 'translate(0)' on iOS
[ https://issues.apache.org/jira/browse/WEEX-217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gabriel Li updated WEEX-217: Summary: WXTransform should not crash while parsing 'translate(0)' on iOS (was: WXTransform should not crash while parsing 'translate(0)') > WXTransform should not crash while parsing 'translate(0)' on iOS > > > Key: WEEX-217 > URL: https://issues.apache.org/jira/browse/WEEX-217 > Project: Weex > Issue Type: Bug > Components: iOS >Reporter: Gabriel Li >Assignee: Adam Feng >Priority: Major > Labels: crash, css, translate > Original Estimate: 1h > Remaining Estimate: 1h > > According to the latest published W3C specification about [CSS > Transforms|https://www.w3.org/TR/css-transforms-1/)]: > {code:java} > translate() = translate( [, ]? ) > specifies a 2D translation by the vector [tx, ty], where tx is the first > translation-value parameter and ty is the optional second translation-value > parameter. If is not provided, ty has zero as a value. > {code} > , _translate(tx)_ is equal to _translate(tx, 0)_. In the previous _version of > Weex_, we removed the array length check in method [WXTransform > parseTranslate:] > {code:java} > - (void)parseTranslate:(NSArray *)value > { > [self parseTranslatex:@[value[0]]]; > [self parseTranslatey:@[value[1]]]; > }{code} > so if the parser encounters a '_translate(0)_', the array contains only one > single value inside, parseTranslate will fetch the element at index 1 from > the array, which causes a typical _out-of-bounds_ exception, and lead to an > app crash eventually. > As we known in many js packing procedures, '_translate(x, 0)_' will be > compressed/minified to the form 'translate(x)', Weex should avoid such > inconsistent implementations and conforms the W3C specifications. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (WEEX-217) WXTransform should not crash while parsing 'translate(0)'
[ https://issues.apache.org/jira/browse/WEEX-217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gabriel Li updated WEEX-217: Description: According to the latest published W3C specification about [CSS Transforms|https://www.w3.org/TR/css-transforms-1/)]: {code:java} translate() = translate( [, ]? ) specifies a 2D translation by the vector [tx, ty], where tx is the first translation-value parameter and ty is the optional second translation-value parameter. If is not provided, ty has zero as a value. {code} , _translate(tx)_ is equal to _translate(tx, 0)_. In the previous _version of Weex_, we removed the array length check in method [WXTransform parseTranslate:] {code:java} - (void)parseTranslate:(NSArray *)value { [self parseTranslatex:@[value[0]]]; [self parseTranslatey:@[value[1]]]; }{code} so if the parser encounters a '_translate(0)_', the array contains only one single value inside, parseTranslate will fetch the element at index 1 from the array, which causes a typical _out-of-bounds_ exception, and lead to an app crash eventually. As we known in many js packing procedures, '_translate(x, 0)_' will be compressed/minified to the form 'translate(x)', Weex should avoid such inconsistent implementations and conforms the W3C specifications. was: According to the latest published W3C specification about [CSS Transforms|https://www.w3.org/TR/css-transforms-1/)]: {code:java} translate() = translate( [, ]? ) specifies a 2D translation by the vector [tx, ty], where tx is the first translation-value parameter and ty is the optional second translation-value parameter. If is not provided, ty has zero as a value. {code} , _translate(tx)_ is equal to _translate(tx, 0)_. In the previous _version of Weex_, we removed the array length check in method [WXTransform parseTranslate:] {code:java} - (void)parseTranslate:(NSArray *)value { [self parseTranslatex:@[value[0]]]; [self parseTranslatey:@[value[1]]]; }{code} so if the parser encounter a '_translate(0)_', the array contains only one single value inside, parseTranslate will fetch the element at index 1 from the array, which causes a typical _out-of-bounds_ exception, and lead to an app crash eventually. As we known in many js packing procedures, '_translate(x, 0)_' will be compressed/minified to the form 'translate(x)', Weex should avoid such inconsistent implementations and conforms the W3C specifications. > WXTransform should not crash while parsing 'translate(0)' > - > > Key: WEEX-217 > URL: https://issues.apache.org/jira/browse/WEEX-217 > Project: Weex > Issue Type: Bug > Components: iOS >Reporter: Gabriel Li >Assignee: Adam Feng >Priority: Major > Labels: crash, css, translate > Original Estimate: 1h > Remaining Estimate: 1h > > According to the latest published W3C specification about [CSS > Transforms|https://www.w3.org/TR/css-transforms-1/)]: > {code:java} > translate() = translate( [, ]? ) > specifies a 2D translation by the vector [tx, ty], where tx is the first > translation-value parameter and ty is the optional second translation-value > parameter. If is not provided, ty has zero as a value. > {code} > , _translate(tx)_ is equal to _translate(tx, 0)_. In the previous _version of > Weex_, we removed the array length check in method [WXTransform > parseTranslate:] > {code:java} > - (void)parseTranslate:(NSArray *)value > { > [self parseTranslatex:@[value[0]]]; > [self parseTranslatey:@[value[1]]]; > }{code} > so if the parser encounters a '_translate(0)_', the array contains only one > single value inside, parseTranslate will fetch the element at index 1 from > the array, which causes a typical _out-of-bounds_ exception, and lead to an > app crash eventually. > As we known in many js packing procedures, '_translate(x, 0)_' will be > compressed/minified to the form 'translate(x)', Weex should avoid such > inconsistent implementations and conforms the W3C specifications. -- This message was sent by Atlassian JIRA (v7.6.3#76005)