Opened 12 years ago

Closed 12 years ago

#3769 closed defect (fixed)

regression in _base/array.js

Reported by: dante Owned by: Ben Lowery
Priority: high Milestone: 0.9
Component: Core Version: 0.9
Keywords: Cc:
Blocked By: Blocking:

Description

in [9615] blowery's safari/array modification causes issues w/ safari. i suspect scoping and makeCall(), but am unsure. Reverting changes fixes issue. Issue was discovered via broken dijit/test_Dialog.html with Safari3/Win32 ... Regression appears in 7-13 nightly.

Change History (4)

comment:1 Changed 12 years ago by tk

I played around with this a bit as well. From my testing, by using alerts, if I place an alert inside of

	var makeCall = function(fn){
		return function(a){
                        alert(a);
			a[fn].apply(a, Array.prototype.slice.call(arguments, 1));
		}
	};

a alerts as nothing... if I replace a with fn, it alerts as 'forEach' so I'm guessing the problem lies in there... but definitely could be wrong.

comment:2 Changed 12 years ago by Ben Lowery

(In [9673]) refs #3769. add a test case that allows array to be tested from a browser-based environment.

comment:3 Changed 12 years ago by Ben Lowery

(In [9675]) refs #3769, refs #3742. Revert change to enable native array iteration methods on Safari3. The change fails the existing unit tests for array.js, and it does not appear that Safari3's implementation is sufficient for dojo's forEach contract. Specifically, forEach is not defined on String objects or null / undefined values, so call against those types fail with a TypeError?.

We could insert an adapter that used the fast path on Safari3 when available and fell back to the default Dojo implementation otherwise, but we'd need to vet that technique with performance testing. For now, I'm just reverting the change and we can figure out what we'd like to do long term.. later.

comment:4 Changed 12 years ago by dante

Resolution: fixed
Status: newclosed

[9765] fixed #3769

Note: See TracTickets for help on using tickets.