Caja should have setImmediate support

[GoogleCodeExporter]

setImmediate is a new proposed JS function that's similar to setTimeout(..., 
0), but doesn't have a minimum time delay.

1. Caja should support setImmediate, and fallback to setTimeout(...,0) if 
there's no browser native support.

2. Caja should use setImmediate when available, instead of setTimeout(..., 0)

Background:

setTimeout(..., 0) is often used by JS code as a "yield to browser", because it 
allows the browser to handle pending events, such as user input, before 
continuing processing.  Due to historical accident, it's not possible for 
setTimeout(..., 0) to run the deferred function "right away" without breaking 
functionality of some webpages.  So browsers impose some minimum delay before 
the function gets fired.  On IE, the minimum delay is 16ms (1/64sec).

setInterval is a new proposed function that lets you defer execution without a 
minimum delay:
http://dvcs.w3.org/hg/webperf/raw-file/tip/specs/setImmediate/Overview.html

The IE10 platform preview supports setImmediate:
http://blogs.msdn.com/b/ie/archive/2011/06/29/site-ready-html5-second-ie10-platf
orm-preview-available-for-developers.aspx

Original issue reported on code.google.com by felix8a on 29 Jun 2011 at 8:59

[GoogleCodeExporter]

While I fully agree that the feature would be good, I'm reclassifying it from 
Defect to Enhancement.

Also, as explained at 
https://groups.google.com/d/topic/google-caja-discuss/4OhcY8qbkKg/discussion , 
we should return an opaque object as a handle, not an integer, no matter how 
the spec finally settles on this issue.

Original comment by erights@google.com on 29 Jun 2011 at 9:29

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

The apparent origin of this silliness: 
https://bugzilla.mozilla.org/show_bug.cgi?id=123273

Original comment by erights@google.com on 30 Jun 2011 at 11:38

[GoogleCodeExporter]

right, some JS coders were relying on the fact that setTimeout(,0) always has a 
delay so won't consume 100% cpu.  adding a delay in the browser is easier than 
fixing JS code in the wild.  setImmediate will avoid the problem because it's 
expected that if you do use that as a looping construct then you will consume 
100% cpu.

Original comment by felix8a on 1 Jul 2011 at 3:25

[GoogleCodeExporter]

> setImmediate will avoid the problem because it's expected that if you do use 
that as a looping construct then you will consume 100% cpu.

Until someone (ahem) build an async programming library on top of setImmediate 
or setTimeout, whichever is available, hiding that detail from the user of the 
library. How do we expect any program to know what tradeoff to make between 
power and speed with no information about preferences or context?

Original comment by erights@google.com on 1 Jul 2011 at 3:41

[GoogleCodeExporter]

MDN says setImmediate is not expected to become standard, and no browser other 
than IE10 implements it, so I'm closing this as wontfix until the situation 
changes.

Original comment by felix8a on 23 Jul 2012 at 4:05

• Changed state: WontFix