Re: Intent to implement and ship: CSS 'prefers-color-scheme' media feature

[Hiroyuki Ikezoe]

On Wed, Mar 20, 2019 at 8:45 AM Hiroyuki Ikezoe  wrote:

> The Android backend for prefers-color-scheme didn't get on Firefox 67,
> it's just landed on mozilla-central, will be shipped in Firefox 68.
>

The backend was uplifted into Firefox 67 beta yesterday.  So
prefers-color-scheme will be available on all platforms in Firefox 67.

Thanks,
hiro
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: CSS 'prefers-color-scheme' media feature

[Hiroyuki Ikezoe]

It's https://bugzilla.mozilla.org/show_bug.cgi?id=1532850, it was at a
deeper level of blockers of bug 1494034, now I added bug 1532850 in the
dependency list of bug 1494034.

Thanks,
hiro

On Wed, Mar 20, 2019 at 9:42 AM Eric Shepherd (Sheppy) <
esheph...@mozilla.com> wrote:

> Presumably that’s noted appropriately in some manner in Bugzilla?
>
> On March 19, 2019 at 7:45:53 PM, Hiroyuki Ikezoe (hike...@mozilla.com)
> wrote:
>
> The Android backend for prefers-color-scheme didn't get on Firefox 67, it's
>
> just landed on mozilla-central, will be shipped in Firefox 68.
>
>
> Eric Shepherd
> Senior Technical Writer
> MDN Web Docs <https://developer.mozilla.org/>
> Blog: https://www.bitstampede.com/
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: CSS 'prefers-color-scheme' media feature

[Hiroyuki Ikezoe]

The Android backend for prefers-color-scheme didn't get on Firefox 67, it's
just landed on mozilla-central, will be shipped in Firefox 68.

Thanks,
hiro

On Sat, Feb 16, 2019 at 5:38 AM Mats Palmgren  wrote:

> Summary:
> The 'prefers-color-scheme' media feature is way for pages to detect
> if the user prefers a light or dark color theme.  The values are
> 'light', 'dark', and 'no-preference'.  If the "resist fingerprinting"
> feature is active we always match 'light'.  If the media type is
> 'print' we always match 'light'.  Otherwise, we try to determine
> a value from the user's current "desktop theme".  This should work
> well on recent versions of OSX and Windows.  On Linux, we don't
> know how to determine a value from the system so we match
> 'no-preference' there - help wanted:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1525775
>
> Bug:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1494034
>
> Link to standard:
> https://drafts.csswg.org/mediaqueries-5/#prefers-color-scheme
>
> Platform coverage: All platforms
>
> Estimated or target release: Firefox 67
>
> Preference behind which this will be implemented:
> The feature is always enabled, but there is an existing hidden
> preference to set a value (integer), ui.systemUsesDarkTheme:
> 0 = light
> 1 = dark
> 2 = no-preference
>
> Is this feature enabled by default in sandboxed iframes?
> Yes, but if widget look-and-feel features are disabled in
> sandboxed iframes then we'll match 'no-preference'.
>
> DevTools bug: none
>
> Do other browser engines implement this?
> Safari has implemented this feature and it's available in their
> Nightly build, but it's not yet shipped AFAICT.
> https://paulmillr.com/posts/using-dark-mode-in-css/ is a post about
> implementation of this feature in Safari;
>
> https://webkit.org/blog/8475/release-notes-for-safari-technology-preview-68/
> documents its addition.
>
> It appears Chrome is actively working on it:
> https://bugs.chromium.org/p/chromium/issues/detail?id=889087
>
> web-platform-tests:
> https://w3c-test.org/css/mediaqueries/prefers-color-scheme.html
>
> Is this feature restricted to secure contexts? No
>
> Credit also goes to Jonathan Kingston who wrote the initial
> implementation of this feature.
>
>
> /Mats
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship the CSS Scroll Snap Module Level 1 and unship old scroll snap properties

[Hiroyuki Ikezoe]

Hello, fantasai!

On Sun, Mar 10, 2019 at 6:14 AM fantasai 
wrote:

