Re: Introducing mozilla::Result for better error handling

2017-01-04 Thread Xidorn Quan 
On Thu, Jan 5, 2017, at 03:28 PM, Cameron McCormack wrote:
> On Tue, Dec 20, 2016, at 09:46 PM, Jan de Mooij wrote:
> > A few weeks ago we added mozilla::Result to MFBT [0][1]. I was
> > asked
> > to inform dev-platform about this, so here's a quick overview.
> > mozilla::Result is based on Rust's Result type [2]. It contains
> > either a success value of type V or an error value of type E.
> 
> I want to write a function that either returns an object that has
> already been AddRefed or an nsresult error. 
> Result, nsresult> doesn't seem to work. 
> Result, nsresult> would presumably work, but might
> wastefully touch the object's refcount.  Is there a better way?

I think Result should change its constructors to support move-only
things like already_AddRefed.

Probably it can add a constructor which accepts T&& and Move it down the
chain. I'm not sure what is the prefect way here, though.

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

Re: Introducing mozilla::Result for better error handling

2017-01-04 Thread Cameron McCormack 
On Tue, Dec 20, 2016, at 09:46 PM, Jan de Mooij wrote:
> A few weeks ago we added mozilla::Result to MFBT [0][1]. I was
> asked
> to inform dev-platform about this, so here's a quick overview.
> mozilla::Result is based on Rust's Result type [2]. It contains
> either a success value of type V or an error value of type E.

I want to write a function that either returns an object that has
already been AddRefed or an nsresult error. 
Result, nsresult> doesn't seem to work. 
Result, nsresult> would presumably work, but might
wastefully touch the object's refcount.  Is there a better way?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: 'Add me to CC list (follow this bug)' checkbox in Bugzilla broken, use Follow button in modal UI

2017-01-04 Thread Dave Lawrence 
Sorry for the inconvenience this recent change caused. We have now pushed
out a fix for bug 1328464 and you should no longer need to click the
'Follow' button to workaround this issue.

dkl

On Wed, Jan 4, 2017 at 9:28 AM, Sebastian Hengst  wrote:

> https://bugzilla.mozilla.org/show_bug.cgi?id=1328464
> The 'Add me to CC list (follow this bug)' checkbox in Bugzilla is broken,
> use the Follow button in modal UI for CCing.
>
> Sebastian
> ___
> 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: Intent to vendor Servo in mozilla-central

2017-01-04 Thread Ms2ger 
On 04/01/17 00:35, Gregory Szorc wrote:
> 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.
> 

As I said before, this approach is, IMO, much too complicated; splitting
the reusable parts of Servo into their own repositories, as we have done
before, would be a much simpler solution.

However, as it seems the decision has already been made quietly long
ago, I don't see much point in continuing to fight it, as long as this
frankenhistory does not affect the canonical Servo history in git.

HTH
Ms2ger

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

'Add me to CC list (follow this bug)' checkbox in Bugzilla broken, use Follow button in modal UI

2017-01-04 Thread Sebastian Hengst 

https://bugzilla.mozilla.org/show_bug.cgi?id=1328464
The 'Add me to CC list (follow this bug)' checkbox in Bugzilla is 
broken, use the Follow button in modal UI for CCing.


Sebastian
___
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?

2017-01-04 Thread Jim Mathies 
On Tuesday, January 3, 2017 at 8:38:05 PM UTC-6, 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

Crazy idea  - we could make the touch bar only accessible through web 
extensions apis, no XPCOM interface or internal api would be provided. This way 
all development happens in a layer that is secure (webextensions will 
eventually run in their own process and get sandboxing) and new features can be 
installed and removed with little effort by our users. We have the ability to 
ship system addons so we can include default features with our install. This is 
more in line with our newer modular approach to features, and would give our 
users much more control.. while also helping to promote web extension 
development. The approach would also help cut down on code bloat and avoid 
technologies we are trying to move away from like XPCOM.


___
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?

2017-01-04 Thread Gervase Markham 
On 03/01/17 17:17, Stephen A Pohl wrote:
> 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?

When the developer tools are open, change the Touch Bar to give quick
access to various Developer functions? I can imagine a web-developer
feeling supercharged with one-touch console, or one-touch inspect, or
one-touch JS toggle.

Gerv
___
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?

2017-01-04 Thread Patrick Brosset 
>
> 1. Design a contextual experience. Make the Touch Bar relevant to the
> current context on the main screen.
>

I wonder if focus can serve as a context too. What if DevTools is opened
and has focused? The "main screen" would still be the content page of
course, but if the user has focused, say, the debugger, then it might be
really cool to have debugger buttons in the touch bar.

A while ago, I had filed this bug to gather ideas for DevTools:
https://bugzilla.mozilla.org/show_bug.cgi?id=1320043

   - In the debugger, having step in/out/over, resume, pause buttons would
   be very useful.
   - In Responsive Design Mode, maybe something to resize the viewport.
   - In the animation inspector, a scrubber to move through animations.
   - In the inspector's DOM view, buttons to add, delete, edit, hide,
   highlight nodes.

Patrick

On Wed, Jan 4, 2017 at 4:01 AM, Robert Helmer  wrote:

> +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
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform