This includes the following API:
* Debugger.Object.prototype.createSource
* startColumn field of the parameter object
* Debugger.Script.prototype.startColumn
* return value
* Debugger.Script.prototype.getPossibleBreakpoints
* minColumn and maxColumn property of the query
* columnNumber property of the returned array elements
* Debugger.Script.prototype.getOffsetMetadata
* columnNumber property of the returned array elements
* Debugger.Script.prototype.getOffsetLocation
* columnNumber property of the returned array elements
* Debugger.Script.prototype.getAllColumnOffsets
* columnNumber property of the returned array elements
* Debugger.Script.prototype.getOffsetsCoverage
* columnNumber property of the returned array elements
* Debugger.Source.prototype.startColumn
* return value
This patch modifies DevTools code to convert the column number from/to 1-origin,
while keep using 0-origin on their side.
One exception is the WASM's column number, which had been using 1-origin 1.
Each consumer in DevTools handles the WASM case, and the code can be removed
once DevTools internal also switches to 1-origin column number.
The other exception is to use 1-based column number in logCustomFormatterError,
which is folded from bug 1864783 patch.
Differential Revision: https://phabricator.services.mozilla.com/D193270
This includes the following API:
* Debugger.Object.prototype.createSource
* startColumn field of the parameter object
* Debugger.Script.prototype.startColumn
* return value
* Debugger.Script.prototype.getPossibleBreakpoints
* minColumn and maxColumn property of the query
* columnNumber property of the returned array elements
* Debugger.Script.prototype.getOffsetMetadata
* columnNumber property of the returned array elements
* Debugger.Script.prototype.getOffsetLocation
* columnNumber property of the returned array elements
* Debugger.Script.prototype.getAllColumnOffsets
* columnNumber property of the returned array elements
* Debugger.Script.prototype.getOffsetsCoverage
* columnNumber property of the returned array elements
* Debugger.Source.prototype.startColumn
* return value
This patch modifies DevTools code to convert the column number from/to 1-origin,
while keep using 0-origin on their side.
One exception is the WASM's column number, which had been using 1-origin 1.
Each consumer in DevTools handles the WASM case, and the code can be removed
once DevTools internal also switches to 1-origin column number.
The other exception is to use 1-based column number in logCustomFormatterError,
which is folded from bug 1864783 patch.
Differential Revision: https://phabricator.services.mozilla.com/D193270
Assert.rejects uses callbacks in a way that the stack no longer includes
the original caller in the stack when the stack is generated.
Consequently, when AssertionError tries to identify the caller, it is
unable to do so, resulting in a `null` stack.
This `null` stack is passed by the SpecialPowers glue to
`do_report_result` in xpcshell/head.js, which doesn't expect a `null`
stack, and consequently the following error is reported:
"TypeError: can't access property "filename", stack is null"
To fix this issue, we save the stack (including the caller) upon
entering `Assert.rejects`, and forward that to `AssertionError`.
Differential Revision: https://phabricator.services.mozilla.com/D189863
... and make sure that `Assert.rejects(Promise.resolve())` resolves even
if the `_reporter` override does not throw. This is needed for the test
to run to completion; otherwise the new Harness_sanity tests get stuck.
An extra test has been added to test_assert.js to verify that under
normal circumstances, `Assert.rejects(Promise.resolve())` rejects.
Differential Revision: https://phabricator.services.mozilla.com/D189862
Assert.rejects uses callbacks in a way that the stack no longer includes
the original caller in the stack when the stack is generated.
Consequently, when AssertionError tries to identify the caller, it is
unable to do so, resulting in a `null` stack.
This `null` stack is passed by the SpecialPowers glue to
`do_report_result` in xpcshell/head.js, which doesn't expect a `null`
stack, and consequently the following error is reported:
"TypeError: can't access property "filename", stack is null"
To fix this issue, we save the stack (including the caller) upon
entering `Assert.rejects`, and forward that to `AssertionError`.
Differential Revision: https://phabricator.services.mozilla.com/D189863
... and make sure that `Assert.rejects(Promise.resolve())` resolves even
if the `_reporter` override does not throw. This is needed for the test
to run to completion; otherwise the new Harness_sanity tests get stuck.
An extra test has been added to test_assert.js to verify that under
normal circumstances, `Assert.rejects(Promise.resolve())` rejects.
Differential Revision: https://phabricator.services.mozilla.com/D189862
Assert.rejects uses callbacks in a way that the stack no longer includes
the original caller in the stack when the stack is generated.
Consequently, when AssertionError tries to identify the caller, it is
unable to do so, resulting in a `null` stack.
This `null` stack is passed by the SpecialPowers glue to
`do_report_result` in xpcshell/head.js, which doesn't expect a `null`
stack, and consequently the following error is reported:
"TypeError: can't access property "filename", stack is null"
To fix this issue, we save the stack (including the caller) upon
entering `Assert.rejects`, and forward that to `AssertionError`.
Differential Revision: https://phabricator.services.mozilla.com/D189863
... and make sure that `Assert.rejects(Promise.resolve())` resolves even
if the `_reporter` override does not throw. This is needed for the test
to run to completion; otherwise the new Harness_sanity tests get stuck.
An extra test has been added to test_assert.js to verify that under
normal circumstances, `Assert.rejects(Promise.resolve())` rejects.
Differential Revision: https://phabricator.services.mozilla.com/D189862
Add asyncVacuum to mozIStorageAsyncConnection, that dispatches a runnable to
the helper thread, where it will execute a full or incremental vacuum, depending
on the connection auto_vacuum value.
It also supports vacuuming attached schemas.
asyncVacuum() supports changing both the page_size and auto_vacuum.
Change mozIStorageVacuumParticipant to return a mozIStorageAsyncConnection and
allow specifying whether incremental vacuum should be enabled.
Change vacuumManager notification from heavy-io-task to vacuum-begin and vacuum-end
since the original proposal of notifying heavy IO didn't take off.
Cleanup test_vacuum to be able to use instances of the test VacuumParticipant,
that means we can remove the no more necessary registerESM hack.
Fix Places History as the only cpp consumer.
Differential Revision: https://phabricator.services.mozilla.com/D168298
Add asyncVacuum to mozIStorageAsyncConnection, that dispatches a runnable to
the helper thread, where it will execute a full or incremental vacuum, depending
on the connection auto_vacuum value.
It also supports vacuuming attached schemas.
asyncVacuum() supports changing both the page_size and auto_vacuum.
Change mozIStorageVacuumParticipant to return a mozIStorageAsyncConnection and
allow specifying whether incremental vacuum should be enabled.
Change vacuumManager notification from heavy-io-task to vacuum-begin and vacuum-end
since the original proposal of notifying heavy IO didn't take off.
Cleanup test_vacuum to be able to use instances of the test VacuumParticipant,
that means we can remove the no more necessary registerESM hack.
Fix Places History as the only cpp consumer.
Differential Revision: https://phabricator.services.mozilla.com/D168298
Some of the tests that fail (or only succeed) with SHIP are currently marked for
Fission. This makes them fail once we turn on SHIP without Fission.
Differential Revision: https://phabricator.services.mozilla.com/D169824
Nipun Shukla