> 1. Handling overlarge snap areas per
> https://www.w3.org/TR/css-scroll-snap-1/#snap-overflow
> This is important to make content accessible on smaller-than-expected
> screens.
>

I think I've finished this properly, but..

2. Handling scroll-padding correctly even when snapping is turned off,
> since it should affect all paging operations and scroll-into-view
> operations. https://www.w3.org/TR/css-scroll-snap-1/#scroll-padding
>
> 3. Likewise, supporting scroll-margin's effects even when snapping is off:
> it still be adjusting the element's scroll-into-view area
> https://www.w3.org/TR/css-scroll-snap-1/#scroll-margin
>

I was totally misunderstanding these two. Filed bug 1534070 for that.

Thanks!
hiro
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to implement and ship the CSS Scroll Snap Module Level 1 and unship old scroll snap properties

[Hiroyuki Ikezoe]

Summary:
  The scroll snap specification has been significantly changed since we
 implemented.  scroll-snap-coordinate, scroll-snap-destination and
 scroll-snap-points-{x,y} were dropped, instead, scroll-snap-align,
 scroll-snap-margin and scroll-snap-padding were added in the spec.  Also,
 scroll-snap-type was changed to a longhand property and its syntax was
 changed in the spec.
  Due to the scroll-snap-type change, this migration will happen
irreversibly
 in terms of the scroll-snap-type property.  Once the change happens in bug
 1312163 [1], you can no longer use the old longhands,
scroll-snap-type-{x,y},
 and no longer use the old shorthand syntax like `scroll-snap-type:
mandatory`.
 That means that, for example, sites specifying only scroll-snap-type-x will
 be broken.  To mitigate it, I am going to land a bunch of relevant stuff
at the
 same time so that we can switch to the new scroll snap at once.

Bug:
 A meta bug is
  https://bugzilla.mozilla.org/show_bug.cgi?id=1231777

Link to standard:
 https://drafts.csswg.org/css-scroll-snap-1/

Platform coverage: all

Estimated or target release: Firefox 68

Preference behind which this will be implemented:
 layout.css.scroll-snap-v1.enabled

Is this feature enabled by default in sandboxed iframes?
 Yes

DevTools bug:
 https://bugzilla.mozilla.org/show_bug.cgi?id=1133666

Do other browser engines implement this?
 Chrome and Safari already shipped

web-platform-tests:
 http://w3c-test.org/css/css-scroll-snap/

Additional notes:
 scroll-snap-stop which was introduced in the new spec is not going to be
 implemented now since it's marked at-risk in the spec

Thanks,
hiro

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1312163
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Fwd: Intent to implement and ship: CSS prefers-reduced-motion media feature for Windows and MacOSX

[Hiroyuki Ikezoe]

I just realized that I did send below message only to Tom. :)

-- Forwarded message --
From: Hiroyuki Ikezoe 
Date: Wed, Jul 25, 2018 at 6:59 AM
Subject: Re: Intent to implement and ship: CSS prefers-reduced-motion media
feature for Windows and MacOSX
To: Tom Ritter 


Thank you, bz and Tom.

I just filed bug 1478158 for that.


On Wed, Jul 25, 2018 at 1:30 AM, Tom Ritter  wrote:

