Re: Intent to ship: navigator.hardwareConcurrency

[Domenic Denicola]

On Tuesday, March 15, 2016 at 12:26:21 AM UTC-4, Boris Zbarsky wrote:
> * Link to standard: You're funny.  People don't bother to put stuff into 
> actual specs anymore.  The closest we have is 
> https://wiki.whatwg.org/wiki/NavigatorCores which does at least have 
> some IDL and some discussion around privacy and whatnot.

Filed https://github.com/whatwg/html/issues/879; should be able to have it in 
the spec by sometime tomorrow.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: W3C WebAppSec credentialmanagement API

[Matthew N.]

On 2016-03-10 12:07 PM, Ben Kelly wrote:

I believe Matthew Noorenberghe had some concerns about the necessity of the
API given requestAutocomplete:


https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/7ouLjWzcjb0/s7aZHGnlAwAJ
  https://github.com/w3c/webappsec-credential-management/issues/2

We should probably come to some consensus there before moving forward.


Axel was already on a thread about this concern before sending out the 
intent to implement so I'm not sure why this intent was sent out a day 
later when the concerns weren't yet addressed.


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

Re: Proposal: revisit and implement navigator.hardwareConcurrency

[Boris Zbarsky]

On 3/14/16 5:30 PM, Ehsan Akhgari wrote:

I brought this up in an in person meeting about this a while ago.  It
seems pretty hard to justify returning a number more than our per-origin
worker limit.  To be clear, this will be a clamping different to what
WebKit does.


OK.  So my current plan is to implement this, clamp to the max workers 
per domain number, but do no other clamping.  Failures of various kinds 
in the API will just cause it to return 1.  I guess I'll send and intent 
to ship.


I'm not sure there's an actual spec for this other than 
https://wiki.whatwg.org/wiki/NavigatorCores though...


-Boris

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

Re: Proposal: revisit and implement navigator.hardwareConcurrency

[Kyle Huey]

On Mon, Mar 14, 2016 at 2:30 PM, Ehsan Akhgari 
wrote:

> On 2016-03-14 3:23 PM, Boris Zbarsky wrote:
> > On 9/8/15 3:21 PM, Luke Wagner wrote:
> >> On a more technical detail: WebKit and Chromium have both shipped,
> >> returning the number of logical processors where WebKit additionally
> >> clamps to 2 (on iOS) or 8 (otherwise) [6] which is explicitly allowed
> >> by WHATWG text [7].  I would argue for not clamping (like Chrome),
> >
> > Given the use cases, should we clamp to our per-origin limit?
>
> I brought this up in an in person meeting about this a while ago.  It
> seems pretty hard to justify returning a number more than our per-origin
> worker limit.  To be clear, this will be a clamping different to what
> WebKit does.
>

That number is 20 or 50 or something like that though.

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

Re: Proposal: revisit and implement navigator.hardwareConcurrency

[Ehsan Akhgari]

On 2016-03-14 3:23 PM, Boris Zbarsky wrote:
> On 9/8/15 3:21 PM, Luke Wagner wrote:
>> On a more technical detail: WebKit and Chromium have both shipped,
>> returning the number of logical processors where WebKit additionally
>> clamps to 2 (on iOS) or 8 (otherwise) [6] which is explicitly allowed
>> by WHATWG text [7].  I would argue for not clamping (like Chrome),
> 
> Given the use cases, should we clamp to our per-origin limit?

I brought this up in an in person meeting about this a while ago.  It
seems pretty hard to justify returning a number more than our per-origin
worker limit.  To be clear, this will be a clamping different to what
WebKit does.

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

Re: Intent to implement: W3C WebAppSec credentialmanagement API

[Martin Thomson]

I don't think that there was any misunderstanding in what it is that
is being proposed, just disagreement about cost-benefit.

