WebExtensions crate #21
Comments
|
I would like to work on this, @Pauan would you be willing to mentor? I assume the first step is to add support for |
|
@OddCoincidence WebIDL would be nice, but it doesn't really exist (there's just the non-standard spec, which differs a bit from what the actual browsers do). There's no need to add support to wasm-bindgen, we should be able to bind to them using the Sure, I'd be happy to mentor. Do you have Discord? I'm Pauan#6666 |
This was referenced Mar 28, 2019
ranile
added a commit
that referenced
this issue
Feb 15, 2022
We no longer need a multi-producer-multi-consumer channel. There's only one consumer as of ranile/reqwasm@445e9a5
ranile
added a commit
that referenced
this issue
Feb 16, 2022
* Initial commit * provide a better interface for errors, rename `RequestMethod` to `Method` * remove method for array buffer and blob in favor of as_raw * prepare for release * add CI, update readme * hide JsError in the docs * fix CI? * Install wasm-pack in CI * misc * websocket API Fixes: ranile/reqwasm#1 * add tests for websocket * update documentation, prepare for release * fix mistake in documentation * Rewrite WebSockets code (#4) * redo websockets * docs + tests * remove gloo-console * fix CI * Add getters for the underlying WebSocket fields * better API * better API part 2 electric boogaloo * deserialize Blob to Vec<u8> (#9) * Update to Rust 2021 and use JsError from gloo-utils (#10) * Update to Rust 2021 and use JsError from gloo-utils * use new toolchain * Add response.binary method to obtain response as Vec<u8> Fixes: ranile/reqwasm#7 * Remove `Clone` impl from WebSocket. When the WebSocket is used with frameworks, passed down as props, it might be `drop`ed automatically, which closes the WebSocket connection. Initially `Clone` was added so sender and receiver can be in different `spawn_local`s but it turns out that `StreamExt::split` solves that problem very well. See #13 for more information about the issue * Rustfmt + ignore editor config files * Fix onclose handling (#14) * feat: feature gate json, websocket and http; enable them by default (#16) * feat: feature gate json support * feat: feature gate weboscket api * ci: check websocket and json features seperately in CI, check no default features * feat: feature gate the http API * refactor: use futures-core and futures-sink instead of depending on whole of futures * ci: test http feature seperately in CI * fix: only compile error conversion funcs if either APIs are enabled * fix: add futures to dev-deps for tests, fix doc test * 0.3.0 * Fix outdated/missing docs * 0.3.1 * Change edition from 2021 to 2018 (#18) * Change edition from 2021 to 2018 * Fix missing import due to edition 2021 prelude * hopefully this will fix the issue (#19) * There's no message * Replace `async-broadcast` with `futures-channel::mpsc` (#21) We no longer need a multi-producer-multi-consumer channel. There's only one consumer as of ranile/reqwasm@445e9a5 * Release 0.4.0 * Fix message ordering not being preserved (#29) The websocket specification guarantees that messages are received in the same order they are sent. The implementation in this library can violate this guarantee because messages are parsed in a spawn_local block before being sent over the channel. When multiple messages are received before the next executor tick the scheduling order of the futures is unspecified. We fix this by performing all operations synchronously. The only part where async is needed is the conversion of Blob to ArrayBuffer which we obsolete by setting the websocket to always receive binary data as ArrayBuffer. * 0.4.1 * move files for gloo merge * remove licence files * gloo-specific patches * fix CI * re-export net from gloo Co-authored-by: Michael Hueschen <mhuesch@users.noreply.github.com> Co-authored-by: Stepan Henek <stepan+github@henek.name> Co-authored-by: Yusuf Bera Ertan <y.bera003.06@protonmail.com> Co-authored-by: Luke Chu <37006668+lukechu10@users.noreply.github.com> Co-authored-by: Valentin <vakevk+github@gmail.com>
|
There is web-extensions now, which uses web-extensions-sys |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Summary
A crate which contains idiomatic high-level Rust APIs for the WebExtensions standard, which is used to create browser extensions for Firefox, Chrome, and Edge.
Motivation
I personally have made multiple Chrome extensions, so this is something I need and have a lot of experience with.
Being able to create fast and safe and maintainable browser extensions in Rust is a big deal. In my experience JavaScript just does not scale well with big extensions.
But the APIs are... well, rather terrible. So in addition to porting the APIs to Rust, we should clean them up and make them actually reasonable.
I've done this sort of work before in JavaScript, so I know a lot of the weird quirks and gotchas of the APIs.
The text was updated successfully, but these errors were encountered: