Re: Proposal: New BMO Toolkit component for Notifications and Alerts
The component was added in https://bugzilla.mozilla.org/show_bug.cgi?id=1013763 and it was pointed out that I was originally missing the prompt service from the list of related code so that has now been added to the description. I've done some bulk moves of open bugs so the component now has about 120 of them (this was done fairly quickly to seed the component). You can filter bugmail on notifications-and-alerts-component to find the changes from the bulk move (e.g. to mark them as read). Current bug list: https://bugzilla.mozilla.org/buglist.cgi?component=Notifications and Alertsproduct=Toolkitbug_status=__open__ A reminder to watch the component and/or update saved searches if that's relevant to you. Happy bug filing/triaging! Matthew N. :MattN ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
e10s: don't call it a comeback
In case you missed Blake Kaplan's announcement at Mozilla's All-Hands meeting a couple weeks ago, allow me to introduce the expanding e10s engineering team! e10s is a priority for Mozilla's engineering management and they are dedicating more help to make it happen. We've picked up some Firefox Metro engineers looking for new homes, new engineering manager, a Google Summer of Code student, and a gfx contractor. So expect to see more progress and more review requests. :) Our current team roster (in alphabetical order): * Ally Naaktgeboren * Bill McCloskey * Blake Kaplan * Brad Lassey, engineering manager * Chris Peterson, program manager * David handyman Parks, contractor dedicated to e10s gfx issues * Jim Mathies * Mike Conley * Tom evilpie Schuster * Tomislav zombie Jovanovic, GSoC student + Sid Stamm's team working on sandboxing + some new volunteer contributors with first patches :D You can test e10s in its own window, like Private Browsing, using the Nightly channel's File New e10s Window menu item. When reporting e10s bugs, please set the tracking-e10s bug flag to ? so we will see your bug in our triage meeting! chris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Link coloring in private browsing (Was: Intent to ship: Hyperlink Auditing (a ping))
On 20.05.2014 23:33, Ehsan Akhgari wrote: On 2014-05-20, 2:25 PM, Jonas Sicking wrote: On Fri, May 16, 2014 at 7:45 AM, Justin Dolske dol...@mozilla.com wrote: However we do implement some additional features in private browsing mode. For example we disable link coloring. I'm not sure what the exact goal of that is. I always guessed that it is to enable you to be extra private about your identity while in private browsing. So that might provide an argument for disabling a ping in private browsing. The goal of disabling link coloring was IIRC to disable websites from being able to run attacks against your browsing history to be able to correlate your browsing sessions like I said above. A smaller reason was that because we don't store history items from private navigations, the link coloring might not work in surprising ways to the user. This was before dbaron's general fix for that issue, I don't actually think we need to keep doing that any more, but nobody has complained about that yet. :-) FWIW I'd like to keep colored links out of private browsing, which is a guest mode benefit: Somebody else using a private browsing window on your computer can't immediately see which websites you visit. (I know private browsing isn't intended to be a guest mode) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: navigator.hardwareConcurrency
On 21.05.2014 01:27, Rik Cabanier wrote: Likewise here. I don't think anyone is saying that hardwareConcurrency is failing on the grounds of exposing too much system information alone. The way I read this thread, people either aren't convinced that it's the right compromise given its usefulness, or that it's the right API for the task at hand in the first place. Yeah, I don't think anyone has the answer. My thoughts are that if this proposed feature works on other platforms, why not here? I understand Ehsan's points but they can be made to any other platform where this is used successfully (ie photoshop, parallel builds, web servers, databases, games, etc) I don't understand people's assertions why the web platform needs to be different. It's generally expected that native applications need to be updated, recompiled or completely rewritten after some time as platforms and hardware architectures change. (Microsoft traditionally tries hard to keep Windows backward compatible, but this is only ever a compromise and doesn't work universally.) This is not how the Web is supposed to work -- Web technology needs to be forward compatible. People have previously pointed out that navigator.hardwareConcurrency could become increasingly meaningless if not harmful in the foreseeable future. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: e10s: don't call it a comeback
I _almost_ did a little dance in my room to celebrate this news, it’s such a valuable project for Firefox! Please sign me up for any find bar related bugs, Tom and I worked on it before anyways. Go get ‘em and… have fun! Mike. On 21 May 2014, at 09:11, Chris Peterson cpeter...@mozilla.com wrote: In case you missed Blake Kaplan's announcement at Mozilla's All-Hands meeting a couple weeks ago, allow me to introduce the expanding e10s engineering team! e10s is a priority for Mozilla's engineering management and they are dedicating more help to make it happen. We've picked up some Firefox Metro engineers looking for new homes, new engineering manager, a Google Summer of Code student, and a gfx contractor. So expect to see more progress and more review requests. :) Our current team roster (in alphabetical order): * Ally Naaktgeboren * Bill McCloskey * Blake Kaplan * Brad Lassey, engineering manager * Chris Peterson, program manager * David handyman Parks, contractor dedicated to e10s gfx issues * Jim Mathies * Mike Conley * Tom evilpie Schuster * Tomislav zombie Jovanovic, GSoC student + Sid Stamm's team working on sandboxing + some new volunteer contributors with first patches :D You can test e10s in its own window, like Private Browsing, using the Nightly channel's File New e10s Window menu item. When reporting e10s bugs, please set the tracking-e10s bug flag to ? so we will see your bug in our triage meeting! chris ___ 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: Can we remove NS_HIDDEN, NS_HIDDEN_(...)?
Android and B2G got fixed to use #pragma GCC visibility. So, we can go ahead and remove all NS_HIDDEN-related code now. This also means that when modifying Android and B2G-specific code that uses symbols imported from other dynamic libraries, you will need to add to config/system-headers (when including system libraries) or add MOZ_EXPORT to the declarations you're importing (e.g. if you're forward-declaring a class name that's defined in a system header). Rob -- Jtehsauts tshaei dS,o n Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.rt sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
[DEPRECATED] Apple OSX QTkit API dependencies
Hi, Mozilla code base (still) relies on OSX QuickTime API. But, this API was deprecated by Apple a few months ago. As a consequence: * New Mozilla based app. are not accepted anymore in OSX app. store * Apple moving pretty fast forward, Mozilla code might be unable to run on future OSX major release. I don't have found much about Mozilla agenda on this topic. Does someone have more information? Regards Emmanuel -- Kiwix - Wikipedia Offline more * Web: http://www.kiwix.org * Twitter: https://twitter.com/KiwixOffline * more: http://www.kiwix.org/wiki/Communication ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: e10s: don't call it a comeback
Benoit Jacob has also recently joined the team. -Brad On 5/21/14, 3:11 AM, Chris Peterson wrote: In case you missed Blake Kaplan's announcement at Mozilla's All-Hands meeting a couple weeks ago, allow me to introduce the expanding e10s engineering team! e10s is a priority for Mozilla's engineering management and they are dedicating more help to make it happen. We've picked up some Firefox Metro engineers looking for new homes, new engineering manager, a Google Summer of Code student, and a gfx contractor. So expect to see more progress and more review requests. :) Our current team roster (in alphabetical order): * Ally Naaktgeboren * Bill McCloskey * Blake Kaplan * Brad Lassey, engineering manager * Chris Peterson, program manager * David handyman Parks, contractor dedicated to e10s gfx issues * Jim Mathies * Mike Conley * Tom evilpie Schuster * Tomislav zombie Jovanovic, GSoC student + Sid Stamm's team working on sandboxing + some new volunteer contributors with first patches :D You can test e10s in its own window, like Private Browsing, using the Nightly channel's File New e10s Window menu item. When reporting e10s bugs, please set the tracking-e10s bug flag to ? so we will see your bug in our triage meeting! chris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: using namespace
On 2014-05-21, 7:40 AM, Nicolas Silva wrote: Sorry, my example was not clear enough. The issue with using namespace + unifoed builds is that the using namespace declaration applies to all (or most) of the headers included in the unified translation unit. So using namespace mozilla at the top of each .cpp is harmless until we include third party libraries, which we do. This build failure is a conflict between our gfx:: classes and some defined by 3rd party libraries we use on Mac. This is really not a style problem. It breaks builds. Yes, I understand this problem. It's basically why our style guide says using namespace ...; is only allowed in .cpp files after all #includes., it tries to protect you from this problem. The only thing that changes in the context of unified builds, is that adding a using namespace statement after the #includes in one .cpp file may be putting it before the #includes in the next file. For the concrete case at hand, I think the simplest fix is to put the code inside those .cpp files in the mozilla::gfx namespace if they belong there, and avoid |using namespace mozilla::gfx;| elsewhere. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Link coloring in private browsing (Was: Intent to ship: Hyperlink Auditing (a ping))
On 2014-05-21, 4:38 AM, Frederik Braun wrote: On 20.05.2014 23:33, Ehsan Akhgari wrote: On 2014-05-20, 2:25 PM, Jonas Sicking wrote: On Fri, May 16, 2014 at 7:45 AM, Justin Dolske dol...@mozilla.com wrote: However we do implement some additional features in private browsing mode. For example we disable link coloring. I'm not sure what the exact goal of that is. I always guessed that it is to enable you to be extra private about your identity while in private browsing. So that might provide an argument for disabling a ping in private browsing. The goal of disabling link coloring was IIRC to disable websites from being able to run attacks against your browsing history to be able to correlate your browsing sessions like I said above. A smaller reason was that because we don't store history items from private navigations, the link coloring might not work in surprising ways to the user. This was before dbaron's general fix for that issue, I don't actually think we need to keep doing that any more, but nobody has complained about that yet. :-) FWIW I'd like to keep colored links out of private browsing, which is a guest mode benefit: Somebody else using a private browsing window on your computer can't immediately see which websites you visit. Sure they can. Cmd+Shift+H is right at their fingertips in private windows, among tons of other UI we have for exposing history. (I know private browsing isn't intended to be a guest mode) Yeah, PB is many things to many different people for the better or worse. :-) That being said, I'm not planning to change the link coloring behavior for now, and if someone writes a patch, I'll need to think more before deciding whether or not to take it! Cheers, Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Update on sheriff-assisted checkin-needed bugs
One issue I often run into is that the contributor doesn't have access to try, and pushing it on their behalf disrupts the rhythm of the other things I'm doing. From http://www.mozilla.org/hacking/commit-access-policy/ Level 1 - Try/User/Incubator Access Because this is all it gives, this sort of access can be given out generously to anyone who would find it convenient when helping us or working on a developer's personal project, without worrying about them affecting core code. In other words, the target audience for this sort of access might be defined as friends of and collaborators with Mozilla. At least to me, that reads as vouch early and vouch often!. Something something...teach a man to fish...something something... :) -Ryan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Update on sheriff-assisted checkin-needed bugs
On Wed 21 May 2014 08:42:28 AM PDT, Ryan VanderMeulen wrote: Level 1 - Try/User/Incubator Access Because this is all it gives, this sort of access can be given out generously to anyone who would find it convenient when helping us or working on a developer's personal project, without worrying about them affecting core code. In other words, the target audience for this sort of access might be defined as friends of and collaborators with Mozilla. At least to me, that reads as vouch early and vouch often!. Something something...teach a man to fish...something something... :) I think the quote you're looking for is, if you teach a man to fish, you'd better teach him how to gut and clean the fish at the same time. Otherwise you'll be forever stuck doing it for him. Or not. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: [DEPRECATED] Apple OSX QTkit API dependencies
On 21/05/14 12:35 PM, Justin Dolske wrote: As a consequence: * New Mozilla based app. are not accepted anymore in OSX app. store * Apple moving pretty fast forward, Mozilla code might be unable to run on future OSX major release. The first isn't a significant concern, since Firefox isn't in the OSX App Store. But something not working in a future OS X release is. Apple doesn't remove deprecated APIs unless they change the architecture, ie a different ABI. For example all the previous round of deprecated API in 10.6 got removed *only* for x86_64 - marked is unavailable in 64bits. They are still present in i386 (32bits) So the only risk is that the next iteration of the ABI will make the code not buildable for it. We are still pretty much on the safe side for the ABI (architectures) we support: i386 and x86_64 on MacOS X. Hub ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: [DEPRECATED] Apple OSX QTkit API dependencies
On 21.05.2014 18:35, Justin Dolske wrote: On 5/21/14, 3:08 AM, Emmanuel Engelhart wrote: Mozilla code base (still) relies on OSX QuickTime API. But, this API was deprecated by Apple a few months ago. Which APIs? Can you be more specific? I don't have more information given by the Apple OSX App store automatic checker. But it seems the Mozilla codes uses this API for many things linked to video stuff: https://mxr.mozilla.org/mozilla-central/search?find=%2Fstring=QTKit Emmanuel -- Kiwix - Wikipedia Offline more * Web: http://www.kiwix.org * Twitter: https://twitter.com/KiwixOffline * more: http://www.kiwix.org/wiki/Communication ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed changes to autocomplete administrative levels
There are existing libraries that can transform tokenized fields to postal-compatible blobs; engineers at Google have referred us to libaddressinput [5]. However, this API seems incomplete. For example, the CN query at [6] lists only city and state as required administrative levels, whereas the comments at [3] suggest that there should be three. An update: I posted this question to https://groups.google.com/forum/#!topic/libaddressinput-discuss/sXHUQGtlwnI , and it looks like this problem is even more complex than originally described. Apparently, administrative levels are not even country-specific, so our UI needs to be responsively designed such that sub-levels are determined only after a higher level is selected. On the upside, assuming the data supplied by libaddressinput is correct, it looks like all of this data is already available to us if we want to use it. Brian ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Update on sheriff-assisted checkin-needed bugs
On Wed, May 21, 2014 at 9:33 AM, Steve Fink sf...@mozilla.com wrote: On Wed 21 May 2014 08:42:28 AM PDT, Ryan VanderMeulen wrote: Level 1 - Try/User/Incubator Access Because this is all it gives, this sort of access can be given out generously to anyone who would find it convenient when helping us or working on a developer's personal project, without worrying about them affecting core code. In other words, the target audience for this sort of access might be defined as friends of and collaborators with Mozilla. At least to me, that reads as vouch early and vouch often!. Something something...teach a man to fish...something something... :) I think the quote you're looking for is, if you teach a man to fish, you'd better teach him how to gut and clean the fish at the same time. Otherwise you'll be forever stuck doing it for him. Is it really the most effective learning experience and use of everyone's time to make first-patch contributors get set up with try access? I try to mentor as many bugs as possible. My ideal workflow would be to grant r+, suggest a try: string, and set checkin-needed in a single act, without having to determine whether the contributor has try access and/or editbugs. If we already have people scanning for checkin-needed and looking for try pushes, it seems pretty logical to have them just trigger any missing pushes. bholley ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: [DEPRECATED] Apple OSX QTkit API dependencies
On 2014-05-21 9:56 AM, Emmanuel Engelhart wrote: checker. But it seems the Mozilla codes uses this API for many things linked to video stuff: https://mxr.mozilla.org/mozilla-central/search?find=%2Fstring=QTKit This is all video capture code for WebRTC. What API does Apple recommend instead? It's also worth reporting this upstream at webrtc.org, since that codebase *is* used in a number of iOS applications. -r ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Web APIs documentation meeting Friday at 9 AM PDT
The Web APIs documentation meeting is Friday at 9 AM Pacific Time. Everyone's welcome to attend; if you're interested in ensuring that Web APIs are properly documented, we'd love your input. We have an agenda, as well as details on how to join, here: https://etherpad.mozilla.org/WebAPI-docs-2014-05-23. If you have topics you wish to discuss, please feel free to add them to the agenda. We look forward to seeing you there! -- Eric Shepherd Developer Documentation Lead Mozilla Blog: http://www.bitstampede.com/ Twitter: @sheppy ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Update on sheriff-assisted checkin-needed bugs
I try to mentor as many bugs as possible. My ideal workflow would be to grant r+, suggest a try: string, and set checkin-needed in a single act, without having to determine whether the contributor has try access and/or editbugs. If we already have people scanning for checkin-needed and looking for try pushes, it seems pretty logical to have them just trigger any missing pushes. Or, alternatively, attempt to automate this with Autoland (https://bugzilla.mozilla.org/show_bug.cgi?id=657828). I think we should lean on that for this use case, personally. On 21/05/2014 3:29 PM, Bobby Holley wrote: On Wed, May 21, 2014 at 9:33 AM, Steve Fink sf...@mozilla.com wrote: On Wed 21 May 2014 08:42:28 AM PDT, Ryan VanderMeulen wrote: Level 1 - Try/User/Incubator Access Because this is all it gives, this sort of access can be given out generously to anyone who would find it convenient when helping us or working on a developer's personal project, without worrying about them affecting core code. In other words, the target audience for this sort of access might be defined as friends of and collaborators with Mozilla. At least to me, that reads as vouch early and vouch often!. Something something...teach a man to fish...something something... :) I think the quote you're looking for is, if you teach a man to fish, you'd better teach him how to gut and clean the fish at the same time. Otherwise you'll be forever stuck doing it for him. Is it really the most effective learning experience and use of everyone's time to make first-patch contributors get set up with try access? I try to mentor as many bugs as possible. My ideal workflow would be to grant r+, suggest a try: string, and set checkin-needed in a single act, without having to determine whether the contributor has try access and/or editbugs. If we already have people scanning for checkin-needed and looking for try pushes, it seems pretty logical to have them just trigger any missing pushes. bholley ___ 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: Update on sheriff-assisted checkin-needed bugs
On 5/21/14, 1:51 PM, Mike Conley wrote: Or, alternatively, attempt to automate this with Autoland (https://bugzilla.mozilla.org/show_bug.cgi?id=657828). Is anyone actively working on Autoland? Rail had been working on Autoland, but when I spoke with him in 2013 Q4, I think he said he would not have time to work on it in 2014 Q1. For a tool as important and often requested as Autoland, we should get it on someone's schedule. :) chris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: [DEPRECATED] Apple OSX QTkit API dependencies
On Wed, May 21, 2014 at 10:22:44PM +0200, Emmanuel Engelhart wrote: On 21.05.2014 21:59, Ralph Giles wrote: On 2014-05-21 9:56 AM, Emmanuel Engelhart wrote: checker. But it seems the Mozilla codes uses this API for many things linked to video stuff: https://mxr.mozilla.org/mozilla-central/search?find=%2Fstring=QTKit This is all video capture code for WebRTC. What API does Apple recommend instead? It's also worth reporting this upstream at webrtc.org, since that codebase *is* used in a number of iOS applications. More Details are given about the deprecated API in 10.9 here (see Deprecated Frameworks paragraph) https://developer.apple.com/library/mac/releasenotes/MacOSX/WhatsNewInOSX/Articles/MacOSX10_9.html Extract The QuickTime and QTKit frameworks are superseded by AV Kit and AV Foundation. More information about transitioning code: https://developer.apple.com/library/mac/technotes/tn2300/_index.html#//apple_ref/doc/uid/DTS40012852 Introduced in OS X 10.7 You can't make a 10.6-compatible build with this. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Update on sheriff-assisted checkin-needed bugs
On 2014-05-21, 5:15 PM, Chris Peterson wrote: On 5/21/14, 1:51 PM, Mike Conley wrote: Or, alternatively, attempt to automate this with Autoland (https://bugzilla.mozilla.org/show_bug.cgi?id=657828). Is anyone actively working on Autoland? Rail had been working on Autoland, but when I spoke with him in 2013 Q4, I think he said he would not have time to work on it in 2014 Q1. For a tool as important and often requested as Autoland, we should get it on someone's schedule. :) I think Taras knows more details. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Do we still need Trace Malloc?
On Mon, May 19, 2014 at 5:32 PM, L. David Baron dba...@dbaron.org wrote: There are some things that I do with trace-malloc that I'm not sure if the other tools do. I've filed https://bugzilla.mozilla.org/show_bug.cgi?id=1014341 for removing trace-malloc. Please add any dependencies that I've missed. Thanks! Nick ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
