Re: Must we rebuild all our rust code constantly?

2019-08-22 Thread Mike Hommey 
On Thu, Aug 22, 2019 at 06:48:03PM -0700, Chris M. wrote:
> On Mon, Aug 19, 2019 at 10:32 PM Kris Maglione 
> wrote:
> 
> > On Tue, Aug 20, 2019 at 02:23:06PM +0900, ISHIKAWA,chiaki wrote:
> > >On 2019/08/20 9:11, Dave Townsend wrote:
> > >>Thanks to a tip I've tracked this down. This seems to only be the case
> > when
> > >>I have sccache enabled. Disabling it gives me nice quick incremental
> > builds
> > >>again. Of course that isn't an ideal solution but it will do for now.
> > >>
> > >>On Mon, Aug 19, 2019 at 1:55 PM Dave Townsend 
> > wrote:
> > >>
> > >>>For a couple of weeks now I've seen that any attempt to build Firefox,
> > >>>even incremental builds seem to rebuild an awful lot of rust code. I
> > found
> > >>>this in the source which seems to suggest why:
> > >>>
> > https://searchfox.org/mozilla-central/source/config/makefiles/rust.mk#238.
> > >>>But, this means that now an incremental build with a couple of code
> > change
> > >>>that have no impact on rust is taking upwards of 4 minutes to complete
> > in
> > >>>comparison to around 40 seconds, and the log file is full of cargo
> > output.
> > >>>I've heard similar comments from other developers.
> > >>>
> > >>>This is a pretty big increase in the time to compile and test and is
> > >>>really slowing down my work. Is there any way we can avoid this?
> > >>>
> > >>
> > >
> > >
> > >I am using linux for local development and noticed something similar.
> > >
> > >So I should disable sccache (!?).
> >
> > For what it's worth, Rust is now configured to use incremental
> > compilation, which has its own cache which isn't cleared after
> > clobber, so sccache isn't actually needed anymore. Ordinary
> > ccache should be sufficient.
> >
> sccache will still cache dependencies from crates.io. From a quick check
> building the rust in the tree on my laptop, a full cache hit for rust with
> sccache produces a significant speedup (2x) versus incremental alone.

I had a similar experience on a 36-core machine earlier today. It seems
incremental is not working properly for the style crate: incremental is
supposed to have the same effect as sccache, but it still takes a long
time to compile style. I'm told mw is going to look into this in the
coming weeks.

In the meanwhile, as discussed on irc, it seems fair to disable
CARGO_INCREMENTAL when building with sccache.

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

Re: Must we rebuild all our rust code constantly?

2019-08-22 Thread Chris M. 
On Mon, Aug 19, 2019 at 10:32 PM Kris Maglione 
wrote:

> On Tue, Aug 20, 2019 at 02:23:06PM +0900, ISHIKAWA,chiaki wrote:
> >On 2019/08/20 9:11, Dave Townsend wrote:
> >>Thanks to a tip I've tracked this down. This seems to only be the case
> when
> >>I have sccache enabled. Disabling it gives me nice quick incremental
> builds
> >>again. Of course that isn't an ideal solution but it will do for now.
> >>
> >>On Mon, Aug 19, 2019 at 1:55 PM Dave Townsend 
> wrote:
> >>
> >>>For a couple of weeks now I've seen that any attempt to build Firefox,
> >>>even incremental builds seem to rebuild an awful lot of rust code. I
> found
> >>>this in the source which seems to suggest why:
> >>>
> https://searchfox.org/mozilla-central/source/config/makefiles/rust.mk#238.
> >>>But, this means that now an incremental build with a couple of code
> change
> >>>that have no impact on rust is taking upwards of 4 minutes to complete
> in
> >>>comparison to around 40 seconds, and the log file is full of cargo
> output.
> >>>I've heard similar comments from other developers.
> >>>
> >>>This is a pretty big increase in the time to compile and test and is
> >>>really slowing down my work. Is there any way we can avoid this?
> >>>
> >>
> >
> >
> >I am using linux for local development and noticed something similar.
> >
> >So I should disable sccache (!?).
>
> For what it's worth, Rust is now configured to use incremental
> compilation, which has its own cache which isn't cleared after
> clobber, so sccache isn't actually needed anymore. Ordinary
> ccache should be sufficient.
>
sccache will still cache dependencies from crates.io. From a quick check
building the rust in the tree on my laptop, a full cache hit for rust with
sccache produces a significant speedup (2x) versus incremental alone.

> ___
> 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: Must we rebuild all our rust code constantly?