On Mon, Mar 14, 2016 at 8:02 PM, Mike West  wrote:
> Websites use passwords today. While I agree that we can and should be
> working on something better, I don't think that we should overlook small
> improvements in the status quo. We can give users a better experience on
> their favourite sites if we allow developers to bypass status quo
> heuristics, and we keep users safer if we mitigate some of the XSS risks of
> password managers today. I think this API does both, and is worth
> experimenting with to see if it's a framework we can build upon.

Maybe it's a value thing, I don't see that gold-plating this
experience is going to make a difference commensurate with the cost.
The fetch API changes are the core of the purported benefit, and that
turns out to be a non-trivial thing, with the added cost of indefinite
support for a feature we don't really want in support of a mechanism
that isn't that great.

The actual benefit is something that is only realized once a site puts
in the effort required.  That is small, yes, but we're seeing sites
actively avoid password managers, hence the aggressive heuristics, and
rAC is much more likely to work for that, since it's implemented and
deployed already.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: MacOS 10.6-10.8 support

[Gabor Krizsanits]

On Mon, Mar 14, 2016 at 8:51 PM, Benjamin Smedberg 
wrote:

>
>
> On 3/12/2016 7:19 PM, Gabor Krizsanits wrote:
>
>>
>> Seems like a tough decision for such a short time...  There were some
>> great
>> points on both sides so far, but I'm missing the math. To evaluate the
>> cost/benefit for a decision like this we should be able to estimate how
>> much engineering time does it take for us to gain 1.2% new users and how
>> much does it cost to keep the support. My personal estimation for the
>> first
>> is pretty high :(
>>
>
> The math is pretty striking: the problem is not so much about user
> acquisition but about retention and user engagement. We have no problem
> getting new Firefox users: we still have amazingly high brand recognition
> and get many downloads. In terms of retention, what kind of engineering
> effort do we need to do to keep users one, two, four, eight weeks after
> they've tried Firefox? In terms of ongoing engagement, the Firefox product
> strategy has us measuring and optimizing how many days (per week) Firefox
> users use Firefox.
>
> Our basic product strategy is that by focusing our engineering efforts on
> engagement/retention of new users, we'll end up in a much better spot, both
> in terms of overall product quality and our position in the market, than if
> we focus on keeping small cohorts of existing users. That tradeoff of
> existing users for new-user engagement is driving our strategy with e10s,
> extensions, and other engineering priorities, and is the basis for this
> decision.
>
> --BDS
>

Thanks for the explanation that makes perfect sense to me. By the way since
the questions is never if we drop support for a system but when do we do
it, would it make sense to track / measure of how much work went into
maintaining a particular system in the last x month (or will be in the next
month like in the e10s case)? I guess that data would help to make this
decision easier and with less debates (although there are ofc always
exceptional cases for fundamental releases like e10s).

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

Re: Tier-1 for Linux 64 Debug builds in TaskCluster on March 14 (and more!)

[Selena Deckelmann]

We've got two outstanding bugs (
https://bugzilla.mozilla.org/show_bug.cgi?id=1231320 and
https://bugzilla.mozilla.org/show_bug.cgi?id=1174263), and so are
postponing this for at least a week. I will give an update this Friday if
we're able to set a date for the switch over.

Sorry for the noise!

-selena

On Tue, Mar 8, 2016 at 2:06 PM Selena Deckelmann  wrote:

> The time has come! We are planning to switch to Tier-1 on Treeherder for
> TaskCluster Linux 64 Debug build jobs on March 14. At the same time, we
> will hide the Buildbot build jobs, but continue running them.
>
> On March 21, we plan to switch the Linux 64 Debug tests to Tier-1 and hide
> the related Buildbot test jobs.
>
> After about 30 days, we plan to disable and remove all Buildbot jobs
> related to Linux Debug.
>
>
>
> Background:
>
> We've been running Linux 64 Debug builds and tests using TaskCluster
> side-by-side with Buildbot jobs since February 18th. Some of the project
> work that was done to green up the tests is documented here:
> https://public.etherpad-mozilla.org/p/buildbot-to-taskcluster-migration
>
> The new tests are running in Docker-ized environments, and the Docker
> images we use are defined in-tree and publicly accessible.
>
> This work was the culmination of many months of effort, with Joel Maher,
> Dustin Mitchell and Armen Zambrano primarily focused on test migration this
> quarter. Thank you to everyone who responded to NEEDINFOs, emails and pings
> on IRC to help with untangling busted test runs.
>
> On performance, we're taking a 14% hit across all the new test jobs vs.
> the old jobs in Buildbot. We ran two large-scale tests to help determine
> where slowness might still be lurking, and were able to find and fix many
> issues. There are a handful of jobs remaining that seem significantly
> slower, while others are significantly faster.  We decided that it was more
> important to deprecate the old jobs and start exclusively maintaining the
> new jobs now, rather than wait to resolve the remaining performance issues.
> Over time we hope to address issues with the owners of the affected test
> suites.
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: MacOS 10.6-10.8 support

[Benjamin Smedberg]

On 3/12/2016 7:19 PM, Gabor Krizsanits wrote:


Seems like a tough decision for such a short time...  There were some great
points on both sides so far, but I'm missing the math. To evaluate the
cost/benefit for a decision like this we should be able to estimate how
much engineering time does it take for us to gain 1.2% new users and how
much does it cost to keep the support. My personal estimation for the first
is pretty high :(


The math is pretty striking: the problem is not so much about user 
acquisition but about retention and user engagement. We have no problem 
getting new Firefox users: we still have amazingly high brand 
recognition and get many downloads. In terms of retention, what kind of 
engineering effort do we need to do to keep users one, two, four, eight 
weeks after they've tried Firefox? In terms of ongoing engagement, the 
Firefox product strategy has us measuring and optimizing how many days 
(per week) Firefox users use Firefox.


Our basic product strategy is that by focusing our engineering efforts 
on engagement/retention of new users, we'll end up in a much better 
spot, both in terms of overall product quality and our position in the 
market, than if we focus on keeping small cohorts of existing users. 
That tradeoff of existing users for new-user engagement is driving our 
strategy with e10s, extensions, and other engineering priorities, and is 
the basis for this decision.


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

Re: Proposal: revisit and implement navigator.hardwareConcurrency

[Mats Palmgren]

On 9/8/15 3:21 PM, Luke Wagner wrote:

On a more technical detail: WebKit and Chromium have both shipped,
returning the number of logical processors where WebKit additionally
clamps to 2 (on iOS) or 8 (otherwise) [6] which is explicitly allowed
by WHATWG text [7].  I would argue for not clamping (like Chrome),


If that clamping is good enough for WebKit then why shouldn't it
work for our users too?

/Mats

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

Platform engineering project of the month: Perfherder

[William Lachance]

Hello from Platform Engineering Operations! Once a month we highlight 
one of our projects to help the Mozilla community discover a useful tool 
or an interesting contribution opportunity.


This month’s project is Perfherder!

What is Perfherder?

Perfherder is a generic system for visualizing and analyzing performance 
data produced by the many automated tests we run here at Mozilla (such 
as Talos, "Are we fast yet?" or "Are we slim yet?"). The chief goal of 
the project is to make sure that performance of Firefox gets better, not 
worse over time. It does this by:


* Tracking the performance generated by our automated tests, allowing
  them to be visualized on a graph.
* Providing a sheriffing dashboard which allows for incoming
  alerts of performance regressions to be annotated and triaged - bugs
  can be filed based on a template and their resolution status can be
  tracked.

In addition to its own user interface, Perfherder also provides an
API on the backend that other people can use to build custom
performance visualizations and dashboards. For example, the metrics
group has been working on a set of release quality indices for
performance based on Perfherder data:

https://metrics.mozilla.com/quality-indices/

How it works

Perfherder is part of Treeherder, building on that project's existing
support for tracking revision and test job information. Like the rest
of Treeherder, Perfherder's backend is written in Python, using the
Django web framework. The user interface is written as an AngularJS
application.

Learning more

For more information on Perfherder than you ever wanted to know, please 
see the wiki page:


https://wiki.mozilla.org/EngineeringProductivity/Projects/Perfherder

Can I contribute?

Yes! We have had some fantastic contributions from the community to
Perfherder, and are always looking for more. This is a great way to
help developers make Firefox faster (or use less memory). The core of 
Perfherder is relatively small, so this is a great chance to learn 
either Django or Angular if you have a small amount of Python and/or 
JavaScript experience.


We have set aside a set of bugs that are suitable for getting
started here:

https://bugzilla.mozilla.org/buglist.cgi?list_id=12722722=---_whiteboard_type=allwordssubstr_format=advanced_whiteboard=perfherder-starter-bug

For more information on contributing to Perfherder, please see the
contribution section of the above wiki page:

https://wiki.mozilla.org/EngineeringProductivity/Projects/Perfherder#Contribution

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

Re: Proposal: revisit and implement navigator.hardwareConcurrency

[Boris Zbarsky]

On 9/8/15 3:21 PM, Luke Wagner wrote:

On a more technical detail: WebKit and Chromium have both shipped,
returning the number of logical processors where WebKit additionally
clamps to 2 (on iOS) or 8 (otherwise) [6] which is explicitly allowed
by WHATWG text [7].  I would argue for not clamping (like Chrome),


Given the use cases, should we clamp to our per-origin limit?

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

Re: Intent to deprecate: MacOS 10.6-10.8 support

[Kartikaya Gupta]

On Thu, Mar 10, 2016 at 5:45 PM, Anthony Jones  wrote:
> My understanding is that the reason people stick to 10.6 is because of
> Rosetta[1] which offers PowerPC compatibility.

I have a laptop on 10.6. The hardware can theoretically support newer
OS X versions, and I've upgraded it, but newer OS X versions are
severely unstable on it, causing hangs and spontaneous OS reboots. So
I downgraded back to 10.6. I don't know if this is a common scenario
but given Apple's hardware uniformity I'm probably not the only one
who has experienced this. Just saying Rosetta isn't the only reason
people stay on 10.6 :)

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

Re: Intent to deprecate: MacOS 10.6-10.8 support

[Richard Z]

On Fri, Mar 11, 2016 at 04:28:50PM -0800, Terrence Cole wrote:
> We've had this conversation several times in the last few years and I think
> I've finally figured out why it has always felt subtly wrong.
> 
> Our share of users on older platforms is disproportionally high compared to
> the market in general because of our decline in market share. People who
> don't want to upgrade their OS generally don't want to "upgrade" their
> browser to the shiny new "chrome" thing the kids are talking about either.

here is the problem. Firefox has a different userbase than chrome.
In my perceprion it is people who are cautious, prefer stable interfaces, 
not attracted to blingbling and more focused on stability, privacy and 
security.

Much of the blingbling features which some developers die for are
a plain nuisance for a significant share of users.
It took 4 years to fix the autoplay bug at least partially?
 https://bugzilla.mozilla.org/show_bug.cgi?id=659285

This is what is driving away users.

Firefox won't win the blingbling race with Google and Co, maybe if it
focuses on its traditional userbase and their demands it would do 
better.


Richard

-- 
Name and OpenPGP keys available from pgp key servers

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

Re: Intent to deprecate: MacOS 10.6-10.8 support

[Justin Dolske]

I don't think it's entirely unfair -- both sets of numbers have their
place. OS X is an important platform, but it's also true that these older
OS X releases represent a tiny portion of our overall userbase.

For a few more data points...

Back in Firefox 16 when we dropped 10.5 -- another long-lived and popular
release -- those users represented 17% of our OS X users (or 0.78% of
overall userbase). Dropping 10.6 - 10.8 is about 1.5x the impact
(percentage wise), and so we should think carefully about that, but it's
not significantly out of character for what we've done before.
https://groups.google.com/d/msg/mozilla.dev.platform/aT7hy7YDdqA/j2O0bUnuYMEJ

When we dropped 10.4 (early in the Firefox 4.0 cycle, about a year before
release), it represented 25% of 3.5 users and 17% of 3.6 users. (I don't
see a overall userbase number in the thread.)
https://groups.google.com/d/msg/mozilla.dev.planning/fTpkdYa6uZM/9aPn58hvVa8J

And wy back when we dropped 10.3 (for FF3.0), it represented 16.5% of
OS X users, 0.69% of total user base.
http://groups.google.com/group/mozilla.dev.planning/msg/c19ecb46e27dbf91
http://groups.google.com/group/mozilla.dev.planning/msg/4bd908b72a5e0759

One thing all of these threads show is that there's a lot of noise and
handwringing and doomsayers when we broach the topic of dropping support
for an OS X release. :)

