Re: How would you like to spell check this?

[Ehsan Akhgari]

On 2015-09-03 6:44 AM, Florian Quèze wrote:

The solution I would like to see implemented (and I'm willing to help)
is automatic detection of the language.


Note that in addition to this, in order to make the feature completely 
useful for multilingual users, we would need to implement support for 
multilanguage spell checking as well (so that we can deal with more than 
one language in a text box correctly) which is another thing that we 
should improve some day.  What makes this difficult now is the fact that 
the spell checking code is written assuming that each editor object has 
only one spell checker which is limited to one dictionary loaded in the 
underlying hunspell component.  This is another thing that people have 
asked us for in the past.

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

Re: Sheriffing Newsletter September!

[Lawrence Mandel]

> 1. Ryan's last week as Sheriff!
>
> As you might have heard that RyanVM is leaving the Sheriff Team to he will
> be leading a new quality team as part of the Firefox org. So its his last
> week as Sheriff this week.
> Thanks for all what do you did for keeping the Trees open and making the
> Sheriff-Role and Sheriffing what it is today and all the best for your new
> Role Ryan!
>
> Also of course there will be other Sheriffs around if you have questions
> let us know anytime (see the contact section below).
>
>
Ryan - You were really excellent in the sheriff role. A great partner for
release management and a strong defender or the tree. I'm thrilled that
you've found a new way to help the Mozilla project. Congratulations on your
new role!

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

Prioritizing tests based on file changes

[Christopher Manchester]

Some tests are more likely than others to fail in response to a given
change, but our automation does little to optimize based on this. As a
result, test automation frequently runs more than necessary for a given
push, leading to excess load on automation and time spent waiting for the
results of tests unlikely to be impacted by a given push.

Work is ongoing on an approach to select/prioritize tests based on the
files that a push changes. The idea is to use build system metadata to map
changed files from source control to impacted tests. This will be based on
the test files included in manifests mentioned in moz.build files along the
path to a given file, and a syntax to specify other relationships between
source files and tests. The syntax isn’t finalized, but the proposal is
that an annotation such as:

with Files(‘testing/mozbase/**’):

   IMPACTED_TESTS += [

   ‘testing/mochitest/tests/**’,

   ]

in a moz.build file will suggest that any file change under
‘testing/mozbase’ is potentially relevant to the mochitest sanity tests.
Specifying tests by tag or test flavor (so you can run all reftests when
parts of layout change, for instance) will be supported in addition to
wildcard file matching.

Tools will use this data to run a subset of tests either before or in place
of a full set of tests. Initially this will be an option for |./mach try|
and |./mach test|, and upcoming work will make it possible to take
advantage of this on integration branches and in coordination with
autoland. There’s also potential to refine and automate this process
further with auxiliary sources of data (such as code coverage), and longer
term I’d like to see annotations become a supplement to a more automatic
prioritization algorithm.

This isn’t intended to be a complete solution, or to replace the current
pipeline: there will always be interactions between code and tests that
can’t reasonably be anticipated. It is, however, an optimization that has
the potential to shorten feedback cycles on Try, help improve integration
tree availability by shortening time to detect regressions, and reduce
overall infrastructure load.

If you’d like to follow this or give feedback on the proposed syntax and
heuristics, initial work is tracked in bug 1184405.


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

Re: Prioritizing tests based on file changes

[Mike Hoye]

On 2015-09-03 4:24 PM, Christopher Manchester wrote:

Work is ongoing on an approach to select/prioritize tests based on the
files that a push changes.

https://youtu.be/IUZEtVbJT5c?t=20


- mhoye

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

Re: How would you like to spell check this?

[Florian Quèze]

On Sun, Aug 30, 2015 at 10:17 PM, Jörg Knobloch  wrote:

> So please voice your objections to the proposed solution, if any ;-)

As someone mentioned already, lots of websites are actually
communication tools (eg. webmail, chat, social networks), and there's
no way the website can know in advance in which language I'll want to
type (I write half the time in French and half the time in English).
My personal experience is that touching a context menu to switch the
dictionary all the time is too much effort, so I gave up and am now
used to completely ignoring the red underlines.

The solution I would like to see implemented (and I'm willing to help)
is automatic detection of the language. We already ship language
detection code 
(http://mxr.mozilla.org/mozilla-central/source/browser/components/translation/LanguageDetector.jsm)
and this could be reused for spell checking. Of course we can't guess
the language when the user starts typing (so we'll still need the
mechanisms you discussed), but as soon as we have a couple words, the
detection is pretty reliable.
This would of course need a way to pref it off for people who speak a
single language and would be annoyed if every once in a while the
dictionary is switched automatically; but I think it would make the
spell checker significantly more usable for multi-language users.

Florian

-- 
Florian Quèze
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: How would you like to spell check this?

[Jörg Knobloch]

On 3/09/2015 12:44, Florian Quèze wrote:
The solution I would like to see implemented (and I'm willing to help) 
is automatic detection of the language.


Nice idea.

I'd like to clean-up the current behaviour first in 
https://bugzilla.mozilla.org/show_bug.cgi?id=1200533 so we have a solid 
base to start from.


This would of course need a way to pref it off for people who speak a 
single language and would be annoyed if every once in a while the 
dictionary is switched automatically; but I think it would make the 
spell checker significantly more usable for multi-language users.


I think this is where Ehsan's argument comes in, to define the user 
interface first (for which I didn't find any support by the UX team).


Currently, "spellchecker.dictionary" is set when the user sets a 
language from the right-click (context) menu. This will only serve as a 
fallback for sites, where no language is defined by the page content.


There are people who want a global override of this (see 
https://bugzilla.mozilla.org/show_bug.cgi?id=1073840).


We could consider both issues at the same time later. I would like to 
fix what is broken now and causes much confusion amongst the users 
before embarking on new adventures.


Jorg K.



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

Re: How would you like to spell check this?

[Panos Astithas]

On Thu, Sep 3, 2015 at 1:44 PM, Florian Quèze  wrote:

> On Sun, Aug 30, 2015 at 10:17 PM, Jörg Knobloch  wrote:
>
> > So please voice your objections to the proposed solution, if any ;-)
>
> As someone mentioned already, lots of websites are actually
> communication tools (eg. webmail, chat, social networks), and there's
> no way the website can know in advance in which language I'll want to
> type (I write half the time in French and half the time in English).
> My personal experience is that touching a context menu to switch the
> dictionary all the time is too much effort, so I gave up and am now
> used to completely ignoring the red underlines.
>
> The solution I would like to see implemented (and I'm willing to help)
> is automatic detection of the language. We already ship language
> detection code (
> http://mxr.mozilla.org/mozilla-central/source/browser/components/translation/LanguageDetector.jsm
> )
> and this could be reused for spell checking. Of course we can't guess
> the language when the user starts typing (so we'll still need the
> mechanisms you discussed), but as soon as we have a couple words, the
> detection is pretty reliable.
> This would of course need a way to pref it off for people who speak a
> single language and would be annoyed if every once in a while the
> dictionary is switched automatically; but I think it would make the
> spell checker significantly more usable for multi-language users.


+1000
___
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

[Tanvi Vyas]

Do we know if Chrome or IE will have a fallback UI?

On 9/1/15 10:30 AM, Richard Barnes wrote:

And from Microsoft:

http://blogs.windows.com/msedgedev/2015/09/01/ending-support-for-the-rc4-cipher-in-microsoft-edge-and-internet-explorer-11/

On Tue, Sep 1, 2015 at 1:03 PM, Richard Barnes  wrote:


Speaking of other browsers, the corresponding Chromium thread is here:


https://groups.google.com/a/chromium.org/forum/#!msg/security-dev/kVfCywocUO8/vgi_rQuhKgAJ


On Tue, Sep 1, 2015 at 12:56 PM, 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


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