> As far as I can tell the specification does not indicate any privacy
> concerns; even though this exposes a system preference.
>
> I'd request that if Resist Fingerprinting is enabled; the browser behaves
> as if the user has not set any preference.
>
> -tom
>
> On Tue, Jul 24, 2018 at 2:34 AM, Hiroyuki Ikezoe 
> wrote:
>
>> Summary: By using CSS prefers-reduced-motion media feature, web developers
>> can provide contents depending on a system setting that users want
>> *motion-less* content.  A WebKit  blog post [1] might be useful to know
>> this feature in more detail.
>>
>> Bugs: https://bugzilla.mozilla.org/show_bug.cgi?id=1365045 for Windows
>>  https://bugzilla.mozilla.org/show_bug.cgi?id=1475462 for Mac OSX
>>
>> Link to standard:
>> https://drafts.csswg.org/mediaqueries-5/#prefers-reduced-motion
>>
>> Platform coverage: Windows and MacOSX
>> Though I don't have a plan for Android at this moment , I maybe do it
>> soonish.
>>
>> Estimated release: For Windows in Firefox 63, for MacOSX it might be
>> delayed in Firefox 64
>>
>> Preference behind which this will be implemented: None
>>
>> Is this feature enabled by default in sandboxed iframes? Yes
>>
>> If allowed, does it preserve the current invariants in terms of what
>> sandboxed iframes can do? I believe so
>>
>> DevTools bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1477920
>>
>> Do other browser engines implement this?
>>
>> WebKit already shipped this feature on the last year.
>>
>> Neither Chrome and Edge hasn't progressed yet.
>> https://bugs.chromium.org/p/chromium/issues/detail?id=722548
>> https://developer.microsoft.com/en-us/microsoft-edge/platfor
>> m/issues/17506002/
>>
>> web-platform-tests: None
>> This feature is tied to a system setting, so, as far as I can tell, we
>> can't write wpt.
>> WebKit has test cases on their tree controlled by something like our
>> SpecialPowers.  We will have reftests controlled by a UI pref.
>>
>> Secure contexts: Yes
>>
>> [1] https://webkit.org/blog/7551/responsive-design-for-motion/
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>>
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to implement and ship: CSS prefers-reduced-motion media feature for Windows and MacOSX

[Hiroyuki Ikezoe]

Summary: By using CSS prefers-reduced-motion media feature, web developers
can provide contents depending on a system setting that users want
*motion-less* content.  A WebKit  blog post [1] might be useful to know
this feature in more detail.

Bugs: https://bugzilla.mozilla.org/show_bug.cgi?id=1365045 for Windows
 https://bugzilla.mozilla.org/show_bug.cgi?id=1475462 for Mac OSX

Link to standard:
https://drafts.csswg.org/mediaqueries-5/#prefers-reduced-motion

Platform coverage: Windows and MacOSX
Though I don't have a plan for Android at this moment , I maybe do it
soonish.

Estimated release: For Windows in Firefox 63, for MacOSX it might be
delayed in Firefox 64

Preference behind which this will be implemented: None

Is this feature enabled by default in sandboxed iframes? Yes

If allowed, does it preserve the current invariants in terms of what
sandboxed iframes can do? I believe so

DevTools bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1477920

Do other browser engines implement this?

WebKit already shipped this feature on the last year.

Neither Chrome and Edge hasn't progressed yet.
https://bugs.chromium.org/p/chromium/issues/detail?id=722548
https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/17506002/

web-platform-tests: None
This feature is tied to a system setting, so, as far as I can tell, we
can't write wpt.
WebKit has test cases on their tree controlled by something like our
SpecialPowers.  We will have reftests controlled by a UI pref.

Secure contexts: Yes

[1] https://webkit.org/blog/7551/responsive-design-for-motion/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to implement and ship: spec compliance Promise microtask behavior

[Hiroyuki Ikezoe]

Summary: We are about to land bug 1193394 which will change microtask
behavior that our microtask behavior complied with the HTML spec.

We had fixed all test failures but still it's possible that new failures 
will

appear before the change gets merged into mozilla-central.  If we found any
failed tests we will disable it temporarily and file a bug to enable it
respectively.  If new test you have locally started failing after this 
change,
the document that Bevis wrote [1] would be helpful to make the test pass 
with
the new behavior.  Bevis' original message [2] has some background of 
this, so

it would be also helpful to understand this change.

Big thanks to Olli who started the initial work and Bevis who took over 
his work
and :arai who had been fixing tests that failed by the microtask change 
in various

areas.  And big thanks to everyone involved!

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1193394
Standard: 
https://html.spec.whatwg.org/multipage/webappapis.html#enqueuejob(queuename,-job,-arguments)

Platform coverage: All
Target release: Firefox 60
Preference: None. We tried to add a pref but didn't add since it will make
 things more complicated and hard to maintain.
 See https://bugzilla.mozilla.org/show_bug.cgi?id=1420816#c9 for the 
detail.

DevTools bug: None
web-platform-tests: There are test cases that this change makes the 
tests pass.
Do other browser engines implement this?: Chrome and Safari as per the 
result of

 a wpt [3].