Justin

On Thu, Mar 10, 2016 at 2:25 PM, Mike Hommey  wrote:

> On Thu, Mar 10, 2016 at 01:03:43PM -0500, Benjamin Smedberg wrote:
> > This is notice of an intent to deprecate support within Firefox for the
> > following old versions of MacOS: 10.6, 10.7, and 10.8
> >
> > The motivation for this change is that we have continued failures that
> are
> > specific to these old operating systems and don't have the resources on
> > engineering teams to prioritize these bugs. Especially with the
> deployment
> > of e10s we're seeing intermittent and permanently failures on MacOS 10.6
> > that we are not seeing elsewhere. We get very little testing of old MacOS
> > versions from our prerelease testers and cannot dedicate much paid staff
> > testing support to these platforms. We also have an increasingly fragile
> set
> > of old hardware that supports automated tests on 10.6 and do not intend
> to
> > replace this.
> >
> > This will affect approximately 1.2% of our current release population.
> Here
> > are the specific breakdowns by OS version:
> >
> > 10.6
> >   0.66%
> > 10.7
> >   0.38%
> > 10.8
> >   0.18%
>
> It's unfair to mention those populations by percentage of the global
> Firefox population. What are those percentages relative to the number of
> OSX users? ISTR 10.6 represented something like 25% of the OSX users,
> which is a totally different story (but maybe I'm mixing things with
> Windows XP).
>
> Mike
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: MacOS 10.6-10.8 support