2019-08-22 Thread Chris M. 
On Tue, Aug 20, 2019 at 12:33 PM Markus Stange  wrote:

> On 2019-08-19 8:11 p.m., Dave Townsend wrote:
> > Thanks to a tip I've tracked this down. This seems to only be the case
> when
> > I have sccache enabled. Disabling it gives me nice quick incremental
> builds
> > again.
>
> What's your sccache version? I think you may be hitting the following
> sccache bug which has been fixed already:
> https://github.com/mozilla/sccache/issues/436
>
> I'm using sccache 0.2.9 and I don't see rust code rebuilding constantly.
>
I've never been able to reproduce this issue, and that would explain why.

Can someone who's experienced this confirm upgrading sccache fixes it?

>
> Markus
> ___
> 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: Watch out for build issues on non-Unicode systems

2019-08-22 Thread Mike Hommey 
On Thu, Aug 22, 2019 at 02:42:48PM +0200, Nihanth Subramanya wrote:
> Note that the config.status changes in bug 844509 seem to break `$./mach
> clobber` - I had to manually rm -rf my objdir.

Filed as bug 1575959, fixed on mozilla-central.

Sorry for the annoyance.

Mike

> On Thu, Aug 22, 2019 at 2:35 AM Mike Hommey  wrote:
> 
> > Hi,
> >
> > In bug 1575135 and bug 844509, we've changed how configure handles
> > strings from files and subprocesses, to normalize everything to Unicode.
> >
> > On systems where the system locale is based on UTF-8 (e.g. most Linux
> > or macOS), this shouldn't make a difference.
> >
> > On systems where the system locale is not based on UTF-8, this might
> > cause problems, so please watch out, especially on non-Latin Windows.
> >
> > I don't believe things would have regressed (things should be handled
> > more or less similarly to before). I can think of a few things that
> > could fail, but for that matter, those I have in mind would have failed
> > before too.
> >
> > However, it is possible that a few corner cases that are not covered by
> > automation lead to configure complaining about some key or values not
> > being unicode strings. If that happens, please file bugs with your
> > mozconfig and as much detail as possible.
> >
> > Cheers,
> >
> > Mike
> > ___
> > 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 unship AppCache

2019-08-22 Thread Andrew Overholt 
It's been a long time coming :) Do you know if Chrome plans to drop
support, too?

On Wed, Aug 21, 2019 at 5:01 PM Jonathan Kingston  wrote:

> The design of AppCache brings many problems to the web platform from a
> performance and security perspective. Service workers have long solved the
> same use cases as AppCache.
>
> Removal of this code would bring a large reduction of code and complexity
> that is largely unmaintained.
>
> History
>
> Four years ago, in Firefox 44, we marked the API as deprecated[1].
>
> Back last year in Firefox 62, we disabled insecure AppCache and Chrome
> followed suit[2].
>
> Safari 11.1 added support for Service Workers, which are a replacement
> technology [3].
>
> Metrics
>
> Chrome measures a few different metrics here which suggest 2.3%[4] of
> secure page loads attempt to use the document visible API whilst only
> 0.27%[5] actually use the offline cache.
>
> Firefox metrics suggest around 0.01% of pages are using an AppCache[6]
> however we don’t have a distinct metric for the API usage.
>
> The last blocker for a removal was usage of AppCache by some Microsoft
> online products.  I’m enquiring into if this is still applicable and also
> want to ensure with this rollout plan that we don’t break these when the
> user has an online connection.
>
> Implementation
>
> Bug where the code will be implemented[7].
>
> Plan
>
>-
>
>In Firefox 70, Remove the previous preference
>“browser.cache.offline.insecure.enable” and related code, forcing all of
>the APIs to only ever be available over Secure Contexts despite user
>choice. Due to the insecure nature of insecure context AppCache it is a
>good time now to remove this fully.
>
>
>-
>
>Create a new preference that disables only the storage and use of
>AppCache data whilst permitting access to the dom property
>window.applicationCache and the “OfflineResourceList” interface.
>-
>
>   Disable access in Nighty and beta for 70 for two releases before
>   disabling for all other releases in 72.
>   -
>
>   Once storage is disabled in all releases:
>   -
>
>  Disable the API access in Nightly and beta via the existing
>  preference (browser.cache.offline.enable) in version 72.
>  -
>
>  Wait two releases and then disable in all releases in Firefox 74.
>
>
> This staged removal of AppCache is to reduce the risk of web compatibility
> issues of the API being accessible to page scripts. Despite the API
> presence it won’t have any ability to use the cache. We may look into
> shimming these APIs depending on how the rollout plan goes.
>
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1204581
>
> [2]
>
> https://groups.google.com/forum/#!msg/mozilla.dev.platform/qLTTpdzcDkw/WKJeq-4HAQAJ
>
> [3]
>
> https://developer.apple.com/library/archive/releasenotes/General/WhatsNewInSafari/Articles/Safari_11_1.html
>
>
> [4] https://www.chromestatus.com/metrics/feature/timeline/popularity/1248
>
> [5] https://www.chromestatus.com/metrics/feature/timeline/popularity/1246
>
> [6] https://mzl.la/2TKRbvA
> [7] https://bugzilla.mozilla.org/show_bug.cgi?id=1237782
> ___
> 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- Double-keyed HTTP cache

