Re: ANN: Default bug view for BMO changed today!

2017-03-02 Thread Jörg Knobloch 

On 01/03/2017 21:47, David Lawrence wrote:

Today, the BMO Team changed the default bug view to the new modal
view that has been in development for a while.


I like the fact that you can now change the Product in one step.

Sadly when resolving a bug, there's now an additional click necessary on 
"Edit Bug" to set the Target Milestone. And at least once I had to click 
once more to expand the Tracking section.


Sorry, some people have never happy with progress ;-)

Jörg.

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

Re: ANN: Default bug view for BMO changed today!

2017-03-02 Thread David Lawrence 
Thanks for the feedback. Please file this as a bug if you haven't
already, outlining the proposed workflow change. I could see how
automatically exposing the milestone form field when resolving a bug
could be useful for a lot of people.

Thanks
dkl

On 3/2/17 3:13 AM, Jörg Knobloch wrote:
> On 01/03/2017 21:47, David Lawrence wrote:
>> Today, the BMO Team changed the default bug view to the new modal
>> view that has been in development for a while.
> 
> I like the fact that you can now change the Product in one step.
> 
> Sadly when resolving a bug, there's now an additional click necessary on
> "Edit Bug" to set the Target Milestone. And at least once I had to click
> once more to expand the Tracking section.
> 
> Sorry, some people have never happy with progress ;-)
> 
> Jörg.
> 
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

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

Re: ANN: Default bug view for BMO changed today!

2017-03-02 Thread Benjamin Smedberg 
One other tip which really helped me: you can hit Control-E to go to bug
editing mode. I bet there are other cool keyboard shortcuts, but I don't
know if there's a guide or not.

--BDS

On Wed, Mar 1, 2017 at 3:47 PM, David Lawrence 
wrote:

>Today, the BMO Team changed the default bug view to the new modal
> view that has been in development for a while. For those who would like
> to use the old form, instructions on how to switch back are below in the
> background information. The old form will, however, be removed one day,
> so please try to use the new one and make suggestions on how it can be
> improved.
>
> As some of you may already know, and maybe even have been using it
> for a while, the BMO [1] team has been working on a new bug view page
> (a.k.a. show_bug.cgi) for some time [2] . The older, stock bug form was
> not well laid out and was difficult to understand, with all of the
> fields visible regardless of how often they were used. The stock form
> was originally designed to  display all of a bug’s data, and users had
> to adapt their workflows accordingly. The BMO team designed a completely
> new and more efficient view for the workflows of the majority of BMO users.
>
> The new bug-editing form has been added to BMO alongside the stock
> form and can be enabled by toggling a user preference [3]. We have been
> incrementally improving it and collecting feedback by those brave enough
> to use it early on. The new form is using more modern design practices
> and therefore is easier for us to improve and expand on. Any new
> enhancements will be done only on the new form going forward. It was
> code named ‘Bug Modal’ due to the modular layout of the page. Each
> submodule can be collapsed out of view and expanded when needed.
>
> At this time we feel that the form is feature complete and has now
> become the new default bug form for BMO. We have finished all the
> blockers in our tracking bug report [4]. The older, stock bug view form
> will still be around, and you can use the user preferences form to
> switch back to the old one [3]. In the future, we will be removing the
> old form completely after fixing a few more bugs [6], and we will make
> another announcement before doing so. Removing the old code will make it
> easier on us from a maintenance standpoint. Any bugs, comments, or ideas
> for improvement of the modal form can be reported in BMO [5].
>
> Thanks!
> BMO Team
>
> [1] https://bugzilla.mozilla.org
> [2] https://globau.wordpress.com/2015/03/31/bmo-new-look
> [3]
> https://bugzilla.mozilla.org/userprefs.cgi?tab=settings#ui_experiments_row
> [4] https://bugzilla.mozilla.org/show_bug.cgi?id=1150541
> [5]
> https://bugzilla.mozilla.org/enter_bug.cgi?product=bugzilla.mozilla.org&;
> component=User%20Interface:%20Modal&format=__default__
> [6] https://bugzilla.mozilla.org/show_bug.cgi?id=1273046
> ___
> 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: ANN: Default bug view for BMO changed today!

2017-03-02 Thread Jörg Knobloch 

On 02/03/2017 16:06, David Lawrence wrote:

Thanks for the feedback. Please file this as a bug if you haven't
already, outlining the proposed workflow change. I could see how
automatically exposing the milestone form field when resolving a bug
could be useful for a lot of people.


Yes, maybe useful for the sheriffs, or is closing a bug fully automated?

Some more feedback: While "3 years ago" is nice for the date display, 
I'd also like to see the full date and hour in a copyable form. Another 
bug for that? Or is there a setting that will do it already?


Jörg.

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

Re: ANN: Default bug view for BMO changed today!

2017-03-02 Thread Byron Jones 

Jörg Knobloch wrote:

Some more feedback: While "3 years ago" is nice for the date display,
I'd also like to see the full date and hour in a copyable form. Another
bug for that? Or is there a setting that will do it already?


set "Use absolute format instead of relative time when viewing a bug"

https://bugzilla.mozilla.org/userprefs.cgi?tab=settings#ui_use_absolute_time

--
glob — engineering productivity — moz://a

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

Re: Intent to ship: WebVR on Windows in Release

2017-03-02 Thread kearwood 
On Wednesday, March 1, 2017 at 2:55:53 PM UTC-8, Boris Zbarsky wrote:
> On 3/1/17 5:03 PM, Kip Gilbert wrote:
> > We have worked directly with the other WebVR platform implementers to 
> > ensure compatibility.
> 
> OK, but what is the actual state of that compatibility?
> 
> https://github.com/w3c/webvr/issues/197#issuecomment-283492774 and 
> https://github.com/w3c/webvr/issues/195#issuecomment-283493130 sure 
> sound like at least Brandon is not on board with those parts of the 
> current API, and he's one of the spec editors.
I tend to agree with Brandon on this particular issue
> 
> > We have regularly scheduled video calls and F2F meetings to improve the 
> > spec and remove any ambiguity.  We have formed a W3C community working 
> > group.
> 
> That's good.  The question that bothers me is how this interacts with 
> the ship schedule.
> 
> >> [1]  For example, what does the VRFrameData constructor actually do? The 
> >> spec doesn't define it at all.  Where is the VRPose inside supposed to 
> >> come from?  What values will it contain?  I filed 
> >> https://github.com/w3c/webvr/issues/195 on this, but note that I've spent 
> >> all of about 5 minutes skimming the spec and ran into this.  I have _not_ 
> >> done a careful read looking for possible interop problems...
> >
> > VRFrameData is described as receiving the output of the 
> > VRDisplay.getFrameData function:
> 
> Yes, but that's totally unrelated to my question about what the 
> _constructor_ does
On the spec issue, I am working to make the initial values explicit as you have 
suggested: https://github.com/w3c/webvr/issues/195

This has not caused any issues with interoperability, as VRFrameData's values 
are not considered valid until after a call to VRDisplay.getFrameData 
initializes them and returns true indicating it was successful.

Would this issue block release of WebVR in Firefox 54?


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

Re: Intent to ship: WebVR on Windows in Release

2017-03-02 Thread L. David Baron 
On Wednesday 2017-03-01 12:50 -0800, kgilb...@mozilla.com wrote:
> Since the initial implementation, a W3C working group was formed including 
> members from Mozilla, Google, Microsoft, Samsung, and Oculus.  The API has 
> stabilized and is frozen at "WebVR 1.1" while its successor "WebVR 2.0" is 
> being conceived.

There seems to be some disagreement within the WebVR community about
whether 1.1 was intended to be shipped in stable releases of
browsers, e.g., in this thread:
https://twitter.com/aeliasnet/status/837139143276711936

What's the intent of the WebVR standards community here?

And is your intend to support the features in 1.1 forever, or to
take them away at some point?

-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 ship: WebVR on Windows in Release

2017-03-02 Thread kearwood 
On Thursday, March 2, 2017 at 11:04:07 AM UTC-8, David Baron wrote:
> On Wednesday 2017-03-01 12:50 -0800, kgilb...@mozilla.com wrote:
> > Since the initial implementation, a W3C working group was formed including 
> > members from Mozilla, Google, Microsoft, Samsung, and Oculus.  The API has 
> > stabilized and is frozen at "WebVR 1.1" while its successor "WebVR 2.0" is 
> > being conceived.
> 
> There seems to be some disagreement within the WebVR community about
> whether 1.1 was intended to be shipped in stable releases of
> browsers, e.g., in this thread:
> https://twitter.com/aeliasnet/status/837139143276711936
> 
> What's the intent of the WebVR standards community here?
> 
> And is your intend to support the features in 1.1 forever, or to
> take them away at some point?

Chris's response to that tweet sums this up.

Our first implementation of WebVR 2.0 will be a system add-on exposing the new 
API, backed by WebVR 1.1.  WebVR 1.1 implementations will be around for a long 
time and have already been shipped by other UA's.  It will take some time for 
2.0 to be ready to implement as it is still in conception.  When the native 
implementation within Firefox is updated to 2.0, the system add-on will be 
updated to provide backwards compatibility to the WebVR 1.1 API.  At this 
point, WebVR 1.1 will be deprecated but supported as long as needed.  I expect 
the timeframe to be several years of support for WebVR 1.1 API in production.

The vast majority of sites using WebVR are using one of the WebVR polyfills, 
such as:

https://github.com/googlevr/webvr-polyfill

This polyfill provides an even higher level abstraction and enables WebVR on 
platforms without WebVR support, such as phones with a google cardboard holder.

Simply updating this polyfill is all that would be needed for sites that are 
still on the WebVR 1.1 API once eventually deprecated.

> 
> -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)

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

