Re: Intent to implement: Limit the maximum life-time of cookies set through document.cookie to seven days

[olivier . vit]

Hi

Sorry but I don't read the webkit.org blog post in the same way
https://webkit.org/blog/8613/intelligent-tracking-prevention-2-1/

"The **beta** releases of iOS 12.2 and Safari 12.1 on macOS High Sierra and 
Mojave include an updated version of Intelligent Tracking Prevention (ITP). For 
purposes of developer communication, we’ll refer to it as ITP 2.1."

=> this is being shipped in **beta** version of Safari 12.1 and iOS 12.2, this 
is not announced as part of Safari 12.0.3 which looks to be a security update 
only https://support.apple.com/en-us/HT209449 

https://developer.apple.com/documentation/safari_release_notes/safari_12_1_beta_3_release_notes

https://developer.apple.com/documentation/ios_release_notes/ios_12_2_beta_6_release_notes

then this is not live yet in a fully released product
___
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

[Eric Shepherd (Sheppy)]

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 
Blog: https://www.bitstampede.com/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Proposed W3C Charter: Web Applications (WebApps) Working Group

[L. David Baron]

The W3C is proposing a charter for:

  Web Applications (WebApps) Working Group
  https://www.w3.org/2019/03/webapps-charter.html
  https://lists.w3.org/Archives/Public/public-new-work/2019Mar/.html

Mozilla has the opportunity to send comments or objections through
Friday, April 5.

Please reply to this thread if you think there's something we should
say as part of this charter review, or if you think we should
support or oppose it.  Given our involvement, we should probably
have some comment, even if it's simply in support (which is what I
intend to do unless anything further comes up).

This charter replaces *most* of what was covered in the Web Platform
working group, whose current charter is at
https://www.w3.org/2017/08/webplatform-charter.html , but not the
parts that are related to forks/copies of WHATWG specifications.

-David

-- 
턞   L. David Baron http://dbaron.org/   턂
턢   Mozilla  https://www.mozilla.org/   턂
 Before I built a wall I'd ask to know
 What I was walling in or walling out,
 And to whom I was like to give offense.
   - Robert Frost, Mending Wall (1914)


signature.asc
Description: PGP signature
___
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 
> 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: android-em-4-3-armv7-api16 possibly falsy timeout

[violet . bugreport]

It's clean now that the tests were successfully passed, the problem is on the 
testing platform.

I've filed a new bug for the problem and marked these intermittent timeout 
failure as duplicates.

See https://bugzilla.mozilla.org/show_bug.cgi?id=1536696
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Soft code freeze for Firefox 67 starts March 11

[Julien Cristau]

To confirm:

The version number on central was bumped to 68 on central yesterday, so the
67 soft code freeze is over.  Land away.

Cheers,
Julien

On Fri, Mar 8, 2019 at 9:45 AM Pascal Chevrel  wrote:

> Hi all,
>
> On March 11, we will be merging Firefox 67 from mozilla-central to beta
> for the first time. In order to avoid invalidating the testing we get
> out of late Nightly and the early Developer Edition builds and to ensure
> that we can roll out Beta 67 to a wider audience with confidence, we'd
> like to ask that any risky changes be avoided from March 11 until after
> the version bump to 68 on March 18. Please also be mindful of any
> landings late this week or over the weekend as there will be very little
> buffer between the first merge and shipping the 67.0b1 builds.
>
> Some reminders for the soft code freeze period:
>
> Do:
> - Be ready to backout patches that cause crash spikes, new crashes,
> severe regressions
> - Monitor new regressions and escalate merge blockers
> - Support release management by prioritizing fixing of merge blockers
>
> Do Not:
> - Land a risky patch or a large patch
> - Land new features (that affects the current Nightly version) — be
> mindful that code behind NIGHTLY_BUILD or RELEASE_OR_BETA ifdefs can
> lead to unexpected CI results
> - Flip prefs that enable new Features that were untested in Nightly cycle
> - Plan to kick off new experiments that might impact a feature's merge
> readiness
>
> Please let us know if you have any questions/concerns.
>
> Thanks,
>
> Release Management Team
>
> --
> Pascal Chevrel
> Firefox Release Manager
> ___
> 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 experiment: Require user interaction for notification permission prompts

[Johann Hofmann]

In bug 1524619  I
plan to implement support for requiring a user gesture when calling
Notification.requestPermission() [0] and PushManager.subscribe() [1].

The rationale is the increasing amount of unsolicited, out-of-context
notification permission prompts users are receiving on a regular basis. Our
telemetry shows that there is an extremely large gap between Notification
prompt acceptance rate and, say, WebRTC prompts [2].

This will land disabled by default. However, we are planning to run
experiments with this feature in Nightly 68, enabling it for a few weeks to
gauge the resulting breakage and overall user experience changes (see bug
1534456 ).

As a result of these changes, we expect to see a lot less prompting for
notifications. This is what we want. However, in some cases there could be
real breakage on sites that need to show notifications as part of their
core user experience (e.g., chat apps). We have set up bug 1536413
 to track this
breakage. Please keep an eye out and file bugs liberally, blocking that
meta-bug.

