926940 - (webserial) WebSerial API

Status: RESOLVED WONTFIX

(Core :: DOM: Core & HTML, enhancement, P5)

Description

[tzikis]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.66 Safari/537.36

Comment 1

[tzikis]

This is a feature request for a proposed WebAPI that allows you to access local Serial ports through the browser (WebSerial API). This would allow websites to access devices like Arduinos, MaKey Makeys, 3d printers, quadcopters, etc.

A similar API has already been made available in Chrome for Chrome Apps.

Here's the original discussion in the WebAPI mailing list:
https://groups.google.com/forum/#!topic/mozilla.dev.webapi/wykkibp6BKo

I've created a wiki page that describes the problem, the suggested solutions, and a reference API which we could start with, as well as helpful links:
https://wiki.mozilla.org/WebAPI/WebSerial

Comment 2

[Florian Bender]

This API should be aimed at Desktop. IMO B2G is secondary, with tablets being a more useful target for stuff that utilizes the Serial API (e. g. development and C&C) than mobile phones. 

See also my comment on m.dev.webapi [1] for further background. 

[1] https://groups.google.com/d/msg/mozilla.dev.webapi/wykkibp6BKo/EFczqy7NqLsJ

Comment 3

[Florian Bender]

The spec is not done yet.

Comment 4

[Alex Chronopoulos [:achronop]]

I have implemented a first version of serial API for Firefox. The implementation is for Linux but it will support windows soon. It has been tested in Linux and I am in the process of checking in MAC.

The API has been implemented as a global object inside DOM and the supported methods (up to now) are

interface SerialPort {
    attribute DOMString port;
    attribute unsigned long baudrate;
    boolean open();
    boolean isOpen();
    void close();
    DOMString read( unsigned long size );
    DOMString readline();
    unsigned long write( DOMString? data );
    boolean getCTS();
    void setDTR(optional boolean level);
};

Since this is a prototype version I would like to bring it out in the open, to share some code and to continue working on it, in order to be finally imported in Firefox. I hope this is the right place to start.

Comment 5

[Kyle Machulis [:qdot] [:kmachulis] (INACTIVE)]

Hi Alexandros! You'll want to post an intent to implement to our dev-webapi and dev-platform mailing lists, as outlined here:

https://wiki.mozilla.org/WebAPI/ExposureGuidelines#Intent_to_Implement

This will let other interested developers know you're working on it and give them a chance to discuss it.

That said, have you looked at the spec that was in the works? It's at

http://whatwg.github.io/serial/

It might give you a better idea of how we were planning on dividing up the classes, doing port enumeration, etc. There's also quite a few issues in the github repo (https://github.com/whatwg/serial/) relating to the peculiarities of trying to implement this.

Comment 6

[Alex Chronopoulos [:achronop]]

Hi Kyle,
Thank you for your response! I will do as mentioned in the wiki link. I am also aware about the spec and that it is not finalized yet. I know that WebSerial API attracts many people attention including me. I beleive that some working code, may help things move forward and it will give the opportunity to discuss some code details.

Comment 7

[Daniele "Mte90" Scasciafratte]

any news about this?

Comment 8

[Alex Chronopoulos [:achronop]]

I am working on applying a basic security model in prototype as discussed here:

https://groups.google.com/forum/#!topic/mozilla.dev.webapi/cs5kFsa1Xeg

In the mean time it would be great if I receive some mentoring about how to raise the API to firefox. For example I do not know if I can update the wiki by myself or I should inform some else before etc. If anyone familiar with the process can show me the steps would be a great help. Thanks!

Comment 9

[Daniele "Mte90" Scasciafratte]

You can create a custom page on the wiki and discuss in the mailing list in this way the updated documentation is present although not official.

Comment 10

[Alex Chronopoulos [:achronop]]

Attachment: webserial_prototype.patch

This is an initial prototype of the API. It works for all linux, mac os and windows. It supports the following attributes:
port, baudrate, parity, databits, stopbits
and methods:
open(), isOpen(), close(), read(), readline(), write(), getCTS(), setDTR()

Code example:
Assuming that a serial device is connected to the system.
// Instantiate api
var serial = new SerialPort();
// Default values: port: "", baudrate: 9600, parity: "none", databits: 8, stopbits: 1
// Change port attribute
serial.port = '/dev/ttyUSB0'; // use the port that your device is connected.
// Open the port
serial.open(); // Return true on success
// Write in the port
serial.write("WebSerial API test"); // return the number of characters written (18)
// Read the message from the other end or
// if you use a tty loopback tester read it immediately 
serial.readline(); // or serial.read(18)

Binaries for all platforms are available here:
https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-1c47dbb272b4/

