onMessage Promise.reject data

[n00b42]

Issue:

According to a comment in the polyfill browser-polyfill.js#L414 a rejected promise is expected to return the message of an Error object OR if its no Error object the object itself.
But in the latter case "An unexpected error occurred" is sent, see line browser-polyfill.js#L420.

Testcase:

background.js

browser.runtime.onMessage.addListener(
	function(data) {
		console.log("message",data)
		if(data==1) return Promise.resolve(42);
		if(data==2) return Promise.resolve({ test: true, message: "Hello" });
		if(data==3) return Promise.reject(24);
		if(data==4) return Promise.reject({ test: false, message: "Not hello" });
		return Promise.reject();
	}
);

content.js

function test(x) {
	browser.runtime.sendMessage(x)
	.then( (data)  => console.log("Resolved", data) )
	.catch( (data) => console.log("Rejected", data) )
}
test(1)
test(2)
test(3)
test(4)

Expected result:

Resolved 42
Resolved Object  { test: true, message: "Hello" }
Rejected 24
Rejected Object  { test: false, message: "Not hello" }

Actual result (Chrome):

Resolved 42
Resolved Object { test: true, message: "Hello" }
Rejected Error: An unexpected error occurred
Rejected Error: Not hello

Result (Firefox)

Resolved 42
Resolved Object { test: true, message: "Hello" }
Rejected Error: "undefined"
Rejected Error: "Not hello"

Remarks:

This behavior is more or less consistent with Firefox (undefined vs "An unexpected error occurred") but both behaviors are actual counter intuitive and not what the comment is suggesting what should happen.

As far as I understand, the actual W3 Spec does not specify the Promise interface for the onmessage listeneers and therefore I can not refer to the spec for the expected results.

Is this an issue to forward to the Firefox team? or to the w3spec? Or is there already an answer/statement or actual doc stating the counter intuitive behavior using the Error object has a purpose?

[Rob--W]

Promise rejections should not be used for control flow. There is related discussion at #210.

[thomaseizinger]

Promise rejections should not be used for control flow. There is related discussion at #210.

Am I understanding this correctly? An event listener that semantically fails should still resolve the promise but define its own error success/error format within the return value?

[fregante]

An event listener that semantically fails

I think the core issue is that Promise.reject() is equivalent to throw, and you wouldn't (shouldn't) throw 42. Always throw real errors and tools will behave as you'd expect.

If you want to return "error data", you can look at how fetch works: the promise still resolves successfully even on 404 errors and it returns an object like {ok: false, status: 404, body: Stream}

The only thing I'd fix here is to make the polyfill results consistent with Firefox’, if possible.