Johan Vromans <jvromans@squirrel.nl> writes:

Ediff the new config.js with my current config.js revealed only one change: setting delegation to true. I applied this change to my current (0.10.0.5) config and copied it to the new caldavzap dir.

Correction: My current CalDAVZap instance was 0.11.rc, not 0.10.0.5. Hence the relatively small number of changes. -- Johan

Ján Máté <jan.mate@inf-it.com> writes:

1.) try to delete your browser cache ...

This seems to do the trick. I'll keep you posted if more strange things happen. Thanks, Johan

Thanks for the comment, we will decrease the time in the 0.11.0.1 ;-) JM

On 02 Oct 2014, at 19:14, Johan Vromans <jvromans@squirrel.nl> wrote:

Ján Máté <jan.mate@inf-it.com> writes:

...

CalDavZAP 0.11.0 with lot of new functionality,

One of the new functionalities is a pop-up of appointment data that is shown when hovering over an appointment. Though this functionality is nice, IMHO the relatively slow fade-in/fade-out makes it irritating.

I decreased the fade-in/fade-out times to 100 millisecs and find the results much more pleasing.

-- Johan

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

Hi Ron, Sorry for the late reply, we were quite busy working on the new release. As to your problem, if the iframe has an id attribute (say 'calframe' for example), you can call the loadConfig() function after the iframe is revealed, to force the login screen to appear like this: /window.frames['calframe'].contentWindow.loadConfig()//;/ Couple of notes though: 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 On 03.10.2014 17:50, Ron Garret wrote:

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

Hi Ron, the internal logic of CalDavZAP and libraries we use (such as the custom version of fullcalendar, jQuery, jQuery-UI, ...) is rather complicated. We have no time to create a workaround by recoding the internal logic just because of a Firefox/jQuery bug and one person (sorry) who have very specific requirement (use our software in iframe). We tried to create a workaround, but it requires significant changes and lot of time, so I stopped the work on it. If you can fix the bug in Firefox and/or jQuery and/or create a patch (with a workaround) for CalDavZAP I have no problem to include your it in the release. JM

On 08 Oct 2014, at 16:03, Ron Garret <ron@flownet.com> wrote:

Thanks for the response. Unfortunately, I am using globalAccountSettings, and I have to use that because the whole point is to put CalDavZap alongside a bunch of other applications behind a common security perimeter.

All the content is being served from one domain, so at least that is not a problem.

Why is forcing a redraw of the main screen so complicated?