I’ll give your “fixed” position suggestion a try tomorrow, Walter. In the meantime, any thoughts on what the bug is in your new code? (See my previous few posts for details.)
Try this – I made a few changes to the order of things. The way it was in your message, the warning would be hidden on the second visit always – not just if the visitor clicked the box.
var jar = new CookieJar({expires: ''});
var message_box = $('legaleze').
setStyle('z-index: 1000; cursor:pointer');
if(!!jar.get('hide_message')){
message_box.hide();
}else{
$$('body').first().insert(message_box.remove());
message_box.observe(
'click',
function(evt){
this.hide();
jar.put('hide_message',true);
}
);
};
I am not sure if my first iteration of this code followed that pattern, I am certain that the second one did.
Walter
On Oct 1, 2012, at 9:13 AM, JDW wrote:
I’ll give your “fixed” position suggestion a try tomorrow, Walter. In the meantime, any thoughts on what the bug is in your new code? (See my previous few posts for details.)
For whatever reason, your 3rd version of the Protaculous code didn’t work at all. So I went back to your 2nd version and looked for any stupid mistakes that I might have made. Sure enough, I am an idiot. I put the display=none Extended code in the
tab instead of the
tab. Putting it in the correct tab got it to work! So even though your 3rd version doesn’t work, the 2nd version does! Sorry about MY mistake. Anyway, the problem where the Overlay flashes on/off when you revisit the page is not solved! Yeah!
Now, as to the problem where the Overlay page-cover is missing from the previously hidden-from-view part of the page, when you scroll down, please note that problem afflicts more than just IE7. I confirmed the problem in IE8, and also in the latest versions of Firefox and Chrome running on WinXP.
I don’t know if it is the “best” solution but what I did was set the Height of my Overlay box to 125% in Freeway. When you open the page in the browser now, the page is longer than it should be, but the problem is fixed in all browsers.
You can see the end result of your code on my websites here:
(If you can’t see anything, then you’ve been there before. You’ll need to restart the browser or clear cookies.)
If you set the overlay to position:fixed in the Inspector (Fixed in Window) you won’t have this problem any more, and you can go back to 100% height.
Walter
On Oct 1, 2012, at 9:00 PM, JDW wrote:
I don’t know if it is the “best” solution but what I did was set the Height of my Overlay box to 125% in Freeway. When you open the page in the browser now, the page is longer than it should be, but the problem is fixed in all browsers.
Oh my, Walter, you are absolutely right! Changing to “Fixed in Window” does solve the problem perfectly, allowing me to keep the Overlay at 100% height.
I have tried desperately to follow this thread but cannot seem to make it work!
I want a pop-up window/box to appear on the index page when it loads which just gives a message about updating contact details and has a link (‘Text Link to New Window’ action) within. I only want this to appear once rather than every time somebody goes back to the index page (which happens with the ‘Timed Spawn New Window’ action). I have done it as an html item and just sat in on top of my inline layout.
I have added Protaculous and the External Javascript actions and added the cookiejar.js script after the head and then placed the code that Walter gave in the top Function body of the Protaculous action and renamed the ‘item 42’ to my element title (contact reminder)
However although the ‘Text link to New Window’ works the box/panel remains and does not disappear when clicked or after navigating away from the index page and then back. It remains like a fixed element.
And finally in the Dom Loaded Observer section of the Protaculous 2 action add the following code where ‘box’ should be replaced by the Name/ID of your container and you adjust the expiry time (in seconds) to suit your needs.
jar = new CookieJar({
expires: '120'
});
if(!jar.get('sawit')){
jar.put('sawit',true);
$('box').removeClassName('hidecookie');
}else{
$('box').addClassName('hidecookie');
}
Now this will rely on a page refresh so opening a pop-up to the log-in page will not be enough. You will have to leave the index page.
Thank you - that did the trick - and along with a ‘close’ graphic with a ‘Show/hide target layer’ action for those who didn’t want to /need to update their details it now works a treat.
So thank you once again for very clear instructions.
I am slightly surprised that Freeway itself does not have an action that does a pop-up like this. I would have thought it quite a useful little thing - especially for reminders etc.
Earlier in this thread, I discussed a cookiejar solution with Walter that has served me well. Zero issues when used in FW5.6.5. But when I opened that document in FW6 today, I found that the DIV I wish to display/hide with the cookie won’t display at all.
I followed your May 18, 2014 suggestion perfectly, but it does not work at all for me.
I tried a slight mod of Walter’s approach, updating the cookiejar URL in the Protaculous 2 “CDN URI” field, but that didn’t work.
I then selected the DIV I want to show/hide and choose Item/Extended. I deleted Walter’s suggestion of putting the following into
:
[code]
Name: display
Value: none
[code]
And instead of that, Dave, I used your suggestion of adding the following into
Name: class
Value: hidecookie
That change gets the DIV to display, but it always displays! Furthermore, it doesn’t cover the bottom portion of the page for some reason.
All these troubles happen only when I open my FW5.6.5 doc in FW6, so clearly there are some changes in FW6 that are incompatible with Walter’s solution and your solution.
Any ideas you might have would be greatly appreciated.
I found that I made a big oversight in that I did not rename ‘box’ by the Name/ID of my container. I’ve made that fix and although it doesn’t show within FW6’s PREVIEW for some reason, the overlay does display in CHROME. However, there are 2 problems with your method:
I cannot click on the overlay to dismiss it – it remains covering my page forever.
It doesn’t cover the leftmost and rightmost sides.
Your Method (has 2 problems I listed above):
Walter’s Method (totally dead in FW6):
Generated by FW5.6.5 and works perfectly:
Restart your browser or use multiple browsers to avoid display problems. On the FW5.6.5 generated page, the cookie displays the overlay once per session. (Merely reloading the page will not bring it back.)
I cannot click on the overlay to dismiss it — it remains covering my page forever.
Try adding a dummy link to your close button which will cause a page refresh and dismiss the popup.
It doesn’t cover the leftmost and rightmost sides.
That your design issue - not mine.
If you reread my post on this I did suggest that you initially try this on a fresh page. Your page is so chock full of JS that it is hard to decipher exactly what is going on.
I added the dummy link to my close button (which is actually a suggestion Walter made to me earlier in this thread pertaining to his implementation of the overlay), but it will not close with a click in the browser:
But if I reload the page, then the overlay vanishes. And remain vanished it does. Even when I relaunch the browser, it no longer shows!
I think that the closes button is not hooked up to any observer. Did you add any code specifically to this button? When I read through the cookie script, it appears to be simply testing if the person has seen that page before – it only shows the overlay if you have not seen it in the last 120 seconds. It’s important to note that a cookie can only be read by the page after you navigate back to it from somewhere else. Reload can be very tricky. You are also using CloudFlare cacheing on that page, which can throw additional spanners into the works. See if turning that off does anything for the script behavior. If you really need to set this thing to only show once, you may need to do something more deliberate than JavaScript.
Walter
On Jul 27, 2014, at 8:47 PM, JDW wrote:
Dave,
I added the dummy link to my close button (which is actually a suggestion Walter made to me earlier in this thread pertaining to his implementation of the overlay), but it will not close with a click in the browser:
Walter, the ultimate problem is FW6. The only reason I even was forced to try Dave’s code is because the code you and I pieced together (earlier in this thread) does not work at all when I Publish my FW5.6.5 site in FW6. It works flawlessly when the page is generated by FW5.6.5.
After comparing the 5.6.5 generated index.html page with the FW6 generated page, I was able to narrow down the “killer of your script” to the following line:
That link is present only when FW6 generates the page. If I delete that line, the page layout collapses, but the overlay (collapsed, of course) appears properly and vanishes properly with a click.
So I am not trying to figure what what in particular within that “index.css” is wreaking havok on my overlay and cookie implementation.
Within that “index.css” file (generated exclusively by FW6), when I delete the following line, the overlay displays as it should in-browser but cookie operation and click-to-close becomes quirky.
I’ve spent way to much time on this. I’m content to stick with FW5.6.5. Because when it ain’t broke, why fix it?
But for those of you brainy types who can figure this stuff out, I’ve prepared two pages for you to examine:
“fw5” = generated by Freeway 5.6.5.
“fw6” = generated by Freeway 6.1.2.
I disabled External StyleSheets in Protaculous2 and in File/DocumentSetup/Output and I set Compatibility in both to IE7, to make it a tad easier to see similarities and differences. But honestly, when I compare both of those index.html files in TextWrangler, I see that FW6 changes the HTML quite a lot from FW5. I tried copying/pasting chunks of code from the FW5 index.html to the FW6 index.html, but I couldn’t find the right spot to fix the problem. Of course, if I swap out the FW6 version “index.html” with the FW5 version, then the overlay starts working beautifully again. But again, that just means I need to stick with FW5.
This is really odd. I deleted the cookie from your server, and I can’t make the message re-appear in either one of these now. I will have to wait a couple of hours and see if it returns.
Walter
On Jul 28, 2014, at 2:34 AM, JDW wrote:
I’ve spent way to much time on this. I’m content to stick with FW5.6.5. Because when it ain’t broke, why fix it?
But for those of you brainy types who can figure this stuff out, I’ve prepared two pages for you to examine:
I disabled External StyleSheets in Protaculous2 and in File/DocumentSetup/Output and I set Compatibility in both to IE7, to make it a tad easier to see similarities and differences. But honestly, when I compare both of those index.html files in TextWrangler, I see that FW6 changes the HTML quite a lot from FW5. I tried copying/pasting chunks of code from the FW5 index.html to the FW6 index.html, but I couldn’t find the right spot to fix the problem. Of course, if I swap out the FW6 version “index.html” with the FW5 version, then the overlay starts working beautifully again. But again, that just means I need to stick with FW5.
This is really odd. I deleted the cookie from your server, and I can’t make the message re-appear in either one of these now. I will have to wait a couple of hours and see if it returns.
Walter, after waiting several hours, what happened?
There is no doubt that what breaks the cookie implementation is FW6’s way of generating code. It works in FW5. It doesn’t work in FW6. I just don’t know WHY this is so. Since we cannot change FW6’s HTML generation, the only way to fix the problem is to alter the cookie implementation to be compatible with FW6. But I don’t understand the ROOT PROBLEM well enough to do that. Do you? Is that why you deleted the cookie?