ehsanakhgari

can you explain the TPO technique or perhaps point me to a reference please?

Yes, this is using the same built-in Tracking Protection feature.

Yes. Over the years we have worked on projects that would reduce the impact of bugs found by this fuzzer. For example we have prevented whole classes of security bugs that this fuzzer would find, which would reduce the priority of fixing them compared to a benign crash.

Yes, this is now common practice for all browser vendors, AFAIK.

I assume you're mentioning https://wiki.mozilla.org/Audio_Data_API. After we implemented Web Audio, we deprecated and removed support for the Audio Data API.

If you hit problems porting that to Firefox, please get in touch with me, would be happy to help you!

For whatever it's worth, we have deprecated support for the Mozilla Audio Data API in favor of Web Audio, and will remove support for it in the near future.

Yes, that should be available in Nightly and Aurora:

https://bugzilla.mozilla.org/show_bug.cgi?id=794282

You can follow this bug https://bugzilla.mozilla.org/show_bug.cgi?id=851290 if you're interested. :)

Absolutely. Feedback from developers testing their applications and ideas with the existing implementations is crucial to having a high quality spec, so if you have specific issues, please provide feedback here: http://lists.w3.org/Archives/Public/public-audio/. We'll definitely take that into consideration and we can always amend the spec based on the feedback we receive to improve things.

If you hit latency issues in Firefox, please get in touch with me. Note that we currently have a rather high latency on Android, which we have plans to fix, but things should work fairly well on desktop platforms.

Great to hear that! Is this project publicly available somewhere by any chance?

About the first and third points, it would be great if you can send detailed feedback to this mailinglist: http://lists.w3.org/Archives/Public/public-audio/. Doing that would give us a chance to discuss these issues and fix the spec if possible.

About the second point, that's not accurate. All audio processing in a conforming Web Audio implementation happens on a background thread reserved for audio processing, which does not need to wait for things happening on the main thread (including GC pauses.) In practice, Gecko's processing model uses message passing between the audio thread and the main Javascript thread. WebKit and Blink use locks to synchronize the two threads some of the times, but the locking is minimal and it should not have a huge impact on performance.

About the testing issue, the working group has started to work on it recently, and you can see the beginning of the work here: https://github.com/w3c/web-platform-tests/tree/master/webaud.... We're planning to integrate the regression tests from both Mozilla and WebKit into the test suite for the spec (http://mxr.mozilla.org/mozilla-central/source/content/media/... and http://trac.webkit.org/browser/trunk/LayoutTests/webaudio) into the test suite. And of course, contributions for more tests are always welcome.

We currently support MP3 playback for Windows Vista+ and Android if I'm not mistaken, and support for other platforms is being worked on. Web Audio will support all of the codecs supported by <audio> depending on the platform.

Do you have specific complaints? We're definitely eager to hear about them at the Audio working group.

That sounds great! Please get in touch with me if you hit any problems, would be happy to help!

This is the main thing which sucks about all this. I still don't have any clue on why this happened. The "how" is exactly how I explained it: I woke up this morning, and my account was disabled.

No, I was not using the two factor authentication feature. I still don't know what caused this, but yeah, my account might have been hacked.