Hacker News Reader

Comment by Mandatum | Hacker News Reader

Doesn't appear to be working in Firefox (a lot of things don't seem to work it Firefox anymore..) however it's working perfectly in Chrome and IE (latest).

Looking really good, I'd add Chat to it as well for people who are having issues with their mic or prefer to just listen. Actually.. Might have a crack at that this weekend.

Cheers!

View on HN

Firefox dev here. Sorry to hear you're having issues with Firefox. This has not been my experience, would love to know more specifics about apps that don't work in Firefox.

Would be hugely helpful if you could file a bug (bugzilla.mozilla.org) when you see something that doesn't work, but if you want a quicker way to help I'll file the bug for you. Just send me a one line email with the problematic URL. joshmoz at gmail

Firefox user here, thanks a lot for all the good work!

If I may ask a question while you're here, do you know if there'll be anytime soon an indicator of the degree of security of WebRTC? Right now, I don't think there is any indication if the keys-exchange is done over HTTP for example or other, which is a bit problematic if privacy is important.

Thanks!

afaik, webrtc uses srtp, which is a separate from https.

SRTP/DTLS to be specific instead of SRTP/SDES. In the past the keys were sent in SDP (using SDES--Security Descriptions) therefore over HTTP, but SRTP/DTLS is the way forward and in the spec.

I am not sure if they are using https://code.google.com/p/webrtc/source/browse/stable/sample... -- it works as a charm on our application.

It seems Firefox's implementation of web audio API is not the same as Chrome or Safari.

Our app that plays audio in sync on multiple devices plays the audio but is out of sync with Safari and Chrome devices.

Any plans to follow safari's and chrome's implementation?

You'll really have to be more specific than that. Firefox's implementation should be standards compliant, from what you said it's impossible to determine if Firefox has a bug, or the app is badly written and relies on non-standards-compliant behavior that only happens to work in WebKit.

If it's the latter, then no, Firefox will not do that.

It's not a problem with the API itself. In Gecko, the time between starting playback and the audio actually beginning is perceivablely greater than in Webkit browsers. It could be resolved by simply delaying start in Gecko, but that's a less than ideal solution.

I think it's just something to do with WebRTC, I'll have a better look once I'm home and file a bug. Firefox is still my go-to browser, it's usually just the new stuff that hasn't been implemented yet in the release version that I have issues with.

Thanks for your work! Mozilla's one of my favourite companies!

chrome, the IE6 of today!

sacarms aside, nobody realize the similarity? defining standards by releasing first? all the cool prototypes at my company are done in chrome and only tested in chrome, before they become internal tools... which will require chrome 32 from 5 years on sice they will probably move to some other prototype while someone in the sales team base his team workflow on that tool...

the pattern is almost the same.

the nice thing is that chrome auto updates, so most of the version specific chrome "things" either break fast or are not version specific.

the other nice thing is that chromium is open source, so if they do something truly novel, there is a publicly visible source repo.

until it updates to something that break that prototype that is now used by the sales team.

Do you really think IE6 is here because people don't want to upgrade to IE7,8,9,10? It is there because the lame code fail on anything but IE6. Just like 10yrs from now several applications will fail on anything but chrome32 or something.

I had the same thought, but a different conclusion. In my opinion, it's Chrome vs other browsers instead of Chrome 32 vs Chrome xx.

A lot of cutting edge apps rely on interesting features of Chrome... features that other browsers may or may not implement. Sometimes it's not even browser features, it's the Javascript engine speed (although the last couple versions of Firefox have hugely improved in that regard).

> rely on interesting features of Chrome... features that other browsers may or may not implement

or chrome 36 may implement differently.

It's balanced by prototypes running only on iOS devices. At least there's no monopoly on frustration!

it should be easy for the devs' to add the interop shim for WebRTC to make it work in both Firefox and Chrome: https://code.google.com/p/webrtc/source/browse/stable/sample...

Reply on news.ycombinator.com