It does not support yet all the functionality described in the standard. Also it does not apply any security restriction. 

I upload this, in so early state, in order to receive comments about the implementation or functionality. Feel free to review/test it and post your comments.

Comment 11

[Daniele "Mte90" Scasciafratte]

Uhm i've linux 64 and i can't try your version.
The 32 bit version of firefox on my 64bit system don't work.

Comment 12

[Kyle Machulis [:qdot] [:kmachulis] (INACTIVE)]

A couple of suggestions to start.

Since almost everything involving the API hits hardware (or at least requires system calls), pretty much everything here should be returning promises. Might take a look at how we dealt with things in bluetooth, though those are mostly DOMRequest based because they predate promises in the browser.

Also, for the POSIX side of things, we already have a socket layer, it's in ipc/unixsocket. You could probably build on top of this for doing serial with what we've already got versus hauling in a whole new header we don't own or maintain.

Comment 13

[Alex Chronopoulos [:achronop]]

> The 32 bit version of firefox on my 64bit system don't work.
Find 64 bit Linux binaries here:
https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-970c076da196

Comment 14

[Alex Chronopoulos [:achronop]]

> pretty much everything here should be returning promises.
The standard already purposes returning promises for one method (not implemented yet). It is good idea to do it for the most of the methods. We can also raise a discussion in the standard about it.

> Also, for the POSIX side of things, we already have a socket layer, it's in
> ipc/unixsocket. You could probably build on top of this for doing serial
> with what we've already got versus hauling in a whole new header we don't
> own or maintain.
This is a different approach. I could investigate that option too. Unixsocket also depends on "foreign" header. Probably the rule here is, the less the better. On the other hand this seems to me as an acceptable cost.

Comment 15

[Daniele "Mte90" Scasciafratte]

I've tried with Arduino!
I've written a little sketch https://gist.github.com/Mte90/54f901ae350eb097e052 and a js example for read the output from the serial port.
Is very funny use Arduino with Firefox :-D

Comment 16

[Kyle Machulis [:qdot] [:kmachulis] (INACTIVE)]

