| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Replace GamepadList
* Fix initial gamepad connection event from gilrs getting dropped
* Fix gamepad reconnection issues, use MutNullableDom
* Reduce some repetition in handle_gamepad_events
* Address feedback, move some steps to navigator methods
* Refactor internal navigator gamepad methods
* Add note re: unused gilrs index, adjust navigator gamepad methods
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Implement missing gamepad slots, align to spec more
- Fixes TODO's from initial gamepad implementation
- Adds some missing spec steps
* Only handle gamepad events when pref is enabled
* Return empty list in getGamepads if document not active
* ./mach fmt
* Update getGamepads to return an array instead of GamepadList
* Add spec link for [[exposed]] slot
* Remove failing test expectations for not-fully-active
* A few fixes
- Change should_notify to has_gesture
- Add spec links and TODO to navigator
- Remove unneeded clone from GamepadList::list
- Move gamepadconnected event firing into has_gesture block
* Use queue_with_canceller for tasks and add expects
* Explicitly check for gamepad user gesture
* Move user gesture check into separate function
* Change contains_user_gesture to be a gamepad function
* mach fmt
* Change axis/button threshold constants to be private to module
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Create embedder event to send to constellation
* Handle gamepad message in constellation, send to script thread
* Handle GamepadEvent in script thread and dispatch event to document
* Add missing Clones, fix event
* Add gamepad task source
* Adjust GamepadIndex type, remove unused imports
* Add internal getter for gamepads list
* Update gamepad new methods
* Handle gamepad connect and disconnect events
* Proto will be none, no need for HandleObject
* Initialize buttons and axes to standard mapping
* Adjust update type index types
* Update GamepadButton update function
* Adjust Gamepad mapping comments to match spec, add update logic
* Amend comment
* Update button and axis inputs on Updated event
* Add GilRs as gamepad backend in servoshell
* Add spec links, queue gamepad updates on task source
* ./mach fmt
* Fix comment length
* Split out button init, update spec comments
* Move gamepad event handling from document to global
* Map and normalize axes/button values
* Use std::time for gamepad timestamp
* Adjust gamepad handling in event loop
* Move button press/touch check into map+normalize function
- Small change but is more in line with spec
* ./mach fmt
* Update comment spec links and warning messages
* Doc comments -> regular comments
* Add window event handlers for gamepad connect/disconnect
* Adjust gamepad disconnect behavior
* Add missing TODO's, adjust gamepad/gamepadbutton list methods and formatting
* Update button handling from gilrs, add comments
* Enable gamepad pref during WPT tests and update expectations
* Update WPT expectations in meta-legacy-layout
|
|
|
|
|
| |
* strict imports formatting
* Reformat all imports
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
http://www.robohornet.org gives a score of 101.36 on master,
and 102.68 with this PR. The latter is slightly better,
but probably within noise level.
So it looks like this PR does not affect DOM performance.
This is expected since `Box::new` is defined as:
```rust
impl<T> Box<T> {
#[inline(always)]
pub fn new(x: T) -> Box<T> {
box x
}
}
```
With inlining, it should compile to the same as box syntax.
|
|
|
|
|
|
|
| |
In a later PR, DomRoot<T> will become a type alias of Root<Dom<T>>,
where Root<T> will be able to handle all the things that need to be
rooted that have a stable traceable address that doesn't move for the
whole lifetime of the root. Stay tuned.
|
|
|
|
|
|
|
|
| |
I don't want to do such a gratuitous rename, but with all the other types
now having "Dom" as part of their name, and especially with "DomOnceCell",
I feel like the other cell type that we already have should also follow
the convention. That argument loses weight though when we realise there
is still DOMString and other things.
|
| |
|
| |
|
|
|