moved CompositorMsg enum into compositing crate.
moved from components/msg/constellation_msg.rs
to components/compositing/lib.rs
fixes#8832
Source-Repo: https://github.com/servo/servo
Source-Revision: 4e73a30b0072dcf93bd8faa18f6ed89b7b2ad245
Review of documentation that was missing needed.
Fixes#8833.
Source-Repo: https://github.com/servo/servo
Source-Revision: 7438bc0425749989b8aab084a34ff3fff2ea6679
This commit moves the FocusType enum to the script crate and replaces all usages with the new `usage`.
Fixes#8840
Source-Repo: https://github.com/servo/servo
Source-Revision: e16c930f36582f40da4736f88675f559e7e47098
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
This makes the initial download for skia go from a 300 MB git repository to a 5 MB tarball. This should help with issues like #6132 and #7687.
Fix https://github.com/servo/skia/issues/70
This builds, but the at the moment causes a number of tidy errors for duplicated crates.
Source-Repo: https://github.com/servo/servo
Source-Revision: 8b95d7b8d860ec4c0834192083361a9fb78ddbeb
Added handlers for https://github.com/servo/servo/issues/8623:
GetWindowSize
IsEnabled(WebElement)
IsSelected(WebElement)
I am not sure how to actually verify my webdriver code works, if someone can give advice I would make the necessary changes.
Thanks!
Source-Repo: https://github.com/servo/servo
Source-Revision: a877a56e0e603c6cc8e9f951c2ad14b6fe8f9b62
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
This intentionally doesn't implement the special handling for boolean
attributes yet, since that requires some kind of exhaustive list of all
such attributes
Source-Repo: https://github.com/servo/servo
Source-Revision: 7f95693288eac546b7b31a51a6fcf80883ae533b
Supports sending keys to an element. The specification here is still
rather unfinished so the error handling and so on in this code will
need iteration as it becomes clearer what the expected behaviour is.
Source-Repo: https://github.com/servo/servo
Source-Revision: afe03870ce1a5a65b4c22f2e64155259da8b4609
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
Instead of always promoting iframes to StackingContexts, integrate them
into the display list. This prevents stacking bugs when
non-stacking-context elements should be drawn on top of iframes.
To accomplish this, we add another step to ordering layer creation,
where LayeredItems in the DisplayList are added to layers described by
the LayerInfo structures collected at the end of the DisplayList.
Unlayered items that follow these layered items are added to
synthesized layers.
Another result of this change is that iframe layers can be positioned
directly at the location of the iframe fragment, eliminating the need
for the SubpageLayerInfo struct entirely.
Iframes are the first type of content treated this way, but this change
opens up the possibility to properly order canvas and all other layered
content that does not create a stacking context.
Source-Repo: https://github.com/servo/servo
Source-Revision: 11d23a41b31c2b2846d1e9c6b40e87ba7e2a095f
This makes use of the new functionality that allows iframes to generate their own pipeline IDs in order to remove any knowledge of subpage ids from the compositor.
(This is the first of several commits removing subpage from parts of servo).
Source-Repo: https://github.com/servo/servo
Source-Revision: 1d617f332edd0036ca4cbc3890f1f44f57597906
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
StackingContexts are added to layers when it is necessary to maintain
their ordering on top of other layered StackingContexts. Instead of
tracking the information about a layer scattered around into different
structs, combine it all into LayerInfo. LayerInfo will be used in the
future to hold layer information for DisplayItems that are layerized
independently of StackingContexts.
Source-Repo: https://github.com/servo/servo
Source-Revision: 27d468b6674b81c396aa0a13d8fe9eb410c12d6e
The old code that attempted to do this during layout wasn't able to work
for multiple reasons: it couldn't know where the iframe was going to be
on the page (because of nested iframes), and at the time it was building
the display list for a fragment it couldn't know where that fragment was
going to be in page coordinates.
This patch rewrites that code so that only the size of an iframe is
determined during layout, and the position is determined by the
compositor. Layout layerizes iframes and marks the iframe layers with
the appropriate subpage ID so that the compositor can place them
correctly.
Closes#7377.
Source-Repo: https://github.com/servo/servo
Source-Revision: a0cb657fe80859dd8862361631268479d1045432
There were two problems here:
(1) The animation state update function was only called when nodes were dirty or there were new animations.
(2) When all animations for a node expired, the entry from the hash table was not removed.
The result was that once an animation began, the compositor would be running as fast as it can forever.
Fixes#7721.
Source-Repo: https://github.com/servo/servo
Source-Revision: b4b3cedc10cec47d95880bfbe55f2dbc37cd910e
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
Currently pseudo-elements, like the fragments created for ::before and
::after, with layers will have the same LayerId as the body of their
owning fragments. Instead all LayerIds should be unique.
Fixes#2010.
Source-Repo: https://github.com/servo/servo
Source-Revision: cf13e806fe2f4cf5ad5f30efd16d7bd3f501f8b3
Thanks to @Jinwoo-Song for the original commit, which I just rebased and cleaned up. Fixes#6237.
Source-Repo: https://github.com/servo/servo
Source-Revision: 6a12f00d6d392651bae10365b4c806f36d704b21
StackingContexts that should be painted on top of StackingContexts that
are already layerized should automatically get their own layer. This
will ensure proper painting order.
Source-Repo: https://github.com/servo/servo
Source-Revision: c0381c732569b9abe6282c6c750533bc271a2019
Previously, StackingContexts might have a PaintLayer. We switch the
ownership, for several reasons:
* We want PaintLayers to potentially contain something other
than a StackingContext soon.
* We want to delay the creation of PaintLayers until the last
minute, so that we can synthesize new layers for sandwiched
content.
This commit also implements the second goal. Instead of creating
PaintLayers during layout itself, wait until we are sorting and
layerizing a completed DisplayList.
Source-Repo: https://github.com/servo/servo
Source-Revision: 8e0b010117889550effa3ad793e7ee8f9b692b40
Also adds HeapSizeOf implementations/derive for some types. I've used "Cannot calculate Heap size" as a reason everywhere, because my imagination is rather limited. If you'd like me to change this message for specific types, please write something like this: "Trusted - Cannot calculate Heap size for Trusted" so that it would be easier for me to replace them through a script :)
Source-Repo: https://github.com/servo/servo
Source-Revision: a03616f379c255cc6c9b6e1d04dd7d98bd9926ce
Known issues:
* Display list optimization can sometimes optimize out elements that
should be shown. This affects the Enyo demo.
* The `overflow: scroll` container doesn't clip the inner layer properly
when borders, border radius, etc. are present.
* `overflow-x: scroll` and `overflow-y: scroll` don't work individually;
elements are scrolled all at once.
Note that multiple layers per stacking context aren't needed for the Enyo demo; rather the issue is that the height of the main area is being calculated incorrectly. (It looks like JS is measuring the height and poking in an explicit value that is too tall.)
r? @glennw
Source-Repo: https://github.com/servo/servo
Source-Revision: b05b02e11fb849e1f0153d009d8fcf0501ace8dc
Large improvement in page load times, especially in debug builds.
r? @jdm
Source-Repo: https://github.com/servo/servo
Source-Revision: d4d4d6dc013ee322282de7ec0effa54c8827a775