(In reply to Alexandros Chronopoulos [:achronop] from comment #14)
> > Also, for the POSIX side of things, we already have a socket layer, it's in
> > ipc/unixsocket. You could probably build on top of this for doing serial
> > with what we've already got versus hauling in a whole new header we don't
> > own or maintain.
> This is a different approach. I could investigate that option too.
> Unixsocket also depends on "foreign" header. Probably the rule here is, the
> less the better. On the other hand this seems to me as an acceptable cost.

Ok, let me restate that then: You can't do main thread I/O, and unixsocket solves that problem for you by putting I/O into the thread gecko expects it to be in and deals with task synchronization. You /really/ do not want to have to relearn the lessons of orchestrating socket I/O in our system. The problem here is that unixsocket doesn't support windows, but getting 2 out of 3 major platforms for free ain't a bad start, and we can use the model with Win32 calls for winsock support (assuming that's how it's still done these days).

BTW, I'm currently working on WebMIDI, which will have much the same structure as what I think WebSerial will in terms of DOM and IPC plumbing. In fact, we should be able to just switch out the core and change API and the rest will "just work", because in the end these are just ports we're flinging messages at (though there's all sorts of timing wackiness in MIDI that serial won't have to deal with). Bug 836897 is where dev is happening on that, and my branch is at https://github.com/qdot/gecko-dev/tree/836897-webmidi

Comment 17

[Daniele "Mte90" Scasciafratte]

any news for that api?

Comment 18

[Daniele "Mte90" Scasciafratte]

I know that I am annoying but there any news.

Comment 19

[Alex Chronopoulos [:achronop]]

No worries. It seems I have been busy lately and this has fallen behind. I will try to re-activate it but it gonna take a while for sure ...

Comment 20

[Daniele "Mte90" Scasciafratte]

this api will amazing with the webextension support, any plans?

Comment 21

[Marcos Caceres [:marcosc]]

(In reply to Daniele "Mte90" Scasciafratte from comment #20)
> this api will amazing with the webextension support, any plans?

No plans, AFAIK. Plus we shouldn't be adding any proprietary APIs that are not directly related to the browser with our extensions framework... we should work towards adding this to the web instead.

Comment 22

[tzikis]

I would argue that it makes a lot of sense to add it as a webextension, while waiting for it to become a web standard

my reasoning is that with Mozilla deprecating NPAPI and WebExtension being one of the pushed towards easy, secure, cross-browser extensions (and a good replacement to NPAPI), and with Google deprecating Chrome Apps which provide the equivalent chrome.serial, a WebExtensions Serial API looks like a good replacement for both NPAPI-based Plugins & Chrome Apps that provide Serial in a more safe & cross-browser way

Comment 23

[Brad]

Hi there!  I'm wondering if there's been any news on this or the WebExtensions serial API mentioned 8 months ago.  I'm building an education tool that depends on the now-deprecated chrome.serial API to connect to an Arduino.

I seem to have a handful of migration options, but this one is my favorite if it comes together - especially since it seems most likely to work on multiple browsers sooner rather than later.  Unfortunately it _looks_ like no serial support has made it into WebExtensions[1] or Chrome's extension APIs[2].

Other options I'm considering are wrapping the tool up as a native app with a webview, or trying to make a virtual serialport connection[3] over WebUSB[4].  The former is a lot of install friction for teachers, with schools often limiting the ability to install new software.  The latter is moving along at a nice clip, but presents one extra layer to work through talking to the Arduino and is Chrome-only for now.

[1] https://developer.mozilla.org/en-US/Add-ons/WebExtensions
[2] https://developer.chrome.com/extensions/api_index
[3] https://github.com/monteslu/webusb-serial
[4] https://wicg.github.io/webusb/

Comment 24

[kgiori]

This is yet another request for WebSerial API support in Firefox. At the very least, let users set a flag to allow it, as Chrome does in their "Experimental Web Platform features" extension. As of this moment, the phenomenal MicroBlocks[1] application[2] which supports "live" physical computing education can only run on Chrome or Edge browsers. It makes me sad to tell coding educators that they must use Chrome. :(

[1] https://microblocks.fun
[2] https://microblocks.fun/run/microblocks.html

Comment 25

[jmaloney]

This is another request for supporting the WebSerial API in Firefox.

I'm the lead developer for MicroBlocks, an open-source, blocks-based programming environment for the micro:bit and other microcontrollers aimed at K-12 education. Many of the teachers, librarians, and museum staff who are using MicroBlocks have requested a browser version so make MicroBlocks easier to use in their settings. Yesterday we released a browser version that uses the experimental Web Serial API currently undergoing origin trials in the Chrome and Edge browsers.

Except for the fact that it cannot communicate with the microcontroller, MicroBlocks works great in Firefox. (It is compiled from C into WASM using the Emscripten compiler -- thank you for those technologies!) It would be great if we could one day offer educators the option of running MicroBlocks in Firefox, as well as Chrome and Edge.

Thanks for considering it!

Comment 26

[jmaloney]

I meant to include this link in my previous post:
http://microblocks.fun/blog-2020-05-24-Running-MicroBlocks-in-the-Browser

Comment 27

[Marcos Caceres [:marcosc]]

As we (Mozilla) consider this API "harmful" to the Web [1], I'm going to go ahead and mark it as WONTFIX as I don't want us to give false hope that we are going to work on this.

Should our position change as the API evolves, we can then reconsider implementing it.

[1] https://mozilla.github.io/standards-positions/#webserial

Comment 28

[filipp]

It's a terrible decision that pushes away your core audience. Instead of trying to make it safe (eg. show permission request, like it's currently done with a web-camera / microphone access) you just mark it as "harmfull".

Why don't you also prohibit access to camera - it is much more harmful that access to UART-port.

I'm using a web-configurator for my drone, https://esc-configurator.com/ and you make me to switch to chrome instead because of you "policy".

I'm staying with Firefox because it's the last browser standing against Chrome monopoly. But making decisions that works against future (like prohibiting WebUsb or WebSerial) is the direct road to losing this future.

Comment 29

[Alexander Weber]

(In reply to filipp from comment #28)

It's a terrible decision that pushes away your core audience. Instead of trying to make it safe (eg. show permission request, like it's currently done with a web-camera / microphone access) you just mark it as "harmfull".

Why don't you also prohibit access to camera - it is much more harmful that access to UART-port.

I'm using a web-configurator for my drone, https://esc-configurator.com/ and you make me to switch to chrome instead because of you "policy".

I'm staying with Firefox because it's the last browser standing against Chrome monopoly. But making decisions that works against future (like prohibiting WebUsb or WebSerial) is the direct road to losing this future.

I more and more have the impression Mozilla is paid by google to force users to use Chrome or Edge. Sadly I donated 100 Euros past year before I started using ESPhome which uses WebSerial. We all know that Chrome and Edge are not our friends, but Mozilla tries really hardly to catch up.
For sure this year I WILL NOT DONATE until WebSerial and WebUSB is implemented in a proper way. Also Mozilla needs money and as common sense does not help, let's close that source. Don't be like Kodak, be smarter - the code is even done already for you.