GoogleChromeLabs/chromeos_smart_card_connector

Switch Smart Card Connector to Extensions Manifest V3

Opened this issue · 4 comments

emaxx-google commented

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 commented

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 commented

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 commented

Okay, thank you, that is good news.

emaxx-google commented

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.