As far as I know both Firefox and Chrome link against libnss, not openssl, so they would not be vulnerable to this bug.

More generally, it's my understanding that either end of a TLS connection can send a heartbeat request, so clients using openssl would be vulnerable (assuming they use an affected version, with heartbeat support).

Chrome:

a recursive search on the libraries linked to in Chrome on OSX shows that the OSX system wide Address Book uses OpenSSL. Specifically LDAP. Here is the dependency tree that leads to OpenSSL on OSX Mavericks:

     /Applications/Google Chrome.app/Contents/MacOS/Google Chrome
     /Applications/Google Chrome.app/Contents/Versions/34.0.1788.0/Google Chrome Framework.framework/Google Chrome Framework
     /System/Library/Frameworks/AddressBook.framework/Versions/A/AddressBook
     /System/Library/Frameworks/LDAP.framework/Versions/A/LDAP
     /usr/lib/libssl.0.9.8.dylib
     
     $ strings /usr/lib/libssl.0.9.8.dylib | egrep '^OpenSSL'
     OpenSSL 0.9.8y 5 Feb 2013

0.9.8 is not effected so Chrome on OSX should be fine. (src: https://www.cert.fi/en/reports/2014/vulnerability788210.html -- versions 1.0.1 to 1.0.1f)

Safari:

A similar search of safari shows some inclusion of OpenSSL code in the system wide Security.framework as a part of libsecurity_apple_csp. It is unlikely the bug crossed over as the inclusion is limited.

     $ strings /System/Library/Frameworks/Security.framework/Versions/A/Security \
       | grep OpenSSL
     OpenSSL DH Method
     OpenSSL DSA method

Firefox:

On OSX it is using the same security framework as safari.

Thanks for the in-depth analysis! If it's not calling any OpenSSL functions, I doubt it's vulnerable since then OpenSSL isn't managing the connection so it couldn't receive any heartbeat effects.