0.3.8 hangs Safari and Chrome on iPad 1 when using alert/confirm/prompt

[janroesner]

I'm using Alertify in a yeoman project using require.js to load it. It works pretty well in all Browsers I have seen so far, but it completely hangs Safari on iOS 5.1.1 as well as latest Chrome.

noticeUser: ->
  if @model.get('status') == 'completed'
    Alertify.set labels:
      ok: "Thanks"
    Alertify.alert "Your data has been sent."
  else
    Alertify.set labels:
      ok: "Ok, I'll try later..."
    Alertify.alert "Error during sending your data!"

This piece of coffe triggers the error. Both browsers become completely unresponsive to touch events in the rendering area. Orientation change still works, and the page can be reloaded, but fails then in the same situation.

Any ideas what could cause this behaviour? Any workarounds?

Regards
Jan

[fabien-d]

There's nothing there that should create an issue outside of Alertify should be alertify.

Can you reproduce it on the example site? If so, can you provide the steps to reproduce. I've just tested it with the latest version of Chrome (Version 26.0.1410.65, Mac 10.8.3) and in Safari on my iPhone and everything worked fine.

If you can't reproduce on example site example site, could you provide sample code with the issue being reproduced?

[janroesner]

In my case it is Alertify, cause I require alertify via require.js and Alertify is the objects name inside my closure. But that does not cause the problem, I tested it already.

The example site hangs my Browser as well as my application does. BUT only as I mentioned above on iPad first generation. The funny thing here is, it hangs Safari mobile and Chrome mobile in latest releases, so I assume, it's related to the device itself. Unfortunately I expect a good number of users still having an iPad first generation.

[fabien-d]

I don't have an iPad first generation to test, but I'll fire up browserstack to test it and see if I can recreate/debug it. I'll update with my findings.

[janroesner]

Thank you, meanwhile I'll try to debug it using 'weinre'.

[janroesner]

No result so far. The rendering engine seems to hang, real debugging is not possible using weinre. I am going out of options here. Any suggestions?

[fabien-d]

I'm looking at it now - so far I'm able to open 1 dialog (iOS 5.1, iOS 4.3.2) with weird behaviour (jumps to the top of the page) but can't open any other afterwards.

I've tested the 0.4.0rc1 version, and it appears to work on both of these. Could you confirm? Test the 0.4.0rc1 demo site. I'll start seeing what the differences are and see what I can do.

[janroesner]

0.4.0rc1 works pretty well on my iPad 1st gen. What I understood so far, is, that 0.4.0 seems to enqueue the first item cleanly. After confirming or canceling the cover is set to display: none. When the next confirm message is created, the relevant item is queued, but the item not rendered. In fact the cover is activated. That's the reason why I was not able to click anything. The browser still ran, but all click events went to the cover. I did not yet find out, what caused the problem, so I'm really interested in your finding. Love the codebase btw, great work.

[fabien-d]

That's correct. There's an issue with the transition properties at the moment, which I've resolved, causing the cover to show, but not the dialog ("hang" mode).

I'm close - I have resolved the issue with the dialog not showing after the first time (2nd time onward dialogs show perfectly), but the first item still causes the page to jump to the top. Need to sort that out and I'll push an update.

[fabien-d]

@janroesner Any chance you could take a look at the above PR and test the new source with your iPad to ensure the fix does indeed work? I was seeing the behaviour in the simulator and the changes resolved the issue, but getting confirmation on the actual device is always better.

edit:
the 2 files to look at are alertify.js and core css

[janroesner]

@fabien-d It works like a charme. I tested alert, confirm and prompt. Transitions are missing, but thats IMHO fine. Everything else seems to work fine as well. Thx.

[fabien-d]

I had to remove the transitions - that's what was causing the issue. It supports an older syntax for CSS transitions but doesn't do so very reliability.

I will look for a workaround but that will be for the 0.4 release.

Thanks for the help. I'll merge/release/update docs when I get a chance.

Sent from my iPhone

On 2013-04-20, at 4:20 PM, Jan Roesner [email protected] wrote:

@fabien-d It works like a charme. I tested alert, confirm and prompt. Transitions are missing, but thats IMHO fine. Everything else seems to work fine as well. Thx.

—
Reply to this email directly or view it on GitHub.

[fabien-d]

Merged. Issue resolved in 0.3.9. Branch 0.3 of repo or can be downloaded for the demo site.