Protocol handler flags for custom protocols that use themselves as UI resources

[Cameron Kaiser]

OverbiteFF (a Gopher add-on for Firefox) calls itself for certain 
internal resources. Since it converts gopher menus to HTML, it just does 
things like


gopher:///internal.js";>

to access its built-in content resources. This worked fine until Firefox 
44, which throws a Security Error, so I added URI_IS_UI_RESOURCE. That 
fixed the internal load, but now clicking on gopher links from HTTP 
fails (with a Security Error also).


Currently, it sets ALLOWS_PROXY | ALLOWS_PROXY_HTTP | 
URI_IS_LOADABLE_BY_ANYONE | URI_IS_UI_RESOURCE. It seems like by setting 
both of the latter, I can't combine the two. What's the best combination 
of flags to get this to work as it did in previous versions? It used to 
work just fine with just ALLOWS_PROXY | ALLOWS_PROXY_HTTP | 
URL_IS_LOADABLE_BY_ANYONE.


Or, can I use resource:// here?

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

Re: Protocol handler flags for custom protocols that use themselves as UI resources

[Cameron Kaiser]

On 1/25/16 9:49 PM, Boris Zbarsky wrote:

On 1/26/16 12:42 AM, Cameron Kaiser wrote:

Currently, it sets ALLOWS_PROXY | ALLOWS_PROXY_HTTP |
URI_IS_LOADABLE_BY_ANYONE | URI_IS_UI_RESOURCE.


Those last two flags are defined to be mutually exclusive; setting both
has undefined behavior in the sense that code will and does assume they
are not both set and might check for one and do something, ignoring the
other.

There should not generally be a security error for loading a
URI_IS_LOADABLE_BY_ANYONE thing; that's what LOADABLE_BY_ANYONE means.
It would be good to figure out why you get an error there (or even just
using mozregression to find who broke it).


I found a workaround. I'm thinking this might just be one of those edge 
cases -- it may be how I deal with the files internally, but it works now.


Cameron Kaiser

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

Re: Protocol handler flags for custom protocols that use themselves as UI resources

[Cameron Kaiser]

On 1/25/16 9:49 PM, Boris Zbarsky wrote:

On 1/26/16 12:42 AM, Cameron Kaiser wrote:

Currently, it sets ALLOWS_PROXY | ALLOWS_PROXY_HTTP |
URI_IS_LOADABLE_BY_ANYONE | URI_IS_UI_RESOURCE.


Those last two flags are defined to be mutually exclusive; setting both
has undefined behavior in the sense that code will and does assume they
are not both set and might check for one and do something, ignoring the
other.

There should not generally be a security error for loading a
URI_IS_LOADABLE_BY_ANYONE thing; that's what LOADABLE_BY_ANYONE means.
It would be good to figure out why you get an error there (or even just
using mozregression to find who broke it).


It was in Fx44, but I haven't found a more granular regression range 
yet. This only seems to occur with loading the script; images and style 
sheets are fine.


I guess I could just inline the (entire) script as a workaround.

Cameron Kaiser

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

Re: Protocol handler flags for custom protocols that use themselves as UI resources

[Boris Zbarsky]

On 1/26/16 12:42 AM, Cameron Kaiser wrote:

Currently, it sets ALLOWS_PROXY | ALLOWS_PROXY_HTTP |
URI_IS_LOADABLE_BY_ANYONE | URI_IS_UI_RESOURCE.


Those last two flags are defined to be mutually exclusive; setting both 
has undefined behavior in the sense that code will and does assume they 
are not both set and might check for one and do something, ignoring the 
other.


There should not generally be a security error for loading a 
URI_IS_LOADABLE_BY_ANYONE thing; that's what LOADABLE_BY_ANYONE means. 
It would be good to figure out why you get an error there (or even just 
using mozregression to find who broke it).



Or, can I use resource:// here?


It really depends on what principal the page linking to this thing is 
running as...


-Boris

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

Testing documentation (was Re: Where to put docker documentation?)

[Armen Zambrano G.]

Sure.

There's no clear structure of where something like this should live. I
thought a good starting point would be this:
https://developer.mozilla.org/en-US/docs/Mozilla/Testing

However, that doesn't seem to be a page that would take you to other
testing related matters.

Then there's this tag:
https://developer.mozilla.org/en-US/docs/tag/Automated%20testing

Then there's this page:
https://developer.mozilla.org/en-US/docs/Running_automated_tests

I wonder if any of you would be interested on fixing this a bit or at
least someone with whom I could brainstorm a new structure proposal.

regards,
Armen

On 16-01-22 02:23 PM, Mike Hoye wrote:
> On 2016-01-22 12:07 PM, Armen Zambrano G. wrote:
>> We're now running side by side Linux x64 debug test jobs inside of
>> docker on TaskCluster [1]
>>
>> Where could I add instructions on how to run jobs running inside of
>> docker? (mdn? the tree? else?)
> MDN please. Docker is going to going to be important for community
> participation in infrastructure, so MDN docs would be very helpful.
> 
> - mhoye


-- 
Zambrano Gasparnian, Armen
Automation & Tools Engineer
http://armenzg.blogspot.ca
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Just Autoland It

[smaug]

On 01/24/2016 04:48 AM, Mike Hommey wrote:

On Sat, Jan 23, 2016 at 09:33:15PM -0500, Boris Zbarsky wrote:

Sure.  And the "r+ with these changes, and feel free to land, but I want to
see the interdiff" mode is supported with Autoland because the interdiff
would be available in mozreview post-facto, as you note.


Note that if /other/ changes from other bugs have happened to the same
files between the last reviewed iteration and the rebase before landing,
the interdiff will show them without any kind of visual cues. People
might think the interdiff problem is solved because mozreview uses a VCS
under the hood, but that's not true. In fact, in some cases it's worse
now, because while splinter could essentially tell you it can't display
an interdiff, mozreview will happily display you an interdiff that is
not what you'd expect.

Mike




Indeed. MozReview showing bogus interdiffs is rather major issue. It happens 
also between
the changes for the same bug, if there are some file deletions etc.

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

Re: Just Autoland It

[smaug]

On 01/23/2016 09:41 PM, Ehsan Akhgari wrote:


Related to this, I always found it a bit surprising we perform so much
activity on the patch author side before submission. Part of me thinks
reviewers should take one quick glance at the interdiff before the final
version lands and should be gate keepers. To not do this is somewhat
undermining the review process.


I am not the busiest reviewer out there but I review a decent number of 
patches.  I can't think of _ever_ wanting to look at the interdiff resulted
from a rebase.

Also, I believe we have data showing that most of our reviews are done by a 
relatively small portion of people.  I'd like to humbly suggest that
changing processes to put even more burden on the reviewers may not necessarily 
be the best course of action going forward.

...


Cheers,
Ehsan



Yeah. This is rather subjective view, but I believe that optimizing reviewers' 
workflows and reducing the time they need to spend on a bug
would increase overall productivity more than optimizing patch authors' workflows. Landing code is not too often blocked on patch author but is often 
blocked on reviewer.

Of course the best would be to improve all the workflows.


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

Re: Just Autoland It

[Honza Bambas]

Writing both as a patch author and a reviewer as well.

- as a patch author I want a full control on when the patch actually 
lands (dependencies, any other timing reasons, that only the author 
knows the best), "Don't land yet" comment somewhere will easily be 
overlooked
- as a reviewer I don't want to bare the decision to land or not to 
land, at all
- I want to preserve the mechanism "r+ with comments", which means to 
let the patch be landed by the author after updated (means reviewer 
doesn't need to look over it again)
- as an author I want to write comments about the patch (about the 
structure, what it does, why) to make the review simpler for the 
reviewer ; commit message description may not be the best place, right?

- will it be possible to still be using hg patch queues?
- I (and others too) am not fun of MozReview UI.  As a reviewer I found 
it very hard to orient in it:
- what is the difference between [Reviews] and [Diff] tab? what is 
exactly it's content
- where exactly to click to start a reivew of a patch I want to 
review now?  Is in the "Commits" table?  And is it under "Diff" or 
"Reviews"?
- how can I mark hunks/files are already reviewed (something I like 
on Splinter)?
- how can I see only a single file diff and easily navigate between 
files? (as in Splinter)
- few weeks ago I didn't even know how to give an r+!!  it's hidden 
under the [Finish review...] *tab*?
- simply said: the UI is everything but self-explanatory and highly 
unfriendly, until that is fixed I'm not much willing to use MozReview 
mainly as a reviewer


-hb-


On 1/22/2016 3:35, Gregory Szorc wrote:

If you have level 3 source code access (can push to central, inbound,
fx-team) and have pushed to MozReview via SSH, as of a few weeks ago you
can now land commits from the "Automation" drop down menu on MozReview.
(Before only the review request author could trigger autoland.)

This means that anyone [with permissions] can land commits with a few mouse
clicks! It will even rewrite commit messages with "r=" annotations with the
review state in MozReview. So if someone does a drive-by review, you don't
have to update the commit message to reflect that reviewer. Neato!

I've gotten into the habit of just landing things if I r+ them and I think
they are ready to land. This has startled a few people because it is a
major role reversal of how we've done things for years. (Typically we
require the patch submitter to do the landing.) But I think
reviewer-initiated landing is a better approach: code review is a gate
keeping function so code reviewers should control what goes through the
gate (as opposed to patch authors [with push access] letting themselves
through or sheriffs providing a support role for people without push
access). If nothing else, having the reviewer land things saves time: the
ready-to-land commit isn't exposed to bit rot and automation results are
available sooner.

One downside to autoland is that the rebase will happen remotely and your
local commits may linger forever. But both Mercurial and Git are smart
enough to delete the commits when they turn into no-ops on rebase. We also
have bug 1237778 open for autoland to produce obsolscence markers so
Mercurial will hide the original changesets when you pull down the rebased
versions. There is also potential for some Mercurial or Git command magic
to reconcile the state of MozReview with your local repo and delete local
commits that have been landed. This is a bit annoying. But after having it
happen to me a few times, I think this is a minor annoyance compared to the
overhead of pulling, rebasing, rewriting commit messages, and pushing
locally, possibly hours or days after review was granted.

I encourage my fellow reviewers to join me and "just autoland it" when
granting review on MozReview.

gps
___
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: IndexedDB access in third-party iFrames disabled or not?

[jason]

Thank you so much for the prompt reply Kyle! Everything has been cleared up now!
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Just Autoland It

[L. David Baron]

On Monday 2016-01-25 11:35 -0500, Mike Conley wrote:
> Just be sure to file them. Having talked to the MozReview team about these
> types of bugs, I do know that trust-worthiness of diffs and interdiffs is
> very much a thing that we should be able to take for granted. Any bugs in
> diff and interdiff trust-worthiness are high-priority to fix.

It's not clear to me that making trustworthy interdiffs across
rebases is a thing that can be done given the current UI for showing
diffs, since it's not clear to me that it shows enough information.

I regularly do diffs of diffs (producing double-diffs that have two
columns of +/-/ before the code rather than one), and I've
gotten used to reading them.  It's not clear to me how to explain
interdiffs in a reliable and trustworthy way without that much
metadata about the changes.

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

Re: IndexedDB access in third-party iFrames disabled or not?

[Chris Mills]

Whoops, sorry about that. I’ve updated it now, and made sure that we don’t 
repeat this erroneous point in any other docs.

Chris Mills
 Senior tech writer || Mozilla
developer.mozilla.org || MDN
 cmi...@mozilla.com || @chrisdavidmills

> On 25 Jan 2016, at 18:35, Kyle Huey  wrote:
> 
> We changed this in bug 1147821.  It looks like the documentation hasn't
> been updated.
> 
> - Kyle
> 
> On Mon, Jan 25, 2016 at 10:26 AM,  wrote:
> 
>> Is IndexedDB supposed to be accessible in third-party iFrames? From what I
>> understand, the MDN documentation says IndexedDB is *not* accessible in
>> third-party iFrames, but from my own tests, I have been fully able to use
>> IndexedDB in third-party iFrames.
>> 
>> The MDN documentation link:
>> https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API/Using_IndexedDB#Security
>> Search for "It's important to note that IndexedDB doesn't work for content
>> loaded into a frame"
>> 
>> MDN links to RESOLVED FIXED Bugzilla 595307:
>> https://bugzilla.mozilla.org/show_bug.cgi?id=595307
>> 
>> I guess I don't really understand what the status is. I'm able to use
>> IndexedDB in third-party iFrames, but maybe I shouldn't be able to? What
>> are Firefox's plans for IndexedDB in third-party iFrames?
>> 
>> If necessary, I can upload some test code. Hopefully this is the right
>> place to ask, thanks for reading this!
>> ___
>> 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: Just Autoland It

[Mike Conley]

I should point out that these interdiff issues are being actively worked on.

At least one of them, bug 1238000[1], already has a patch that's under
review to land in core[2].

Just be sure to file them. Having talked to the MozReview team about these
types of bugs, I do know that trust-worthiness of diffs and interdiffs is
very much a thing that we should be able to take for granted. Any bugs in
diff and interdiff trust-worthiness are high-priority to fix.

