1071167 - [B2G][NFC] Support EventHandler for HCI EVENT Transaction

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: NFC, defect)

Description

[Garner Lee]

There is discussion on how to improve the FirefoxOS platform concerning SystemMessages (FirefoxOS only), and callbacks (W3C flavored design), to deliver data to applications where the application may not already be running.

HCI Event Transaction (A secure element API) currently uses a filterable system message to route transaction messages.

System wide application events, where the application may not be already running, are not currently well supported in FirefoxOS.

System Messages can start applications to deliver data notifications to an application. Event callbacks cannot start applications. A possible hybrid may register a "hidden" callback depending on whether the permissions for handling secure element transaction messages exist or not.

https://bugzilla.mozilla.org/show_bug.cgi?id=979767#c29

A third option mentioned, is using a W3C draft spec ServiceWorker that will add another option for application developers, as mentioned in the following group discussion thread. However, this API model appears to have only one service instance for all apps/tabs, not per application.

https://groups.google.com/d/msg/mozilla.dev.webapi/oER2OLg40pg/9QqLSLjcWggJ

Comment 1

[Garner Lee]

Attachment: 0001-Bug-1071167-WIP.-Internal-message-handling.patch

Add a minor parallel message registration mechanism for "internal" system message names.

Comment 2

[Garner Lee]

Attachment: 0002-WIP-Remove-nfc-hci-event-transaction-declaration-req.patch

Remove requirement to declare system messages. This uses a specific permission to implicitly declare a corresponding system message when the webapp messages are is being registered/updated upon bootup.

Comment 3

[[:fabrice] Fabrice Desré]

Garner, I'm not sure to understand the design here. Can you write down the flow of events and system messages you expect?

Comment 4

[Garner Lee]

Attachment: Bug 1071167 - System Message to Event Handler Proposal.pdf

"Internal System Message" design proposal.

Comment 5

[Garner Lee]

Attachment: System Message to Event Handler Proposal.pdf

Hi, update to fix export formatting. This diagram has the basic idea (and reference some affected files) behind forwarding system messages to events.

Comment 6

[Garner Lee]

Attachment: 0001-Bug-1071167-WIP-Reserved-Internal-Message-type-handi.patch

Sync to head update (flame-kk change)

Comment 7

[Garner Lee]

Attachment: 0002-Bug-1071167-WIP-Remove-manifest-requirement-for-reserved.patch

Comment 8

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Comment on attachment 8516777 [details] [diff] [review]
0001-Bug-1071167-WIP-Reserved-Internal-Message-type-handi.patch

Review of attachment 8516777 [details] [diff] [review]:
-----------------------------------------------------------------

Fabrice asked me to have a look

Comment 9

[Garner Lee]

^ I'm actually currently cleaning up the exploratory WIP code, but the idea is there (runtime chrome only message registration).

Comment 10

[Garner Lee]

Attachment: 0001-Bug-1071167-WIP-Reserved-Internal-Message-type-handi.patch

Cleanup, and moved "reserved" permission check to SystemMessagePermissionChecker.jsm.

Comment 11

[Garner Lee]

Attachment: 0002-Bug-1071167-WIP-Remove-manifest-requirement-for-rese.patch

Comment 12

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Hi Garner,

Sorry, I don't quite understand the flow chart, or the problem that you are trying to solve here.

The current design of FirefoxOS is that there are two types of "callbacks":

A) For callbacks that should only be delivered as long as the app is running, we use DOM Events.

B) For callbacks that should be delivered even when the app is not currently running, we use System Messages.

All callbacks *should* fall into one of those categories unless I'm missing something?

What makes things a bit more complicated is that W3C Specs that fall into the B category use Service Worker Events (which are a type of DOM Events).

If there are W3C Specs that want to fire callbacks event to websites that may not be currently running, but that are not using Service Worker Events and rather use plain DOM Events, then those specs needs to be fixed. I.e. that would be a bug in those W3C specs.

The concept of delivering callbacks to websites that are not currently running is very new to W3C, so it's quite possible that specs get this wrong.


So with that background, are you trying to make the NFC API deliver callbacks only to running pages? Or pages which may not be running? Or to something else?

Or am I looking at the problem entirely the wrong way?

Comment 13

[Garner Lee]

(In reply to Jonas Sicking (:sicking) from comment #12)
> The concept of delivering callbacks to websites that are not currently
> running is very new to W3C, so it's quite possible that specs get this wrong.

Yes, I don't think there's mention of service workers yet in the W3C NFC DOM Draft 20 as of writing. And I think service workers are disabled currently in gecko (I may be wrong). Are there any Mozilla side roadmaps or updates on service workers?

I guess the question is if it ready for use yet (it may be relevant to the rest of the privileged targeted NFC APIs (W3C like). However, I think there's a desire to not have those changed again so quickly.

It's also true navigator.mozNfc.onhcieventransation isn't in a current W3C proposal, so there's that argument to wait.

> So with that background, are you trying to make the NFC API deliver
> callbacks only to running pages? Or pages which may not be running? Or to
> something else?
> 
> Or am I looking at the problem entirely the wrong way?

This one mainly (running, and not already running apps), and a bit on the "other" side to make it look more like existing NFC apis.
> Or pages which may not be running?

The current landed and working implementation is "callback type B" only.

The app might not be running, and that app could be a Wallet backed by a Secure Element Cardlet app, where UI feedback is usually desired.

There's no app selection, unless there happens to be more than one wallet App. "Access Control Enforcer" helps select the right "Application ID" via a route table pulled from the SE itself.


Example existing NFC APIs:

window.navigator.mozNfc.onpeerfound = ...
window.navigator.mozNfc.onpeerlost = ...
window.navigator.mozNfc.ontagfound = ...
window.navigator.mozNfc.ontaglost = ...

// NEW (goal):
window.navigator.mozNfc.onhcieventtransaction = ...
// Instead of current:
window.navigator.setMozSystemMessage('nfc-hci-event-transaction', func...);



----
This bug's goal is to support NFC HCI event transactions as event callbacks (A-like, delivered by B):
----

- Again, the current working landed implementation is "callback type B" only.
- The current WIP patches just combines the two callback types (A+B), but hides from the developer the fact it was a system message sending it to the application.
  - No race conditions by just having an chrome system message fire the event into the app content. At least, the timing looks correct (event arrives after content is complete or callback is set).
  - Patch part 2 (not fully required): WIP Remove manifest requirement for declaring system messages.
    - Developer just declares the permission, and the event arrives to the event callback, provided the application passes access control.
  - One callback entry point that the developer needs to pay attention to.

Comment 14

[Garner Lee]

Attachment: 0003-Test-interface.patch

Comment 15

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Ok, I *think* I understand your goal better.

You're wanting to implement the current W3C spec, which currently uses DOM Events, but for actions that should be delivered to apps even if they are not running. I.e. the callbacks are of type B, but the current spec uses DOM Events.

Is that correct?

If so, I think that the problem is that the spec is simply buggy. Using plain DOM Events to provide type-B callbacks does not work well. I think that we should count on the spec getting updated to use Service Workers in the future.

Sadly you are right that ServiceWorkers aren't implemented yet in Gecko though.

So that means that we can't currently be compliant with what the spec will look like.

But rather than trying to create something that looks like the current spec (and therefor won't work well), we should simply use system messages to deliver these callbacks.

Once we have ServiceWorkers implemented we can switch to using those instead.

Comment 16

[BMO Automation]

Firefox OS is not being worked on