E4X filter prefers local variable over matching XML node name

RESOLVED INVALID

Status

Tamarin
Virtual Machine
RESOLVED INVALID
9 years ago
7 years ago

People

(Reporter: Chris Peyer, Assigned: Jeff Dyer)

Tracking

(Blocks: 1 bug)

unspecified
Future
x86
All
Bug Flags:
in-testsuite ?
flashplayer-injection -
flashplayer-qrb +
flashplayer-bug +
flashplayer-needsversioning +

Details

(Whiteboard: loose-end)

(Reporter)

Description

9 years ago
as source:
var xml:XML = <items>
  <item id="item1" type="item1_type" />
  <item id="item2" type="item2_type">
<item id="item3" type="item3_type" />
  </item>
</items>;



function getItemTypeNotWorking(item:String):void {
    trace("test1 = ", xml..*.(name() == "item" && @id == item).@type);
}

function getItemTypeWorking(itemID:String):void {
    trace("test2 = ", xml..*.(name() == "item" && @id == itemID).@type);
}

getItemTypeNotWorking("item2");
getItemTypeWorking("item2");



Steps to reproduce:
1. filter an XML with a E4X filter, example: xml..*.(name() == "item" && @id == "item1").@type
2. encapsulate the filter in a function with a variable name identical to the node

sources and explanation there:
http://www.soundstep.com/blog/2008/11/12/flash-cs4-bug-with-xml-e4x-filters/

Actual Results:
value not returned by the filter
 
Expected Results:
value returned
 
Workaround (if any):
use a different variable name 

This bug transferred from: http://bugs.adobe.com/jira/browse/ASC-3787
(Reporter)

Updated

9 years ago
Flags: in-testsuite?
Flags: flashplayer-qrb?

Updated

9 years ago
Target Milestone: --- → Future

Updated

9 years ago
Flags: flashplayer-qrb? → flashplayer-qrb+

Comment 1

7 years ago
Jeff, is the behavior consistent with the E4X specification?
Assignee: nobody → jodyer
Blocks: 479769
Flags: flashplayer-needsversioning+
Flags: flashplayer-injection-
Flags: flashplayer-bug+
Summary: XML E4X filter variable name → E4X filter prefers local variable over matching XML node name
Whiteboard: loose-end
(Assignee)

Comment 2

7 years ago
Actually what is going on here is @id == item is comparing the current value of @id and item, both of which are in the dynamic scope created by the filter expression. In other words the parameter 'item' is being shadowed by the XML element 'item'. This is per spec. 

(It is a know language bug that there is not way to resolve the scope of name in a filter expression to an outer scope.)

Resolving as NAB.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.