[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1238000
[2]: https://reviews.reviewboard.org/r/7874/

On 25 January 2016 at 11:28, Boris Zbarsky  wrote:

> On 1/23/16 9:48 PM, Mike Hommey wrote:
>
>> Note that if /other/ changes from other bugs have happened to the same
>> files between the last reviewed iteration and the rebase before landing,
>> the interdiff will show them without any kind of visual cues.
>>
>
> Ah, that's unfortunate.
>
> I agree that this is a hard problem, though (interdiff across rebases).  I
> guess that does mean that you can't really use the final attached thing for
> the "I want to see the interdiff" use case; need to push something to
> MozReview before rebasing to address that.
>
>
> -Boris
> ___
> 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: Dynamic Logging

[Honza Bambas]

Nice idea although unfortunately incomplete.  On Windows this has no 
effect at all.  We cannot use it for common users.  When you set the 
pref, it logs only to the debug output that can be captured only with 
visual studio or similar software being attached.  Not something to ask 
for a common user.


We also need to figure out how to start writing to a file w/o a 
restart.  I believe a harder part of this effort...


-hb-


On 1/9/2016 2:32, Eric Rahm wrote:

Hi Folks-

With bug 1233881  we
landed the ability turn on logging via prefs.

Lets say you have a log module "Foo", if you add a "logging.Foo" pref and
set it to "Debug" you will now see all output from the Foo log module that
is of Debug and higher importance.

Why is this so cool? Well now you don't need to restart your browser to
enable logging [1]. You also don't have to set env vars to enable logging
[2].

There is one caveat: if you don't use LazyLogModule and friends, you don't
get dynamic logging. So go update your loggers!

-e

[1] Okay, this only kind of works right now. You'll still need to set
NSPR_LOG_MODULES="anything_you_want" to see output. Bug 1174972
 will fix this.

[2] If you care about messages during startup you will still need to set
the NSPR_LOG_MODULES env var. Unfortunately it takes time to load the pref
system, and then more time to load your profile.
___
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: Just Autoland It

[Steve Fink]

Heh. Your list of UI complaints is very similar to mine. Some comments:


On 01/25/2016 04:26 AM, Honza Bambas wrote:

Writing both as a patch author and a reviewer as well.

- as a patch author I want a full control on when the patch actually 
lands (dependencies, any other timing reasons, that only the author 
knows the best), "Don't land yet" comment somewhere will easily be 
overlooked
- as a reviewer I don't want to bare the decision to land or not to 
land, at all
- I want to preserve the mechanism "r+ with comments", which means to 
let the patch be landed by the author after updated (means reviewer 
doesn't need to look over it again)
- as an author I want to write comments about the patch (about the 
structure, what it does, why) to make the review simpler for the 
reviewer ; commit message description may not be the best place, right?


Yes, is there a place for this? I feel this is a really important bit of 
functionality that would fit naturally into the mozreview world, but I 
don't see how to do it. Situation: I put up a set of commits for review, 
and I want to give per-commit notes to the reviewer that they'll see 
before reviewing. Previously, I would put them in as comments on the bug 
and either pray that the reviewer happened to see them, or ping the 
reviewer on IRC and tell them to read them. In MozReview, I don't see a 
place to put such things at all?



- will it be possible to still be using hg patch queues?


A valid question, though I'd not that the mq-less workflow is actually 
pretty good these days. mq is still easier/nicer for some things, but 
doing without mq is nicer in other ways, and the future leads away from mq.


On the other hand, there still isn't a great way to figure out the 
mq-less workflow. I remember a pretty good writeup from someone, and I 
intend to write up my own. But there isn't anything that's easily 
discoverable.


- I (and others too) am not fun of MozReview UI.  As a reviewer I 
found it very hard to orient in it:
- what is the difference between [Reviews] and [Diff] tab? what is 
exactly it's content


I just attempted to use MozReview again recently, and from what I can 
tell: there are kind of two main modes, I'll call them "overall" and 
"per-commit". There's is an overall pane that sticks to the top, 
incidentally making it difficult to figure out whether you're in the 
overall or per-commit mode. Clicking on "Review Summary" goes to the 
overall review mode -- as in, the metadata about the whole review. Below 
the fixed pane is the history of metadata changes (so "Review summary" 
means "Overall review metadata view", or something.) Clicking on 
"Squashed diff" is also for the overall review mode, but now it shows 
the squashed diff. In the overall mode, there's some text that claims 
that you can leave comments on the squashed diff, but advises against 
it. There's also no obvious way to leave such comments, but I just 
figured out that it must mean that you can select regions of code and 
it'll pop up a comment box. AFAICT, there's no way to leave general 
comments.


Also, on a large (overall) change, the UI goes off and spends so much 
time loading in all of the changed chunks that it doesn't have time to 
be responsive to button clicks and things, so it's really hard to tell 
what is working and what isn't. But my browser is suffering for other 
reasons these days (yeah, Nightly really sucks for me right now), so 
that may be local.


You get into "per-commit" mode by clicking on the description of a 
review. That will try to trick you by leaving the overall summary in 
place at the top, but if you are careful you'll notice that the portion 
below it is now specific to one commit.


Oh! In writing this, I finally figured out the data model. You have two 
orthogonal dimensions: "review vs diff" and "overall vs per-commit". 
"Review Summary" means "overall x review". "Squashed diff" means 
"overall x diff". The summary table at the top lists links that will get 
you to per-commit views for each commit. The ones in the "Diff" column 
are "per-commit x diff". The textual descriptions in the "Reviews" 
column are "per-commit x review". The two 
tabs-that-still-aren't-true-tabs in the top right control just the 
"review vs diff" dimension for either the overall or the per-commit views.


\o/ It's starting to finally make sense to me! (I think?)

Then there are the tabs-that-aren't-even-close-to-being-tabs, which have 
various context-specific actions on them.


> - where exactly to click to start a reivew of a patch I want to 
review now?  Is in the "Commits" table?  And is it under "Diff" or 
"Reviews"?


To leave a comment, it looks like you have to go to the Commits table, 
under the "Diff" column, and then select line regions.


It took me a while to figure out the latter part, btw. I selected a 
region of code to comment on it. No luck. I double-clicked a line of 
code. No luck. I eventually figured out that it wants you to only 

Re: Moving FirefoxOS into Tier 3 support

[nhirata]

I think the QC gonk layer had required 4.7 to lunch.

As far as I know you would have had to use the emulator from the get go if you 
wanted to test the ril?  The ril is in the Gonk layer as far as I know still 
and the Gonk layer isn't in the mulet nor desktop builds...

On Monday, January 25, 2016 at 10:36:35 AM UTC-8, Steve Fink wrote:
> On 01/25/2016 09:40 AM, Fabrice Desré wrote:
> > On 01/25/2016 09:30 AM, Ehsan Akhgari wrote:
> >
> >> For example, for a long time b2g partners held back our minimum
> >> supported gcc.  Now that there are no such partner requirements, perhaps
> >> we can consider bumping up the minimum to gcc 4.8?  (bug 1175546)
> > We moved to 4.8 on b2g a year ago: see
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1056337
> > Who's behind? :P
> 
> I am.
> 
> The b2g rooting hazard analysis build is still using gcc 4.7. I spent a 
> bunch of effort trying to upgrade it to gcc 4.9, but ran into a variety 
> of issues I didn't understand related to the b2g build system (both on 
> my local laptop and on a build slave), and finally gave up in despair. 
> But the b2g hazard build is also a mozharness tangle of mixins and weird 
> inheritance structure (as is the older b2g emulator build), and those 
> are being replaced with taskcluster-based builds.
> 
> In the last 2 weeks, I've been working on redoing the b2g hazard build 
> on top of taskcluster and mulet. Partly because it's mulet, and partly 
> because it uses Docker and simple shell scripts, it has been *way* way 
> way way way *way* easier and more pleasant to deal with. I have it 
> working locally, so I hope to have the b2g hazard builds upgraded to gcc 
> 4.9 soonish.
> 
> But that's on top of mulet, which means it isn't compiling any of the 
> MOZ_B2G_RIL code, which means it has lost some coverage over the 
> original build. If I understand correctly, the "right" thing to do would 
> be to use an emulator build instead, but that means that the b2g build 
> system gets involved again, which is complex and slings around a lot 
> more data, so everything is far slower to work on.
> 
> With FxOS becoming tier 3, I am disinclined to even attempt the emulator 
> version. In theory, it would be a straightforward adaptation of the 
> mulet hazard build script. In practice, it would take a while to even 
> test out that theory.

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

Re: Moving FirefoxOS into Tier 3 support

[Ehsan Akhgari]

Hi Fabrice,

On 2016-01-25 11:00 AM, Fabrice Desré wrote:

Hi all,

   With the smartphone activity shifting to a more exploratory status, we
have been discussing with the platform & releng people which setup would
allow us to keep improving the product and supporting our community of
users while minimizing impact on other parts of the organization.

   The decision we ended up with is to move Firefox OS into Tier 3
support category (see
https://developer.mozilla.org/en-U/docs/Supported_build_configurations).
That means that other teams won't be backed out and yelled at by
sheriffs for breaking b2g tests, and that the FirefoxOS team will be
responsible for fixing such breakage. Landing code for FirefoxOS stays
the same as today - we don't fork.
   We're also working on a solution to move the b2g builds & tests to
their own infrastructure from which we'll ship our builds & updates.


I have two questions about this:

1. What does this mean for Firefox OS specific code in Gecko which is 
designed to keep some level of testing possible on the Firefox OS side 
by adding hacks to Gecko?  Another example is hacks that we have needed 
around Firefox OS's toolchain limitations (the gcc version requirements, 
for example.)  Can we remove such hacks now?


2. What about patches that couldn't land because of Firefox OS tests 
failing in ways the author couldn't figure out?  I'm thinking of 
examples such as bug 1043562.  Can we land such patches now?


Thanks,
Ehsan


   I want to thank all the people from various corners of the platform
that helped us so far. I guess I'll have to bribe you now!

   Feel free to reach out to me if you need any more details on the subject,



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

Re: Moving FirefoxOS into Tier 3 support

[Fabrice Desré]

Hi Ehsan,

On 01/25/2016 08:38 AM, Ehsan Akhgari wrote:

> I have two questions about this:
> 
> 1. What does this mean for Firefox OS specific code in Gecko which is
> designed to keep some level of testing possible on the Firefox OS side
> by adding hacks to Gecko?  Another example is hacks that we have needed
> around Firefox OS's toolchain limitations (the gcc version requirements,
> for example.)  Can we remove such hacks now?

First, what you call "now" will not happen until we setup the
infrastructure we need for b2g. I would appreciate you to send me bug
numbers for all these issues you're talking about.
Secondly, since I really don't want us to fork gecko it would be
unfortunate if people felt like they can just burn the house. Please use
your best judgment and talk to people before *knowingly* breaking us.

> 2. What about patches that couldn't land because of Firefox OS tests
> failing in ways the author couldn't figure out?  I'm thinking of
> examples such as bug 1043562.  Can we land such patches now?

Yes.

-- 
Fabrice Desré
Connected Devices
Mozilla Corporation
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

[Firefox Desktop] Issues found: January 18th to January 22nd

[Andrei Vaida]

Hi everyone,

Here's the list of new issues found and filed by the Desktop Manual QA 
team last week, *January 18th - January 22nd* /(week 3)/.


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*
ID  Summary Product Component   Is a regression 
Assigned to
1241484 
	crash in mozilla::layers::TextureChild::WaitForCompositorRecycle | 
mozilla::layers::CanvasClientSharedSurface::Updated

Core
Graphics
YES NOBODY
1241861 
crash in mozilla::layers::TextureChild::Release
Core
Graphics
YES NOBODY
1241471 
[Ubuntu] Unable to make Firefox the default browser
Toolkit
Preferences
YES NOBODY
1240727 
	Capital letters keywords are not recognized when showing which of the 
search engine will be used in the next search

Firefox
Search
NO  NOBODY
1240729 
	No favicon displayed for baidu.com in Search bar panel after adding the 
engine

Firefox
Search
YES NOBODY
1240695 
	[intermittent] Flicker in Default Search Engine drop-down while 
deleting engines via about:preferences#search

