Re: PSA: searchfox now indexes rust

[Gijs Kruitbosch]

On 08/01/2018 21:51, Mike Hommey wrote:

On Mon, Jan 08, 2018 at 11:15:13AM -0500, Kartikaya Gupta wrote:

Just a heads-up, thanks to a bunch of work by Emilio, searchfox.org
now indexes rust code as well, so you can do things like jump to
function definitions and call sites and whatnot. Please use it and
file bugs under Webtools :: Searchfox for defects or feature requests.
I'm not sure how quickly we'll be able to fix them but it'll be good
to have stuff on file.


So, now that searchfox is definitely more useful than dxr, can we do
something about not having two such services?


I would like there not to be 2 services that we maintain etc.

However, querying searchfox is still less powerful than DXR. I can't 
search for two separate strings on the same line, I can't progressively 
filter my search by excluding more and more directories that I see 
turning up in searches that I don't care about, etc.


For indexing, it seems searchfox also doesn't index JS in any non-JS 
files (HTML, XUL, XBL, ...).


I expect which of the two is more useful is quite likely to depend on 
what people use it *for*.


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

Re: PSA: searchfox now indexes rust

[Mike Hommey]

On Mon, Jan 08, 2018 at 11:15:13AM -0500, Kartikaya Gupta wrote:
> Just a heads-up, thanks to a bunch of work by Emilio, searchfox.org
> now indexes rust code as well, so you can do things like jump to
> function definitions and call sites and whatnot. Please use it and
> file bugs under Webtools :: Searchfox for defects or feature requests.
> I'm not sure how quickly we'll be able to fix them but it'll be good
> to have stuff on file.

So, now that searchfox is definitely more useful than dxr, can we do
something about not having two such services?

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

Intent to ship: overscroll-behavior

[Botond Ballo]

I would like to ship support for the 'overscroll-behavior' CSS
property (formerly called 'scroll-boundary-behavior') in Firefox 59.

Preference behind which the feature was developed:
  layout.css.overscroll-behavior.enabled

"Intent to implement" thread:
  https://www.mail-archive.com/dev-platform@lists.mozilla.org/msg23947.html

Tracking bug for shipping:
  https://bugzilla.mozilla.org/show_bug.cgi?id=1428879

Draft spec:
  https://wicg.github.io/overscroll-behavior/

  There have not been any significant changes to the spec since
  the "Intent to implement" email, except for the change of name
  from 'scroll-boundary-behavior' to 'overscroll-behavior'.

Support by other browser engines:
  Blink: Shipping in Chrome 63 [1]
  Edge: Public support [2]
  WebKit: No public signals

Testing:
  The feature has a manual web-platform-test [3].
  The Chromium folks are working on upstreaming
  an automated web-platform-test [4].

Example:

  #chatbox {
/* Excess scrolling on the chatbox will not be handed off
to its parent scrollable .*/
overscroll-behavior: contain;
  }

  See [5] for more examples.

Cheers,
Botond

[1] https://www.chromestatus.com/features/5734614437986304
[2] 
https://discourse.wicg.io/t/generic-scroll-chaining-prevention-mechanism-or-expand-standardize-ms-scroll-chaining/1811/5?u=majidvp
[3] 
https://searchfox.org/mozilla-central/rev/cf149b7b63ff97023e28723167725e38cf5df757/testing/web-platform/tests/css/cssom-view/overscrollBehavior-manual.html
[4] https://bugs.chromium.org/p/chromium/issues/detail?id=762054
[5] https://wicg.github.io/overscroll-behavior/#motivating-examples
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Proposed W3C Charter: Web Payments Working Group

[L. David Baron]

The W3C is proposing a revised charter for:

  Web Payments Working Group
  https://w3c.github.io/webpayments/proposals/charter-2017
  https://lists.w3.org/Archives/Public/public-new-work/2018Jan/0002.html

Mozilla has the opportunity to send comments or objections through
Monday, February 5.

A diff relative to the current charter is:
https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2FPayments%2FWG%2Fcharter-201510.html=https%3A%2F%2Fw3c.github.io%2Fwebpayments%2Fproposals%2Fcharter-2017

The participants in the working group are:
https://www.w3.org/2000/09/dbwg/details?group=83744=1=org

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 almost
certainly say something.)

-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: PSA: searchfox now indexes rust

[Boris Zbarsky]

On 1/8/18 11:15 AM, Kartikaya Gupta wrote:

Just a heads-up, thanks to a bunch of work by Emilio, searchfox.org
now indexes rust code as well


This is awesome.  :)

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

Re: PSA: searchfox now indexes rust

[Bobby Holley]

This is amazing! I just tried it out and it's now much easier to navigate
around the style system.

