Re: New JavaScript engine module owner
On Wednesday, March 10, 2021 at 9:27:33 AM UTC-5, Gabriele Svelto wrote: > On 10/03/2021 02:12, Jason Orendorff wrote: > > Hi, everyone. > > > > I'm pleased to announce that Jan De Mooij has agreed to take ownership of > > the JavaScript engine module. > > > > Following a Mozilla tradition that was venerable when I got here, Jan has > > been doing the job already for quite some time. Please join me in > > congratulating Jan and thanking him for his ongoing leadership. > Congrats Jan, that's one big module! > > Gabriele Congrats to Jan and many thanks to Jason! ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: Return pixel deltas in wheel event if deltaMode is not checked by authors
On 2021/03/10 21:23, Xidorn Quan wrote: On Wed, Mar 10, 2021, at 8:01 PM, Anne van Kesteren wrote: That does seem unfortunate, but unless other browsers are interested in picking this up, I think it will hurt us more to be different than that it helps. I don't think we should make aligning with Chrome and Safari conditional upon some new API. I agree with this. My main concern is that an event may be checked in multiple places, e.g. some in web framework like React, some in the site itself, or maybe just inside code owned by different teams. It would be pretty surprising if some of them checks the `deltaMode` and then the behavior suddenly changes for other places trying to read the value. I would suggest that we bring this back to W3C to discuss with other vendors regarding the current situation. If the web has been relying on delta being always pixel, maybe we should make `deltaMode` always return `DOM_DELTA_PIXEL`, and deltas always return pixel value. If the raw value is still useful to authors, one possible solution is that we expose a new `rawDeltaMode` and probably a new `getDeltaValue` method or so which requires a delta mode to be provided, and in the case such mode matches the raw delta mode, the raw value is returned without conversion. This way it could be less likely to be misused. WDYT? Yes, I also think that the current behavior has the risk on web apps which have multiple `wheel` event listeners. On the other hand, mainly from my experience at aligning `keypress` event to Chrome, existing behavior change is also really risky because a lot of web apps may check UA name and OS instead of checking behavior. The hacky way guarantees that the behavior does NOT change on web apps which handle `wheel` event correctly. --� Masayuki Nakano Working on DOM, Events, editor and IME handling for Gecko ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to prototype: Honoring bogo-XML declaration for character encoding in text/html
# Summary For compatibility with WebKit and Blink, honor the character encoding declared using the XML declaration syntax in text/html. For reasons explained in https://hsivonen.fi/utf-8-detection/ , unlike other encodings, UTF-8 isn't detected from content, so with the demise of Trident and EdgeHTML (which don't honor the XML declaration syntax in text/html), has become a more notable Web compat problem for us. With non-Latin scripts, the failure mode is particularly bad for a Web compat problem: The text is completely unreadable. That is, this isn't a feature for Web authors to use. This is to address a push factor for users when authors do use this feature. # Bug https://bugzilla.mozilla.org/show_bug.cgi?id=673087 # Standard https://github.com/whatwg/html/pull/1752 # Platform coverage All # Preference To be enabled unconditionally. # DevTools bug No integration needed. # Other browsers WebKit has had this behavior for a very long time and didn't remove it when HTML parsing was standardized. Blink inherited this from WebKit upon forking. Trident and EdgeHTML don't have this; their demise changed the balance for this feature. # web-platform-tests https://hsivonen.com/test/moz/xml-decl/ contains tests which are wrapped for WPT as part of the Gecko patch. -- Henri Sivonen hsivo...@mozilla.com ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: New JavaScript engine module owner
On 10/03/2021 02:12, Jason Orendorff wrote: > Hi, everyone. > > I'm pleased to announce that Jan De Mooij has agreed to take ownership of > the JavaScript engine module. > > Following a Mozilla tradition that was venerable when I got here, Jan has > been doing the job already for quite some time. Please join me in > congratulating Jan and thanking him for his ongoing leadership. Congrats Jan, that's one big module! Gabriele ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: Return pixel deltas in wheel event if deltaMode is not checked by authors
On Wed, Mar 10, 2021, at 8:01 PM, Anne van Kesteren wrote: > That does seem unfortunate, but unless other browsers are interested > in picking this up, I think it will hurt us more to be different than > that it helps. I don't think we should make aligning with Chrome and > Safari conditional upon some new API. I agree with this. My main concern is that an event may be checked in multiple places, e.g. some in web framework like React, some in the site itself, or maybe just inside code owned by different teams. It would be pretty surprising if some of them checks the `deltaMode` and then the behavior suddenly changes for other places trying to read the value. I would suggest that we bring this back to W3C to discuss with other vendors regarding the current situation. If the web has been relying on delta being always pixel, maybe we should make `deltaMode` always return `DOM_DELTA_PIXEL`, and deltas always return pixel value. If the raw value is still useful to authors, one possible solution is that we expose a new `rawDeltaMode` and probably a new `getDeltaValue` method or so which requires a delta mode to be provided, and in the case such mode matches the raw delta mode, the raw value is returned without conversion. This way it could be less likely to be misused. WDYT? - XIdorn ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: Return pixel deltas in wheel event if deltaMode is not checked by authors
On Wed, Mar 10, 2021 at 9:11 AM Masayuki Nakano wrote: > Indeed, in long term goal must be that we'd dispatch exactly same wheel > events as Chrome/Chromium. However, without implementing alternative new > API, web apps will not be able to handle raw value for better UX. > Therefore, I filed a spec issue, but it's not been fixed yet. > https://github.com/w3c/uievents/issues/181 That does seem unfortunate, but unless other browsers are interested in picking this up, I think it will hurt us more to be different than that it helps. I don't think we should make aligning with Chrome and Safari conditional upon some new API. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
heads-up: code-review bot's clang-format message changing
Hi all, You can stop reading, if you have a setup that never requires you to applying clang-format manually. (Aside: For those that eagerly want to belong to this group, but don't yet, I suggest you look into `./mach ide`.) For all those who get the clang-format warning from code-review bot and prefer not to download the suggested patches to apply locally, I have moderately exciting news: The new comment will give you a readily applicable command line suggestion, that formats the affected files directly The bot currently suggests you to run: - `./mach clang-format -s -p dom/test.cpp` (C/C++) The bot will soon tell you to run: - `./mach clang-format -p dom/test.cpp` This small patch is happening in https://github.com/mozilla/code-review/pull/858. That is all, Frederik ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: Return pixel deltas in wheel event if deltaMode is not checked by authors
Oops,
On 2021/03/10 17:11, Masayuki Nakano wrote:
Example 1:
```
addEventListener("wheel", event => {
let amount = event.deltaY;
if (isFirefox) {
amount *= 16;
}
scroll(amount);
event.preventDefault();
});
```
Example 2:
```
addEventListener("wheel", event => {
let amount = event.deltaY;
if (isFirefox && navigator.platform.includes("Mac")) {
amount *= 16;
}
scroll(amount);
event.preventDefault();
});
```
These cases are what they will be broken with current hack.
Example 3:
```
addEventListener("wheel", event => {
const amount =
event.deltaY > 0
? Math.min(event.deltaY, 16)
: Math.max(event.deltaY, -16);
scroll(amount);
event.preventDefault();
});
```
And this must be better, but may keep broken if user users
high-resolution wheel on Windows (and maybe on Linux?).
So, in most broken web apps, current hack must work as expected because
`deltaMode` is not referred.
So, the case which will be fixed by the hack is:
```
addEventListener("wheel", event => {
scroll(event.deltaY);
event.preventDefault();
});
```
--
Masayuki Nakano
Working on DOM, Events, editor and IME handling for Gecko
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: Return pixel deltas in wheel event if deltaMode is not checked by authors
Hi,
Thank you Emilio for your great work!
I'd like to explain the background. First, `WheelEvent` was designed
for making it possible web browsers to expose raw wheel event
information with 3 kinds of delta value modes which listeners can
distinguish with `WheelEvent#deltaMode`. And then, I implemented it
as-is before Chrome/Safari. So, the spec (and I) assumed that the
"wheel" event listeners should be like this:
```
addEventListener("wheel", event => {
let amount = 0;
switch (event.deltaMode) {
case event.DOM_DELTA_PIXEL:
default:
amount = event.deltaY;
break;
case event.DOM_DELTA_LINE:
amount = event.deltaY * computeLineHeight(even.target);
break;
case event.DOM_DELTE_PAGE:
amount = event.deltaY * computePageHeight(event.target);
break;
}
scroll(amount);
event.preventDefault();
});
```
But finally, Chrome implemented "wheel" event only with
`DOM_DELTA_PIXEL` and `DOM_DELTA_PAGE`.
Unfortunately, some web app developers didn't realize that there is
`WheelEvent#deltaMode`. Then, they implemented their own listeners like
these:
Example 1:
```
addEventListener("wheel", event => {
let amount = event.deltaY;
if (isFirefox) {
amount *= 16;
}
scroll(amount);
event.preventDefault();
});
```
Example 2:
```
addEventListener("wheel", event => {
let amount = event.deltaY;
if (isFirefox && navigator.platform.includes("Mac")) {
amount *= 16;
}
scroll(amount);
event.preventDefault();
});
```
Example 3:
```
addEventListener("wheel", event => {
const amount =
event.deltaY > 0
? Math.min(event.deltaY, 16)
: Math.max(event.deltaY, -16);
scroll(amount);
event.preventDefault();
});
```
So, in most broken web apps, current hack must work as expected because
`deltaMode` is not referred.
If `deltaMode` is checked but after referring `deltaY`, the web apps
will lost raw value, but must work mostly as expected since they must
treat the delta value as `DOM_DELTA_LINE`.
Indeed, in long term goal must be that we'd dispatch exactly same wheel
events as Chrome/Chromium. However, without implementing alternative new
API, web apps will not be able to handle raw value for better UX.
Therefore, I filed a spec issue, but it's not been fixed yet.
https://github.com/w3c/uievents/issues/181
(FYI: On Windows, mouse diver/utility can consider wheel delta amount
with native window's class name or process name. E.g., whether the app
support or does not support high resolution wheel events. Therefore,
this fact would cause that it's impossible to dispatch **exactly** same
wheel events as Chrome/Chromium.)
--
Masayuki Nakano
Working on DOM, Events, editor and IME handling for Gecko
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