2019-08-22 Thread dom 
On Thursday, August 22, 2019 at 11:26:55 AM UTC+9, Martin Thomson wrote:
> Hi Sebastian,
> 
> I'm glad to see us moving toward having better isolation in this way.
> 
> In discussions of this sort of keying strategy, the guidance I repeatedly
> hear is that "double-keying" isn't sufficient and that you need to key on
> the chain of origins.  That is, if A frames B and C, and B in turn also
> frames C, then the two C frames are isolated from each other in the same
> way that they are isolated from a top-level C.
> 
> I took a look at both the fetch issue and your patch and it wasn't clear
> what strategy we're using.  As an aside, an issue on a repo isn't really a
> specification.  I couldn't find a PR on fetch either.

For what its worth, browsers are also discussing what changes will need to be 
made for certain requests (like prefetch) in a double-keyed world. See [1], and 
the associated HTML Standard PR [2]. But you're right, there doesn't seem to be 
a real spec change at the moment for double-keyed cache itself from what I know.

]1]: https://github.com/w3c/resource-hints/issues/82
[2]: https://github.com/whatwg/html/pull/4115
> 
> What is the tuple we're keying on?
> 
> Cheers,
> Martin
> 
> On Thu, Aug 22, 2019 at 3:40 AM Sebastian Streich 
> wrote:
> 
> > Intent to Implement- Double-keyed HTTP cache
> >
> >
> > Summary:
> >
> > Currently Browsers are vulnerable to cache-timing attacks, commonly
> > referred to as XS Leaks attacks. Starting with Firefox 70 we want to
> > explore a double-keyed HTTP cache. Instead of solely using the origin of
> > the resource, we will double key the HTTP Cache using the top-level origin.
> > Using the top-level origin as the 2nd Key in the HTTP Cache allows to
> > counterfeit XS Leaks and eliminates the ability of checking cache contents
> > across Origins.
> >
> > Bug:  Bugzilla 1536058
> > 
> >
> > Standard: https://github.com/whatwg/fetch/issues/904
> >
> > Platform coverage: all platforms
> >
> > Estimated or target release: Firefox 70
> >
> > Preference: The feature will be pref'd behind
> > “browser.cache.cache_isolation”
> >
> >  and disabled by default.
> >
> > Other browsers:
> >
> > webkit: shipped
> >
> > Chrome :
> > implementing
> >
> > web-platform-tests: 
> >
> > Secure contexts:  This feature isn’t restricted to Secure Contexts.
> > Estimated or target release: Firefox 70
> > ___
> > 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: Watch out for build issues on non-Unicode systems

2019-08-22 Thread Jonathan Kew 

On 22/08/2019 13:42, Nihanth Subramanya wrote:

Note that the config.status changes in bug 844509 seem to break `$./mach
clobber` - I had to manually rm -rf my objdir.



Ah, that'll be what just happened to me, too. (Not just ./mach clobber, 
I was getting the same failure with ./mach build as well.)


Unfortunately I was a bit slow to realize that manually rm'ing the 
objdir might help, so in the meantime I'd wasted time re-running ./mach 
bootstrap, checking if my python was current, etc. :\


JK


On Thu, Aug 22, 2019 at 2:35 AM Mike Hommey  wrote:


Hi,

In bug 1575135 and bug 844509, we've changed how configure handles
strings from files and subprocesses, to normalize everything to Unicode.

On systems where the system locale is based on UTF-8 (e.g. most Linux
or macOS), this shouldn't make a difference.

On systems where the system locale is not based on UTF-8, this might
cause problems, so please watch out, especially on non-Latin Windows.

I don't believe things would have regressed (things should be handled
more or less similarly to before). I can think of a few things that
could fail, but for that matter, those I have in mind would have failed
before too.