[Dao Gottwald]

Mike Hommey wrote on 11.03.2016 01:52:

>> Why can't we just not ship e10s to these users?  We have a number of other
>> populations we're not shipping to, at least for now.
> 
> This is actually a sensible option.
> A not-quite top-notch but up-to-date Firefox is still better than old
> versions of Firefox or other browsers.

Is it? Are you confident that quality and stability of an up-to-date Firefox 
won't go downwards over time on those old platforms? It's not quite clear to me 
that it will perform better than ESR half a year or a year from now.

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

Re: Intent to deprecate: MacOS 10.6-10.8 support

[Anthony Jones]

  
  
My understanding is that the reason people stick to 10.6 is because
of Rosetta[1] which offers PowerPC compatibility.

https://en.wikipedia.org/wiki/Rosetta_(software)

Chrome is dropping support for these platforms so it seems like an
opportunity to pick up some of their discarded users. I'd rather
have a 1% gain in market share than a 1% loss. The question is
whether supporting 10.6 costs us more than 1% of our resources.

Some people may upgrade from 10.7 or 10.8 but last time I looked at
the graph I saw 10.6 was on very slow decay path probably inline
with hardware replacement.

10.6 has been more effort to support in the past (i.e. getting
decoders working) but I don't think it costs us more to maintain.

