Switch Smart Card Connector to Extensions Manifest V3

[emaxx-google]

Currently, Smart Card Connector is a Chrome App. A couple of years ago we started the work on migrating it an Extension (https://github.com/GoogleChromeLabs/chromeos_smart_card_connector/projects/3), however originally this was targeting Manifest V2 Extensions.

With the new deprecation timelines (https://developer.chrome.com/docs/extensions/develop/migrate/mv2-deprecation-timeline), we should switch to Extensions Manifest V3 instead.

[Test18415]

Is it possible that this could this be an issue for us, considering the fact that we use a chrome kiosk app with manifest version 2 and also using smart card connector reader chrome app, or does this only apply for extension of smart card connector?

[emaxx-google]

Is it possible that this could this be an issue for us, considering the fact that we use a chrome kiosk app with manifest version 2 and also using smart card connector reader chrome app, or does this only apply for extension of smart card connector?

The latter is correct, so the timelines aren't pressuring as long as one stays on ChromeOS Apps.

[Test18415]

Okay, thank you, that is good news.

[emaxx-google]

Capturing one thought: probably #1152 should be enhanced in a way similar to the code touched in #1155. In other words, when we await on an incoming port, the port should initially freeze incoming messages until it's marked as "ready". Otherwise we risk the following race condition:

1. receiver: creates PortMessageChannelWaiter, and starts awaiting on it
2. sender: port = chrome.runtime.connect(...)
3. receiver: chrome.runtime.onConnect received by PortMessageChannelWaiter, and the Port is created
4. receiver: the awaited promise starts being resolved
5. sender: port.postMessage(...)
6. receiver: the Port receives the message, and discards it because there's been no service registered for incoming messages yet
7. receiver: the awaited promise gets resolved, and the code registers services, but the message that has been sent is already lost

So the fix would be to move the message handling to happen at a later step ("8") instead of step 6.