1. This will work as long as you are using either the 'globalNetworkCheckSettings' or 'globalNetworkAccountSettings' for authentification. Using the 'globalAccountSettings' skips the login screen entirely and would thus require a much more complex solution to work.
2. Due to security limitations of using cross-domain iframes on a webpage, this will only work if the iframe's caldavzap content is hosted on the same domain as the webpage itself. Alternatively, the iframe content can also be a hosted on a subdomain of the webpage's domain.
3. If you really need the webpage and the caldavzap client to be hosted on a different domains, you can probably still get this to work, however you must resort to a bit hackish behaviour (see http://madskristensen.net/post/iframe-cross-domain-javascript-calls). Note that this requires you to slightly modify the source code of both the webpage and the hosted caldavzap instance, so you can't source the caldavzap official demo for example.
   
4. Calling the loadConfig() function after the user has already logged in will have no effect - eg. you don't have to worry about it displaying the login screen again (which is a good thing :)).

Matej Mihalik

Hm interesting.  Unfortunately, the hiding and revealing of the iframe is also out of my hands because we’re using bootstrap tabs.  So we have a three-way bug (FF + JQ + BS)!

Is there perhaps a function I can invoke to force CDZ to refresh the display when it is revealed?  I can get it to work by forcing the iframe to reload itself on reveal, but the latency is pretty high.

On Oct 3, 2014, at 5:19 AM, Matej Mihalik <matej.mihalik@inf-it.com> wrote:

Hi Ron,

We've spent some time looking at this problem and your description is spot on: this problem only manifests when displaying CalDavZAP in an iframe on Firefox, while the iframe is hidden (display:none) during initialization.

Unfortunately this is a jQuery / Firefox compatibility bug, that has existed for a few years now and the folks at jQuery don't feel like fixing it (see http://bugs.jquery.com/ticket/9106 and http://bugs.jquery.com/ticket/12179). Basically it all comes down to us using the jQuery fadeTo() / fadeIn() / fadeOut() functions throughout the software, however those rely on the use of the show() function, which is known not to work properly on Firefox under certain circumstances (much like those you described).

The best I can advise you in this situation is to use a different approach when it comes to the iframe hiding. Instead of modifying the css display property (none/block) try using visibility (hidden/visible) or opacity (0/1). It's not ideal, but with some modifications it should work.

I'm sorry I can't be of more help to you in this matter, however this issue is largely out of our hands.

Matej Mihalik

On 02.10.2014 19:57, Ron Garret wrote:

Thanks for this update!  Looks terrific!

I have found an apparent bug: CDZ doesn’t work under the following confluence of circumstances:

1.  CalDavZap displayed in an iframe
2.  Running on Firefox (I’m using 32.0.3 but I don’t think that matters)
3.  The iframe is hidden during the initialization process

I’ve enclosed a self-contained demo file.  To reproduce the problem, load test.html into Firefox, wait until it is loaded, then go to the Calendar tab.

The problem does not manifest itself on Safari or Chrome.  I have not tried IE.  (This bug was also present in previous versions of CalDavZap, though it manifested slightly differently.)

rg

On Oct 2, 2014, at 2:08 AM, Ján Máté <jan.mate@inf-it.com> wrote:

Hi everybody,

CalDavZAP 0.11.0 with lot of new functionality, fixes and Japan localization (thanks Muimu Nakayama) released.

Links:

download: https://www.inf-it.com/CalDavZAP_0.11.0.zip
demo: https://www.inf-it.com/caldavzap/
changelog: https://www.inf-it.com/caldavzap/changelog.txt


Thanks for help, suggestions, bug reports and translations!


JM