Anthony

On 11/03/2016 11:31, Nathan Froyd
  wrote:


  

  On Thu, Mar 10, 2016 at 5:25 PM, Mike
Hommey 
wrote:
On Thu, Mar 10, 2016 at 01:03:43PM -0500,
Benjamin Smedberg wrote:
> This will affect approximately 1.2% of our current
release population. Here
> are the specific breakdowns by OS version:
>
> 10.6
>       0.66%
> 10.7
>       0.38%
> 10.8
>       0.18%

  It's unfair to mention those populations by
  percentage of the global
  Firefox population. What are those percentages relative to
  the number of
  OSX users? ISTR 10.6 represented something like 25% of the
  OSX users,
  which is a totally different story (but maybe I'm mixing
  things with
  Windows XP).

  
  

I heard much the same thing from the
  media team when I suggested getting rid of 10.6 support to
  make our C++ standard library situation easier.  CC'ing
  Anthony.
  

-Nathan

  


  

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

Re: On nsICancelableRunnable (or how bad decisions come back to haunt you)

[Gabriele Svelto]

On 13/03/2016 09:22, Kyle Huey wrote:
> Much of the "disease" you see is simply support for DOM worker threads,
> because every runnable that can run on those threads must be
> cancelable.  Workers do not guarantee one of the invariants that other
> XPCOM threads do: that every runnable is eventually run after being
> successfully dispatched.  Instead we guarantee that every runnable is
> either Run() or Cancel()ed.

Yeah, that's something I had noticed and I was trying to understand why.
So it seems that this interface actually turned out to have a proper use
after all.

> The disadvantage of pushing this into the event queue is that today
> runnables that are dispatched from other threads to workers *must*
> implement nsICancelableRunnable, which means authors of code that runs
> on workers must think about this.  We do already have an exception for
> NS_DispatchToCurrentThread though (via ExternalRunnableWrapper), so this
> may be something we can relax.  It would generally require us to write
> cleanup code (for the existing runnables and any future ones) to run
> from destructors, and historically destructors could run on either the
> dispatching thread or the executing thread (although that has changed
> somewhat.)

My gripes with its original design is that it's inherently
non-thread-safe and non-atomic (i.e. Cancel() can be called while Run()
is being executed) and it essentially drops the burden of implementing
proper cancellation on the user. My idea of handling cancellation
externally was motivated by having the operation be both thread-safe and
fully atomic (either something runs or it doesn't). This however implies
that if the task was fire-and-forget, then destruction will always be
done by the canceling thread and will happen immediately; in the current
scenario destruction will be done by the thread owning the queue, and it
will happen only when the runnable is drained from it.

> Regardless, your plan should probably involve me ;)

Yeah, this was my idea when nsICancelableRunnable was practically only
used in FxOS-specific code to support canceling potentially long-running
operations posted on the main thread (and which might have not executed
yet). Since it's use has evolved it might not be worth pursuing it
anymore, which is why I wanted to hear about how it's been used now.

> PS. Subscribe to the mailing list so you don't get caught in moderation.

I'm already subscribed, I just verified it, it's bizarre that the
message was held :-/

 Gabriele



signature.asc
Description: OpenPGP digital signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

[Firefox Desktop] Issues found: March 7th to March 11th

[Andrei Vaida]

Hi everyone,

Here's the list of new issues found and filed by the Desktop Release QA 
team last week, *March 07 - March 11* (week 10).


Additional details on the team's priorities last week, as well as the 
plans for the current week are available at:


   https://public.etherpad-mozilla.org/p/DesktopManualQAWeeklyStatus



*RELEASE CHANNEL*
none

*BETA CHANNEL*
none

*AURORA CHANNEL
*
ID  Summary Product Component   Is a regression 
Assigned to
1255428 
crash in ntdll.dll@0x7496c
Plugins
Other
NO  NOBODY
1254134 
Bad repainting while scrolling on cnn.com
Core
Panning and Zooming
YES NOBODY
1254135 
Glitches while scrolling in Print Preview mode
Core
Panning and Zooming
NO  NOBODY
1255747 
First Run blue indicator is not displayed properly after reloading the 
page
Firefox
Tours
YES NOBODY
1255781 
The image glitches while scrolling on pages with Flash content
Core
Plug-ins
YES NOBODY
1255789 
	[e10s] Soundcloud video sharing pop up is repositioning itself towards 