To reach the goal of better, more natural user interaction with
Notification permission prompts, requiring a user gesture may not be
sufficient (or too much). In another experiment, we are planning to further
research the nature of user engagement with permission prompts to come up
with good heuristics that we can ship on release.

Both experiments will be further discussed in an upcoming blog post.

As we ramp up automatic denial of permission prompts, in bug 1508961
, we will also
experiment with a post-prompt UI that will enable users to revert the
automatic rejection by the browser.

Note that because PushManager.subscribe() requires a
ServiceWorkerRegistration, as part of this change, we will carry
user-interaction flags through Promises that return
ServiceWorkerRegistration objects. This enables popular examples such as
this one [3] to continue to work when called from an event handler.

Let me know if you have any thoughts.

Thanks,

Johann

[0]
https://developer.mozilla.org/en-US/docs/Web/API/Notification/requestPermission

[1] https://developer.mozilla.org/en-US/docs/Web/API/PushManager/subscribe

[2] https://mzl.la/2UAAaUd

[3]
https://developer.mozilla.org/en-US/docs/Web/API/PushManager/subscribe#Example
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: CSS Containment

[Xidorn Quan]

On Tue, Mar 19, 2019, at 6:01 AM, Daniel Holbert wrote:
> As of today (March 18th 2019), I intend to turn CSS Containment
>  on by default on all platforms, in
> Firefox Nightly 68. It has been developed behind the
> 'layout.css.contain.enabled' preference.

IIRC this feature is designed to allow authors to provide hints to UAs for some 
optimization opportunities in the rendering pipeline.

Does our implementation also include any such optimizations for faster 
rendering, or is it currently just a basic implementation for conformance?

If we already include optimizations based on the hints, do we know how much 
they help the performance?

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

Re: android-em-4-3-armv7-api16 possibly falsy timeout

[Jason Orendorff]

Here is another bug with the same pattern (recently added, unrelated to the
others, no other failures on this test, timeout "literally" "impossible",
log shows that the test is not timing out):

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

It would be good to have a single bug to dup all of these to. Who's working
on this platform?

-j



On Mon, Mar 18, 2019 at 11:20 PM  wrote:

> Hi,
>
> There are some strange intermittent timeout reports on
> android-em-4-3-armv7-api16 platform, I suspect there is something wrong on
> this test platform.
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1533737
> https://bugzilla.mozilla.org/show_bug.cgi?id=1535286
> https://bugzilla.mozilla.org/show_bug.cgi?id=1534079
>
> All of the tests are recently added, they are completely unrelated to each
> other, and there are no other failures on these tests.
>
> But they have one or two intermittent failure on
> "android-em-4-3-armv7-api16". I'm familiar with 2 of the testcases, they
> are impossible to cause a timeout. Especially Bug 1535286 is just a patch
> to remove a bogus assertion with a trivial testcase ` keyTimes='.1;.6;.6' path='m0,1l7,3' keyPoints='.6;1;.7'/>`, which literally
> is impossible to timeout.
>
> Could anyone investigate whether there are some problems on
> "android-em-4-3-armv7-api16" to cause newly added testcase to timeout?
>
> Thanks.
> ___
> 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 ship: CSS Containment

[Daniel Holbert]

On Tue, Mar 19, 2019 at 2:13 AM Xidorn Quan  wrote:

> On Tue, Mar 19, 2019, at 6:01 AM, Daniel Holbert wrote:
> > As of today (March 18th 2019), I intend to turn CSS Containment
> >  on by default on all platforms,
> in
> > Firefox Nightly 68. It has been developed behind the
> > 'layout.css.contain.enabled' preference.
>
> IIRC this feature is designed to allow authors to provide hints to UAs for
> some optimization opportunities in the rendering pipeline.
>

Right, yeah - that's the primary intent.

Does our implementation also include any such optimizations for faster
> rendering, or is it currently just a basic implementation for conformance?
>

It does! The main one is
https://bugzilla.mozilla.org/show_bug.cgi?id=1497414 (making
`contain:layout size` elements reflow roots.

If we already include optimizations based on the hints, do we know how much
> they help the performance?
>

It entirely depends on the use-case, and of course it depends on web
authors opting in to use it.

The best results will come from adding containment around rapidly-changing
(i.e. frequently-reflowing) content, in a page with other
expensive-to-reflow content (which we can then ignore during the frequent
reflows, if we make the rapidly-changing area into a reflow root).  As one
example, we tried adding "contain:layout style" to the Web Console
text-entry area in https://bugzilla.mozilla.org/show_bug.cgi?id=1502524 ,
and this gave a ~50% reduction in time spent in reflow for a particular
stress test. However, we had to back it out in that case, because the Web
Console's functionality depends on some layout information *not* being
contained.  But that's an example of the sort of speedup that this can
give, in cases where it *is* appropriate to use.

- Xidorn
> ___
> 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: android-em-4-3-armv7-api16 possibly falsy timeout

[gbrown]

I updated bug 1534079 with some investigation. In all 3 cases (and Jason's 
looks the same), these are shutdown hangs in firefox for android, after a test 
has been run in test verification, in chaos mode. Who might be able to track 
that down further?

If it cannot be fixed, we could turn off chaos mode in test verification, 
perhaps only on Android.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform