Safari on IOS 9.3.1: problem since version 0.11.4

[BahKoo]

I'm building an application with the following libraries:

• angular 2.0.0-rc.4
• webpack 1.13.1

Some angular components do not immediately render to the screen when navigating to a new page. If the user taps the screen, the components are then rendered.

This was not a problem in version 0.11.3. This problem exists in versions 0.11.4, 0.11.5 and 0.11.6.

My webpack config does not contain an entry for devtools.

Please let me know what additional details I can provide.

[calvinmetcalf]

are you sure the only difference is this module considering from what I can tell, angular 2 doesn't use process.nextTick anywhere, unless you are using it somewhere.

Otherwise would you mind posting an example that doesn't work ?

[BahKoo]

I'm sure that this module is the only difference. However I'm beginning to uncover more details. I'm also using the following libraries:

• breeze-client 1.5.6
• q 1.41

The stacktrace looks like this:

nextTick /* q */
then /* q */
R /* q */
executeQuery /* breeze */
execute /* breeze */
getDocuments /* my code */
getData /* my code */
load /* my code */
ngOnInit /* angular */

[calvinmetcalf]

ok so this will almost always be at the top of any stack trace because of how things work in JavaScript, the only difference after 0.11.3. was that we fixed a bug where changing the global setTimeout would change the version we used.

[BahKoo]

I'm not sure I follow. What would always be at the top of any stack trace? There are functions from the "q" and "breeze" libraries at the top of my stack trace.

[calvinmetcalf]

nextTick is a function in this library, there may be one in q as well

[BahKoo]

I tested release 0.11.7 and the issue remains. It looks like the Q Library does have its own implementation of a nextTick function and I imagine there's some kind of conflict with these libraries. The workaround that works for me is to continue using version 0.11.3 of this library.

[calvinmetcalf]

@BahKoo are you able to put together like a simple example that shows this happening?

likely somewhere there is someone replacing setTImeout with something else...

[semmypurewal]

I believe we're hitting the same issue (or a closely related issue). We're also using q, and our target platform doesn't have a native setTimeout. We define a setTimeout when our file is first evaluated, but you may be caching the undefined setTimeout before we can set it.

It does look like the stack trace is originating with q, however. We're using q 1.0.1.

Right now I can repro this issue from 0.11.4 and above. So we're pinning back to 0.11.3.

I attempted to put together a small example that demonstrates the issue in the browser, but I haven't been successful yet. I'll give it another try next week.

[calvinmetcalf]

Ok sounds like a short term fix would be to make site to define the thing earlier and for us to ignore the catched value if it's falsey

On Sat, Aug 27, 2016, 1:56 AM Semmy Purewal notifications@github.com wrote:

I believe we're hitting the same issue or a closely related issue. We're also using q, and our target platform doesn't have a native setTimeout. We define a setTimeout when our file is first evaluated, but you may be caching the undefined setTimeout before we can set it.

It does look like the stack trace is originating with q, however. We're using q 1.0.1.

Right now I can repro this issue from 0.11.4 and above. So we're pinning back to 0.11.3.

I attempted to put together a small example that demonstrates the issue in the browser, but I haven't been successful yet. I'll give it another try next week.

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/defunctzombie/node-process/issues/68#issuecomment-242879710, or mute the thread https://github.com/notifications/unsubscribe-auth/ABE4n3S3BT-sC6iG_wfaO9mbTGMRHs2kks5qj303gaJpZM4JWXLx .

[calvinmetcalf]

ok we have a similar test for it working if setTimeout is not available so we should be able to possibly add a test here, in generally it sounds like we want to defer caching if set/clear timeout aren't available yet

[calvinmetcalf]

@semmypurewal please test against #73 I think I fixed it and added tests that cover it

[semmypurewal]

Thanks very much for the quick turnaround on this! It may be tomorrow or Wednesday before I can give it a try, but I'll report back here when I do.

[semmypurewal]

I gave this a try, and it does seem to solve our problem! I also ran the tests without the console.log statements, and they seem to pass just fine.

Will this fix be in 0.11.9?

[calvinmetcalf]

yeah It works from me without the console.log...I feel like I'm being lampshaded

[calvinmetcalf]

anyway I think this was fixed by #73 so closing