- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [X] These changes fix#11185
- [X] These changes do not require tests because it only removes dead code.
----
This fixes#11185.
Source-Repo: https://github.com/servo/servo
Source-Revision: 2c674d0397927ef6563feb70e54f46815af55600
Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `__` with appropriate data:
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [ ] These changes fix #__ (github issue number if applicable).
Either:
- [ ] There are tests for these changes OR
- [X] These changes do not require tests because no functional change
Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process.
Source-Repo: https://github.com/servo/servo
Source-Revision: ea84601bf08618254200b3faca055c36e9ff29b4
* Rewrite constructors of `Blob` and `File` with `DataSlice` as argument
* Update WebIDL of `Blob` and `File`
* Implement missing interfaces of `File` (However, due to lack of working `ArrayBuffer/ArrayBufferView` in `Blob`, so it still differs from spec)
* Update WPT test `File-constructor.html`
Source-Repo: https://github.com/servo/servo
Source-Revision: 392135bd0c2f512a0d632a7d76e667bc9af8f4a7
Adresses #9949.
This adds a function that tests whether a request should be blocked or not based on it's url's scheme and port. It also adds testing for port restriction to the `main_fetch` method. More info in eb07418c83.
@Ms2ger In https://github.com/whatwg/html/issues/841, @annevk proposes to remove port restrictions from websockets. Should we go ahead do that, given that the spec hasn't been changed yet?
Source-Repo: https://github.com/servo/servo
Source-Revision: 0008c07dc343d911be042516b32c994fc18e3900
Trigger a WebSocket error after receiving an invalid message from the server. Rebased from #8868. Fixes#7861.
Source-Repo: https://github.com/servo/servo
Source-Revision: 26b40afe237f97ebd81d537e8ed1201c7c1e4011
components/script/dom/bindings/global.rs modified -> all *_thread_source occurrences renamed to *_task_source to comply with spec
Source-Repo: https://github.com/servo/servo
Source-Revision: 63dc161b773775c6755a604ec04b81c0bc479bf3
Addresses both cookies in request and response. Resolves#9540.
Source-Repo: https://github.com/servo/servo
Source-Revision: bc034845b7e543e4e71fa21d6bf99e9f10ddb6c5
The origin field is part of location and url spec but hasn't been implemented in servo yet.
https://html.spec.whatwg.org/multipage/browsers.html#dom-location-originhttps://url.spec.whatwg.org/#dom-url-origin
All of the logic to calculate the url origin exists in https://github.com/servo/rust-url
This review threads through rust-url origin implementation into the servo location and url API.
This fixes one websockets test:
servo/tests/wpt/web-platform-tests/websockets/opening-handshake/003.html
testing done:
./mach test-wpt tests/wpt/web-platform-tests/websockets/
I'm brand new to rust so feedback is appreciated, thanks!
Source-Repo: https://github.com/servo/servo
Source-Revision: 1c6fb0f04e0cf305f4e1f75371be84944b1e5518
Fixes#7860.
This also changes quite a bit about how close codes are implemented, I believe bringing them closer in line with the spec. Instead of saving off the close code sent by the client, it uses the code from the server's closing handshake. It also handles `NO_STATUS` in what I believe is the correct manner. Making this work required a change to the test harness to make the `/echo` websocket handler echo the code sent by the client and handle `NO_STATUS` properly, rather than always replying with `NORMAL`.
Source-Repo: https://github.com/servo/servo
Source-Revision: 6663f28f0de308c9365b360cd8ad9ee9e43127ee
Addresses #8177
I also noticed some bugs/gaps (and at least one of my TODO's can be an E-Easy)
cc @jdm
Source-Repo: https://github.com/servo/servo
Source-Revision: 63923bc7c923587652fb966f1f45009e483b1ebf
`Event` internally stores the `type` as an `Atom`, and we're `String`s
everywhere, which can cause unnecessary allocations to occur since
they'll end up as `Atom`s anyways.
Source-Repo: https://github.com/servo/servo
Source-Revision: 99fd946130c9f06433b47c7f60241d5f7ad14a5b
This is a pull request for part of https://github.com/servo/servo/issues/6638
It includes the following changes:
-The websocket networking code (ie. making a connection, receiving data, and sending data) has been extracted out of components/script/dom/websocket.rs and into the new file components/net/websocket_loader.rs.
-websocket.rs now communicates with the resource task (components/net/resource_task.rs) to instruct it to initiate a new websocket connection
- websocket_loader.rs now provides an API sent over an IPCChannel that allows websocket.rs to receive feedback about this process and to subsequently send and receive data
Source-Repo: https://github.com/servo/servo
Source-Revision: 951ab565d150b4f108254e06a14ccbe7f1005469
This patch makes DOMString an opaque wrapper round String (currently it's a transparent wrapper).
The changes are:
* Replacing DOMString(foo) by DOMString::from(foo).
* Replacing foo.0 by String::from(foo).
* Adding functions clear, push_str and extend for in-place mutation of DOMStrings.
* Replacing DOMString by String in other threads (devtools, storage and filereader).
* Making DOMString implement !Send.
* Removing the pub attribute from the contents of DOMString.
This enables experimenting with other string representations in the DOM.
Source-Repo: https://github.com/servo/servo
Source-Revision: 62acdd303b78951885c2c90747b31f318907d6c9
I'm working on resolving https://github.com/servo/servo/issues/8213 as per the spec online and feedback in the servo channel. Note that currently I cannot build (and thus test) my code, so this is a bit of a rough first draft. I'd still like feedback on my progress, and I hope that there is another way for my code to be tested.
Source-Repo: https://github.com/servo/servo
Source-Revision: 021f441d24893861d45fec0cef7ed88dc9e6543a
The existing implementation could panic; make sure that doesn't
happen by requiring that the contents of a RefCell are trivially
traceable (i.e. the value don't contain any traceable objects).
I'm not sure whether the TriviallyJSTraceable trait is actually
worthwhile; maybe we should just never use RefCell in the DOM.
Source-Repo: https://github.com/servo/servo
Source-Revision: 4f51710ed387baa1ad0a6e4cdb0fc5eee44093d5
Removes all those messy FooCast structures in InheritTypes.rs.
Source-Repo: https://github.com/servo/servo
Source-Revision: 674589c370d978f543e71f995d58c5b28e6e9842
This adds a readonly bufferedAmount attribute to Servo's websocket implementation.
Source-Repo: https://github.com/servo/servo
Source-Revision: 0e4abddd37b1808033ad8811552575713fe7fa5a
This should fix#7858. An empty `USVString` is now used when `data` is `None`.
Source-Repo: https://github.com/servo/servo
Source-Revision: 8c81d9ab28132cff1d792b5c99e98bea6f7870bd
The data field is currently not used (no reads/ writes). This commit
removes this temp. field.
Ref.-Issue: #7859
Source-Repo: https://github.com/servo/servo
Source-Revision: 94816bb3b42e50127db56e64086843b14614ca88