the edge of the display

Core
DOM: Animation
YES NOBODY


*NIGHTLY CHANNEL*
ID  Summary Product Component   Is a regression 
Assigned to
1254909 
Focus ring is too small on the new 'More Information' button
Firefox
Theme
NO  NOBODY



*ESR CHANNEL*
none


Regards,
Andrei
Andrei Vaida| QC Team Lead

SOFTVISION | 57 Republicii Street, 400489 Cluj-Napoca, Romania
Email: andrei.va...@softvision.ro  | 
Web: www.softvision.ro 


The content of this communication is classified as SOFTVISION 
Confidential and Proprietary Information.



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

Re: Intent to implement: W3C WebAppSec credentialmanagement API

[Mike West]

Hey folks! Glad to see that there's interest in this API from Mozilla. :)

On Sun, Mar 13, 2016 at 10:15 AM, Martin Thomson  wrote:

> On 12 Mar 2016 7:28 PM, "Anne van Kesteren"  wrote:
> > It should be identical to password manager integration.
>
> But it is not,  though I suppose that a password manager might be
> exploited to store state. I hope that isn't possible... (note to self,
> attempt this attack)
>
Credential managers guess at a user's username and password, and ask the
user if they'd like to persist that information. It's generally stored
outside of "site data" (cookies, localstorage, IDB, etc), and users
generally treat it differently (anecdotally: ~12.9% of Chrome's users
who've opted into sharing usage data cleared cookies in the last week;
~2.7% cleared passwords). I think this distinction is pretty much in line
with user expectation.

This API offers a few things that the status quo cannot: Imperative
certainty about the data being persisted as opposed to heuristic guessing,
XSS mitigation, federation hints, and automatic sign-in for users who have
done whatever dance the UA requires to enable such a feature.

I don't believe, however, that it offers additional tracking capability
above and beyond the (quite intentional) capabilities inherent in a
credential manager. Sites are not granted any ability to persist data
without user knowledge; they are only granted control over the timing of
the prompt, but the prompt itself is still required. Nor are sites granted
the ability to read data without user knowledge; users are either directly
involved in handing credentials over to a site, or they grant the UA
permission to hand credentials over.

As we add more credential types (FIDO, etc), we'll certainly need to ensure
that we don't introduce privacy footguns, but I think we're capable of
maintaining that dicipline.

> > > In that case, credentials stored by a site should last no longer than
> > > cookies. Credentials created by a user maybe can live longer.
> >
> > How do you distinguish the two if the access is through a UI-mediated
> API?
>
> If credentials created in response to a `get()` call are stored at the
> point they are created, you could treat calls to `store()` very
> differently. Maybe. If the intent is to use a password manager, see
> Richard's earlier mail.
>
I'm not sure, but it sounds like this is based on some misunderstanding of
what the API offers. Does the above description ease your concerns? Or am I
missing the critique?

> > If we think this API should have no more power than storage/cookies,
> > there's not much point in having this API.
>
> Yes, the source of my concerns, right there. Sure, the fig leaf might
> allow us to convince ourselves that we aren't creating a tracker that
> trumps the rest.
>
> If we are creating something that is somehow greater out of the framework
> this provides (FIDO), then that is useful. But the stepping stone we are
> being offered on that path looks suspicious. Why not go straight for the
> real prize?
>
Websites use passwords today. While I agree that we can and should be
working on something better, I don't think that we should overlook small
improvements in the status quo. We can give users a better experience on
their favourite sites if we allow developers to bypass status quo
heuristics, and we keep users safer if we mitigate some of the XSS risks of
password managers today. I think this API does both, and is worth
experimenting with to see if it's a framework we can build upon.

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