encoded email functionality now breaks

Page: 1

Author Post
rubycat
Guest
I am in love with this script. Is that possible??? Really, it's fantastic and I am most appreciative of your efforts!! One little glitch, however...

I am using a content management system which encodes the e-mail addresses within the content being displayed in the floatbox via Ajax. Unfortunately, the e-mail encoding breaks when displayed in this manner (works as it should if done via iframe). Like, the js for the e-mail encoding contains a span with an error message which will display if js is not available. The error message is being output to the browser even though js is very much enabled.

Could this little snippet from the e-mail encoding have something to do with this?

document.getElementById('eeEncEmail_m4GoffNKzZ').innerHTML = output;


As you can see, I'm kind of clueless. Any insight you could provide would be great. Thanks in advance!
Administrator
Registered: Aug 2008
Posts: 3382
Glad you're liking the floatbox.

Does it work as expected in Opera, Safari and Chrome, but not in IE or Firefox? Then I know what the problem is. IE and FF don't execute javascript that's inserted into floatbox via javascript. Those other browsers do. I've added some code to the next release that explicitly looks for and manually executes js for those browsers.

Does it work as expected in IE but fail in other browsers? Then the problem is likely the setting of innerHTML. Setting innerHTML does not always work. In particular, it will usually fail (with an abort of the executing javascript) when used on pages served as application/xhtml. Could it be that your primary page is xhtml but the iframe page that it's working in is type text/html?

So if it works when loaded as an iframe, then why not just use iframes and be done? Or, if it's problem #1 you can wait for the next release or I can share a small code snippet to patch in to the current release to manually run incoming javascript. Or, if it's problem #2 you would probably want to find something more reliable than innerHTML. For example, you could change that line to fb.setInnerHTML(document.getElementById('eeEncEmail_m4GoffNKzZ'), output);.

Or, it could be something else altogether and I might way off base here. Let me know...
rubycat
Guest
Hiya! It doesn't work in any browser I've tested...WIN/FF, WIN/IE6-7, WIN/Safari...

I can't do the iframe thing because as I understand it, clicking a link within the floatbox will open up the new link in that or another floatbox and that won't work for this site.

So I guess my answer it that it's...um...something else? I could send you a link privately to a test page that has all extraneous crud removed...?
Administrator
Registered: Aug 2008
Posts: 3382
A test page would be great. I'm working blind if I can't see the problem and can then only make guesses about what might be happening.

You can have a link in an iframe open a page in the parent window with <href="whatever" onclick="parent.location.href=this.href; return false;">
rubycat
Guest
I sent it to you via your contact form. Hope that was okay. :D
Administrator
Registered: Aug 2008
Posts: 3382
More than okay. Thanks.

It looks like the javascript is just not firing (but I think you already know that). Could you please try something for me?
On that test page, change the floatbox include lines to point to my test instance. E.g.,
http://test.randomous.com/floatbox/floatbox.js and similar for the css.

That test version has the new code for manually firing javascript in the ajax content. If you could try that out in as many browsers as you've got, I'd be very interested in the results.
rubycat
Guest
WIN/FF --> works!
WIN/IE6 --> works!
WIN/IE7 --> works!
WIN/IE8RC1 --> works!
WIN/Safari --> boo! doesn't work!
WIN/Opera --> boo! doesn't work!

I didn't point to your CSS because mine is inline at the moment but I see none of mine is working...that's temporary, right?
Administrator
Registered: Aug 2008
Posts: 3382
Ok. Below is the code you need.

I'm glad for the testing opportunity your case has provided, but now I have a problem. In other testing, I've seen Opera and Webkit (Safari, Chrome) fire the javascript on its own while other browsers do not. Now in your case, Opera and Webkit are behaving differently. I'll have to remove the browser type check, but this will mean that on some occasions the javascript will get executed twice. Usually not a problem, but I'm sure there will be occasions when it causes grief. But this is my problem, not yours.

Not sure what you're saying about the css, but I won't worry about it unless there's some issue with a normal setup.

In the v3.24 floatbox.js code, inside the fetchContent function, you will find this block of code:
if ((xhr.status === 200 || xhr.status === 203 || xhr.status === 304) && xhr.responseText) {
that.setInnerHTML(that.fbContent, xhr.responseText);
that.tagAnchors(that.fbContent);
} else {

Add the setTimeout block to make it look like:
if ((xhr.status === 200 || xhr.status === 203 || xhr.status === 304) && xhr.responseText) {
that.setInnerHTML(that.fbContent, xhr.responseText);
that.tagAnchors(that.fbContent);
setTimeout(function() {
var match, rex = /<script[^>]*>([\s\S]+?)<\/script>/gi;
rex.lastIndex = 0;
while ((match = rex.exec(xhr.responseText))) {
try { eval(match[1]); } catch(e) {};
}
}, 40);
} else {
rubycat
Guest
Okay, I've inserted that snippet and everything seems to work as expected. Yay! You're great! Just curious if there's some type of behavior I should look out for...? You said something about js executing twice in certain circumstances...? (Just as an aside, the test page content will be incorporated into a home page chock full of jquery goodness so more stuff is going to be interacting with it.)

Is there an easy way for me to take my adjusted js file and compress it?
Administrator
Registered: Aug 2008
Posts: 3382
I can't think of too many cases where executing the downloaded javascript twice would create grief, but I'm sure there's cases out there I haven't imagined yet. One that comes to mind is if the js includes an alert notification about something. That alert would popup twice. I don't know why some browsers run the ajaxed javascript sometimes but not others. Inconsistent browser behaviour is very hard to code for.

It's a bit of a pain to recompress the js files. Here's the drill I use.
First, you have to be careful not to include the IE conditional compilation section right near the bottom of the page. The compressor screws that up. So...
- Clipboard copy or cut everything in the code from just below the beginning options section, starting with Floatbox.prototype = {
to just above, but not including (function() {
/*@cc_on // IE via conditional compilation
about 20 lines up from the bottom.
- Go to http://compressorrater.thruhere.net/ and paste the copied stuff into the big box. (Use firefox because it won't wrap the output).
- Clear all the checkboxes except "YUI Compressor".
- When the results return, click view on the top-listed item.
- Paste that resulting code back in to the js file, replacing the copied or cut content, but leaving the stuff above and below it in place.
- You can manually take out the whitespace from the small bottom section of code if you like, but there's not much bang for that buck.
- You can then use that compressed version, or gzip for further compression if you're using that approach (see the readme.txt in floatbox's "compressed" folder).

Be sure to test stuff before rolling it out to make sure nothing got trashed along the way.
rubycat
Guest
Not to sound dumb but I see that the compressor thingie took out my comments and one place where I commented out a line of code. I guess that was the whole point of excluding the IE conditional stuff, huh?
Administrator
Registered: Aug 2008
Posts: 3382
Yeah, a compressor will strip out anything not essential to running the code, and do some other tricks as well. Comments are the first thing to be discarded.

Page: 1