Tooling like this matters a lot. My deepest thanks to everyone involved in
making this happen.

bholley

On Mon, Jan 8, 2018 at 8:15 AM, Kartikaya Gupta  wrote:

> Just a heads-up, thanks to a bunch of work by Emilio, searchfox.org
> now indexes rust code as well, so you can do things like jump to
> function definitions and call sites and whatnot. Please use it and
> file bugs under Webtools :: Searchfox for defects or feature requests.
> I'm not sure how quickly we'll be able to fix them but it'll be good
> to have stuff on file.
>
> Cheers,
> kats
> ___
> 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

QA Firefox 60 feature testing pi-requests deadline is January 10

[Tom Grabowski]

As suggested by Liz, I'm adding dev-platform@lists.mozilla.org to this
announcement.

Hi,

Similar to what QA did for Fx59 feature testing prioritization
,
we would like to do the same for Fx60. In order to help with the
process, *please
submit your pi-request
 by Jan 10. *This is
needed to assure QA will be involved in your feature development work for
the next Nightly 60 cycle.


*Q: What happens after the deadline?*
A: After the deadline QA will come back with a prioritized list of work
that represents what we are committing to for the next cycle. We want to
ensure this list matches eng and product expectations.

*Q: What if I miss the deadline?*
A: We reserve the right to say that we can't pick up work for late requests
in the current cycle. You can still develop and execute your own test plan
or defer the work to the following cycle.

*Q: What about unknown or unexpected requests? What if there is a business
reason for a late request? What do we do with experiments and System
Add-ons?*
A: In order to remain flexible, we will keep some percentage of time open
for requests like these.

*Q: There's no way I'm going to remember to do this. *
A: Do it now! I'll also send out a reminder next week.

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

PSA: searchfox now indexes rust

[Kartikaya Gupta]

Just a heads-up, thanks to a bunch of work by Emilio, searchfox.org
now indexes rust code as well, so you can do things like jump to
function definitions and call sites and whatnot. Please use it and
file bugs under Webtools :: Searchfox for defects or feature requests.
I'm not sure how quickly we'll be able to fix them but it'll be good
to have stuff on file.

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

Re: Intent to ship: RC4 disabled by default in Firefox 44

[shiv88534404]

On Tuesday, 1 September 2015 09:56:28 UTC-7, Richard Barnes  wrote:
> For a while now, we have been progressively disabling the known-insecure
> RC4 cipher [0].  The security team has been discussing with other the
> browser vendors when to turn off RC4 entirely, and there seems to be
> agreement to take that action in late January / early February 2016,
> following the release schedules of the various browsers.  For Firefox, that
> means version 44, currently scheduled for release on Jan 26.
> 
> More details below.
> 
> 
> # Current status
> 
> Since Firefox 37, RC4 has been partly disabled in Firefox.  It still works
> in Beta and Release, but in Nightly and Aurora, it is allowed only for a
> static whitelist of hosts [1][2].  Note that the whitelist is not
> systematic; it was mainly built from compatibility bugs.
> 
> RC4 support is controlled by three preferences:
> 
> * security.tls.unrestricted_rc4_fallback - Allows use of RC4 with no
> restrictions
> * security.tls.insecure_fallback_hosts.use_static_list - Allow RC4 for
> hosts on the static whitelist
> * security.tls.insecure_fallback_hosts - A list of hosts for which RC4 is
> allowed (empty by default)
> 
> 
> # Proposal
> 
> The proposed plan is to gradually reduce RC4 support by making the default
> values of these preferences more restrictive:
> 
> * 42/ASAP: Disable whitelist in Nightly/Aurora; no change in Beta/Release
> * 43: Disable unrestricted fallback in Beta/Release (thus allowing RC4 only
> for whitelisted hosts)
> * 44: Disable all RC4 prefs by default, in all releases
> 
> That is, as of Firefox 44, RC4 will be entirely disabled unless a user
> explicitly enables it through one of the prefs.
> 
> 
> # Compatibility impact
> 
> Disabling RC4 will mean that Firefox will no longer connect to servers that
> require RC4.  The data we have indicate that while there are still a small
> number of such servers, Firefox users encounter them at very low rates.
> 
> Telemetry indicates that in the Beta and Release populations, which have no
> restrictions on RC4 usage, RC4 is used for around 0.08% for Release and
> around 0.05%  for Beta [3][4].  For Nightly and Aurora, which are
> restricted to the whitelist, the figure is more like 0.025% [5].  These
> numbers are small enough that the histogram viewer on telemetry.mozilla.org
> won't show them (that's why the below references are to my own telemetry
> timeline tool, rather than telemetry.mozilla.org).
> 
> That said, there is a small but measurable population of servers out there
> that require RC4.  Scans by Mozilla QA team find that with current Aurora
> (whitelist enabled), around 0.41% of their test set require RC4, 820 sites
> out of 211k.  Disabling the whitelist only results in a further 26 sites
> broken, totaling 0.4% of sites.  I have heard some rumors about there being
> a higher prevalence of RC4 among enterprise sites, but have no data to
> support this.
> 
> Users can still enable RC4 in any case by changing the above prefs, either
> by turning on RC4 in general or by  adding specific hosts to the
> "insecure_fallback_hosts" whitelist.  The security and UX teams are
> discussing possibilities for UI that would automate whitelisting of sites
> for users.
> 
> [0] https://tools.ietf.org/html/rfc7465
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1128227
> [2]
> https://dxr.mozilla.org/mozilla-central/source/security/manager/ssl/IntolerantFallbackList.inc
> [3]
> https://ipv.sx/telemetry/general-v2.html?channels=release=SSL_SYMMETRIC_CIPHER_FULL=1
> [4]
> https://ipv.sx/telemetry/general-v2.html?channels=beta=SSL_SYMMETRIC_CIPHER_FULL=1
> [5]
> https://ipv.sx/telemetry/general-v2.html?channels=nightly%20aurora=SSL_SYMMETRIC_CIPHER_FULL=1

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

