Intent to stop dispatching "keypress" event for non-printable keys and key combinations in Nightly and early Beta

[Masayuki Nakano]

I'd like to stop dispatching "keypress" event for non-printable keys and 
key combinations in the default event group of web content in Nightly 
and early Beta for collecting regression reports.

https://bugzilla.mozilla.org/show_bug.cgi?id=1440189

By UI Events, "keypress" event is defined as:
> this event MUST be dispatched when a key is pressed down,
> if and only if that key normally produces a character value.
https://w3c.github.io/uievents/#event-type-keypress

So, non-printable key means:
* Function keys like ArrowLeft, ArrowDown, F1, Home, End, Tab, etc.
* Ctrl + KeyA etc.

Note that Enter key is special. Other browsers' behavior of "keypress" 
event for Enter key is not same.  However, unmodified Enter, 
Shift+Enter, Ctrl+Enter causes any browsers and any platforms. 
Therefore, we'll continue to dispatch "keypress" event only for those 
key combinations.

https://github.com/w3c/uievents/issues/183

If you're a developer of our UI, please consider to use "keydown" event 
listener to handle non-printable keys and key combinations.  However, 
calling preventDefault() of "keydown" event stops dispatching the 
following "keypress" event.  Therefore, if you cannot handle even 
non-printable keys with "keydown" event since other "keypress" event 
listeners in our UI are broken by calling preventDefault(), you can keep 
using "keypress" event listeners in the system event group or in chrome 
document.


You can add an event listener in the system event group with using 
nsIEventListenerService::addSystemEventListener():

https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIEventListenerService#addSystemEventListener()

Or, specify group="system" to event handler in XBL like this:
https://searchfox.org/mozilla-central/rev/14d933246211b02f5be21d2e730a57cf087c6606/toolkit/content/widgets/browser.xml#1680

Or, you might be able to use EventTarget.addEventListener() with 
{mozSystemGroup: true} as 3rd argument. However, I couldn't fix new 
oranges with this approach. So, it works with some condition, but I 
don't know about this.



So, I'll keep struggling with regressions of this behavior change. 
However, probably, we won't get regression reports for minor UI, e.g., 
running only first time to use something.  So, I'd be happy everyone to 
check your own UI.


Thanks in advance.

--
Masayuki Nakano 
Software Engineer, Mozilla
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to unship: rowspan=0

[Boris Zbarsky]

On 2/27/18 5:28 PM, Manish Goregaokar wrote:


You can already achieve this behavior with `rowspan=`


Only if you can guarantee that this number is in fact larger than the 
number of rows in your rowgroup, yes?


And even then, is it exactly equivalent?


and we should encourage developers to use Grid anyway


What does that have to do with anything?  This feature is for semantic 
tables where you want a cell (e.g. one labeling something about an 
entire rowgroup) to span to the end of the rowgroup.



it's questionable whether it's used
enough on the Web for it to be something we must keep for compat reasons.


Have we tried doing actual telemetry here?

-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to unship: rowspan=0

[Manish Goregaokar]

(Of course, this is contingent on the Chrome people agreeing to unship this
as well)

-Manish Goregaokar

On Tue, Feb 27, 2018 at 2:28 PM, Manish Goregaokar 
wrote:

> Gecko (and previously Presto) support setting `rowspan=0` in
> non-quirksmode documents to mean "up to the end of the rowgroup" (for rows
> not within rowgroups, this means that it spans up to the next rowgroup or
> the end of the table). It is equivalent to setting rowspan to a very large
> number.
>
> colspan=0 does not do this[1]
>
> Chrome/Blink very recently added support[2], but it's still in Canary, and
> I'd like to remove it from both browsers and the spec before it hits
> release.
>
> You can already achieve this behavior with `rowspan=`, and
> we should encourage developers to use Grid anyway, so I don't see much
> value in having this feature in and of itself. Given that it was only
> supported by one browser (us) for so many years, it's questionable whether
> it's used enough on the Web for it to be something we must keep for compat
> reasons.
>
> Thoughts?
>
>  [1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1241840
>  [2]: https://bugs.chromium.org/p/chromium/issues/detail?id=180722
>
>
> -Manish Goregaokar
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to unship: rowspan=0

[Manish Goregaokar]

Gecko (and previously Presto) support setting `rowspan=0` in non-quirksmode
documents to mean "up to the end of the rowgroup" (for rows not within
rowgroups, this means that it spans up to the next rowgroup or the end of
the table). It is equivalent to setting rowspan to a very large number.

colspan=0 does not do this[1]

Chrome/Blink very recently added support[2], but it's still in Canary, and
I'd like to remove it from both browsers and the spec before it hits
release.

You can already achieve this behavior with `rowspan=`, and we
should encourage developers to use Grid anyway, so I don't see much value
in having this feature in and of itself. Given that it was only supported
by one browser (us) for so many years, it's questionable whether it's used
enough on the Web for it to be something we must keep for compat reasons.

Thoughts?

 [1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1241840
 [2]: https://bugs.chromium.org/p/chromium/issues/detail?id=180722


-Manish Goregaokar
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: WebVR on macOS

[kearwood]

On Wednesday, September 20, 2017 at 4:30:56 PM UTC-7, Kearwood  Kip  Gilbert 
wrote:
> As of 2017-10-01, I intend to turn WebVR on by default for macOS.  It has 
> been developed behind the dom.vr.enabled preference.  We have already shipped 
> WebVR by default for the Windows platform.  macOS support has been 
> implemented for several months but disabled by default.  Our WebVR 
> implementation supports OpenVR for the HTC Vive on macOS High Sierra, which 
> is now hitting release.
> This feature was previously discussed in this "intent to implement" thread: 
> . 
> Bug to turn on by default: 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1374399
> Link to standard: https://w3c.github.io/webvr/spec/1.1/
> Testing: 
> Automated tests have been implemented and are already active for the macOS 
> builds in taskcluster.  Platform conformance tests are shared with other UA’s.

As of 2018-02-27, I intend to turn WebVR [back] on by default for macOS.  Due 
to hardware availability for QA, this was disabled before riding to release for 
FF58 and FF59.  We have since gained QA approval to allow it to ride to release 
in FF60.

Bug to turn on by default:
https://bugzilla.mozilla.org/show_bug.cgi?id=1438044

Link to standard:
https://w3c.github.io/webvr/spec/1.1/

Testing: 
Automated tests have been implemented and are already active for the macOS 
builds in taskcluster.  Platform conformance tests are shared with other UA’s.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

PSA: Possible Issues running ESLint (could not load globals from file)

[Mark Banner]

We've had a few reports of issues when running ESLint in 
mozilla-central. The have tended to be along the lines of:


Could not load globals from file browser.js: Error: Invalid ecmaVersion.

If you get this, please check if you have a 
/tools/lint/eslint/node_modules/ directory, if so:


- remove the directory
- remove /node_modules/ as well.
- finally, run ./mach eslint --setup

You should then be able to run ESLint again.

(We believe this is a hang over from one of the early configurations we 
had in the tree that is now causing conflicts somehow).


Mark.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform