On 18/10/17 10:45, Gregory Szorc wrote: > I agree that errors like this should have better visibility in order to > help catch bugs. > > I'm not sure changing behavior of the JS VM is the proper layer to > accomplish this. I think reporting messages from the JS console is a > better place to start. We could change the test harnesses to fail tests > if certain errors (like SyntaxError or TypeError) are raised. If there > is a "hook" in the JS VM to catch said errors at error time, we could > have the test harnesses run Firefox in a mode that makes said errors > more fatal (even potentially crashing as you suggest) and/or included > additional metadata, such as stacks.
Works for me. I'd need to check how much performance this would cost. > Another idea would be to require all non-log output in the JS console to > be accounted for. Kinda like reftest's expected assertion count. > Assuming most JS errors/warnings are unwanted, this would allow us to > fail all tests reporting JS errors/warnings while allowing wanted/known > failures to not fail the test. A problem though is background services > "randomly" injecting their output during test execution depending on > non-deterministic timing. It could be difficult to roll this out in > practice. But it feels like we should be able to filter out messages or > stacks accordingly. This looks like a much larger undertaking. > But why stop there? Shouldn't Firefox installs in the wild report JS > errors and warnings in Firefox code back to Mozilla (like we do > crashes)? I know this has been discussed. I'm not sure what we're > doing/planning about it though. I would be for it, but as a followup. _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