[1] 
https://docs.google.com/presentation/d/1momsC3suU8m-CrdZyYD_6QATATehjzZHbkGmL6KsmSk/edit#slide=id.g28ecd2197a_0_269
[2] 
https://groups.google.com/forum/#!msg/mozilla.dev.platform/naB6gaevSSo/w-29kbpUBQAJ
[3] 
https://wpt.fyi/html/webappapis/scripting/event-loops/task_microtask_ordering.html


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

Intent to ship: PerformanceObserver

[Hiroyuki Ikezoe]

As of Firefox 57 I intend to turn PerformanceObserver on by default. 
It's been enabled on nightly by default for 16 months. Chrome has 
already shipped it since 52, WebKit has implemented it since January 
2017, but not shipped yet.  Edge has not implemented it yet, but as far 
as I know they have been interested in.


Bugs to turn on by default on all channels: 
https://bugzilla.mozilla.org/show_bug.cgi?id=1386021


Link to standard: https://w3c.github.io/performance-timeline/

Testing: All web platform tests for PerformanceObserver that do not 
require Navigation Timing 2 
.


hiro

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

Intent to ship: PerformanceObserver

[Hiroyuki Ikezoe]

In Firefox 51 I indent to turn PerformanceObserver on by default. It has 
been developed behind the dom.enable_performance_observer preference. 
Chrome has been shipping it[1]. Their 'intent to ship' is [2].


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

Link to standard:
https://w3c.github.io/performance-timeline/#the-performanceobserver-interface

[1] https://bugs.chromium.org/p/chromium/issues/detail?id=485613
[2] 
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/zLL_d4DLAno


Thanks,
hiro

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

Re: web-platform-tests on debug builds running on try

[Hiroyuki Ikezoe]

Hi!

Just FYI

The try result [1] shows only
/html/semantics/embedded-content/the-img-element/current-pixel-density/basic.html, 
but /service-workers/service-worker/fetch-csp.https.html is another 
suspicion.


See
https://treeherder.mozilla.org/logviewer.html#?job_id=8942921repo=try
and
https://treeherder.mozilla.org/logviewer.html#?job_id=8946879repo=try

On 07/01/15 08:35, James Graham wrote:

Web-platform-tests are now running in debug builds on try only. However
due to some teething problems, they are not currently all green. This is
expected to be fixed in the next 24 hours but, in the meantime, if you
see some orange that seems unrelated to your change, particularly orange
that looks like [1], please don't panic; it's likely safe to ignore (if
there is a sheriff reading this, we should possibly hide those jobs
temporarily).

Sorry for the inconvenience this has caused.

[1] https://treeherder.mozilla.org/logviewer.html#?job_id=8927888repo=try
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


--
Hiroyuki Ikezoe hiike...@mozilla-japan.org
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to implement: Frame Timing API

[Hiroyuki Ikezoe]

Summary: Provides an interface for receiving frame performance timing
including composites happening on a separate thread/process. This can
be used to calculate measures of smoothness that incorporate the
effect of async pan and zoom and off-main thread animation.

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

Link to standard: https://w3c.github.io/frame-timing/

Platform coverage:  all platforms

Estimated or target release:  Firefox 43 although we might hold off
shipping depending on the state of the spec at that time (there has
been discussion of replacing the buffer-based interface with an
observer interface).

Preference behind which this will be implemented:  dom.enable_frame_timing

DevTools bug:  No specific bug yet but the DevTools team is aware of
our intention to implement and indicated they could use this API.

Other browser support: Blink: in development, soon to reach Canary.[1]

[1] https://code.google.com/p/chromium/issues/detail?id=120796#c53

Thanks,

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

Re: New XPIDL attribute: [infallible]

[Hiroyuki Ikezoe]

On 2012年08月23日 18:11, Justin Lebar wrote:


I encourage you to consider using [infallible] in new code for
attributes whose getters never fail.  Not only is it cleaner to call
such methods, but using [infallible] also draws attention to those
attributes which /may/ fail.


Before each time using [infallible] for new attribute, discussion
whether the interface should be builtinclass or not will be opened? Or
you also encourage to make the interface builtinclass anyway?

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