Re: Password autofilling

[Jonathan Kingston]

So it turns out dev-platform is plain text.

Here is a link explaining the states instead:
https://imgur.com/a/JO6pk

Thanks
Jonathan

On Mon, Jan 8, 2018 at 2:10 PM, Jonathan Kingston  wrote:

> I wanted to follow up to make it clear what the change would look like.
>
> Here is what autofill population looks like:
>
>
> Here is what the it looks like after autofill is disabled:
>
>
> ​
>
> This then becomes consistent with Private Browsing mode and HTTP sites
> already work.
> This is also consistent with how we fill Credit Cards and Addresses, we
> always require a user selection.
>
> When the user has multiple accounts we choose not to populate by default
> also:
>
> ​
>
> The term Autofill is used inconsistently in Nightly, to mean "On
> selection" and also "Populate field on load". The research post
> concentrates on just the pre-population of fields in which advertisers are
> stealing details from users that are unaware.
> Making this change to credential population will make autofill a
> consistent UX.
>
> The login manager filling happens over multiple pages (like the Google
> accounts screenshots above) which works the same with or without this
> change.
>
> Can we move to making signon.autofillForms = false the default on Nightly
> and Early Beta and see if we have issues?
>
> Kind regards
> Jonathan
>
> (Sorry for the super tiny images, dev-platform blocks bigger ones)
>
>
> On Wed, Jan 3, 2018 at 2:51 AM, Jonathan Kingston  wrote:
>
>> There are some other alternatives that we could take here:
>>
>> 1. Improve the UX of autofill
>>   a. present the credentials to the user on visible forms when the page
>> loads
>>   - Google had a project on doing this and it never got completed. It
>> appears there are many issues with this solution [4].
>> 2. Prevent autofill on third party forms
>>   - might not actually address the issue as advertisers are often first
>> party
>> 3. Add heuristics on if the form should be autofilled
>>   a. Don't fill when a form isn't visible, editable etc
>>
>> I also think that removing autofill aligns with the Credential Management
>> API, providing incentive for developers to use over having their forms
>> autofilled by default and that users expect their details to require an
>> interaction for filling.
>>
>> > There's an about:config pref, as [1] points out, which does this.
>>
>> My comment regarding this wasn't possible was misleading however I don't
>> expect the pref is discoverable to most.
>>
>> [4] https://twitter.com/estark37/status/947667756400361474
>>
>>
>> On Tue, Jan 2, 2018 at 5:23 PM, Axel Hecht  wrote:
>>
>>> Am 02.01.18 um 17:22 schrieb Gijs Kruitbosch:
>>>
>>> On 01/01/2018 20:08, Jonathan Kingston wrote:

