WebSerial API
Categories
(Core :: DOM: Core & HTML, enhancement, P5)
Tracking
()
People
(Reporter: tzikis, Unassigned)
References
(Blocks 1 open bug, )
Details
Attachments
(1 file)
88.67 KB,
patch
|
Details | Diff | Splinter Review |
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
Comment 2•11 years ago
|
||
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•10 years ago
|
||
The spec is not done yet.
Comment 4•10 years ago
|
||
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•10 years ago
|
||
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•10 years ago
|
||
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.
Updated•10 years ago
|
Comment 7•10 years ago
|
||
any news about this?
Comment 8•10 years ago
|
||
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•10 years ago
|
||
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•9 years ago
|
||
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.
Comment 11•9 years ago
|
||
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•9 years ago
|
||
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•9 years ago
|
||
> 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
Comment 14•9 years ago
|
||
> 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•9 years ago
|
||
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•9 years ago
|
||
(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•9 years ago
|
||
any news for that api?
Comment 18•8 years ago
|
||
I know that I am annoying but there any news.
Comment 19•8 years ago
|
||
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•8 years ago
|
||
this api will amazing with the webextension support, any plans?
Comment 21•8 years ago
|
||
(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.
Reporter | ||
Comment 22•8 years ago
|
||
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•7 years ago
|
||
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/
Updated•4 years ago
|
Comment 24•4 years ago
|
||
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
Updated•4 years ago
|
Comment 25•4 years ago
|
||
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•4 years ago
|
||
I meant to include this link in my previous post:
http://microblocks.fun/blog-2020-05-24-Running-MicroBlocks-in-the-Browser
Comment 27•4 years ago
|
||
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
Updated•4 years ago
|
Comment hidden (advocacy) |
Comment hidden (advocacy) |
Updated•1 year ago
|
Description
•