Re: ANN: Default bug view for BMO changed today!

2017-03-02 Thread Myk Melez 
> Mike Hommey 
> 2017 March 1 at 14:50
> 1. I often wish browsers were helpful here. Seriously. When an anchor is
> close enough to the end of the page that the page can't be scrolled for
> it to be at the top of the viewport, it's a PITA to find where it is.
Indeed. I thought I recalled reading a particular comment about why this
is hard to resolve, but I don't find that one now, only a bunch of
discussion in a variety of interrelated bugs:

https://bugzilla.mozilla.org/show_bug.cgi?id=735614
https://bugzilla.mozilla.org/show_bug.cgi?id=269172
https://bugzilla.mozilla.org/show_bug.cgi?id=68402

-myk

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

Re: Intent to ship: CSS 'transform-box' property

2017-03-02 Thread Jonathan Watt 
On 01/03/2017 21:54, Jeff Muizelaar wrote:
> What is the status of this property in other browsers?

We would be the first to implement.

Safari: it's primarily Apple people who edit the spec so I'd hope they'd
implement, but who knows.

Blink: previously when we've tried to get commitment there's not been much
engagement one way or another. As I'd hoped, using this intent-to-ship as
leverage my latest attempt to engage the Blink devs has now seen some action on
https://bugs.chromium.org/p/chromium/issues/detail?id=595829 to add usage 
counters.

Edge: no immediate plans to implement CSS transforms on SVG.

___
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

2017-03-02 Thread akayla1977 
On Tuesday, September 1, 2015 at 9:56:28 AM 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&measure=SSL_SYMMETRIC_CIPHER_FULL&target=1
> [4]
> https://ipv.sx/telemetry/general-v2.html?channels=beta&measure=SSL_SYMMETRIC_CIPHER_FULL&target=1
> [5]
> https://ipv.sx/telemetry/general-v2.html?channels=nightly%20aurora&measure=SSL_SYMMETRIC_CIPHER_FULL&target=1

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

CodeCoverage: First Monthly Update

2017-03-02 Thread Kyle Lahnakoski 

It is my pleasure to introduce you all to our project to collect code
coverage!


Motivation

Knowing code coverage statistics and code coverage specifics can help
evaluate risk in code: It can show what test suites cover what lines, it
can show if new code is covered by an existing test.  There are many
other exciting insights we can extract from code coverage. But first, we
must collect it.

The Problem

The biggest problem we face is scale:  Firefox has many LoC, it is
composed of multiple languages, it is run on multiple platforms, and the
test suites are split among hundreds of machines for a single build.

History

For just over a year, this CodeCoverage project has had number of
excellent contributors from various Universities across Canada[1].  They
did the exploratory work required to solve the problems of scaling
collection and aggregation so to handle the Mozilla-scale problem with
code coverage.  If any of those contributors are reading this: Thank you!

The Plan

For the next month we will be working on c++ coverage, Rust coverage and
validating the data and process.  There are many unknowns and I will
have more concrete deliverables in the next update.  The details of that
plan is in our freshly minted planning document [2].  There you can find
bugs, and code links.  If you are interested in more, please contact me [3]

I will send out monthly emails with our progress, some links where you
see our progress, and our future plans.


[1] UCOSP (Undergraduate Capstone Open Source Projects)http://ucosp.ca/

[2] The actual plan:
https://docs.google.com/document/d/1dOWi18qrudwaOThNAYoCMS3e9LzhxGUiMLLrQ_WVR9w/edit#

[3] Kyle Lahnakoski email: klahnako...@mozila.org  irc: ekyle on
#at...@irc.mozilla.org

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

Re: Intent to ship: WebVR on Windows in Release

2017-03-02 Thread Boris Zbarsky 

On 3/2/17 1:52 PM, kearw...@kearwood.com wrote:

I tend to agree with Brandon on this particular issue


That's fine.  I agree with you and Brandon too. ;)  I'm just worried 
about possible interop problems more than anything else at the moment.



Would this issue block release of WebVR in Firefox 54?


To some extent this is a call people more familiar with how this API 
gets used and what interop issues can arise should make.


Note that per 
https://github.com/w3c/webvr/issues/128#issuecomment-283854007 the 
behavior of getFrameData is not interoperable between Edge and Firefox: 
we create new objects hanging off the VRFrameData each time, while they 
mutate all the existing stuff in-place.  This can lead to bugs like code 
that tries to optimize by grabbing a reference to one of the typed 
arrays and then calling getFrameData and assuming the array they are 
referencing is updated (if they test in Edge).  Or not updated and 
represents the previous frame (if they test in Firefox)...


Again, I only spent a few minutes looking at this spec.  What would be 
most helpful here is if someone went through it carefully looking for 
underpecified bits like this, then filed issues as needed and checked 
what browsers actually do in the underspecified cases.  Then we can 
decide whether whatever behavior differences we find are sufficient that 
there is high interop risk from shipping.


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