This code dates back to the time when absolutely positioned flows were
ignored by all of their ancestors up to the containing block. This
hasn't been true for at least a year.
Closes#9306.
Closes#9309.
Is a partial fix for #9308.
r? @glennw
Source-Repo: https://github.com/servo/servo
Source-Revision: 4755cc5c6211e845fc8081cb3c8a67b4bdbea5cc
Fix#9417
For the test, I'm not sure how to simulate a mouse event or a key event in a way that it would be forwarded to the iframe.
Any idea?
Source-Repo: https://github.com/servo/servo
Source-Revision: 842ec7c41566c478c07e30c10f330f9f8595eadd
r? @frewsxcv for python stuff
r? @pcwalton for the "remove usage of Gaol" stuff for Win32
r? anybody else for misc cargo.lock updates, etc.
This replaces #7878.
This works best with https://github.com/servo/mozjs/pull/71, too, to enable static linking, but can be run without (via some PATH hackery).
The instructions are here, and will be added to a .md file in the repo once the mozjs changes also land:
https://hackpad.com/Servo-on-Windows-C1LPcI2bP25
I'd like to get these changes landed because I've been rebasing them for months, they're otherwise quite stable, and don't affect our other platforms and targets.
Source-Repo: https://github.com/servo/servo
Source-Revision: 525e77f64fc65ea2397b4ff3849f5b1f39386698
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
I've written two new tests for Fetch: one to test the highest possible number of redirects succeeds; and another to ensure a failure in Fetch by requesting too many redirects. I also wrote a helper function to be used by each test, since the main difference is how many times they try to redirect.
I've also changed the check against redirect_count in http_network fetch to compare it as greater than or equal to 20, as opposed to being only equal to 20. That's outside of the spec, but in my experience testing for pure equality can easily create errors. Even though it's technically not possible for redirect_count be above 20, bizarre bugs during runtime certainly happen.
Source-Repo: https://github.com/servo/servo
Source-Revision: c80fa3386459efd27b64c8b6cab33794e66d082b
Implement the interface HTMLDetailsElement ( // https://html.spec.whatwg.org/multipage/#htmldetailselement )
All tests pass in
tests/wpt/web-platform-tests/html/semantics/interactive-elements/the-details-element/details.html
&
tests/wpt/web-platform-tests/html/semantics/interactive-elements/the-details-element/toggleEvent.html
Anyway, no change is made on layout and attribute open currently has no effect, it just fires a toggle event.
Source-Repo: https://github.com/servo/servo
Source-Revision: 5b2d2c0ed88e8b635f91c3421b472c804dd1afe4
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
The wrapper stuff is partially-complete, modulo some unimplemented methods. The glue code is just a toy for now. Regardless, I think it's worth getting some of this stuff in-tree to minimize breakage.
Source-Repo: https://github.com/servo/servo
Source-Revision: 77d3fbcca3c6f7e8b4068f89e25b090977fe5672
I've updated http_fetch to now set response.body, as well as written a test to ensure that fetch can retrieve a message on a server. I've also looked into partially implementing some more of http_fetch while trying to figure out where response.body gets written to.
As always I'd like feedback on my logic, I'm confident there are more steps for handling response.body I need but I find the specification difficult to parse on this.
Source-Repo: https://github.com/servo/servo
Source-Revision: 175b3c2d271cdfdfcac4c3daf5cde3060748b0b8
…to net_traits.
Also updated unit tests to correctly reference and use Request and Fetch methods.
This is in preparation for XHR and EventSource (possibly WebSocket as well), which rely on using Request, but we cannot make the script crate depend upon the net crate.
cc @nikkisquared @jdm
Source-Repo: https://github.com/servo/servo
Source-Revision: ce0b89d310212aaaa66b759c7c2548fb2f9a2738
--HG--
rename : servo/components/net/fetch/request.rs => servo/components/net/fetch/methods.rs
servo/glutin@servo-v0.4.5...servo-v0.4.7
The primary reason I'm updating servo-glutin is to indirectly pick up
these changes:
vberger/wayland-kbd#9Daggerbot/x11-rs#32
...which results in two fewer libc 0.1.x dependency
servo#8608
Source-Repo: https://github.com/servo/servo
Source-Revision: 6b81a72228b54f37028e9400808768bd0d52d69f
Fixes#5439.
Please tell me if anything is wrong or needs some change!
Source-Repo: https://github.com/servo/servo
Source-Revision: a4e805d9092ae197a129fb9802bd45bf6602623e
I’ve been asked for that list by two different people this week :)
r? @larsbergstrom
Source-Repo: https://github.com/servo/servo
Source-Revision: dba1f27305c5e81eda6acd4c438a2adfb6ed053d
DOMContentLoaded event is currently set as non bubbling event.
Test :
./tests/wpt/web-platform-tests/html/syntax/parsing/the-end.html
Source-Repo: https://github.com/servo/servo
Source-Revision: 0c500a9da53145bf065804794137e2b4fc295dee
As per @jdm's suggestion that I start minimally testing the Fetch protocol to catch any errors, I wrote a very simple test that just calls Fetch and checks that the response isn't a network error. I've made changes as necessary for every failure I encountered, although this doesn't mean the implementation is faultless yet.
As always, I look forward to any feedback for improvements regarding the test itself, the changes to the fetch files I've made, and anything that I missed and should update.
Source-Repo: https://github.com/servo/servo
Source-Revision: 9c713cb4688f1a1729ada64846fac2d8426b1ef4