Firefox
Search
NO  NOBODY
1241092 
	Browser console errors while reopening a recently closed conversation 
window

Hello (Loop)
Client
NO  NOBODY
1241097 
”Email link” option throws an error in Browser console
Hello (Loop)
Client
NO  NOBODY
1241101 
Browser console errors while closing the conversation window
Hello (Loop)
Client
NO  NOBODY



*BETA CHANNEL*
ID  Summary Product Component   Is a regression 
Assigned to
1240439 
Edit email or password field inside Save Logins is larger then it should
Firefox
Preferences
YES NOBODY



*AURORA CHANNEL*
ID  Summary Product Component   Is a regression 
Assigned to
1241876 
crash in RefPtr::RefPtr
Core
Graphics
YES NOBODY
1241875 
crash in mozilla::layers::TextureClient::Destroy
Core
Graphics
YES NOBODY
1241851  
“Fetching Synced Tabs” panel is continuously displayed 	Firefox 
Sync 	NO 	NOBODY
1241860  
Interrupted line in “Synced tabs” panel 	Firefox 	Sync 	NO 	NOBODY



*
**NIGHTLY CHANNEL*
ID  Summary Product Component   Is a regression 
Assigned to
1241141 
	Synced tabs panel height changes when it is accessed from History 
(Panel Menu)

Firefox
Sync
NO  Kit Cambridge
1241120 
	Default icon is shown for context tile when loading more heavy content 
websites

Hello (Loop)
Client
NO  NOBODY
1241431 
[Ubuntu] Panel Menu is incorrectly positioned after accessing Synced 
Tabs
Firefox
Sync
NO  NOBODY
1241424 
	The crash reporter content is not displayed if was automatically 
checked on tab crash

Firefox
General
NO  NOBODY
1241430 
"Crash report already submitted" screen is not displayed
Firefox
General
NO  NOBODY
1241433 
Make the "Submit report" option (also its sub-options) keyboard 
accessible
Firefox
General
NO  NOBODY
1241436 
	User shouldn't be able to enter email address if the "email me when 
more info is available" option is unchecked in the tab crash reporter

Firefox
General
NO  NOBODY
1241439 
	After closing a second crashed tab, "restore all 

Re: Just Autoland It

[Mike Connor]

On Sat, Jan 23, 2016 at 11:11 AM, Eric Rescorla  wrote:

> Following up in this. We're not the first people to have autoland, so is
> there some reason
> not to simply copy what others do here. Specifically, here's the Chromium
> commitbot
> behavior: https://www.chromium.org/developers/testing/commit-queue
>

I don't think that policy really solves for putting the patch author in
clear control, or enabling a lands-when-reviewed workflow.  That's why I
suggested a different flag to allow authors and reviewers to explicitly
incorporate autoland into the workflow on an opt-in basis.

tl;dr

* We should make it easy for authors to explicitly opt-in to reviewer-lands
as a workflow.
* If the patch author doesn't opt in, we should assume business as usual.

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

Re: Just Autoland It

[Paolo Amadini]

On 1/22/2016 2:00 PM, Mark Hammond wrote:

(Hopefully) related - what exactly is the "checkin?" flag for?


As far as I understand, it's used together with the "checkin-needed"
keyword when there is ambiguity about which of the attachments in the
bug should be landed by the sheriffs or the reviewer.

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

Re: Just Autoland It

[Boris Zbarsky]

On 1/23/16 9:48 PM, Mike Hommey wrote:

Note that if /other/ changes from other bugs have happened to the same
files between the last reviewed iteration and the rebase before landing,
the interdiff will show them without any kind of visual cues.


Ah, that's unfortunate.

I agree that this is a hard problem, though (interdiff across rebases). 
 I guess that does mean that you can't really use the final attached 
thing for the "I want to see the interdiff" use case; need to push 
something to MozReview before rebasing to address that.


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

Re: Moving FirefoxOS into Tier 3 support

[doug . turner]

On Monday, January 25, 2016 at 8:38:08 AM UTC-8, Ehsan Akhgari wrote:
> Hi Fabrice,
> 
> On 2016-01-25 11:00 AM, Fabrice Desré wrote:
> > Hi all,
> >
> >With the smartphone activity shifting to a more exploratory status, we
> > have been discussing with the platform & releng people which setup would
> > allow us to keep improving the product and supporting our community of
> > users while minimizing impact on other parts of the organization.
> >
> >The decision we ended up with is to move Firefox OS into Tier 3
> > support category (see
> > https://developer.mozilla.org/en-U/docs/Supported_build_configurations).
> > That means that other teams won't be backed out and yelled at by
> > sheriffs for breaking b2g tests, and that the FirefoxOS team will be
> > responsible for fixing such breakage. Landing code for FirefoxOS stays
> > the same as today - we don't fork.
> >We're also working on a solution to move the b2g builds & tests to
> > their own infrastructure from which we'll ship our builds & updates.
> 
> I have two questions about this:
> 
> 1. What does this mean for Firefox OS specific code in Gecko which is 
> designed to keep some level of testing possible on the Firefox OS side 
> by adding hacks to Gecko?  Another example is hacks that we have needed 
> around Firefox OS's toolchain limitations (the gcc version requirements, 
> for example.)  Can we remove such hacks now?
> 
> 2. What about patches that couldn't land because of Firefox OS tests 
> failing in ways the author couldn't figure out?  I'm thinking of 
> examples such as bug 1043562.  Can we land such patches now?
> 
> Thanks,
> Ehsan
> 
> >I want to thank all the people from various corners of the platform
> > that helped us so far. I guess I'll have to bribe you now!
> >
> >Feel free to reach out to me if you need any more details on the subject,
> >


I think the answer to (1) is no. There might be specific code-removals which 
enable us to move faster on supporting Firefox. I believe blassey has specific 
details on this.  But, in general, do no harm yet.

As for (2), land patches and don't think about FirefoxOS.  It's tier three and 
that's the point.



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

Re: Moving FirefoxOS into Tier 3 support

[Joshua Cranmer ]

On 1/25/2016 11:30 AM, Ehsan Akhgari wrote:
For example, for a long time b2g partners held back our minimum 
supported gcc.  Now that there are no such partner requirements, 
perhaps we can consider bumping up the minimum to gcc 4.8?  (bug 1175546)


Strictly speaking, I would advocate for 4.8.1, since that gets us ref 
qualifiers on methods (or will, once we get VS 2015 as the minimum 
requirement on Windows).


--
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist

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

IndexedDB access in third-party iFrames disabled or not?

[jason]

Is IndexedDB supposed to be accessible in third-party iFrames? From what I 
understand, the MDN documentation says IndexedDB is *not* accessible in 
third-party iFrames, but from my own tests, I have been fully able to use 
IndexedDB in third-party iFrames.

The MDN documentation link: 
https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API/Using_IndexedDB#Security
Search for "It's important to note that IndexedDB doesn't work for content 
loaded into a frame"

MDN links to RESOLVED FIXED Bugzilla 595307: 
https://bugzilla.mozilla.org/show_bug.cgi?id=595307

I guess I don't really understand what the status is. I'm able to use IndexedDB 
in third-party iFrames, but maybe I shouldn't be able to? What are Firefox's 
plans for IndexedDB in third-party iFrames? 

If necessary, I can upload some test code. Hopefully this is the right place to 
ask, thanks for reading this!
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: IndexedDB access in third-party iFrames disabled or not?

[Kyle Huey]

We changed this in bug 1147821.  It looks like the documentation hasn't
been updated.

- Kyle

On Mon, Jan 25, 2016 at 10:26 AM,  wrote:

> Is IndexedDB supposed to be accessible in third-party iFrames? From what I
> understand, the MDN documentation says IndexedDB is *not* accessible in
> third-party iFrames, but from my own tests, I have been fully able to use
> IndexedDB in third-party iFrames.
>
> The MDN documentation link:
> https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API/Using_IndexedDB#Security
> Search for "It's important to note that IndexedDB doesn't work for content
> loaded into a frame"
>
> MDN links to RESOLVED FIXED Bugzilla 595307:
> https://bugzilla.mozilla.org/show_bug.cgi?id=595307
>
> I guess I don't really understand what the status is. I'm able to use
> IndexedDB in third-party iFrames, but maybe I shouldn't be able to? What
> are Firefox's plans for IndexedDB in third-party iFrames?
>
> If necessary, I can upload some test code. Hopefully this is the right
> place to ask, thanks for reading this!
> ___
> 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: Moving FirefoxOS into Tier 3 support

[Steve Fink]

On 01/25/2016 09:40 AM, Fabrice Desré wrote:

On 01/25/2016 09:30 AM, Ehsan Akhgari wrote:


For example, for a long time b2g partners held back our minimum
supported gcc.  Now that there are no such partner requirements, perhaps
we can consider bumping up the minimum to gcc 4.8?  (bug 1175546)

We moved to 4.8 on b2g a year ago: see
https://bugzilla.mozilla.org/show_bug.cgi?id=1056337
Who's behind? :P


I am.

The b2g rooting hazard analysis build is still using gcc 4.7. I spent a 
bunch of effort trying to upgrade it to gcc 4.9, but ran into a variety 
of issues I didn't understand related to the b2g build system (both on 
my local laptop and on a build slave), and finally gave up in despair. 
But the b2g hazard build is also a mozharness tangle of mixins and weird 
inheritance structure (as is the older b2g emulator build), and those 
are being replaced with taskcluster-based builds.


In the last 2 weeks, I've been working on redoing the b2g hazard build 
on top of taskcluster and mulet. Partly because it's mulet, and partly 
because it uses Docker and simple shell scripts, it has been *way* way 
way way way *way* easier and more pleasant to deal with. I have it 
working locally, so I hope to have the b2g hazard builds upgraded to gcc 
4.9 soonish.


But that's on top of mulet, which means it isn't compiling any of the 
MOZ_B2G_RIL code, which means it has lost some coverage over the 
original build. If I understand correctly, the "right" thing to do would 
be to use an emulator build instead, but that means that the b2g build 
system gets involved again, which is complex and slings around a lot 
more data, so everything is far slower to work on.


With FxOS becoming tier 3, I am disinclined to even attempt the emulator 
version. In theory, it would be a straightforward adaptation of the 
mulet hazard build script. In practice, it would take a while to even 
test out that theory.


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

Re: Moving FirefoxOS into Tier 3 support

[Eric Rescorla]

On Mon, Jan 25, 2016 at 9:34 AM, Nathan Froyd  wrote:

> On Mon, Jan 25, 2016 at 12:30 PM, Ehsan Akhgari 
> wrote:
>
> > For example, for a long time b2g partners held back our minimum supported
> > gcc.  Now that there are no such partner requirements, perhaps we can
> > consider bumping up the minimum to gcc 4.8?  (bug 1175546)
> >
> > I'm sure others have similar examples to fill in.
> >
>
> One current example is b2g's reliance on stlport and changing the build to
> support a modern C++ library like libc++.
>

It would be great to be able to make this change.

-Ekr


>
> -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: Moving FirefoxOS into Tier 3 support

[Fabrice Desré]

On 01/25/2016 09:30 AM, Ehsan Akhgari wrote:

> For example, for a long time b2g partners held back our minimum
> supported gcc.  Now that there are no such partner requirements, perhaps
> we can consider bumping up the minimum to gcc 4.8?  (bug 1175546)

We moved to 4.8 on b2g a year ago: see
https://bugzilla.mozilla.org/show_bug.cgi?id=1056337
Who's behind? :P

> Another example, last year because of 2.5 release pressure where people
> were planning on using service workers in gaia app, we had to add a huge
> hack for "supporting" app:// URIs for service worker interception.  The
> last time that this code bit me was earlier this morning.  It would be
> nice if I can remove this broken code now instead of worrying about how
> to keep supporting it going forward (this makes fixing bug 1222008 more
> complicated than it needs to be.)

I have no objections to remove this particular support.

-- 
Fabrice Desré
Connected Devices
Mozilla Corporation
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Moving FirefoxOS into Tier 3 support

[Nathan Froyd]

On Mon, Jan 25, 2016 at 12:30 PM, Ehsan Akhgari 
wrote:

> For example, for a long time b2g partners held back our minimum supported
> gcc.  Now that there are no such partner requirements, perhaps we can
> consider bumping up the minimum to gcc 4.8?  (bug 1175546)
>
> I'm sure others have similar examples to fill in.
>

One current example is b2g's reliance on stlport and changing the build to
support a modern C++ library like libc++.

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

Re: Moving FirefoxOS into Tier 3 support

[Ehsan Akhgari]

On 2016-01-25 12:11 PM, Fabrice Desré wrote:

Hi Ehsan,

On 01/25/2016 08:38 AM, Ehsan Akhgari wrote:


I have two questions about this:

1. What does this mean for Firefox OS specific code in Gecko which is
designed to keep some level of testing possible on the Firefox OS side
by adding hacks to Gecko?  Another example is hacks that we have needed
around Firefox OS's toolchain limitations (the gcc version requirements,
for example.)  Can we remove such hacks now?


First, what you call "now" will not happen until we setup the
infrastructure we need for b2g. I would appreciate you to send me bug
numbers for all these issues you're talking about.


Hmm, I'm not sure if there are bugs on file for all of these things. 
But an example would be bug 1197379.



Secondly, since I really don't want us to fork gecko it would be
unfortunate if people felt like they can just burn the house. Please use
your best judgment and talk to people before *knowingly* breaking us.


Of course.  :-)

My point wasn't about code that is needed for basic b2g support.  I'm 
talking about situations that caused us to add hacks inside Gecko 
because of either partner issues or b2g timeline/release pressure.


For example, for a long time b2g partners held back our minimum 
supported gcc.  Now that there are no such partner requirements, perhaps 
we can consider bumping up the minimum to gcc 4.8?  (bug 1175546)


Another example, last year because of 2.5 release pressure where people 
were planning on using service workers in gaia app, we had to add a huge 
hack for "supporting" app:// URIs for service worker interception.  The 
last time that this code bit me was earlier this morning.  It would be 
nice if I can remove this broken code now instead of worrying about how 
to keep supporting it going forward (this makes fixing bug 1222008 more 
complicated than it needs to be.)


I'm sure others have similar examples to fill in.


2. What about patches that couldn't land because of Firefox OS tests
failing in ways the author couldn't figure out?  I'm thinking of
examples such as bug 1043562.  Can we land such patches now?


Yes.


Fantastic!

Just to double check, does the above "now" apply to this as well?  IOW, 
can I land that patch right now, or should I wait for a future 
announcement which goes out when the aforementioned separate build/test 
infrastructure is ready?


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

Re: Moving FirefoxOS into Tier 3 support

[Andrew Halberstadt]

On 25/01/16 11:00 AM, Fabrice Desré wrote:

   We're also working on a solution to move the b2g builds & tests to
their own infrastructure from which we'll ship our builds & updates.


What specifically does this mean? Do you mean infrastructure at the IT
level? Or at the continuous integration level (taskcluster,
mozharness, test harnesses, etc)?

If the latter, is there a detailed outline of the plans being proposed here?

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

Re: Moving FirefoxOS into Tier 3 support

[Naoki Hirata]

It sounds basically like Gecko support is cut off for the most part.  If
there's no decision to pull it out of teir 3 support, ie a direction for
the project needs to be decided...
the project will eventually fail unless we lock into a gecko.  (60 % of
failures for smoke tests come from gecko).

How soon do you think we will pull out of tier 3 support?

On Mon, Jan 25, 2016 at 9:40 AM, Fabrice Desré  wrote:

> On 01/25/2016 09:30 AM, Ehsan Akhgari wrote:
>
> > For example, for a long time b2g partners held back our minimum
> > supported gcc.  Now that there are no such partner requirements, perhaps
> > we can consider bumping up the minimum to gcc 4.8?  (bug 1175546)
>
> We moved to 4.8 on b2g a year ago: see
> https://bugzilla.mozilla.org/show_bug.cgi?id=1056337
> Who's behind? :P
>
> > Another example, last year because of 2.5 release pressure where people
> > were planning on using service workers in gaia app, we had to add a huge
> > hack for "supporting" app:// URIs for service worker interception.  The
> > last time that this code bit me was earlier this morning.  It would be
> > nice if I can remove this broken code now instead of worrying about how
> > to keep supporting it going forward (this makes fixing bug 1222008 more
> > complicated than it needs to be.)
>
> I have no objections to remove this particular support.
>
> --
> Fabrice Desré
> Connected Devices
> Mozilla Corporation
> ___
> dev-fxos mailing list
> dev-f...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-fxos
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Dynamic Logging

[Eric Rahm]

On Monday, January 25, 2016 at 11:06:15 AM UTC-8, Honza Bambas wrote:
> Nice idea although unfortunately incomplete.  On Windows this has no 
> effect at all.  We cannot use it for common users.  When you set the 
> pref, it logs only to the debug output that can be captured only with 
> visual studio or similar software being attached.  Not something to ask 
> for a common user.