> We have the ability to turn off the whole login manager within Firefox
> preferences: "Remember logins and passwords for web sites" but no way
> to
> prevent autofill.
>

 There's an about:config pref, as [1] points out, which does this.

 I wonder if there's a way to require user interaction only when pages
 contain non-same-origin scripts. Then again, it's not clear that that'd be
 "worth it", in the sense that that would actually significantly reduce the
 number of pages where user interaction would be required, nor that it
 wouldn't make the browser's behaviour less understandable to end users (as
 we would sometimes autofill without interaction, and sometimes wouldn't).

 In other form code we also care about whether form fields are focusable
 (ie visible, editable etc.), which is something we could also potentially
 use to mitigate these attacks, though it could probably be bypassed by
 having a visible element that is positioned "offscreen" in an
 overflow:hidden container, or something of that sort.

 ~ Gijs

>>>
>>> Or could we start blocking tracking-providers with this practice in
>>> general?
>>>
>>> As much as this sounds like an arm-race, these providers are only
>>> valuable if they're on a lot of sites, so this might actually be a winnable
>>> arm-race.
>>>
>>> Axel
>>> ___
>>> 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

Fwd: Password autofilling

[Jonathan Kingston]

I wanted to follow up to make it clear what the change would look like.

Here is what autofill population looks like:


Here is what the it looks like after autofill is disabled:


​

This then becomes consistent with Private Browsing mode and HTTP sites
already work.
This is also consistent with how we fill Credit Cards and Addresses, we
always require a user selection.

When the user has multiple accounts we choose not to populate by default
also:

​

The term Autofill is used inconsistently in Nightly, to mean "On selection"
and also "Populate field on load". The research post concentrates on just
the pre-population of fields in which advertisers are stealing details from
users that are unaware.
Making this change to credential population will make autofill a consistent
UX.

The login manager filling happens over multiple pages (like the Google
accounts screenshots above) which works the same with or without this
change.

Can we move to making signon.autofillForms = false the default on Nightly
and Early Beta and see if we have issues?

Kind regards
Jonathan

(Sorry for the super tiny images, dev-platform blocks bigger ones)


On Wed, Jan 3, 2018 at 2:51 AM, Jonathan Kingston  wrote:

> There are some other alternatives that we could take here:
>
> 1. Improve the UX of autofill
>   a. present the credentials to the user on visible forms when the page
> loads
>   - Google had a project on doing this and it never got completed. It
> appears there are many issues with this solution [4].
> 2. Prevent autofill on third party forms
>   - might not actually address the issue as advertisers are often first
> party
> 3. Add heuristics on if the form should be autofilled
>   a. Don't fill when a form isn't visible, editable etc
>
> I also think that removing autofill aligns with the Credential Management
> API, providing incentive for developers to use over having their forms
> autofilled by default and that users expect their details to require an
> interaction for filling.
>
> > There's an about:config pref, as [1] points out, which does this.
>
> My comment regarding this wasn't possible was misleading however I don't
> expect the pref is discoverable to most.
>
> [4] https://twitter.com/estark37/status/947667756400361474
>
>
> On Tue, Jan 2, 2018 at 5:23 PM, Axel Hecht  wrote:
>
>> Am 02.01.18 um 17:22 schrieb Gijs Kruitbosch:
>>
>> On 01/01/2018 20:08, Jonathan Kingston wrote:
>>>
 We have the ability to turn off the whole login manager within Firefox
 preferences: "Remember logins and passwords for web sites" but no way to
 prevent autofill.

>>>
>>> There's an about:config pref, as [1] points out, which does this.
>>>
>>> I wonder if there's a way to require user interaction only when pages
>>> contain non-same-origin scripts. Then again, it's not clear that that'd be
>>> "worth it", in the sense that that would actually significantly reduce the
>>> number of pages where user interaction would be required, nor that it
>>> wouldn't make the browser's behaviour less understandable to end users (as
>>> we would sometimes autofill without interaction, and sometimes wouldn't).
>>>
>>> In other form code we also care about whether form fields are focusable
>>> (ie visible, editable etc.), which is something we could also potentially
>>> use to mitigate these attacks, though it could probably be bypassed by
>>> having a visible element that is positioned "offscreen" in an
>>> overflow:hidden container, or something of that sort.
>>>
>>> ~ Gijs
>>>
>>
>> Or could we start blocking tracking-providers with this practice in
>> general?
>>
>> As much as this sounds like an arm-race, these providers are only
>> valuable if they're on a lot of sites, so this might actually be a winnable
>> arm-race.
>>
>> Axel
>> ___
>> 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

[desktop] Bugs logged by Desktop Release QA in the last 8 days

[Bogdan Maris]

Hello,

Here's the list of new issues found and filed by the Desktop Release QA team 
last week.
Additional details on the team's priorities last week, as well as the plans for 
the current week are available at: https://goo.gl/tqu63Y 
.

Bugs logged by Desktop Release QA in the last 8 days

* NEW - https://bugzil.la/1427735  - [Google 
calendar] Graphical artifact inside the Create event page
* NEW - https://bugzil.la/1428368  - Minimize, 
Maximize and Close buttons are not visible when High Contrast Theme is 
activated at the same time with the Light browser theme.

This is available as a Bugzilla bug list as well: https://mzl.la/2CHbReB 
.

Regards,
Bogdan (:bogdan_maris)
Desktop Release QA
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform