Re: nsIDownloadManager replaced by Downloads.jsm
On 04/08/2013 1.42, Neil wrote: > So nsIDownloadManagerUI is going away too? The Downloads back-end will not call any method of nsIDownloadManagerUI anymore, new downloads should be detected using views. Technically, the interface will still be there for a short time until we refactor the code that opens the user interface (the Library window or the Downloads tab in Firefox for Desktop). > Or you could just edit the MDN pages for the interfaces that are being > removed and link to the replacements for all the relevant methods... Good idea, will do that also. Cheers, Paolo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: On indirect feedback
Although I agree fully that by far the best way of offering feedback is by talking to that person directly. I do think we have to face the fact that at this point in time a significant amount of people find it very hard to speak to people directly about things. Even when their intention is to provide constructive criticism, they will often rather avoid the confrontation for fear of creating grudges, damaging their reputation, their career, etc. It also simply takes some amount of training and social skills to deliver criticism in such a way that the target of that feedback will perceive it as the intent to improve them, rather than an attempt to simply criticize them or even bring them down. On the other hand I think it's important for everyone I think to work on both their ability and willingness to -receive- feedback, as well as to provide it. An environment where people feel comfortable talking to other people with their feedback will only really come about when people on the receiving end of feedback keep an open-mind to that feedback and treat it as an honest attempt from the other person to help them improve themselves. In that sense it's a shame we don't have a 360-degree feedback process in affect with Mozilla at the moment, I firmly believe that can positively contribute to creating an atmosphere where providing your co-workers with feedback on the things they are doing and how they're doing them is simply part of day-to-day operations. In the end as long as there's people uncomfortable/afraid/unable to share their feedback directly, it would still be a good thing if they provide that feedback to their 'leaders' (managers/module owners/etc.) as they will hopefully be able to take that feedback and use it in a meaningful way to improve others, this is part of their job after all. I think this form of indirect feedback is much preferred over building up long term irritations or simply spewing negative comments over the watercooler :-). Just my two cents, Bas - Original Message - From: "Robert O'Callahan" To: "Brian Smith" Cc: "Mozilla Product Builds" , "dev-platform" , "Gregory Szorc" Sent: Saturday, August 3, 2013 1:28:39 PM Subject: Re: On indirect feedback On Sat, Aug 3, 2013 at 12:43 PM, Brian Smith wrote: > I think some people may interpret what you say in that last paragraph the > opposite of how you intend. I am pretty sure you mean something like "If > somebody starts to complain to you about somebody else, then stop them and > ask them to first talk to the person they were trying to complain about." > Yes, that's exactly what I mean. Thanks. Rob -- Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t 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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: On builds getting slower
On 8/5/13 2:05 AM, Justin Lebar wrote: Nick, when you made changes to the JS engine's #includes, did you observe a change in build times? Just for data, when khuey just reduced the number of includes in bindings code, that did in fact affect build times. https://bugzilla.mozilla.org/show_bug.cgi?id=887533#c8 has some numbers, but the upshot is that rebuilding every single binding .cpp (equivalent of a clobber build) went from about 5 minutes to about 3 minutes. Which is still too darned long. :( -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: On indirect feedback
On 05/08/13 14:53, Bas Schouten wrote: > Although I agree fully that by far the best way of offering feedback > is by talking to that person directly. I do think we have to face the > fact that at this point in time a significant amount of people find > it very hard to speak to people directly about things. Even when > their intention is to provide constructive criticism, they will often > rather avoid the confrontation for fear of creating grudges, damaging > their reputation, their career, etc. It also simply takes some amount > of training and social skills to deliver criticism in such a way that > the target of that feedback will perceive it as the intent to improve > them, rather than an attempt to simply criticize them or even bring > them down. If we accept all that as true for the sake of argument, then it doesn't legitimise complaining to random 3rd parties. If you are unwilling to talk to someone directly, find someone who will, and approach them with a specific request to raise the issue with the person concerned. This is not as good as approaching them directly, and it should be an indicator that either you need to work on your feedback-giving or they need to work on their feedback-receiving, but it's a lot better than the other alternatives. Gerv ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
DOM Bindings Meeting - Monday @ 12:30 PM PDT
Our (ostensibly) weekly DOM bindings meetings continue on Monday August 4th at 12:30 PM PDT. Meeting details: * Monday, August 4, 2013, 12:30 PM PDT (3:30 PM EDT/9:30 PM CEST) * Conference room 7-N, San Francisco office, 7th floor. * Dial-in Info: - Vidyo room: Boris Zbarsky - In office or soft phone: extension 92 - US/INTL: 650-903-0800 or 650-215-1282 then extension 92 - Toll-free: 800-707-2533 then password 369 - Conference number 9235 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: On builds getting slower
On 8/5/13 1:46 AM, Joshua Cranmer 🐧 wrote: DOMJSProxyHandler.h [2614, #197] includes xpcpublic.h [2645, #188] includes nsIURI [3295, #121]. DOMJSProxyHandler appears to include xpcpublic.h solely for IsDOMProxy; xpcpublic.h appears to include nsIURI because it uses it as an nsCOMPtr in the CompartmentStatsExtras class it defines. The end result is that touching nsIURI will require us to rebuild all of the DOM bindings. Note that BindingUtils.h also includes xpcpublic.h, so even fixing the DOMJSProxyHandler bits wouldn't necessarily help. On the bright side, nsIURI is almost never touched, unlike xpcpublic itself. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: reminder: content processes (e10s) are now used by desktop Firefox
Justin Lebar schrieb: It's a lot better than the page a) playing audio, b) spinning your cpu, or a) pwning you. True. Still, if this is a problem (there /are/ a lot of websites which are just one big flash object), I wonder if we could detect it. Yes, I worry about those pages that are one big Flash object, or about pages which have a video as the centerpiece or such. We also get worse thumbnails than before on pages that are basically just a big login screen when you aren't actually logged in. It's pretty hard to figure out the right thing to do in cases like that, I guess (esp. on the "well, but private info can't be shown" front). Robert Kaiser ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: DOM Bindings Meeting - Monday @ 1:30 PM PDT (Note new time)
We pushed this back an hour due to the MoCo meeting today. Our (ostensibly) weekly DOM bindings meetings continue on Monday August 4th at 1:30 PM PDT. Meeting details: * Monday, August 4, 2013, 12:30 PM PDT (3:30 PM EDT/9:30 PM CEST) * Conference room 7-I, San Francisco office, 7th floor. * Dial-in Info: - Vidyo room: Boris Zbarsky - In office or soft phone: extension 92 - US/INTL: 650-903-0800 or 650-215-1282 then extension 92 - Toll-free: 800-707-2533 then password 369 - Conference number 9235 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: reminder: content processes (e10s) are now used by desktop Firefox
On 8/5/2013 9:30 AM, Robert Kaiser wrote: Justin Lebar schrieb: It's a lot better than the page a) playing audio, b) spinning your cpu, or a) pwning you. True. Still, if this is a problem (there /are/ a lot of websites which are just one big flash object), I wonder if we could detect it. Yes, I worry about those pages that are one big Flash object, or about pages which have a video as the centerpiece or such. We also get worse thumbnails than before on pages that are basically just a big login screen when you aren't actually logged in. It's pretty hard to figure out the right thing to do in cases like that, I guess (esp. on the "well, but private info can't be shown" front). Robert Kaiser Private info can't be shown is not a hard requirement here -- at least that's not the position of the Product or Privacy teams. The issue we're solving for here is over-the-shoulder privacy and we've used a pretty big hammer that we may want to back off of some. We should evaluate, possibly through telemetry or FHR, how many users are seeing the e10s thumbnails and if that number is high, I think we'll want to change the criteria for when we go to the e10s thumbnails. - A ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: NavigationController
On 26/07/13 18:29, Ehsan Akhgari wrote: > We're planning to implement a prototype of the NavigationController > interface (see bug 898524). We will try to get feedback from web > developers on the prototype and will use that feedback to change the spec > and the implementation and iterate on the API. Our major goal for now is > coming up with a good API that is useful for the intended use cases. Once > we're there, we will talk about plans to ship the API. For now, all of > this work will be disabled for web content. > > Please let me know if you have any questions! My understanding is that we wanted to implement this feature on top of Event Pages. Is there any plan to implement this too? -- Mounir ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: NavigationController
On Monday, August 5, 2013 10:01:06 AM UTC-7, Mounir Lamouri wrote: > On 26/07/13 18:29, Ehsan Akhgari wrote: > > > We're planning to implement a prototype of the NavigationController > > > interface (see bug 898524). We will try to get feedback from web > > > developers on the prototype and will use that feedback to change the spec > > > and the implementation and iterate on the API. Our major goal for now is > > > coming up with a good API that is useful for the intended use cases. Once > > > we're there, we will talk about plans to ship the API. For now, all of > > > this work will be disabled for web content. > > > > > > Please let me know if you have any questions! > > > > My understanding is that we wanted to implement this feature on top of > > Event Pages. Is there any plan to implement this too? > > > > -- Mounir I'm experimenting with this. The SharedWorker patches are crucial to this, and I've spent some time trying to get them to work on m-c, before I can start working on this. Nikhil ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
w3c touch disabled on FX24
TL;DR: Touch-scroll is broken on some high profile pages which register w3c touch events - such as google search results. w3c touch will be disabled by default starting with FX24 until it doesn't break touch scroll (bug 736048). QA will start testing touch on Firefox-desktop. w3c touch was enabled by default since Firefox-desktop 18 (for pages which register touch events, on touch-devices such as windows 7 tablets and many new windows 8 tablets/laptops). However, in recent months it was noticed that this breaks touch-scroll on some high profile pages (google search results, twitter, some MDN pages, and more). It's probable that the code didn't regress, but rather that those pages started registering for touch events, but we don't have concrete info on this. This is now bug 736048, and it currently affects FX >=22. On top of that, disabling w3c touch (which should restore touch-scroll) using the pref dom.w3c_touch_events.enabled=0 was also broken (bug 888300 - landed by Felipe, awaits uplifting approval). Bug 888304 suggests to disable w3c touch by default until it doesn't break touch-scroll, and after some discussion with ASA, Felipe landed it and it also got uplifted to FX24. Anthony Hughes from QA got into the loop and started drafting a plan for testing w3c on Firefox desktop, starting with some smoke-tests - https://wiki.mozilla.org/QA/Desktop_Firefox/Touch If you need to work with w3c touch, it can be enabled using dom.w3c_touch_events.enabled=2 , but expect broken touch-scroll on some pages. Watch bug 736048 and bug 888305 for re-enabling w3c touch by default. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
MemShrink meeting: Tuesday August 6 2013 @ 4:00pm PDT
The next MemShrink meeting will be brought to you by the Mushroomer game: http://www.areweflashyet.com/Mushroomer The wiki page for this meeting is at: https://wiki.mozilla.org/Performance/MemShrink Agenda: * Prioritize unprioritized MemShrink bugs. * Discuss how we measure progress. * Discuss approaches to getting more data. Meeting details: * Tue, 6 August, 4:00 PM PDT * Vidyo: SFO 7N Noise Pop * MTV: Very Good Very Mighty, Mountain View office, 3rd floor * SF: Noise Pop. 7th Floor * Dial-in Info: - In office or soft phone: extension 92 - US/INTL: 650-903-0800 or 650-215-1282 then extension 92 - Toll-free: 800-707-2533 then password 369 - Conference num 95704 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: On indirect feedback
I don't see a contradiction here. If the person giving feedback is skilled at doing it, the person receiving it doesn't need to be as skilled in receiving it. if the person receiving feedback is skilled at receiving, the person giving it doesn't need to be as skilled at giving it. If both are good - awesome. If neither one of them is, getting somebody to help that you think is good at it works well. If you complain to a random 3rd party, hopefully they're skilled enough to ask if you mind them helping you deliver this message. -- - Milan On 2013-08-05, at 10:23 , Gervase Markham wrote: > On 05/08/13 14:53, Bas Schouten wrote: >> Although I agree fully that by far the best way of offering feedback >> is by talking to that person directly. I do think we have to face the >> fact that at this point in time a significant amount of people find >> it very hard to speak to people directly about things. Even when >> their intention is to provide constructive criticism, they will often >> rather avoid the confrontation for fear of creating grudges, damaging >> their reputation, their career, etc. It also simply takes some amount >> of training and social skills to deliver criticism in such a way that >> the target of that feedback will perceive it as the intent to improve >> them, rather than an attempt to simply criticize them or even bring >> them down. > > If we accept all that as true for the sake of argument, then it doesn't > legitimise complaining to random 3rd parties. If you are unwilling to > talk to someone directly, find someone who will, and approach them with > a specific request to raise the issue with the person concerned. This is > not as good as approaching them directly, and it should be an indicator > that either you need to work on your feedback-giving or they need to > work on their feedback-receiving, but it's a lot better than the other > alternatives. > > Gerv > ___ > 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: reminder: content processes (e10s) are now used by desktop Firefox
On 08/03/2013 10:28 PM, Mark Hammond wrote: On 3/08/2013 5:30 AM, Philip Chee wrote: On 02/08/2013 16:57, t...@adblockplus.org wrote: The code in question was explicitly running in Firefox Mobile only. It used messageManager.loadFrameScript() API to inject code into the content process of new tabs - I doubt that it will work the same here, Adblock Plus would probably need to look explicitly for these elements (is there an event when they are created?). Altogether, supporting this in Adblock Plus should be possible - but it will require significant amounts of additional code and introduce quite a bit of new complexity. I also have doubts whether this is work that should receive priority. It has just occurred to me that Flashblock would probably be affected similarly. We ask the docShell to not allow plugins or media - so no flash should be seen anyway (which obviously some will consider a bug, but there you have it) Note that until bug 874016 lands it is unsafe to use plugins in content processes. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Standard C/C++ and Mozilla
On 08/02/2013 08:09 PM, Brian Smith wrote: > 2. It is reasonable to expect that std::whatever works as the C++ standard > says it should. It isn't reasonable to expect mozilla::Whatever to work > exactly like std::whatever. And, often, mozilla::Whatever isn't actually > the same as std::whatever. Why is this a problem? People should never assume mozilla::* is the same as std::*, unless they verify in the documentation that it is. Sometimes our documentation makes promises of compatibility (or approximate compatibility, or common-case compatibility). Usually it doesn't. Caveat lector. Reading documentation, it seems to me, has to be a baseline requirement for all Mozilla contributors. If a contributor isn't reading documentation about the classes/structures/algorithms he uses in the patches he writes, I'm scared. (Which is not to say that doc-reading is always the solution, as sometimes our docs are incoherent, scattered, or non-existent. But for this new stuff, the docs come with the code, and are a prerequisite to landing. I think we've held that line pretty well. So that's a legacy problem not relevant here.) Jeff ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
