Constant regeneration of the NoScript menu preventing the user from whitelisting audio

[ssokolow]

Something about how this is implemented makes it impossible to allow audio on Firefox if "Apply these restrictions to whitelisted sites too" is checked in NoScript's Embeddings tab. (It allows me to keep YouTube whitelisted while reliably preventing autoplay)

Specifically, it keeps forcing NoScript to regenerate its menu so quickly that I can't keep the submenu open for more than a split second.

(While I can't read anything in the menu, would it be correct to guess that you're using an <audio> element which receives new data URIs almost constantly? NoScript does regenerate its menu whenever the list of blocked elements or the URIs they reference change.)

If so, my suggestion would be to add a test which detects that the audio element has been blocked and pauses during the interval after the element has been added but before the runtime starts to offer the user the option to select Allow *@domain from the NoScript menu.

[juj]

The audio uses the Mozilla Audio Data API, which does not do audio elements or fetching from the network (as far as I know). I am not quite sure what is going on here.

The Mozilla Audio Data API provides a JS callback that pulls new audio samples every 100 milliseconds to the device.

The Mozilla Audio Data API has since been deprecated, and Mozilla has moved to also supporting the Web Audio spec. It is an open task in the Emscripten toolchain to reimplement SDL audio in terms of the Web Audio spec.

I think this is best revisited after that task is done in Emscripten side.