It turns out that certain objects such as a DOMRectList have peculiarities
that cause string comparison to throw. This is normally not a problem
as error.isError is usually passed JSON serialisable data. But when it
is not, this try condition helps diagnose problems.
MozReview-Commit-ID: BLNSziwfxXs
--HG--
extra : rebase_source : 8bad973a20d8b69fa27f5de66e4ea287d4bcddcd
Generally, Error prototypes that are not based on WebDriverError must
be wrapped so that they can be serialised across the AsyncMessageChannel.
MozReview-Commit-ID: EtkpEOBhrST
--HG--
extra : histedit_source : c35a686b6b9cea4ae50d0d63223f4cdde6f6e4a2
extra : rebase_source : 4aad87845982cc81fec375ae9f63223a58003aec
extra : commitid : 825ScXhXQSy
extra : source : 1f5e37f8e44641e5434d8393f307f2ea4e80cdc6
extra : intermediate-source : dc6460e0f336c151be27bd124935b52361ea9557
Due to a previous programming error, error.isError only recognised
the base Error prototype. It must also test for the other built-in
prototypes, such as TypeError et al.
MozReview-Commit-ID: HLkiOAg0Jl1
--HG--
extra : histedit_source : 77fd0e6b6471b18528c27954e6348f93fc520d64
extra : rebase_source : 0e6d2085c37f2a2646c560b10e0c35eead6fcd3a
extra : commitid : F50Xhg2Q86e
extra : source : aec0a01666851a1e03dcb139e1766bae0c1b0fd7
extra : intermediate-source : 36526a2e8b0071b9f51cc30d5b6e0b5c345ec437
Generally, Error prototypes that are not based on WebDriverError must
be wrapped so that they can be serialised across the AsyncMessageChannel.
MozReview-Commit-ID: EtkpEOBhrST
--HG--
extra : commitid : 825ScXhXQSy
extra : rebase_source : 1d2b7022e311ced9a07830f1017449fbb6220454
extra : source : 1f5e37f8e44641e5434d8393f307f2ea4e80cdc6
extra : histedit_source : c35a686b6b9cea4ae50d0d63223f4cdde6f6e4a2
Due to a previous programming error, error.isError only recognised
the base Error prototype. It must also test for the other built-in
prototypes, such as TypeError et al.
MozReview-Commit-ID: HLkiOAg0Jl1
--HG--
extra : commitid : F50Xhg2Q86e
extra : rebase_source : e7a81b7c07a59209c689b9a53895c17377e39692
extra : source : aec0a01666851a1e03dcb139e1766bae0c1b0fd7
extra : histedit_source : 77fd0e6b6471b18528c27954e6348f93fc520d64
Generally, Error prototypes that are not based on WebDriverError must
be wrapped so that they can be serialised across the AsyncMessageChannel.
--HG--
extra : commitid : 825ScXhXQSy
extra : rebase_source : c525b539b5139d479ea562614c26e46d3fb01bb8
extra : histedit_source : c35a686b6b9cea4ae50d0d63223f4cdde6f6e4a2
Due to a previous programming error, error.isError only recognised
the base Error prototype. It must also test for the other built-in
prototypes, such as TypeError et al.
--HG--
extra : commitid : F50Xhg2Q86e
extra : rebase_source : 3f757bf9667763718d54fcb6912156bcdcd9e787
extra : histedit_source : 77fd0e6b6471b18528c27954e6348f93fc520d64
This fixes an instance of passing an Error prototype over the message
manager as a CPOW. We solve this by marshaling the error, which is
now done automatically by the new AsyncMessageChannel. It allows us to
create an (almost) transparent promise-based interface between chrome-
and content contexts.
The patch also makes AsyncMessageChannel reusable on both sides of the
message listener, but it's currently not used at its maximum potential
because of the way the listener is architected.
--HG--
extra : commitid : EQd5E4Digdv
extra : rebase_source : 8e0c36960759d25c73bbbc0f4f0bcb453c1028f4
extra : amend_source : 6bb6a76a8b30a5524639f8236291980b16402e6a