However, it is possible that a few corner cases that are not covered by
automation lead to configure complaining about some key or values not
being unicode strings. If that happens, please file bugs with your
mozconfig and as much detail as possible.

Cheers,

Mike
___
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
.



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

Re: Watch out for build issues on non-Unicode systems

2019-08-22 Thread Nihanth Subramanya 
To clarify: it only breaks the clobber of an existing old objdir.
Clobbering works fine henceforth.

On Thu, Aug 22, 2019 at 2:42 PM Nihanth Subramanya  wrote:

> Note that the config.status changes in bug 844509 seem to break `$./mach
> clobber` - I had to manually rm -rf my objdir.
>
> On Thu, Aug 22, 2019 at 2:35 AM Mike Hommey  wrote:
>
>> Hi,
>>
>> In bug 1575135 and bug 844509, we've changed how configure handles
>> strings from files and subprocesses, to normalize everything to Unicode.
>>
>> On systems where the system locale is based on UTF-8 (e.g. most Linux
>> or macOS), this shouldn't make a difference.
>>
>> On systems where the system locale is not based on UTF-8, this might
>> cause problems, so please watch out, especially on non-Latin Windows.
>>
>> I don't believe things would have regressed (things should be handled
>> more or less similarly to before). I can think of a few things that
>> could fail, but for that matter, those I have in mind would have failed
>> before too.
>>
>> However, it is possible that a few corner cases that are not covered by
>> automation lead to configure complaining about some key or values not
>> being unicode strings. If that happens, please file bugs with your
>> mozconfig and as much detail as possible.
>>
>> Cheers,
>>
>> Mike
>> ___
>> 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: Watch out for build issues on non-Unicode systems

2019-08-22 Thread Nihanth Subramanya 
Note that the config.status changes in bug 844509 seem to break `$./mach
clobber` - I had to manually rm -rf my objdir.

On Thu, Aug 22, 2019 at 2:35 AM Mike Hommey  wrote:

> Hi,
>
> In bug 1575135 and bug 844509, we've changed how configure handles
> strings from files and subprocesses, to normalize everything to Unicode.
>
> On systems where the system locale is based on UTF-8 (e.g. most Linux
> or macOS), this shouldn't make a difference.
>
> On systems where the system locale is not based on UTF-8, this might
> cause problems, so please watch out, especially on non-Latin Windows.
>
> I don't believe things would have regressed (things should be handled
> more or less similarly to before). I can think of a few things that
> could fail, but for that matter, those I have in mind would have failed
> before too.
>
> However, it is possible that a few corner cases that are not covered by
> automation lead to configure complaining about some key or values not
> being unicode strings. If that happens, please file bugs with your
> mozconfig and as much detail as possible.
>
> Cheers,
>
> Mike
> ___
> 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: multi-keyword values on the CSS 'display' property

2019-08-22 Thread Emilio Cobos Álvarez 

On 8/22/19 11:28 AM, 一丝 wrote:
Is there a plan to implement multi-valued table | flex | grid? E.g 
display: inline flex.


That should work, afaict.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: multi-keyword values on the CSS 'display' property

2019-08-22 Thread 一丝 
Is there a plan to implement multi-valued table | flex | grid? E.g display: 
inline flex.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to Implement- Double-keyed HTTP cache

2019-08-22 Thread Anne van Kesteren 
On Thu, Aug 22, 2019 at 4:26 AM Martin Thomson  wrote:
> What is the tuple we're keying on?

Top-level origin only. This still allows C to attack B in your
scenario (or vice versa). There's a variety of other side channel
attacks on " sites" too, including various members of the
Window object, history.length, and clickjacking. It would also allow B
or C to attack A, though there's a number of other things possible
there too.

I definitely think it's worth figuring out how we can enable "
sites" to better protect themselves as well as figuring out how to
improve sandboxing of " sites", but it would require a broader
effort than caches I think. I think isolating by top-level origin is a
huge improvement over the status quo and stops a fair number of
practical attacks against major sites (modulo popup attacks, see
Cross-Origin-Opener-Policy for that). (Many of which you can't frame
to be clear, due to X-Frame-Options.)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Must we rebuild all our rust code constantly?

2019-08-22 Thread Simon Sapin 

On 22/08/2019 03:42, ISHIKAWA, Chiaki wrote:

At the same time, I have a feeling that the debug symbol that rustc
generates may be a tad bigger than I would like it to be, but I need to
investigate more about this.


Sounds like this known bug of rustc:
https://github.com/rust-lang/rust/issues/56068

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