It turns out that the temporary fix for bug 1528690 might be the right way to
do. Based on the recent crash reports, the mResultCode for the Transaction
object wasn't an NS_OK and the crashing operation hasn't updated the failure to
that yet. So, the right way to do here is that we should abort the operation on
the connection thread.
Differential Revision: https://phabricator.services.mozilla.com/D32004
--HG--
extra : moz-landing-system : lando
This API abstracts away the details of the decision on what context should be
partitioned away from the consumers and centralizes the decision making into
the same location in the code base.
Differential Revision: https://phabricator.services.mozilla.com/D29742
--HG--
extra : moz-landing-system : lando
We can run /debug mochitests against geckoview for the cost of another dozen
or so test annotations. Both /opt and /debug mochitests are nearly worthy of
tier 1, but still waiting for bug 1534732.
Differential Revision: https://phabricator.services.mozilla.com/D30931
--HG--
extra : moz-landing-system : lando
This API abstracts away the details of the decision on what context should be
partitioned away from the consumers and centralizes the decision making into
the same location in the code base.
Differential Revision: https://phabricator.services.mozilla.com/D29742
--HG--
extra : moz-landing-system : lando
We haven't collected any crash from the assertions in bug 1528690. So, that
means there is no a closing connection and its mInWriteTransaction flag is true
or its transaction count is non-zero.
Bug 1481164 corrects dispatching to the wrong thread for closing idle databases.
That might be related to the mUpdateRefcountFunction issue because that make it
possible to access dbInfo, transactionInfo on a Connection thread.
Therefore, this patch intends to remove the pointer check on Nightly and enable
an assertion to see if the problem is still exsit.
Differential Revision: https://phabricator.services.mozilla.com/D29187
--HG--
extra : moz-landing-system : lando
FileCreatorHelper creates a FileBlobImpl on the main-thread and, because of
this, we end up executing I/O operations on that thread, slowing down other
components. With this patch, FileCreatorHelper logic is moved to PBackground.
That the 'type' getter is still called on the main-thread because FileBlobImpl
uses nsIMIMEService which is a non thread-safe component.
Differential Revision: https://phabricator.services.mozilla.com/D27641
--HG--
extra : moz-landing-system : lando
FileCreatorHelper creates a FileBlobImpl on the main-thread and, because of
this, we end up executing I/O operations on that thread, slowing down other
components. With this patch, FileCreatorHelper logic is moved to PBackground.
That the 'type' getter is still called on the main-thread because FileBlobImpl
uses nsIMIMEService which is a non thread-safe component.
Differential Revision: https://phabricator.services.mozilla.com/D27641
--HG--
extra : moz-landing-system : lando
Key::ToLocaleBasedKey() overlooked the existence of |eBinary| type,
probably because |eBinary| was added later and the code wasn't updated
properly.
Differential Revision: https://phabricator.services.mozilla.com/D24882
--HG--
extra : moz-landing-system : lando
The real problem is because the connection was closed for some reason. This
patch won't resolve the issue by only let the operation and the transaction fail
to escape from the crash. Note that it also changing an assertion when the
transaction is either commiting or aborting. This is prevent the problem for
closing connection is worser than we expected.
Differential Revision: https://phabricator.services.mozilla.com/D28148
--HG--
extra : moz-landing-system : lando
When using JS_IsArrayBufferViewObject() to check ArrayBufferView object,
we should use JS_GetObjectAsArrayBufferView() to get its length and data.
Because in rare case there might be a wrapper on the object, JS_GetObjectAsArrayBufferView()
will handle it, js::GetArrayBufferViewLengthAndData() won't.
Differential Revision: https://phabricator.services.mozilla.com/D24009
--HG--
extra : moz-landing-system : lando
KeyPath [..., ''] will be serialized to have a trailing comma, when deserializing it, we should
append back the empty string. Otherwise we will get inconsistent result with the KeyPath::Parse() method, causing assertions failure.
Differential Revision: https://phabricator.services.mozilla.com/D24724
--HG--
extra : moz-landing-system : lando
