- Most of util::memory has been moved into profile::mem, though the
`SizeOf` trait and related things remain in util::memory. The
`SystemMemoryReporter` code is now in a submodule
profile::mem::system_reporter.
- util::time has been moved entirely into profile::time.
Source-Repo: https://github.com/servo/servo
Source-Revision: d1268ec9c6633684270015e7b2619181aeb47b8b
This fixes the case of clicking a link in an iframe, going back, then clicking the link again.
Source-Repo: https://github.com/servo/servo
Source-Revision: 2f85c5bb502c2582d34772db979e27c741ee76e3
In these cases for `format!`, we're just constructing a String of the
single argument with no special format.
Source-Repo: https://github.com/servo/servo
Source-Revision: dfb8929b001c8d0fb6d5e63f5a9d6dcc17cb388a
There were a few things that were bothering me with `SetBody`:
* The 'Step 3' comment is in the wrong place
* The logic of 'Step 4' comes before 'Step 3'
* 'Step 5' was not documented
Source-Repo: https://github.com/servo/servo
Source-Revision: 445f1c891a5536a26b4759ba4b2dab99c31505f4
Gives us a place to store polyfills and other userscripts so that we can:
- Quickly determine what DOM features are needed to make stuff like jQuery work by iteratively writing stub implementations
- Write spec-incompatible but "good enough" polyfills for stuff like jQuery to make Servo more testable on live sites, for demos, and for browser.html
r? @jdm
cc @eddyb
Source-Repo: https://github.com/servo/servo
Source-Revision: 72e2c79a089ff6654a36951ce4aedac62006e6a1
Fixes#1871
I thought I'd take a look at this for a first contribution to servo. A couple of things I'm not 100% sure on are:
1) `get_proto_or_iface_array` returns a `*mut *mut JSObj`, which I'm assuming is really an array of pointers to `JSObj`s. So dropping its return value will drop the memory for the array of pointers. Do we also need to drop each element, or is that handled by GC?
2) Are there any tests I need to add for this? I don't know if there are existing leak tests, or if leaks are mostly discovered by profiling.
Source-Repo: https://github.com/servo/servo
Source-Revision: 8998edb912b4f6efea7b2ff4e707325d7c03488c
Fixing ConsoleMsg for console.log messages in the Developer Tools web console.
Source-Repo: https://github.com/servo/servo
Source-Revision: ab8d43910ca2f3e60e3dd1417be80ab53f438b6e
This addresses #849. This PR cannot land until the corresponding PR (https://github.com/servo/html5ever/pull/91) in html5ever lands. I've done some simple testing of this code, but I don't consider it thorougly tested yet. I wanted to start getting feedback about the overall design before I spend more time polishing the details, and testing.
Source-Repo: https://github.com/servo/servo
Source-Revision: b2fb06d6e25d6728d6000c283ed1dab1e8bfabb1
Implements view-source protocol by having a view-source handler, and modifying the content type to be text/plain if that is used.
Implements text/plain handling. This allows view-source content to display as plain text.
Example usage:
./mach run http://cd.pn/x.txt
./mach run view-source:http://tinyvid.tv/
This fixes issue #4181. Issue #3649 includes "support text/plain" so this possibly fixes some of that issue as well.
Source-Repo: https://github.com/servo/servo
Source-Revision: 7bd6cb00911572e8733e462156122d974ff0c8a8
Otherwise, the new iframe may not get a valid window size until the parent frame does another reflow.
Source-Repo: https://github.com/servo/servo
Source-Revision: b4b2c63c11a38ebda3eb3235af6ffa2413a73cf1
These changeset implements the beginnings of fine-grained measurement of Servo's data structures.
@pcwalton, @jdm: are you likely reviewers for this?
Source-Repo: https://github.com/servo/servo
Source-Revision: f093620922621e1877393b03968ed0ce767fdf12
The history is now recorded per frame, but needs to be exposed in a followup PR.
Source-Repo: https://github.com/servo/servo
Source-Revision: 1092ca10192c79b4b96c25985a2c6245d369090b
@jdm This initial version has a few outstanding issues that I wanted to invite input on. Specifically:
1. I had some difficulty finding a home for the `StorageType` enum. Structs defined outside of the `script` module don't seem to be able to use the `#[jstraceable]` annotation and the `net` module (where `StorageTask` lives) doesn't have access to `script`. Per Simon Sapin's suggestion, I worked around this temporarily by creating a `TraceableStorageType` stand-in struct that was traceable and which could be translated into a regular `StorageType` when being sent to the `StorageTask`. Unsure of the best way to resolve this hack. Thoughts?
2. Apart from the `Storage` constructor used in `Window::SessionStorage` and the new `Window::LocalStorage`, there's also a method called `Storage::Constructor`. I'm unclear on what (if anything) will actually invoke this, so I'm not sure which variant of `StorageType` to use here. I've temporarily created an `Unknown` variant of `StorageType` as a placeholder.
3. I discovered that the web platform tests directory's localStorage tests. Many of them now pass despite the configured expectation that they fail. However, several do not pass. Is there a good way for me to add debug logging or otherwise get a sense of which assertion failed / what went wrong?
Thanks for your continued help!
Source-Repo: https://github.com/servo/servo
Source-Revision: b8e87ea020879090c931421cf3cec73d8cd1156f
Don't add a stylesheet if the current device does not match the media
query specified in a link or style tag.
Cheers,
cyndis
Source-Repo: https://github.com/servo/servo
Source-Revision: 660ea05ddb3b17b0bb914cb09968cbcf7c6b1aec
Table layout code has been refactored to push the spacing down to
rowgroups and rows; this will aid the implementation of
`border-collapse` as well.
r? @SimonSapin
Source-Repo: https://github.com/servo/servo
Source-Revision: 8e811229bae6b338fabcd7df602079730c942889
Fix for issue #2108. That issue mentions an `unwrap_object` which doesn't seem to exist so I renamed `unwrap` to `native_from_reflector` and `unwrap_jsmanaged` to `native_from_reflector_jsmanaged`. The latter is a bit unweildy - maybe a shorter name might be better?
Source-Repo: https://github.com/servo/servo
Source-Revision: d7e9b8b96b77377fa37fd59cdb8c44fa866b5b2e
This is a cleanup for issue #3959
Do I need to inline force_relayout?
Source-Repo: https://github.com/servo/servo
Source-Revision: 7b6e314df1b93bd749eee9036927d795f26e1590
This will be re-introduced in a follow up PR with a different usage, but I'm trying to create small, independent PRs that are easier to review than one large change.
Source-Repo: https://github.com/servo/servo
Source-Revision: 6ba3014d9b413d5d1d9911833e3ac08ecf97d65a
This fixes some test failures that begin occurring when other events (such as resize) are fixed to only occur when needed.
Source-Repo: https://github.com/servo/servo
Source-Revision: 19827658deaf21eb811203f89c78a0f99e631ad4
This patch enables the use of `arc()` on the canvas.
I couldn't add reftest this time, as it involves some antialiasing issues, and so the reference doesn't match.
Source-Repo: https://github.com/servo/servo
Source-Revision: e8f1a046c6c704915419cb75181f6e0bc402ef98
Opening this PR to invite feedback.
Of the many `match` statement candidates for conversion to `if let`, several included `if` guards. Since `if let` doesn't support this syntax, I used nested if statements. If this is undesirable, say the word and I can revert those cases to `match`.
Source-Repo: https://github.com/servo/servo
Source-Revision: d31e80f89490afe4863574c062f34b2a0df43bae