I'm reasonably sure it logs to stderr, if there is an issue in the Windows 
implementation please file a bug and we'll get it fixed.

> We also need to figure out how to start writing to a file w/o a 
> restart.  I believe a harder part of this effort...

Valentin has a patch for dynamically specifying a log file in bug 1239686.

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

Re: Moving FirefoxOS into Tier 3 support

[nhirata]

More over : https://bugzilla.mozilla.org/show_bug.cgi?id=1239082 ; Aren't we 
disabling all Buildbot Based b2g desktop "hazard" builds on all trees ?

On Monday, January 25, 2016 at 12:26:58 PM UTC-8, nhi...@mozilla.com wrote:
> I think the QC gonk layer had required 4.7 to lunch.
> 
> As far as I know you would have had to use the emulator from the get go if 
> you wanted to test the ril?  The ril is in the Gonk layer as far as I know 
> still and the Gonk layer isn't in the mulet nor desktop builds...
> 
> On Monday, January 25, 2016 at 10:36:35 AM UTC-8, Steve Fink wrote:
> > On 01/25/2016 09:40 AM, Fabrice Desré wrote:
> > > On 01/25/2016 09:30 AM, Ehsan Akhgari wrote:
> > >
> > >> For example, for a long time b2g partners held back our minimum
> > >> supported gcc.  Now that there are no such partner requirements, perhaps
> > >> we can consider bumping up the minimum to gcc 4.8?  (bug 1175546)
> > > We moved to 4.8 on b2g a year ago: see
> > > https://bugzilla.mozilla.org/show_bug.cgi?id=1056337
> > > Who's behind? :P
> > 
> > I am.
> > 
> > The b2g rooting hazard analysis build is still using gcc 4.7. I spent a 
> > bunch of effort trying to upgrade it to gcc 4.9, but ran into a variety 
> > of issues I didn't understand related to the b2g build system (both on 
> > my local laptop and on a build slave), and finally gave up in despair. 
> > But the b2g hazard build is also a mozharness tangle of mixins and weird 
> > inheritance structure (as is the older b2g emulator build), and those 
> > are being replaced with taskcluster-based builds.
> > 
> > In the last 2 weeks, I've been working on redoing the b2g hazard build 
> > on top of taskcluster and mulet. Partly because it's mulet, and partly 
> > because it uses Docker and simple shell scripts, it has been *way* way 
> > way way way *way* easier and more pleasant to deal with. I have it 
> > working locally, so I hope to have the b2g hazard builds upgraded to gcc 
> > 4.9 soonish.
> > 
> > But that's on top of mulet, which means it isn't compiling any of the 
> > MOZ_B2G_RIL code, which means it has lost some coverage over the 
> > original build. If I understand correctly, the "right" thing to do would 
> > be to use an emulator build instead, but that means that the b2g build 
> > system gets involved again, which is complex and slings around a lot 
> > more data, so everything is far slower to work on.
> > 
> > With FxOS becoming tier 3, I am disinclined to even attempt the emulator 
> > version. In theory, it would be a straightforward adaptation of the 
> > mulet hazard build script. In practice, it would take a while to even 
> > test out that theory.

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

Status of the Component Owners for Bug Decisions Sheet. Monday 1/25

[Emma Humphries]

Monday 25 January 2016

Stay on target, Ren (or Luke, if you're Old School,) and don't turn
off your targeting computer. We're up to almost 70% complete on the
list!

Thanks again to everyone filling this in, including bgrinstead, who
updated the Developer Tools component Friday afternoon after I sent
out the update.

And yes, that was a typo in the subject of Friday's email. It didn't
come from the alternate universe where the 26th is on a Tuesday.

%Complete

Core 67.13%
Toolkit 59.46%
Firefox 70.00%
Fennec iOS 45.45%
Fennec Android 100.00%
Overall 69.31%

Cheers,
---
Emma Humphries
irc: emceeaich
bugmail: ehumphr...@mozilla.com
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Moving FirefoxOS into Tier 3 support

[Steve Fink]

Sorry. To be clear: the (still existing) hazard builds *do* use the 
emulator, which is at least half the reason why they're so difficult to 
maintain and upgrade.


I don't know what the Gonk layer is exactly. I do know that there is 
code in the gecko tree guarded by #ifdef MOZ_B2G_RIL, and I believe that 
code is compiled by the same compiler that compiles the rest of gecko, 
which is why the hazard analysis found bugs in it. There is other code 
compiled when doing an emulator build that is compiled by a different 
compiler, but it can't call the JSAPI directly or indirectly so I don't 
care about it for the analysis. (The problems I ran into when I 
attempted to change only the gecko compiler seemed to be related to more 
stuff than I expected getting compiled with the gecko compiler, but 
that's my confused impression of what was going on and doesn't really 
matter here.)


As for bug 1239082, it started as bug 1236835 that originally planned to 
turn off *all* buildbot based b2g desktop builds. When I stated that I 
still needed the hazard builds, Callek reduced his changes so that he'd 
turn off all but the hazard builds, then forked off bug 1239082 to 
finish up the job after I migrated the hazard builds to taskcluster. I'm 
working on that (that's the thing I said works locally on my laptop 
now), but I did it as a mulet-based build so I wouldn't have to deal 
with the b2g build system again, at least until we decided we needed the 
ril coverage back.


Only now with b2g being tier-3, I'm thinking that if b2g needs that 
coverage back, then a person who is not me can port my mulet build 
changes over to the emulator build script, and I will congratulate 
not-me on a job well done and breathe a sigh of relief that not-me is, 
in fact, not me.


On 01/25/2016 01:06 PM, nhir...@mozilla.com wrote:

More over : https://bugzilla.mozilla.org/show_bug.cgi?id=1239082 ; Aren't we
disabling all Buildbot Based b2g desktop "hazard" builds on all trees ?

On Monday, January 25, 2016 at 12:26:58 PM UTC-8, nhi...@mozilla.com wrote:

I think the QC gonk layer had required 4.7 to lunch.

As far as I know you would have had to use the emulator from the get go if you 
wanted to test the ril?  The ril is in the Gonk layer as far as I know still 
and the Gonk layer isn't in the mulet nor desktop builds...

On Monday, January 25, 2016 at 10:36:35 AM UTC-8, Steve Fink wrote:

On 01/25/2016 09:40 AM, Fabrice Desré wrote:

On 01/25/2016 09:30 AM, Ehsan Akhgari wrote:


For example, for a long time b2g partners held back our minimum
supported gcc.  Now that there are no such partner requirements, perhaps
we can consider bumping up the minimum to gcc 4.8?  (bug 1175546)

We moved to 4.8 on b2g a year ago: see
https://bugzilla.mozilla.org/show_bug.cgi?id=1056337
Who's behind? :P

I am.

The b2g rooting hazard analysis build is still using gcc 4.7. I spent a
bunch of effort trying to upgrade it to gcc 4.9, but ran into a variety
of issues I didn't understand related to the b2g build system (both on
my local laptop and on a build slave), and finally gave up in despair.
But the b2g hazard build is also a mozharness tangle of mixins and weird
inheritance structure (as is the older b2g emulator build), and those
are being replaced with taskcluster-based builds.

In the last 2 weeks, I've been working on redoing the b2g hazard build
on top of taskcluster and mulet. Partly because it's mulet, and partly
because it uses Docker and simple shell scripts, it has been *way* way
way way way *way* easier and more pleasant to deal with. I have it
working locally, so I hope to have the b2g hazard builds upgraded to gcc
4.9 soonish.

But that's on top of mulet, which means it isn't compiling any of the
MOZ_B2G_RIL code, which means it has lost some coverage over the
original build. If I understand correctly, the "right" thing to do would
be to use an emulator build instead, but that means that the b2g build
system gets involved again, which is complex and slings around a lot
more data, so everything is far slower to work on.

With FxOS becoming tier 3, I am disinclined to even attempt the emulator
version. In theory, it would be a straightforward adaptation of the
mulet hazard build script. In practice, it would take a while to even
test out that theory.

___
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: Just Autoland It

[Mike Hommey]

On Mon, Jan 25, 2016 at 11:23:59AM -0800, Steve Fink wrote:
> Heh. Your list of UI complaints is very similar to mine. Some comments:
> 
> 
> On 01/25/2016 04:26 AM, Honza Bambas wrote:
> >Writing both as a patch author and a reviewer as well.
> >
> >- as a patch author I want a full control on when the patch actually lands
> >(dependencies, any other timing reasons, that only the author knows the
> >best), "Don't land yet" comment somewhere will easily be overlooked
> >- as a reviewer I don't want to bare the decision to land or not to land,
> >at all
> >- I want to preserve the mechanism "r+ with comments", which means to let
> >the patch be landed by the author after updated (means reviewer doesn't
> >need to look over it again)
> >- as an author I want to write comments about the patch (about the
> >structure, what it does, why) to make the review simpler for the reviewer
> >; commit message description may not be the best place, right?
> 
> Yes, is there a place for this? I feel this is a really important bit of
> functionality that would fit naturally into the mozreview world, but I don't
> see how to do it. Situation: I put up a set of commits for review, and I
> want to give per-commit notes to the reviewer that they'll see before
> reviewing. Previously, I would put them in as comments on the bug and either
> pray that the reviewer happened to see them, or ping the reviewer on IRC and
> tell them to read them. In MozReview, I don't see a place to put such things
> at all?

It's also painful to use MozReview's comment system. The comments in the
reviews pane don't show much diff context, and while I just realized
it's possible to make it show more by hovering the diff part for a
little while, it's not really great, as it doesn't actually show a diff
view like the diff pane does, and switching to the diff pane a) is slow
for large diffs and b) has an entirely different comment UX that doesn't
seem really great either.

Also, iirc, when you reply diff comments in MozReview, the resulting
comments sent to bugzilla lack context (but I could be misremembering).

> >- will it be possible to still be using hg patch queues?
> 
> A valid question, though I'd not that the mq-less workflow is actually
> pretty good these days. mq is still easier/nicer for some things, but doing
> without mq is nicer in other ways, and the future leads away from mq.
> 
> On the other hand, there still isn't a great way to figure out the mq-less
> workflow. I remember a pretty good writeup from someone, and I intend to
> write up my own. But there isn't anything that's easily discoverable.

Whether or not mq is deprecated, it still uses changesets that can be
pushed. And with a non publishing remote repository, it should still be
able to qpop without having to fool around with the draft state.

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

Re: Just Autoland It

[Andrew Halberstadt]

On 25/01/16 05:44 PM, Eric Rescorla wrote:

On Mon, Jan 25, 2016 at 1:58 PM, Mike Hommey  wrote:


On Mon, Jan 25, 2016 at 11:23:59AM -0800, Steve Fink wrote:

Heh. Your list of UI complaints is very similar to mine. Some comments:


On 01/25/2016 04:26 AM, Honza Bambas wrote:

Writing both as a patch author and a reviewer as well.

- as a patch author I want a full control on when the patch actually

lands

(dependencies, any other timing reasons, that only the author knows the
best), "Don't land yet" comment somewhere will easily be overlooked
- as a reviewer I don't want to bare the decision to land or not to

land,

at all
- I want to preserve the mechanism "r+ with comments", which means to

let

the patch be landed by the author after updated (means reviewer doesn't
need to look over it again)
- as an author I want to write comments about the patch (about the
structure, what it does, why) to make the review simpler for the

reviewer

; commit message description may not be the best place, right?


Yes, is there a place for this? I feel this is a really important bit of
functionality that would fit naturally into the mozreview world, but I

don't

see how to do it. Situation: I put up a set of commits for review, and I
want to give per-commit notes to the reviewer that they'll see before
reviewing. Previously, I would put them in as comments on the bug and

either

pray that the reviewer happened to see them, or ping the reviewer on IRC

and

tell them to read them. In MozReview, I don't see a place to put such

things

at all?


It's also painful to use MozReview's comment system. The comments in the
reviews pane don't show much diff context, and while I just realized
it's possible to make it show more by hovering the diff part for a
little while, it's not really great, as it doesn't actually show a diff
view like the diff pane does, and switching to the diff pane a) is slow
for large diffs and b) has an entirely different comment UX that doesn't
seem really great either.



Indeed. It would be great if it would just include 5-8 lines of context by
default.

-Ekr


It's not terribly obvious, but instead of clicking on a line number you 
can click and drag on the numbers to set the exact amount of context you 
want.


-Andrew





Also, iirc, when you reply diff comments in MozReview, the resulting
comments sent to bugzilla lack context (but I could be misremembering).


- will it be possible to still be using hg patch queues?


A valid question, though I'd not that the mq-less workflow is actually
pretty good these days. mq is still easier/nicer for some things, but

doing

without mq is nicer in other ways, and the future leads away from mq.

On the other hand, there still isn't a great way to figure out the

mq-less

workflow. I remember a pretty good writeup from someone, and I intend to
write up my own. But there isn't anything that's easily discoverable.


Whether or not mq is deprecated, it still uses changesets that can be
pushed. And with a non publishing remote repository, it should still be
able to qpop without having to fool around with the draft state.

Mike
___
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: Just Autoland It

[Steve Fink]

On 01/25/2016 01:58 PM, Mike Hommey wrote:

On Mon, Jan 25, 2016 at 11:23:59AM -0800, Steve Fink wrote:

- will it be possible to still be using hg patch queues?

A valid question, though I'd not that the mq-less workflow is actually
pretty good these days. mq is still easier/nicer for some things, but doing
without mq is nicer in other ways, and the future leads away from mq.

On the other hand, there still isn't a great way to figure out the mq-less
workflow. I remember a pretty good writeup from someone, and I intend to
write up my own. But there isn't anything that's easily discoverable.

Whether or not mq is deprecated, it still uses changesets that can be
pushed. And with a non publishing remote repository, it should still be
able to qpop without having to fool around with the draft state.



For the first (force) push, sure. But given mq's love of rewriting 
history, I assume it will not maintain any correspondence between 
versions of a patch (either via obsolescence markers, or gps's magic 
metadata field, or whatever). So if you push an updated patch, I 
wouldn't expect it to be able to figure out that it's an update of an 
earlier commit? Unless it's doing some heuristic matching on comments or 
something.


It just got one of my patches wrong, though, so maybe it *is* doing 
something fancy. :-)


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

Re: Moving FirefoxOS into Tier 3 support

[Mike Hommey]

On Mon, Jan 25, 2016 at 11:57:40AM -0600, Joshua Cranmer ? wrote:
> On 1/25/2016 11:30 AM, Ehsan Akhgari wrote:
> >For example, for a long time b2g partners held back our minimum supported
> >gcc.  Now that there are no such partner requirements, perhaps we can
> >consider bumping up the minimum to gcc 4.8?  (bug 1175546)
> 
> Strictly speaking, I would advocate for 4.8.1, since that gets us ref
> qualifiers on methods (or will, once we get VS 2015 as the minimum
> requirement on Windows).

IIRC, 4.8.x < 4.8.5 (or was it 4.8.3?) miscompiles gecko anyways.

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

Re: Just Autoland It

[Eric Rescorla]

On Mon, Jan 25, 2016 at 1:58 PM, Mike Hommey  wrote:

> On Mon, Jan 25, 2016 at 11:23:59AM -0800, Steve Fink wrote:
> > Heh. Your list of UI complaints is very similar to mine. Some comments:
> >
> >
> > On 01/25/2016 04:26 AM, Honza Bambas wrote:
> > >Writing both as a patch author and a reviewer as well.
> > >
> > >- as a patch author I want a full control on when the patch actually
> lands
> > >(dependencies, any other timing reasons, that only the author knows the
> > >best), "Don't land yet" comment somewhere will easily be overlooked
> > >- as a reviewer I don't want to bare the decision to land or not to
> land,
> > >at all
> > >- I want to preserve the mechanism "r+ with comments", which means to
> let
> > >the patch be landed by the author after updated (means reviewer doesn't
> > >need to look over it again)
> > >- as an author I want to write comments about the patch (about the
> > >structure, what it does, why) to make the review simpler for the
> reviewer
> > >; commit message description may not be the best place, right?
> >
> > Yes, is there a place for this? I feel this is a really important bit of
> > functionality that would fit naturally into the mozreview world, but I
> don't
> > see how to do it. Situation: I put up a set of commits for review, and I
> > want to give per-commit notes to the reviewer that they'll see before
> > reviewing. Previously, I would put them in as comments on the bug and
> either
> > pray that the reviewer happened to see them, or ping the reviewer on IRC
> and
> > tell them to read them. In MozReview, I don't see a place to put such
> things
> > at all?
>
> It's also painful to use MozReview's comment system. The comments in the
> reviews pane don't show much diff context, and while I just realized
> it's possible to make it show more by hovering the diff part for a
> little while, it's not really great, as it doesn't actually show a diff
> view like the diff pane does, and switching to the diff pane a) is slow
> for large diffs and b) has an entirely different comment UX that doesn't
> seem really great either.
>

Indeed. It would be great if it would just include 5-8 lines of context by
default.

-Ekr


>
> Also, iirc, when you reply diff comments in MozReview, the resulting
> comments sent to bugzilla lack context (but I could be misremembering).
>
> > >- will it be possible to still be using hg patch queues?
> >
> > A valid question, though I'd not that the mq-less workflow is actually
> > pretty good these days. mq is still easier/nicer for some things, but
> doing
> > without mq is nicer in other ways, and the future leads away from mq.
> >
> > On the other hand, there still isn't a great way to figure out the
> mq-less
> > workflow. I remember a pretty good writeup from someone, and I intend to
> > write up my own. But there isn't anything that's easily discoverable.
>
> Whether or not mq is deprecated, it still uses changesets that can be
> pushed. And with a non publishing remote repository, it should still be
> able to qpop without having to fool around with the draft state.
>
> Mike
> ___
> 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: Moving FirefoxOS into Tier 3 support

[Juan Gómez]

Yeah, upgarding to gcc 4.8 was a bit tough but it established the basis for
less compllcated upgardes in the future. I could compile all FFOS flavors
(ICS, JB, KK and LL) using gcc-4.9 base toolchain without any remarcable
complication. My plan was to upgrade to gcc 4.9 [1] last year, but we had
to stop it becuase we needed the partner confirmation to move forward. Now
that we don't need that confirmation, we could resume the work and land
gcc-4.9 support.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1087161

On Mon, Jan 25, 2016 at 6:40 PM, Fabrice Desré  wrote:

> On 01/25/2016 09:30 AM, Ehsan Akhgari wrote:
>
> > For example, for a long time b2g partners held back our minimum
> > supported gcc.  Now that there are no such partner requirements, perhaps
> > we can consider bumping up the minimum to gcc 4.8?  (bug 1175546)
>
> We moved to 4.8 on b2g a year ago: see
> https://bugzilla.mozilla.org/show_bug.cgi?id=1056337
> Who's behind? :P
>
> > Another example, last year because of 2.5 release pressure where people
> > were planning on using service workers in gaia app, we had to add a huge
> > hack for "supporting" app:// URIs for service worker interception.  The
> > last time that this code bit me was earlier this morning.  It would be
> > nice if I can remove this broken code now instead of worrying about how
> > to keep supporting it going forward (this makes fixing bug 1222008 more
> > complicated than it needs to be.)
>
> I have no objections to remove this particular support.
>
> --
> Fabrice Desré
> Connected Devices
> Mozilla Corporation
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>



-- 
___
Juan Gómez Mosquera
Platform Engineer
Mozilla Corporation
_AtilA_
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: IndexedDB access in third-party iFrames disabled or not?

[Kyle Huey]

Awesome, thanks.

- Kyle

On Mon, Jan 25, 2016 at 10:56 AM, Chris Mills  wrote:

> Whoops, sorry about that. I’ve updated it now, and made sure that we don’t
> repeat this erroneous point in any other docs.
>
> Chris Mills
>  Senior tech writer || Mozilla
> developer.mozilla.org || MDN
>  cmi...@mozilla.com || @chrisdavidmills
>
> > On 25 Jan 2016, at 18:35, Kyle Huey  wrote:
> >
> > We changed this in bug 1147821.  It looks like the documentation hasn't
> > been updated.
> >
> > - Kyle
> >
> > On Mon, Jan 25, 2016 at 10:26 AM,  wrote:
> >
> >> Is IndexedDB supposed to be accessible in third-party iFrames? From
> what I
> >> understand, the MDN documentation says IndexedDB is *not* accessible in
> >> third-party iFrames, but from my own tests, I have been fully able to
> use
> >> IndexedDB in third-party iFrames.
> >>
> >> The MDN documentation link:
> >>
> https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API/Using_IndexedDB#Security
> >> Search for "It's important to note that IndexedDB doesn't work for
> content
> >> loaded into a frame"
> >>
> >> MDN links to RESOLVED FIXED Bugzilla 595307:
> >> https://bugzilla.mozilla.org/show_bug.cgi?id=595307
> >>
> >> I guess I don't really understand what the status is. I'm able to use
> >> IndexedDB in third-party iFrames, but maybe I shouldn't be able to? What
> >> are Firefox's plans for IndexedDB in third-party iFrames?
> >>
> >> If necessary, I can upload some test code. Hopefully this is the right
> >> place to ask, thanks for reading this!
> >> ___
> >> 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: Just Autoland It

[Mike Hommey]

On Mon, Jan 25, 2016 at 06:15:10PM -0500, Andrew Halberstadt wrote:
> On 25/01/16 05:44 PM, Eric Rescorla wrote:
> >On Mon, Jan 25, 2016 at 1:58 PM, Mike Hommey  wrote:
> >
> >>On Mon, Jan 25, 2016 at 11:23:59AM -0800, Steve Fink wrote:
> >>>Heh. Your list of UI complaints is very similar to mine. Some comments:
> >>>
> >>>
> >>>On 01/25/2016 04:26 AM, Honza Bambas wrote:
> Writing both as a patch author and a reviewer as well.
> 
> - as a patch author I want a full control on when the patch actually
> >>lands
> (dependencies, any other timing reasons, that only the author knows the
> best), "Don't land yet" comment somewhere will easily be overlooked
> - as a reviewer I don't want to bare the decision to land or not to
> >>land,
> at all
> - I want to preserve the mechanism "r+ with comments", which means to
> >>let
> the patch be landed by the author after updated (means reviewer doesn't
> need to look over it again)
> - as an author I want to write comments about the patch (about the
> structure, what it does, why) to make the review simpler for the
> >>reviewer
> ; commit message description may not be the best place, right?
> >>>
> >>>Yes, is there a place for this? I feel this is a really important bit of
> >>>functionality that would fit naturally into the mozreview world, but I
> >>don't
> >>>see how to do it. Situation: I put up a set of commits for review, and I
> >>>want to give per-commit notes to the reviewer that they'll see before
> >>>reviewing. Previously, I would put them in as comments on the bug and
> >>either
> >>>pray that the reviewer happened to see them, or ping the reviewer on IRC
> >>and
> >>>tell them to read them. In MozReview, I don't see a place to put such
> >>things
> >>>at all?
> >>
> >>It's also painful to use MozReview's comment system. The comments in the
> >>reviews pane don't show much diff context, and while I just realized
> >>it's possible to make it show more by hovering the diff part for a
> >>little while, it's not really great, as it doesn't actually show a diff
> >>view like the diff pane does, and switching to the diff pane a) is slow
> >>for large diffs and b) has an entirely different comment UX that doesn't
> >>seem really great either.
> >>
> >
> >Indeed. It would be great if it would just include 5-8 lines of context by
> >default.
> >
> >-Ekr
> 
> It's not terribly obvious, but instead of clicking on a line number you can
> click and drag on the numbers to set the exact amount of context you want.

Which is something for the person writing the comment to do. Also, even
when they do that, most of the time, that won't contain the surrounding
code.

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

Re: about:profiles and the new profile manager

[Karl Dubost]

Andrea,

Le 19 déc. 2015 à 02:17, Andrea Marchesini  a écrit :
> This week I landed a set of patches to introduce 'about:profiles'.

Where is the initial bug?
With the change, we got a couple of orphaned bugs related to the new profile 
manager (old-new, I should say. it's gone from nightly, back to the old one.)

https://bugzilla.mozilla.org/show_bug.cgi?id=1235832
https://bugzilla.mozilla.org/show_bug.cgi?id=1235295
https://bugzilla.mozilla.org/show_bug.cgi?id=1235284

-- 
Karl Dubost, Mozilla
http://www.la-grange.net/karl/moz

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

Re: Moving FirefoxOS into Tier 3 support

[Ehsan Akhgari]

On 2016-01-25 5:59 PM, Juan Gómez wrote:

Yeah, upgarding to gcc 4.8 was a bit tough but it established the basis
for less compllcated upgardes in the future. I could compile all FFOS
flavors (ICS, JB, KK and LL) using gcc-4.9 base toolchain without any
remarcable complication. My plan was to upgrade to gcc 4.9 [1] last
year, but we had to stop it becuase we needed the partner confirmation
to move forward. Now that we don't need that confirmation, we could
resume the work and land gcc-4.9 support.


That would be wonderful!

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