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
Hi, this should fix#8841!
Any change that might be needed please tell me
Source-Repo: https://github.com/servo/servo
Source-Revision: fed41a42da7a369dafd5d1eed52604ed6e683754
Resolves#9222. Moved Epoch from components/msg/compositor_msg to
components/gfx_traits/lib. Updated use statements to reflect the move.
Source-Repo: https://github.com/servo/servo
Source-Revision: e89dd05a169aa16267bdb2dbfe5bca01ad6cfe84
Separated layout-specific messages to the constellation out from the `ScriptMsg` enum into a `LayoutMsg` enum within `script_traits/script_msg.rs`, addresses [#8843](https://github.com/servo/servo/issues/8843).
I initially tried to move `LayoutMsg` into `layout_traits/lib.rs`, but this introduced a cyclic dependency: `layout_traits` depends on `script_traits` for the `LayoutTaskFactory` implementation, and `script_traits/script_task.rs` now depends on `LayoutMsg` for new layout channels in `InitialScriptState` and `ScriptTask`.
Source-Repo: https://github.com/servo/servo
Source-Revision: 941653da653a1925ade35597e97f61a6a8a0018d
Moved ScriptToCompositorMsg enum and EventResult enum to script_traits
resolving issue #8835.
(Need to be checked)
Variants in ScriptToCompositorMsg enum and EventResult enum had no doc
comment. I found some with grep command and copied it, and others I
wrote some doc comments manually to pass the build system. It needs to
be checked whether the doc comment is proper or not.
Source-Repo: https://github.com/servo/servo
Source-Revision: 62b11a28fa41d6665408844eb7b09d3479c4ea20
This changes several tests that contain <iframe></iframe> from FAIL to TIMEOUT. This is correct
since there is a bug that prevents these iframes from ever rendering.
~~~There are also a few previous FAILs that changed to OK. These may be intermittents or they
may genuinely be fixed by this change.~~~
Source-Repo: https://github.com/servo/servo
Source-Revision: c6ae32abdde715dbdc3097a40ab7abdbc98cf4b0
Review of documentation that was missing needed.
Fixes#8833.
Source-Repo: https://github.com/servo/servo
Source-Revision: 7438bc0425749989b8aab084a34ff3fff2ea6679
Fixes browser.html blocker #8759. r? @pcwalton
This adds a slow path for cases where the compositor's layer-based hit testing is incorrect. If the script task discovers that a mouse event should have been dispatched to an iframe, it bounces the event back to the constellation to be forwarded to the correct pipeline.
This isn't terribly slow (on the slow path, it adds one extra round-trip message between script and constellation), but if we want to optimize this better we could instead replace the compositor's layer hit testing with display list hit testing in the paint task. This would be a more complicated change that I think we should save for a follow-up.
This only fixes mouse input for now. A basically-identical change will be needed for touch-screen input, whether we stick with this approach or switch to the paint task.
Source-Repo: https://github.com/servo/servo
Source-Revision: bc62b5aadb62267582fbd65daa28438ce6c6ac9c
Multiprocess mode is enabled with the `-M` switch, and sandboxing is
enabled with the `-S` switch.
Rebase of #6884.
Source-Repo: https://github.com/servo/servo
Source-Revision: 8b39b9afed6ef8a3d7d3e6609fd301a37825d3e1
Stylesheets for `HTMLLinkElement`s are now loaded by the resource task, triggered by the element in question. Stylesheets are owned by the elements they're associated with, which can be `HTMLStyleElement`, `HTMLLinkElement`, and `HTMLMetaElement` (for `<meta name="viewport">).
Additionally, the quirks mode stylesheet (just as the user and user agent stylesheets a couple of commits ago), is implemented as a lazy static, loaded once per process and shared between all documents.
This all has various nice consequences:
- Stylesheet loading becomes a non-blocking operation.
- Stylesheets are removed when the element they're associated with is removed from the document.
- It'll be possible to implement the CSSOM APIs that require direct access to the stylesheets (i.e., ~ all of them).
- Various subtle correctness issues are fixed.
One piece of interesting follow-up work would be to move parsing of external stylesheets to the resource task, too. Right now, it happens in the link element once loading is complete, so blocks the script task. Moving it to the resource task would probably be fairly straight-forward as it doesn't require access to any external state.
Depends on #7979 because without that loading stylesheets asynchronously breaks lots of content.
Source-Repo: https://github.com/servo/servo
Source-Revision: 7ff3a17524e0e703e3ac279441729c185444be24
…s to a new one for the first time. Resolves#7865.
Source-Repo: https://github.com/servo/servo
Source-Revision: 4067960ba5d309ec6c4c6aef6e7aa231aca0e5d5
Instead of just converting the mouse into a single "touch" input, Servo can now listen for multi-touch events from Glutin, maintain a list of active touch points, and dispatch events for all of them.
r? @glennw (for the compositor changes) and @jdm (for the DOM changes)
Source-Repo: https://github.com/servo/servo
Source-Revision: 3fdaa6e3f32f6996c416e75119177b98d404adb2
This implements just enough of [Touch Events](http://w3c.github.io/touch-events/) to enable scrolling on Android without regressing basic single-touch interaction like clicking on links.
Dragging a page will scroll it, unless the page calls `preventDefault` on the "touchstart" event.
Does **not** yet support pinch zooming or other multi-touch gestures or events.
Includes a `-Z convert-mouse-to-touch` command line flag for testing on non-touch platforms. This is also enabled by default on Android because Glutin currently translates touch input to mouse events on Android.
Source-Repo: https://github.com/servo/servo
Source-Revision: dcd207f9bf15c9ecf5d043385ba93277e69201f6
This is an rough solution to the issue described in #3396. XHRs still do their own thing and an overall clean up is in order. Before I do that, though, I'd really like someone to sign off on the overall idea.
There's one major difference to what jdm layed out #3396: The timers remain with the window/worker and only the earliest expiring one is coordinated with the dedicated timer thread.
That means both the timer thread and the window/worker have to keep track of which timer expires next, which feels a bit wonky. However, the upshot is that there's no need for communication with the timer thread when a pipeline is frozen, thawed or dropped.
Most relvant parts are
- the [`TimerScheduler`](6f5f661958 (diff-74137a6f50ab38e7a1e4d16920a66ce7R73)), which is the new per-constellation timer task and
- the [`ActiveTimers`](6f5f661958 (diff-86707d952414a2860b78bcf6c1db8e2eR34)) which is what's left on the window/worker side.
Source-Repo: https://github.com/servo/servo
Source-Revision: 2de5407cdabef67ed03b2ad4edf4a22541d77875
This doesn't change any functionality, but it's the first step towards removing SubpageId.
Adding this change now will allow us to gradually change over code referencing subpage id rather than in one massive PR.
Introduces a namespace for pipeline ID generation - there is a namespace for the constellation thread, and one per script thread.
Source-Repo: https://github.com/servo/servo
Source-Revision: 098bdb5f22500a6e856b085a1140090f63ef8645
This is a direct extract from my abandoned PR for a lint (#7546), along with some rather clumsy modifications (only on `components/script/dom/mod.rs` and `components/style/lib.rs`), because I had to sort some of the files again to make peace with tidy, which hasn't been educated about sorting yet!
Source-Repo: https://github.com/servo/servo
Source-Revision: a7208869f2903e36f9b2f540b55b50283d7df466
The script crate had its own built-in profiling which was basically doing the same thing as the profile crate. This wraps the internal profiling around the main profile functionality. Script-related tasks are now added to the ProfilerCategory enum.
Source-Repo: https://github.com/servo/servo
Source-Revision: ca36779a7e8298918b21ae243a43a71b1520119b
Expands on the work by @wilmoz and cleans up the existing errors. Closes#7180. Closes#7111.
Source-Repo: https://github.com/servo/servo
Source-Revision: e74825f9fde8e222f4ba9bb24b2c2a3864c73e5f
SpiderMonkey provides an extremely fine-grained breakdown of memory
usage, but for Servo we aggregate the measurements into a small number
of coarse buckets, which seems appropriate for the current level of
detail provided by Servo's memory profiler. Sample output:
```
| 17.41 MiB -- url(file:///home/njn/moz/servo/../servo-static-suite/wikipedia/Guardians%20of%20the%20Galaxy%20(film)%20-%20Wikipedia,%20the%20free%20encyclopedia.html)
| 7.32 MiB -- js
| 3.07 MiB -- malloc-heap
| 3.00 MiB -- gc-heap
| 2.48 MiB -- used
| 0.34 MiB -- decommitted
| 0.09 MiB -- unused
| 0.09 MiB -- admin
| 1.25 MiB -- non-heap
```
Most of the changes are plumbing to get the script task communicating
with the memory profiler task.
Source-Repo: https://github.com/servo/servo
Source-Revision: 2b0bdbe1c195f2f6dd7671981999d622c505fbc5
This will make it easier to adapt to IPC.
The trickiest part here was to make script tasks spawn new layout tasks
directly instead of having the pipeline do it for them. The latter
approach will not work in multiprocess mode, because layout and script
must run in the same address space and the pipeline cannot inject tasks
into another process.
r? @larsbergstrom
Source-Repo: https://github.com/servo/servo
Source-Revision: e06eaa0064f49bc215e3851f0a3686e1191b356a
My previous attempt (1303dd6e2e1af39b13b57986f154a67f9e7490e7) was foiled by
a typo that made the requirement only apply to the next item.
Source-Repo: https://github.com/servo/servo
Source-Revision: 5386b0122c52a2e869065676d46b242a4ddd1726
Sorry for not doing it yesterday, I couldn't.
cc @metajack @SimonSapin
Source-Repo: https://github.com/servo/servo
Source-Revision: 4ebb95ccd8e034007eacb447a054919ef4af2bf7
