[
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( <length-percentage> [, <length-percentage> ]? )
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 <ty> 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( <length-percentage> [, <length-percentage> ]? )
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 <ty> 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( <length-percentage> [, <length-percentage> ]? )
> 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 <ty> 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)
