Closed Bug 926940 (webserial) Opened 11 years ago Closed 4 years ago

WebSerial API

Categories

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

enhancement

Tracking

()

RESOLVED WONTFIX

People

(Reporter: tzikis, Unassigned)

References

(Blocks 1 open bug, )

Details

Attachments

(1 file)

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
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
Keywords: dev-doc-needed
OS: Mac OS X → All
Hardware: x86 → All
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
The spec is not done yet.
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
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.
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.
any news about this?
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!
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.
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/achronop@gmail.com-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.
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.
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.
> 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/achronop@gmail.com-970c076da196
> 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.
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
(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
any news for that api?
I know that I am annoying but there any news.
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 ...
this api will amazing with the webextension support, any plans?
(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.
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
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/

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

Component: General → DOM: Core & HTML

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!

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

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

Status: NEW → RESOLVED
Type: defect → enhancement
Closed: 4 years ago
Priority: -- → P5
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: