Since WebRender uses the pipeline ID stored in the iframe element to
determine which pipeline to display, it had better be kept up to date!
Closes#9919.
r? @jdm
Source-Repo: https://github.com/servo/servo
Source-Revision: 3836c2c4cba1f49ea5ce3ce802b0bd604213c2a2
This is a work in progress PR for #10581. I just want to make sure I am headed in the right direction.
cc @jdm
Source-Repo: https://github.com/servo/servo
Source-Revision: daa1a2a0a82d336205dae340d705ea6c0bed4ed2
PR1 for https://github.com/servo/servo/issues/10311
This puts the code and data structures in place to set the Referer header based on the Referrer Policy for a given document. Note that document:: get_referrer_policy() always returns the 'No Referrer' option, so for now, this should have no impact on production code, and that policy requires that the Referer header is not added.
Later PRs will determine the policy and edit that get_referrer_policy() accordingly.
Source-Repo: https://github.com/servo/servo
Source-Revision: 34900814fca3b21fbb27bed58d4f4af8a8e307e9
…oading.
No bug report corresponds to this, but I noticed it while trying to
reduce #10593
Source-Repo: https://github.com/servo/servo
Source-Revision: 47a0f58f98e1a6ddcf5db24347fc6bf890d4a7d6
Added a dedicated panic channel, and removed the panic messages for the script and layout threads. This is needed so that other threads can report panics, which is part of #10334.
Note that this PR includes the commit from #10572, so should land after it lands.
r? @Manishearth
Source-Repo: https://github.com/servo/servo
Source-Revision: bd4b3a66a2aa57ab6fa881e3cc11091edc494a68
Added the panic message to failures. This is a step towards #10334, since it gives us access to the panic error message when we fire a `mozbrowsererror` event. The remaining steps are also to record the backtrace, and to report the failure in the event.
Source-Repo: https://github.com/servo/servo
Source-Revision: 2b910678db8b461dc50919832044bd95cdecb53e
In rust-url 1.0 the `Url` struct is going to have private fields, and there is no way to to create an aribitrary one without going through the parser.
The plugin never had a clear demonstrated performance benefit, it was made mostly because it was possible and relatively easy at the time.
This commit was originally part of #9840, but it’s taking a while to land and I keep removing new uses of `url!` when rebasing.
r? @nox
Source-Repo: https://github.com/servo/servo
Source-Revision: 3368565b3c6c76e5ce2d170d5c5cfb2f52a56956
This adds in preferences for all the SM 39 available options (as
retrieved from Gecko), and uses the same defaults as Gecko. A few
properties are not supported yet, and incremental GC is still always
disabled regardless of the preference setting.
Source-Repo: https://github.com/servo/servo
Source-Revision: bc2237ea2ba3beac501ca4347b8118f3dccd9629
This PR mistakenly removed JIT enabling/disabling by preference:
https://github.com/servo/servo/pull/10342/files
Look for `get_pref`.
I'm putting the missing piece of code into the appropriate place in
script_runtime.rs
r? @KiChjang
Source-Repo: https://github.com/servo/servo
Source-Revision: bead9585000eed60394b20c7a8e3788284ea458a
When creating a runtime (script.rs), we check prefs and then enable or
disable the JITs (Baseline and Ion) accordingly.
Closes#10278.
Source-Repo: https://github.com/servo/servo
Source-Revision: 863c905025e75e7119539c832e4e4647f44d90bb
This is a large-ish PR that contains the following:
* A new directory is created under `components/script/` called `task_source`, which houses all the stuff for different task sources. Note that the ones that I have now aren't exhaustive - there are more task sources than just the generic ones.
* A `DOMManipulationTaskMsg` which eliminates some usage of `Runnable`s to fire events. Instead, they send event information to the `DOMManipulationTaskSource` and lets the `ScriptTask` handle all the event firing.
* Re-added `fn script_chan`, since I can't think of any other way to give `Trusted` values an appropriate sender.
* Rewrote step 7 of [the end](https://html.spec.whatwg.org/multipage/syntax.html#the-end) to make use of the `DOMManipulationTaskSource`
Partial #7959
Source-Repo: https://github.com/servo/servo
Source-Revision: 740965e39f4d62e5807d21734ed9a7a881eca392
Now we only query for the topmost node, and apply the hover state to all
of the parent elements.
This fixes things like #9705, where the hover state was applied only to
the children.
This also makes us more conformant with other browsers in the case of
taking in account margins and paddings.
For example, prior to this PR, when your mouse was over the inner
element, in the bottom part, `hover` styles didn't apply to the parent.
```html
<style>
div {
padding: 10px;
margin: 10px;
height: 15px;
background: blue;
}
div:hover {
background: red;
}
</style>
<div>
<div></div>
</div>
```
Fixes#9705
Source-Repo: https://github.com/servo/servo
Source-Revision: 056a7cf1a2284063e5d32c6627b86f6931957a74
Fixes#3648.
Note that I have only implemented "mutate action URL" and "get action URL". The remaining ones can have E-less easy issues created for them.
Source-Repo: https://github.com/servo/servo
Source-Revision: fe70efe07f6d72665f10c752884e5705d5bdc600
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
Fixes#8544
No test yet. Is there a way to mock a https connection?
Also, I wish I could use the `HTTPSState` enum instead of a `String` when calling `trigger_mozbrowser_event` (https://github.com/servo/servo/compare/master...paulrouget:securitychange?expand=1#diff-30a18e04d7e0b66aafdf192e416cad44R306) but that would require `constellation_msg.rs` to know about `HTTPSState`, which is defined in `document.rs`, which would add a dependency to `components/msg`. I could define `HTTPSState` somewhere else maybe? Or maybe it's fine to use a `String`. But then, should I use the HTTPSState strings (`"modern/deprecated/none"`) or the mozbrowser strings (`"secure/insecure/broken"`) (as it is now)
Source-Repo: https://github.com/servo/servo
Source-Revision: 3d63f09361afa80b9d5c4f6b192c9bd8936094b7
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
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
