Take into account node offsets in browser_webconsole_object_inspector_local_session_storage.js.
MozReview-Commit-ID: 73waFejjsF0
--HG--
extra : rebase_source : d34e26c280f777e266ab7f014cfb9b41e07c9a5e
This causes various changes to properties-db.js and also many devtools
tests get updated.
There are two changes affect multiple tests:
* `calc` gets removed from everywhere. We never have it listed in all
properties which deserve it, and doing so without much false positive
(i.e. properties don't deserve but get it) can be pretty tricky.
So they are just removed for now.
* The complete color keyword list is no longer included, and instead,
"COLOR" is prepended to the list directly. We can probably remove
the related code which replaces color keywords with "COLOR" from
devtools. Note that, with stylo enabled, the list is already unrelated
to what the parsing code uses. We should eventually re-enable the
disabled test here after we can get the color list from cssparser
in bug 1456715.
Other changes to properties-db.js seem to be valid, some of them also
affect tests:
* `{-webkit-,}align-{content,items,self}` get `first baseline`, `safe`,
`unsafe`, and lose `left` and `right`.
* `{-moz-,-webkit-,}{animation,transition}{,-timing-function}` has a
new `frame` keyword which is a function value in `<timing-function>`.
* `{background,{-webkit-,}mask}-position-x` lose `top` and `bottom`, and
correspondingly `{background,{-webkit-,}mask}-position-y` lose `left`
and `right`. They don't deserve those values.
* `{background,{-webkit-,}mask}{,-size}` get `auto`.
* `border` shorthand loses `<image>` values as well as other keyword
values for `border-image-*` subproperties, because they aren't parsed
on the shorthand.
* `{-moz-,}border-image{,-width}` get `auto`.
* `-moz-context-properties` gets `none`.
* `cursor` get some -moz-prefixed values as well as `url`.
* `fill` and `stroke` get the color keywords.
* `{-webkit-,}filter` get the keywords and function names.
* `font` shorthand loses values from many of `font-variant-*` properties
because they are not parsed there.
* `font-variant` and `font-variant-alternates` get function values of
the longhand.
* `font-variant-{east-asian,ligatures,numeric}` get `normal`, and
`font-variant-ligatures` in addition gets `none`.
`font-{feature,variation}-settings` also get `normal`.
* `grid` and `grid-template-{areas,columns,rows}` get `none`.
* `grid`, `grid-template`, and `grid-template-{columns,rows}` get
`auto`, `fit-content`, `minmax`, and `repeat`.
* `grid-auto-{columns,rows}` get `auto`, `fit-content` and `minmax`.
* `-moz-image-region` gets `auto` and `rect`.
* `{-webkit-,}justify-content` lose `baseline`, `last baseline`, and
get `safe` and `unsafe`.
* `{justify,place}-items` get `first baseline`, `legacy`, `safe`,
`unsafe` and lose `auto`.
* `{justify,place}-self` and `place-content` get `first baseline`,
`safe`, and `unsafe`.
* `outline{,-style}` get `hidden`.
* `scroll-snap-coordinate` gets `none`, and `scroll-snap-points-{x,y}`
gets `none` and `repeat`.
* `shape-outside`, `text-emphasis{,-style}` get all the keyword values
and function names they deserve.
* `stroke-dasharray` gets `none`.
* `text-combine-upright` drops `digits` which we never implemented.
* `{-moz-,-webkit-,}transform` and `-moz-window-transform` get their
transform function list. `accumulatematrix` and `interpolatematrix`
aren't real CSS value but they have `#[css(function)]` specified.
We should probably remove them at some point.
* `will-change` gets `auto`.
* All properties accept `<image>` value now gets -webkit-prefixed
gradient function names, including
* `background{,-image}`,
* `{-moz-,-webkit-,}border-image{,-source}`, and
* `{-webkit-,}mask{,-image}`.
MozReview-Commit-ID: E7Y0CFUFYgW
--HG--
extra : source : bab732c8c531cfca1bcd233f769c25bb2e373773
This also removes any redundant Ci.nsISupports elements in the interface
lists.
This was done using the following script:
acecb401b7/processors/chromeutils-generateQI.jsm
MozReview-Commit-ID: AIx10P8GpZY
--HG--
extra : rebase_source : a29c07530586dc18ba040f19215475ac20fcfb3b
Test changes for removal of PopupBoxObject and popup.xml methods, some reflow tests now have different stacks now that they are not going through popup.xml binding methods, test_popupanchor.xul changes due to need to wait for popuppositioned event after resizing. The old code would just adjust the arrow directly when sizeTo was called, but the new code does this through an asynchronous popuppositioned event. Changes to some places that check for XULElement class.
--HG--
rename : dom/webidl/PopupBoxObject.webidl => dom/webidl/XULPopupElement.webidl
rename : layout/xul/PopupBoxObject.cpp => dom/xul/XULPopupElement.cpp
rename : layout/xul/PopupBoxObject.h => dom/xul/XULPopupElement.h
Navigation events now require a "remoted" target. Add `makeRemote` calls to a
tests which make use of these features.
MozReview-Commit-ID: GJsleBWryCd
--HG--
extra : rebase_source : 37ffaac7215b2458a82b8a7a2a59fa4321e370b8
Navigation events now require a "remoted" target. Add `makeRemote` calls to a
tests which make use of these features.
MozReview-Commit-ID: GJsleBWryCd
--HG--
extra : rebase_source : 2319d43ea29cfa33850295ff2d4c902e22ae3727
These issues were previously ignored due to the nature of our global import
rules. They need to be fixed before that rule can be updated.
MozReview-Commit-ID: DCChktTc5TW
--HG--
extra : rebase_source : cffb1c9762191c579d1397c8169e6e7635d229da
extra : histedit_source : dea59ddd2daaae52069c5faceae9149a4f08dd73
This is pretty simple... finding the best locations for the probes was the
struggle here.
In order to land these probes before the freeze the test for these events will
be created as part of bug 1456073.
MozReview-Commit-ID: 7hIfbD3wQ1I
--HG--
extra : rebase_source : 990e69e0816742fc306b9313bd113f2d71f00b72
***
Bug 1454202: Part 1a - Auto-replace uses of callback-based AddonManager APIs with Promise-based versions. r=aswan
This was done using the following script:
4cd5ae9597/processors/aom-api-generators.jsm
MozReview-Commit-ID: 8hobLz15a66
***
Bug 1454202: Part 1b - Manually fix eslint errors after auto-rewrite. r=aswan
This also deletes an obsolete test whose xpcshell variant was already deleted.
MozReview-Commit-ID: DM9W9Q2SVIE
***
Bug 1454202: Part 1c - Manually fix non-eslint issues after auto-rewrite. r=aswan
MozReview-Commit-ID: DtMscWZuExc
--HG--
extra : rebase_source : d4c2f80bdf02ec4a07e3713a9ae1823145d25942
There are some extra hoops here because devtools has a lint to prevent Cu.importGlobalProperties, which is the normal way one would import a WebIDL constructor.
MozReview-Commit-ID: 2mdNI6N1z5B
After switching to Stylo, animation is handled by Servo, and thus it no
longer relies on the animation type recorded in nsCSSPropList.h, and
devtools become the only consumer of that information.
This patch puts a map of longhands to animation types into devtools
instead. The map is extracted from nsCSSPropList.h by the script below
based on the logic of nsDOMWindowUtils::GetAnimationTypeForLonghand.
There are two reasons that I don't port this into Servo:
First, Servo doesn't have a concept of property-level animation type.
Animation change in Servo is directly encoded into value types. It means
porting this to Servo would require creating a new concept purely for
devtools. It's not great because that data doesn't reflect how animation
is handled in the engine, and people may keep forgetting to give proper
animation type to new animatable types they add.
Second, the handling of animation type in devtools also looks rather
arbitrary to me. For example, eStyleAnimType_Corner_* types are actually
two coordinate values, bug GetAnimationTypeForLonghand returns "coord"
for them, and devtools just parses the first value and uses it. This
means the animation type here is really more closely related to how
devtools handles the value, rather than how the style engine does so.
Given above, I decided to put the list into devtools rather than encode
the information into Servo code. To encourage people to think about
animation handling in devtools for new properties, there is also a new
test added to ensure every property has a devtools animation type.
The content of ANIMATION_TYPE_FOR_LONGHANDS is generated via running
the following script in layout/style:
```python
#!/usr/bin/env python3
import subprocess
from collections import defaultdict
ANIMTYPE_MAPPING = {
"Custom": "custom",
"Coord": "coord",
"Sides_Top": "coord",
"Sides_Right": "coord",
"Sides_Bottom": "coord",
"Sides_Left": "coord",
"Corner_TopLeft": "coord",
"Corner_TopRight": "coord",
"Corner_BottomRight": "coord",
"Corner_BottomLeft": "coord",
"nscoord": "length",
"float": "float",
"Color": "color",
"ComplexColor": "color",
"PaintServer": "paintServer",
"Shadow": "shadow",
"Discrete": "discrete",
"None": "none",
}
input = b"""
#define CSS_PROP(name, id, method, flags, pref, \\
variant, kwtable, animtype) name, flags, animtype
#include "nsCSSPropList.h"
"""
props = subprocess.check_output(["clang", "-E", "-P", "-"], input=input)
props = props.decode("ascii")
result = defaultdict(list)
for line in props.splitlines():
line = line.strip()
if not line:
continue
name, flags, animtype = line.split(", ")
assert animtype.startswith("eStyleAnimType_")
if "CSS_PROPERTY_PARSE_INACCESSIBLE" in flags:
continue
animtype = ANIMTYPE_MAPPING[animtype[15:]]
result[animtype].append(name)
print("[")
for animtype, names in result.items():
print(' ["{}", new Set(['.format(animtype))
for name in names:
print(' "{}",'.format(name))
print(" ])],")
print("]")
```
MozReview-Commit-ID: BGiGq0jUgG5
--HG--
extra : rebase_source : 54fc15b9ccdb6c11d06160d63b8f4b911b754d5a
- Compute constraints so that a dragged marker stays visible with the viewport.
- Constrain dragging of marker to the viewport of the node's host window.
- If the marker is visible outside of the node host's viewport (ex:
shapes within a smaller iframe nested in a larger document), do not
constrain that marker and allow dragging it outside the viewport.
If dragging starts while the marker is within its intended viewport,
do constrain it to that viewport.
MozReview-Commit-ID: 9JyEfseSLXW
The previous implementation treated any zero coordinate as pixels,
regardless of its unit type. For example, 0% would be converted to 0px.
This changed the shape value resulting in unintentional unit mismatch
after editing a coordinate which started off as 0% or 0em or 0vh, etc.
This patch fixes that and preserves the unit type for zero coordinates.
It changes the implementation of isUnitless() to return false for values
like 0%, 0px, 0em, 0.00000%, etc.
It introduces getUnitToPixelRatio() to get the ratio by which to
multiply a pixel value to convert it to the given unit during shape
editing operations (point move, scale, translate, rotate, etc.)
The ratio is constant by unit type. Previously, this ratio was
calculated in-place for each unit value. Values which started as zero,
always resulted in a ratio equal to zero. This multiplied with a pixel
value resulted zero. So the previous code defaulted to ratio of 1 when
the ratio was zero, but this meant that a 1:1 ratio between pixels and
another unit type (%, em, vh) would result in disproportionate
shape changes (1px of mouse travel would result in 1em). This is why
isUnitless() originally discarded the original unit from a zero
coordinate and replaced it with pixels; to account for this fallback
ratio of 1.
MozReview-Commit-ID: 49tyLfYjkLO
