Moving to micro-task for stuff
If we move to a micro-queue for more things, we may have some issues with window.open in some scenarios:
test page: http://static.iamstef.net/security-open.html
This may or may not be a blocker, but figured I would drop findings so far here. So we can decide.
What is this? Turns out, there are some security features that prevent window.open from causing a window to open in several cases. specific if it seems to be not legimately the result of a user interaction either nothing happens, or a popup blocker UI is provided.
Now, the heuristics for "legit" vs "illegitimate" window.open attempt is abit fuzzy.
Table depicting:
| sync | micro task | raf | setTimeout | |
|---|---|---|---|---|
| Chrome 55 | ✓ | ✓ | blocker | ✓ |
| Safari 9.1.2 | ✓ | nothing | nothing | ✓ |
| Safari 10 | ? | ? | ? | ? |
| FF 50 | ✓ | blocker | blocker | ✓ |
| IE Edge | ? | ? | ? | ? |
| IE 11 | ? | ? | ? | ? |
| IE 10 | ? | ? | ? | ? |
| IE 9 | ? | ? | ? | ? |
? needs to be tested
| sync | microtask | raf | setTimeout | |
|---|---|---|---|---|
| Safari 10 | ✓ | ✓ | nothing | ✓ |
| IE 9 | ✓ | nothing | nothing | blocker |
FWIW, #306 is starting down the path for microtask queues for autoruns and transitioning from queue to queue via microtask.
You should retest this on Chrome 72, rAF now works correctly due to redesign of user activation
| sync | micro task | raf | setTimeout | |
|---|---|---|---|---|
| Chrome 90 | ✓ | ✓ | ✓ | ✓ |
| Safari 14 | ✓ | ✓ | blocker | ✓ |
| iOS 13 iPad | ✓ | ✓ | nothing | ✓ |
| FF 89 | ✓ | ✓ | blocker | ✓ |
| Edge 80 | ✓ | ✓ | ✓ | ✓ |
| Edge 18 | ✓ | ✓ | nothing | ✓ |
| IE 11 | ✓ | nothing | nothing | ✓ |