Facebook login broken in Safari 4 beta?

May 30th, 2009

Here’s a fun, major example of a cross-browser bug in the wild. It seems that, for certain users of the Safari 4 beta (latest update after the Mac OSX release), logging into Facebook is totally hosed. If I try to log in, Safari gives me a cursor with a lovely blue ball. It doesn’t even spin like the beach ball of death.

Running the Safari Developer tools error console yields the following errors on Facebook’s end:

Unsafe JavaScript attempt to access frame with URL http://www.facebook.com/home.php? from frame with URL
http://static.ak.facebook.com/common/redirectiframe.html. Domains, protocols and ports must match.

Unsafe JavaScript attempt to access frame with URL http://www.facebook.com/home.php? from frame with URL
http://0.channel14.facebook.com:80/[snip...]. Domains, protocols and ports must match.

Basically, it looks like Facebook’s trying to send a request during the login process from a subdomain of their site. Safari’s flagging it as breaking the AJAX “same origin” URL policy and preventing the request from completing. By acting correctly - Facebook’s requests are indeed breaking the same origin policy - Safari’s also blocking me (and a whole bunch of other people) from being able to login. (Now, I could be wrong here with the exact cause of the behavior, but the bottom line is something on Facebook is still totally breaking login in Safari 4.)

Is the new Safari being too strict? Why can I login in Firefox and Google Chrome? Is this an odd use case in a browser with a small market share (I’m guessing less than 4% of Facebook’s base) that wouldn’t be caught during testing as it’s not part of Facebook’s test platform, or is it a legitimate cross-browser bug that will be solved?

Clearing my cache (holding SHIFT and pressing the refresh button in the address bar or holding CONTROL + F5 / CONTROL + FN + F5 on a macbook) seemed to do the trick: the requests still showed up as failing, but I was able to log in. But, I’m still interested to see if this winds up being a fairly high-profile example of cross-browser development’s pitfalls on a really big stage.

Very, very odd.

YUI IE8 Selector utility bug

May 22nd, 2009

Versions of the YUI Selector utility prior to 2.7.0 won’t work with IE 8. There’s a bug in there somewhere that breaks className selectors.

So, something like div.bd won’t return any results.

The solution is to upgrade to 2.7.0. I’m working on a site on which I can’t upgrade the whole package; it would take too much QA time. So, I tried dropping Selector 2.7.0 over the existing file (in my case, an ancient 2.5.2 version). The result: seems to work like a charm, so it’s worth a try.

EDIT: Also just saw that IE8 likes to detect our internal dev servers as intranet sites and throw itself into IE7 compatibility mode. Make sure you use developer tools on whatever site you’re testing (production, in my case), and then reset them wherever you’re developing.

It’s a launch!

May 14th, 2009

Have a look at that lovely Learn and Explore section on NikonUSA.

Copious uses of the YUI library and a whole bunch of lightbox / media player functionality that I hacked together. My favorite part: the in-page glossary (nice little RegExp there) and the little lava menu I worked up on any of the Glossary pages.

Note to self…

May 14th, 2009

If you’re running an animation for 250 ms and you need a function to execute after that, make sure you either run it as a call back or set a timer that’s longer than 250 ms…

Copying an HTMLElement’s styles to another … all of them

May 14th, 2009

Kind of a thought experiment. You have one HTMLElement with a bunch of unknown style properties set on an ID selector or Element selector, and you need to get them over to another, completely different Element.

Paul and I came up with this:


// transfer an element's styles to another element.
// adam mcintyre & paul irish
// public domain, bitchezzz.

// we'll start with an h1.
var el = document.getElementsByTagName('h1')[0];

var cStyle = ''; 

for(var i in el.style){      

  if(typeof el.style[i] != 'function'){ 

    cStyle += i.replace(/([A-Z])/g,'-$1').toLowerCase() +
    ':' +
    (document.defaultView.getComputedStyle(el,null)
      .getPropertyValue(i) || 'none') +
    ';'
  }
}

// at this point cStyle is a big long string of
// display:block;opacity:1;css-text:none;parent-rule:none;azimuth:none;....

// h3's will grow up big and strong like h1's!!!!
document.getElementsByTagName('h3')[0].style.cssText = cStyle;

Working with Omniture?

May 12th, 2009

Data not going through? Try adding a call to s.tl() to flush things out and make sure they’re sent to Omniture. It seems to not want to send certain custom events by default.

NikonUSA plug

May 1st, 2009

QUICK TAKE: Stay up to date on the latest news from Nikon, producer of much-heralded cameras, scanners, and other imaging

Nikon site ranked #13 in the Top 100 photo sites. Not too shabby.

CakePHP - Helper filenames must be lower case?

March 7th, 2009

Bit of an odd one. It seems that in between the beta version of CakePHP 1.2 that I’ve been using and the full release, Helpers now must have lower-case filenames or they go missing.

You’ll wind up with a null object error otherwise.

I wonder if I did something wrong?

YUI Cookie utility and single-page cookies

February 9th, 2009

I’m doing a bit of work with cookies, so I figured that I’d give YUI’s Cookie utility a try. Got it up and running on a proof of concept with no problem and it worked pretty well. However, once I moved off the proof of concept, it seemed like my cookies were only living for one page.

A quick inspection with Firecookie revealed that the Cookie utility was creating a huge number of cookies with the same name and binding them to a single page by default. (At least in 2.5.2). If you’re on that branch (I can’t upgrade a production instance, for example), make sure you add a path to the cookie you’re creating if you’d like the cookie to be readable and writable by more than the page you’re on. That would look something like this:

        YAHOO.util.Cookie.set('someName','someValue, {
            expires : new Date('January 1, 2010'),
            path : "/"
        });

That will make your cookie readable beyond a single page and might save you a headache.

Handy little for … in test

January 20th, 2009

Quick and easy:

 if(fileType in {'jpg':'','gif':'','bmp':''}){ ... }

Create the Object you’re testing against on the fly. Seems that Object creation trumps in in the order of operations (at least in Firefox 3.0).

I'm Reading…
Search This Site

AddThis Feed Button

Need great hosting?

Categories