Without this `./mach run -b -- -M` would start fine but navigating to a site would fail with:
`thread 'ScriptThread PipelineId { namespace_id: PipelineNamespaceId(0), index: PipelineIndex(0) }' panicked at 'assertion failed: mozbrowser_enabled()', /Users/ulf/Documents/Code/servo/components/script/dom/htmliframeelement.rs:163`
Source-Repo: https://github.com/servo/servo
Source-Revision: e8e354d5d3e6757c16912e7f5e6234ec5eece493
Got `etc/ci/check_no_unwrap.sh` to pass, and re-enabled it.
Source-Repo: https://github.com/servo/servo
Source-Revision: a61fc5285fa00915d538a9672c04030804f7db2d
The main issue was resources_dir_path. Every time it was called it would start from the executable's path and walk up the hierarchy to find a directory named "resources". The sandbox was granted permission to read from the found resources dir, but after the sandbox had been activated resources_dir_path would again start from the executable's path and try to find the resources dir. It would then fail with "Operation not permitted" when trying to canonicalize the path because it didn't have permissions to read metadata under ./target.
To fix this the resources dir path is now cached between resources_dir_path calls.
Source-Repo: https://github.com/servo/servo
Source-Revision: a162cfe45cceab123504289a7afc7bf06a4eeec8
A retry of #10294, which was closed due to homu issues.
Source-Repo: https://github.com/servo/servo
Source-Revision: 85f9f9626eaff12b66299eb6190955f2726b432c
In WebRender mode, we were sending two mouse move events: one with the
proper coordinates and one with the wrong coordinates, because of
incorrect fall-through. The script task would usually (but not always,
depending on timing) ignore the first event in favor of the second
event, resulting in incorrect mouse move event coordinates in most
cases.
Closes servo/webrender#238.
Closes#10298.
r? @metajack
Source-Repo: https://github.com/servo/servo
Source-Revision: 0bf0f61a56eae3e3797c73847763e6c8b882d160
Removed the methods `pipeline(id)`, `pipeline_mut(id)`, `frame(id)` and `frame_mut(id)` from constellation, which panicked when the table lookup failed.
The panics were causing race conditions, e.g. visiting google.com and resizing the page would cause a panic, most likely due to an iframe being added and removed, with the `DOMLoad` event arriving after the iframe had been removed, causing a panic.
This patch fixes#10017 and #8769 (although in non-webrender builds there's now a different panic, see https://github.com/servo/servo/issues/10017#issuecomment-198160200).
There are a few `TODO` items in the initial commit, for cases where it's not completely obvious what to do in the case of failure.
Source-Repo: https://github.com/servo/servo
Source-Revision: 7518c4de9317af3a643fc35131e556104b8693fa
This is part of the effort to harden the constellation (#10124), in this case against panics caused by channel send.
Source-Repo: https://github.com/servo/servo
Source-Revision: 821afa071e0bb4aa3c48f35b44ab8984a1ec92bc
Added flags:
* `--random-pipeline-closure-probability`: probability of each event triggering a forced exit of a randomly chosen pipeline.
* `--random-pipeline-closure-seed`: seed to use for the RNG (to remove a source of intermittent failure).
These are designed for testing the hardness of the constellation.
Source-Repo: https://github.com/servo/servo
Source-Revision: dc0e541747d41a53989fd08eb88c39ceb6036d4e
Fixes the issue where once a jump tag is clicked, the viewport rects are not updated. #9671
Source-Repo: https://github.com/servo/servo
Source-Revision: f1baba973f9bc788a65d77b59528b3719c198315
This is a change in the Browser API itself.
Before, on `mozbrowserlocationchange`, we would call `getCanGoBack()` and `getCanGoForward()`. Two asynchronous methods called on an event, which doesn't make much sense, especially because we already know on `mozbrowserlocationchange` if we can go back/forward. So here I'm adding 2 new properties to the event to tell if the iframe can go back/forward.
The way `event.detail` is defined also changed. Before, `event.detail` was a string (the new uri), now it's an object (`{uri:String,canGoBack:bool,canGoForward:bool}`).
This is one of the design flaw of the early Browser API: not using objects for the detail property, making it hard to extend the event payload.
So that makes this event not backward compatible. We can:
1. just don't care. It's up to the client to test if event.detail is a string or not if it needs to be compatible with Gecko
2. fix it in Gecko. The client will still have to test `event.detail` to make it compatible with older version of gecko
3. rename `mozbrowserlocationchange` to something else (`mozbrowserlocationchange2` ?)
Please advise.
Source-Repo: https://github.com/servo/servo
Source-Revision: db63aa423fcfc87e47d9250680737ef11d2c3d26
This avoids a flash of unstyled content, which looks especially bad in
browser.html since unstyled content is white and browser.html has a
transparent background.
Closes#9996.
r? @metajack
cc @jdm since you had some concerns
Source-Repo: https://github.com/servo/servo
Source-Revision: 84d3ba075977c55d226bd6b70d695a292b2329c9
We need to bump webrender before being able to bump Serde, but we also needs these bumps, so let's include them ASAP first because bumping a lot of things is always a pain.
Source-Repo: https://github.com/servo/servo
Source-Revision: 0f526054ebfa164ca2545d881b8392a744af7870
Previously, the flow for ticking animations was:
Compositor -> Constellation -> Layout -> Script
However, this means that the compositor <-> layout messages can thrash, meaning layout thread is very rarely idle.
This means that the script thread (which joins on the layout thread during reflow) was unable to execute and run rAF callbacks.
With this change, the flow is now:
Compositor -> Constellation -> Script (when rAF is active).
Compositor -> Constellation -> Layout (when transitions / animations are active and no rAF is present).
This makes rAF based animation *much* smoother.
Source-Repo: https://github.com/servo/servo
Source-Revision: aba500a698584e66975cd93006ca8cf745370f7d
The main reason stb_image was used for decoding JPEGs was the lack of progressive support in piston_image.
With version 0.7, piston_image gained support for decoding progressive JPEGs through use of the [jpeg-decoder](https://crates.io/crates/jpeg-decoder) crate.
This PR removes the dependency on stb_image and instead uses piston_image 0.7 for decoding JPEGs.
Source-Repo: https://github.com/servo/servo
Source-Revision: a8c321a7e0402bcfc8d8da10cc94a5b287d29ffc
Instead, schedule a delayed composite after each frame of an animation.
The previous code would cause jank, because the following sequence
frequently occurred:
1. The page uses `requestAnimationFrame()` to request a frame.
2. The compositor receives the message, schedules a composite,
dispatches the rAF message to the script thread, composites, and goes to
sleep waiting for vblank (frame 1).
3. The script makes a change and sends it through the pipeline.
Eventually it gets painted and is sent to the compositor, but the
compositor is sleeping.
4. The compositor wakes up, sees the new painted content, page flips,
and goes to sleep (frame 2). Repeat from step 1.
The problem is that we have two composition frames, not just one. This
halves Web apps' framerate!
This commit fixes the problem by scheduling the composite in step 2 to
12 ms in the future. We already have this delayed-composition
functionality in the form of the scrolling timer, which I repurposed and
renamed to the "delayed composition timer" for this task. This change
gives the page 12 ms to prepare the frame, which seems to usually be
enough, especially with WebRender.
Note that simply removing the scheduled composite after rAF is not the
correct solution. If this is done, then pages that call rAF and don't
modify the page won't receive future rAFs, since the compositor will be
sleeping and won't be notified of vblank.
Fixes a bunch of jank in browser.html. The remaining jank seems to be a
problem with browser.html itself.
r? @glennw
Source-Repo: https://github.com/servo/servo
Source-Revision: 9d47b344d9d0cf6faa3430bb32bdb4ba3eb11cf7
WebRender is an experimental GPU accelerated rendering backend for Servo.
The WebRender backend can be specified by running Servo with the -w option (otherwise the default rendering backend will be used).
WebRender has many bugs, and missing features - but it is usable to browse most websites - please report any WebRender specific rendering bugs you encounter!
Source-Repo: https://github.com/servo/servo
Source-Revision: ab07b06823ea9748a6091aee2281495f86f00bce
It occurs to me as I write this that this doesn't handle the case of removing the iframe from the document before it's finished loading. Consider this an early feedback release!
Source-Repo: https://github.com/servo/servo
Source-Revision: a31f31e81977be5215f31851885e8ab46890c556
Often, a rAF callback will request another rAF from the callback itself.
Previously, the constellation would quickly receive two messages saying
that there were no animations, and then there are animations again in the
situation above. This would make the compositor tick the new animation straight
away, causing strange fluctuations and timings in rAF callbacks.
Instead, only send the NoAnimationCallbacks message if the animation
callback queue is still empty after invoking the callbacks.
This fixes rAF timing, which now runs at the correct (vsync) framerate.
Source-Repo: https://github.com/servo/servo
Source-Revision: bc44ae679f0d4a01194777c56e09a48fbebea1ad
The first bug was that iframes were not reflowed in their parent DOM when the child page navigated. This is fixed by simply having the constellation notify the appropriate script thread when navigation occurs.
The second bug was that the compositor was unable to adjust the pipeline for existing iframe layers, only new ones. This patch adds logic to do that.
The third bug was that we have ad-hoc reflow calls throughout script/, and we didn't trigger any reflow from the code that dispatches the `load` event for the iframe so the test for the first two issues would always time out. The second commit adds another reflow call to do that, and also bites the bullet and adds a catch-all reflow (which does nothing if there's no dirty nodes in the document) at the return to the event loop.
Closes#8081.
Extension of #9285.
Source-Repo: https://github.com/servo/servo
Source-Revision: 0fa9d32c6915c9cad18e5430c10973399599458a
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
