Re: What are your use cases for the Touch Bar on the new MacBook Pro?

[Robert Helmer]

+1 on doing WebExt APIs in parallel - this can be done outside of
mozilla-central on non-release channels using WebExtension Experiments
(https://webextensions-experiments.readthedocs.io)

Once the implementation in mozilla-central is settled down, the
experimental API can be merged.

On Tue, Jan 3, 2017 at 6:38 PM, Stephen A Pohl  wrote:
> I can see the advantage of addons exploring and iterating on this, but
> making the first version of this API addon-accessible might
> unnecessarily delay it. If there is enough interest in this, we might
> want to start this effort in parallel and release it in a subsequent
> version.
>
> On 1/3/17 4:31 PM, Ryan VanderMeulen wrote:
>> Will this API be accessible to addons? Seems like this would be a good
>> place for people to explore and iterate.
>>
>> On 1/3/2017 12:17 PM, Stephen A Pohl wrote:
>>> We will develop[1] a solid 1.0 API around the top features to get the
>>> ball rolling and will iterate on these going forward.
>> ___
>> 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: What are your use cases for the Touch Bar on the new MacBook Pro?

[Stephen A Pohl]

I can see the advantage of addons exploring and iterating on this, but
making the first version of this API addon-accessible might
unnecessarily delay it. If there is enough interest in this, we might
want to start this effort in parallel and release it in a subsequent
version.

On 1/3/17 4:31 PM, Ryan VanderMeulen wrote:
> Will this API be accessible to addons? Seems like this would be a good
> place for people to explore and iterate.
>
> On 1/3/2017 12:17 PM, Stephen A Pohl wrote:
>> We will develop[1] a solid 1.0 API around the top features to get the
>> ball rolling and will iterate on these going forward.
> ___
> 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: adding vector effects non-scaling-size, non-rotation and fixed-position to SVG

[ktecramin99]

Hi Jeff
> I'm concerned about the complexity this will add to the SVG implementation
> as we're looking to transition to WebRender.
if WebRender supports currently implemented "non-scaling-stroke", 
new modifications must be nothing more than recalculating CTM for those new 
effects. 

> Can the desired effects be achieved by interleaving HTML and SVG content
> today? 
my understanding is CTM translations do work well with interleaving HTML and 
SVG.

> e.g. It seems like introductory notes example could just use a
> separate SVG element that had fixed positioning instead of needing to build
> fixed-position into SVG.

By "introductory notes example" do you mean the example in following link?
https://svgwg.org/svg2-draft/coords.html#VectorEffects 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to vendor Servo in mozilla-central

[Gregory Szorc]

Over in bug 1322769, we're planning to vendor the contents of the Servo Git
repository into mozilla-central as part of Quantum efforts.

The initial vendoring of the Servo repository is the first milestone of a
larger project that aims to "unify" workflows and automation across the two
projects, allowing both projects to have insights into the other's
automation and allowing development work spanning both projects to be
simpler.

In this first milestone, we will vendor the history of the Servo Git
repository into mozilla-central.

We only get one chance to vendor the history of Servo before it is forever
set in stone in the history of mozilla-central. So I'd prefer to get it
right so we don't have regrets about the approach 10 years from now.
Therefore, if you care about getting it right, your brain and eyeballs on
the proposal would be useful.

The current plan is to rewrite Servo's history to:

* Remove merge commits (only taking the p1 ancestry of the repo)
* Add something in commit message summary line to indicate commit comes
from Servo
* Add source repo and commit annotations to the commit message
* Reformat some GitHub-flavored markdown to something more sane for plain
text display
* Remove everything related to submodules
* Drop WPT files (there's ~135,000 of them!)

We also tentatively plan to introduce the Servo history as a new root in
the mozilla-central repository so that bisect operations on Firefox/Gecko
don't land in the middle of thousands of Servo-only commits. (I concede
this is an ugly hack to work around limitations of the "bisect" command of
your preferred VCS.)

Unless we prune more from history rewriting, this will add ~8,000 commits
to mozilla-central touching ~5,700 files. The on-wire clone size of the
repository will increase by ~36 MB. On-disk repo size will increase by ~50
MB (not including inode overhead).

Also, I anticipate the techniques and tools used to import Servo's history
and keep it "synchronized" have uses outside of Servo. Our current
mechanisms for keeping upstream/third party projects in sync with
mozilla-central are not well standardized. I'd really like the work to
support Servo to be used for other projects as well. This potentially
includes a future where certain directories in mozilla-central are
effectively developed on GitHub or are using other "non-standard"
workflows. If you think you may benefit from this future work, I'd
appreciate if you could look at the Servo vendoring effort and make sure
things like the annotations tracking the original source of the commit are
sufficient for uses outside of Servo.

Again, it's bug 1322769 if you want to comment or follow along.

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

Re: What are your use cases for the Touch Bar on the new MacBook Pro?

[Ryan VanderMeulen]

Will this API be accessible to addons? Seems like this would be a good 
place for people to explore and iterate.


On 1/3/2017 12:17 PM, Stephen A Pohl wrote:

We will develop[1] a solid 1.0 API around the top features to get the
ball rolling and will iterate on these going forward.

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

Re: What are your use cases for the Touch Bar on the new MacBook Pro?

[David Teller]

To build upon the "tab bar" idea: scrolling quickly among my 300+ tabs.

On 03/01/17 21:50, sev...@gmail.com wrote:
> Off the top of my head ideas:
> 
> Quick-access to the back, forward, refresh, bookmark, share buttons could be 
> a good. Tab bar might be handy too, so with a touch of my finger I can go to 
> the tab I want quickly. The bar could change depending on your screen to. If 
> you’re on YouTube/Netflix it could be player controls, or if on NewTab a row 
> of highlights of some type?
> ___
> 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: What are your use cases for the Touch Bar on the new MacBook Pro?

[sevaan]

Off the top of my head ideas:

Quick-access to the back, forward, refresh, bookmark, share buttons could be a 
good. Tab bar might be handy too, so with a touch of my finger I can go to the 
tab I want quickly. The bar could change depending on your screen to. If you’re 
on YouTube/Netflix it could be player controls, or if on NewTab a row of 
highlights of some type?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: GCC 4.9 now required to build on Linux/Android

[Ralph Giles]

On Tue, Jan 3, 2017 at 7:05 AM, Ben Kelly  wrote:

> FWIW, it seems ./mach bootstrap does not install gcc 4.9 on ubuntu 14.04.

It looks like it's not packaged for 14.04; so we'd have to add a ppa
to do this prior to 16.04.

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

What are your use cases for the Touch Bar on the new MacBook Pro?

[Stephen A Pohl]

We are gathering ideas for possible use cases of the Touch Bar on the
new MacBookPro and would like to hear from you! What would improve your
workflow? What would help our users?

We will develop[1] a solid 1.0 API around the top features to get the
ball rolling and will iterate on these going forward.

Apple has outlined guidelines and best practices[1] for the Touch Bar
that are good to keep in mind. Here are some of the most important
points to consider:
1. Design a contextual experience. Make the Touch Bar relevant to the
current context on the main screen.
2. Use the Touch Bar as an extension of the keyboard and trackpad, not
as a display.
3. **Don’t expose functionality solely in the Touch Bar.
4. Avoid using the Touch Bar for tasks associated with well-known
keyboard shortcuts.

-Stephen

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1313455
[2]
https://developer.apple.com/library/content/documentation/UserExperience/Conceptual/OSXHIGuidelines/AbouttheTouchBar.html#//apple_ref/doc/uid/2957-CH104-SW1
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: Payment Request API

[santosrudy05]

Pada Selasa, 22 November 2016 12.27.52 UTC+7, mcac...@mozilla.com  menulis:
> ## Summary 
> The Payment Request API allows web sites selling goods and services to 
> utilize one or more payment methods through the browser. The browser then 
> facilitates the payment flow between merchant and user. 
> 
> Initial implementation is going to be limited to “basic card” payments, based 
> on a wallet Firefox will manage… The Firefox folks will have UI mockups and 
> further details about the wallet (and security aspects), as it's outside the 
> scope of the Platform work (but we are working together on it as a team).
> 
> At time of writing, the interface are limited to the following methods and 
> event handlers. However, this is subject to change as the spec is still 
> evolving (there are also attributes, but I’ve omitted them as they mostly 
> reflect what goes into the constructor). New methods/attributes/events will 
> be sent with a new intent to implement:
> 
> ### interface `PaymentRequest`
> How a developer requests payment.
> 
>- promise show() - request show payment panel. 
>- promise abort() - request close payment panel, aborting the payment. 
>- promise canMakeActivePayment()* - not in spec, proposed by Google.
>- Events (see PaymentRequestUpdateEvent): 
>- onshippingaddresschange
>- onshippingoptionchange
> 
> For discussion around canMakeActivePayment(), please see: 
> https://github.com/w3c/browser-payment-api/pull/316
>   
> ### interface `PaymentResponse` 
> The resulting response from the end-user. 
> 
>   - promise complete() - let’s you know when the flow is done.  
> 
> ### interface `PaymentRequestUpdateEvent` 
>   - updateWith(Promise d) - request an update be made to the 
> payment panel with new payment details. 
> 
> ### interface `PaymentAddress`
> A serializable object that represents a physical address in the real world… 
> trying to get this changed to a dictionary, as it's just a bunch of DOM 
> Strings, and an array. 
> 
> ### Extension to IFRAMEs 
> The API also extends the `HTMLIframeElement` interface by adding a new 
> attribute:
> 
>   * allowPaymentRequest - defaults to false. Similar in behavior to 
> `.allowFullScreen`. 
> 
> ## Bug
> https://bugzilla.mozilla.org/show_bug.cgi?id=1318984
> 
> ## Link to standard
> https://w3c.github.io/browser-payment-api/
> 
> ## Platform coverage
> Desktop first, Android later.
> 
> ## Estimated or target release:
> Sometime in 2017 - not sure yet.  
> 
> ## Preference behind which this will be implemented: 
> dom.payments.enabled
> 
> ## DevTools bug: 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1318994
> 
> ## Do other browser engines implement this? 
> 
> ### Shipped
> Chrome for Android release 53.
> Blink-dev intent to ship: 
> https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/p1DYoxHlkKg
> https://www.chromestatus.com/feature/5639348045217792
> 
> ### Considering
> According to Microsoft’s Platform Status, the feature is “in development” in 
> Edge. 
> https://developer.microsoft.com/en-us/microsoft-edge/platform/status/webpaymentsapi/?q=payments
> 
> ## Tests
> Initial tests have been taken from Chrome’s implementation. However, these 
> have not yet been verified by us, nor merged into the the web platform tests. 
> We intend for those to be merged, and for us to contribute additional tests 
> there. 
>   
>  https://github.com/w3c/web-platform-tests/pull/3441
> 
> Kind regards,
> Marcos

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

Re: GCC 4.9 now required to build on Linux/Android

[Ben Kelly]

FWIW, it seems ./mach bootstrap does not install gcc 4.9 on ubuntu 14.04.

On Fri, Dec 23, 2016 at 11:08 AM, Nathan Froyd  wrote:

> Bug 1322792 has landed on inbound, which changes configure to require
> GCC 4.9 to build; our automation switched over to GCC 4.9 for our
> Linux builds earlier this week.  (Android builds have been using GCC
> 4.9 for some time.)
>
> This change paves the way for being able to compile in C++14 mode for
> all of our Tier-1 platforms, which in turn unlocks using some C++14
> features in our codebase:
>
> * binary literals
> * digit separators
> * generic lambdas
> * initialized lambda captures
> * return type deduction (not quite sure if we want to use this feature
> widely)
>
> We did not upgrade to GCC 5 for ABI compatibility reasons (GCC 5
> changed the libstdc++ ABI); we did not upgrade to GCC 6 for the same
> reason and because Gecko still has a few issues with GCC 6 (bug
> 1316555 tracks).
>
> Thanks,
> -Nathan
> ___
> 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: Several leak failures have slipped passed continuous integration

[Andrew Halberstadt]

Ah, I misunderstood.

If the log line is printed or dumped directly to stdout, then the string
TEST-UNEXPECTED-FAIL actually will fail the job. It's only if we do
log.info('TEST-UNEXPECTED-FAIL ...') that we run into problems. So if
you see the string 'TEST-UNEXPECTED-FAIL' somewhere, it isn't
necessarily wrong (though I think we should stop relying on this string
anyway).

I did a quick DXR for the failure case and found one place in a rarely
used mozrunner utility function that needs to be updated. Afaict, no
problems have landed as a result, but will get this fixed asap as well.


On 29/12/16 02:55 PM, Boris Zbarsky wrote:

On 12/29/16 11:49 AM, ahalberst...@mozilla.com wrote:

Have we done any sort of audit to see whether any other tests got broken
by the structured logging changes?  Had we done such an audit after bug
1321127 was fixed?


Once bug 1321127 was fixed, any other tests that were broken would
turn the job orange so would have prevented the fix from landing.


No, what I meant was this: we now have two separate instances of
harnesses not showing failures because they were relying on the
TEST-UNEXPECTED-FAIL string parsing, not the structured logger.  Have we
done any auditing for _other_ cases that are relying on said string
parsing?

-Boris

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

Re: Rust required to build Gecko

[Ted Mielczarek]

On Wed, Dec 21, 2016, at 04:56 PM, Julian Seward wrote:
> On 21/12/16 07:55, Jim Blandy wrote:
> > The only things I really want anyway are:
> > 
> > mk_add_options MOZ_OBJDIR=obj-bug
> > ac_add_options --enable-debug='-g3 -O0 -fno-inline'
> > ac_add_options --disable-optimize
> 
> As a side note, I tend to use "-Og -g" as that gives much faster code
> than -O0 whilst retaining a reasonable debugging experience, viz:
> 

Just FYI,

> ac_add_options --enable-optimize="-g -Og"
> ac_add_options --enable-debug-symbols

--enable-debug-symbols is the default, so you don't need to specify it.
Additionally, --enable-debug-symbols should be adding -g to the compile
command, so you ought to be able to just use `--enable-optimize="-Og"`.

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

[Firefox Desktop] Issues found: December 26th to December 30th

[Andrei Vaida]

Hi everyone,

Here's the list of new issues found and filed by the Desktop Release QA 
Team last week, December 26 - December 30 (week 52).


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
IDSummaryProductComponentIs a regressionAssigned to1326385 
Crash in 
::operator() | mozilla::WebGLFramebuffer::BlitFramebufferCoreCanvas: 
WebGLNOJeff Gilbert


AURORA CHANNEL
none

NIGHTLY CHANNEL
none

ESR CHANNEL
none


Regards,
Andrei Vaida
Team Lead
SOFTVISION
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