This has now landed in Bug 1431050 - remaining consumers were either
migrated to console.assert or changed to throw an exception.
You can continue to use console.assert instead of NS_ASSERT in JS. If you
find a case where console logging from chrome code doesn't do what you
expect please let me kn
On Mon, Feb 26, 2018 at 7:02 PM, Brian Grinstead wrote:
> console.assert doesn't throw an exception, and neither does NS_ASSERT. So I
> don’t think replacing consumers with exceptions is correct if we want to keep
> the current behavior. But I guess the intent for places code in bug 1431050
> i
+1 Please make NS_ASSERT die.
On Mon, Feb 26, 2018 at 09:37:09AM -0800, Brian Grinstead wrote:
There have been some improvements to the console API for chrome callers
recently:
* The WebIDL implementation is available as a global in JSMs - no need to
import Console.jsm (bug 1425574)
* Chrome
console.assert doesn't throw an exception, and neither does NS_ASSERT. So I
don’t think replacing consumers with exceptions is correct if we want to keep
the current behavior. But I guess the intent for places code in bug 1431050 is
to change the behavior and make those assertions throw? If that
We were already working with a contributor to remove NS_ASSERT and debug.js in
https://bugzilla.mozilla.org/show_bug.cgi?id=1431050 and we were just
replacing those few calls with simple exceptions.
The usage is not particularly spread in the codebase and the benefits
in ruining Nightly testers lif
There have been some improvements to the console API for chrome callers
recently:
* The WebIDL implementation is available as a global in JSMs - no need to
import Console.jsm (bug 1425574)
* Chrome console API calls print to stdout if "browser.dom.window.dump.enabled"
is true (bug 1439686)
* `c
6 matches
Mail list logo
