PSA, I am landing additional leak tests for AudioContext IDB WebSocket
As part of: https://bugzilla.mozilla.org/show_bug.cgi?id=1451913 On Thu, Apr 5, 2018 at 12:18 PM, Ben Kelly <bke...@mozilla.com> wrote: > Hi all, > > I recently landed some test infrastructure for testing event targets for > memory leaks. This was part of fixing my service worker memory leak in bug > 1447871. I wanted to let people know this existed and also ask for help > writing tests for more event targets. > > To repeat, I need help writing more tests. Please see the list of > untested APIs at the bottom of this email. > > To write an event target leak test you need to import this script: > > <script type="text/javascript" src="/tests/dom/events/test/ > event_leak_utils.js"></script> > > And then call this function: > > await checkForEventListenerLeaks("Worker", useWorker); > > The string is just a name to make reporting assertions easier. The second > argument is a callback function where you exercise the API you want to test > for leaks. In this case I'm testing the worker API: > > async function useWorker(contentWindow) { > contentWindow.messageCount = 0; > let w = new contentWindow.Worker("data:application/javascript,self. > postMessage({})"); > w.onerror = _ => { > contentWindow.errorCount += 1; > }; > await new Promise(resolve => { > w.onmessage = e => { > contentWindow.messageCount += 1; > resolve(); > }; > }); > is(contentWindow.messageCount, 1, "message should be received"); > } > > The callback function should add an event listener that holds the given > contentWindow alive. Then try to leave the API in an active state to see > if its properly torn down when the test harness closes the window. > > This particular test found that the Worker API leaks. See bug 1451381. > > I've written tests for a number of APIs so far: ServiceWorker*, XHR, > Animation, MediaQueryList, EventSource, BroadcastChannel, MessageChannel, > SharedWorker, AbortSignal, WebSocket, Notification > > The WebSocket and Notification tests have not landed yet because they > trigger assertions. These look like bugs in the respective APIs. > > There are many, many event targets in the system, though. Using searchfox > to look for subclasses of DOMEventTargetHelper I came up with a list of > event targets that are not currently tested. Some of these are deprecated > or not exposed. But a lot of these are web exposed. It would be really > great to get this kind of simple leak test written for these APIs. > > ContentFrameMessageManager > DOMRequest > ScreenOrientation > BatteryManager > OffscreenCanvas > ConstructibleEventTarget > FetchObserver > FileReader > IDBFileHandle > IDBMutableFileHandle > IDWrapperCache (and sub classes) > DOMMediaStream > MediaDevices > MediaRecorder > MediaStreamTrack > MediaTrack > MediaTrackList > TextTrack > TextTrackCue > TextTrackList > MediaKeySession > ImageCapture > MediaSource > SourceBuffer > SourceBufferList > AudioContext > AudioNode > SpeechRecognition > SpeechSynthesis > SpeechSynthesisUtterance > MIDIAccess > MIDIPort > Connection > TCPServerSocket > TCPSocket > UDPSocket > PaymentRequest > Performance > PermissionStatus > PresentationAvailability > PresentationConnection > PresentationConnectList > PresentationRequest > VRDisplay > FontFaceSet > ChannelWrapper > StreamFilter > > If one of these targets falls in your area, please try to find the time to > write a small test as described above. Also, please link it against the > meta bug here: > > https://bugzilla.mozilla.org/show_bug.cgi?id=1451787 > > Thanks! > > Ben > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
