Re: Intent to deprecate: MacOS 10.6-10.8 support
On 10/03/16 06:17 PM, Trevor Saunders wrote: > given they haven't upgraded from 10.6 - 10.8 why do you believe they are > likely to in the future? 1. their machine can die and they'll replace it with a new one that will come with the latest MacOS, and restore their data from a Time Machine backup. 2. they have some software that is important that require an update so they will update - and since only updating to that latest OS is easy, that's what they'll pick. Hub ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Rewriting YouTube's Flash video embedding code to use HTML video?
Disclaimer: I wrote the Firefox add-on mentioned, and I filed the bug mentioned as well. So my opinion is sorta made. On 21/08/15 06:17 PM, Chris Peterson wrote: Does Gecko have a precedent for rewriting certain HTML patterns? YouTube is migrating from Flash to HTML video, but many third-party websites copied YouTube's old example code to embedded Flash videos. YouTube's current embedding code automatically switches between Flash and HTML video, but YouTube can't fix third-party websites still using the old embedding code. Bug 769117 discusses whether Gecko should detect YouTube's old embedding boilerplate and automatically rewrite it to use the current code. Firefox and Safari extensions [1] [2] already do this, but should Gecko include this feature directly? It would improve users' video experience and fix dead links if/when Firefox or YouTube stop supporting Flash. OTOH, this is a site-specific workaround and thus might not belong in Gecko itself. It think that it is a feature that could be implemented in Firefox: 1. make it so that the rules are rewritable without updating the browser, or at least touching the core. ESR comes to mind as a reason why we'd love to update these. 2. make it cross platform. Mobile (including FirefoxOS) would completely benefit from that. Case in point, Safari on iOS has been doing that for a very long time. 3. don't make it specific to YouTube but specific to Flash. no-flash supports Dailymotion (the French YouTube) and Vimeo (rarer since they have done HTML5 embed for even longer). With 1. we can add rules easily. As for the question if Gecko has a feature, maybe that's where we implement it. I'm not sure if that's a feature to expose in the wild or not but given that we can do it with add-ons, and there are a few concrete use cases, we can possibly think of making this of general usefulness. Just my CAD$0.02 Hub ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Rewriting YouTube's Flash video embedding code to use HTML video?
On 21/08/15 07:52 PM, Chris Peterson wrote: 2. make it cross platform. Mobile (including FirefoxOS) would completely benefit from that. Case in point, Safari on iOS has been doing that for a very long time. Do you know what Safari is rewriting? I assume it's more than just Flash videos. It does a bit more, not sure exactly why. This is on iOS 8. For a Youtube video embedded in Flash, it replaces with the iframe, or a reasonbly looking substitute. To that it also will put its own video controller on video playback - losing the benefit of the rest of the Youtube bells and whistle. This is not only for Youtube but for HTML5 in general. Also I do believe they never autoplay (yay!) Note that Apple made the choice to not show a Flash placeholder - just empty space - which is IMHO bad. Cheers, Hub ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Can we make a plan to retire Universal Mac builds?
On 06/08/15 09:31 PM, Syd Polk wrote: If the chip is a Core 2 Duo, yes. If the chip is a Core Duo (32-bit chip), no. But these system aren't supported by MacOS X 10.7 or later. Also the 32-bits kernel is used for older machine that have a 64-bits CPU but not 64-bits UEFI firmware and gets restricted to 32-bits kernel - like the early Core2 Duo systems. You don't notice but this is done transparently to the user. Hub ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Can we make a plan to retire Universal Mac builds?
On 06/08/15 01:34 AM, Matthew N. wrote: On 2015-08-05 4:28 PM, Martin Thomson wrote: On Wed, Aug 5, 2015 at 3:59 PM, Matthew N. ma...@mozilla.com wrote: If we have data on CPU architecture I don't think the OS version is relevant unless I'm missing something. My understanding is that OS version is all that matters. 64-bit apps require a 64-bit OS. (Such an OS requires a 64-bit processor of course.) All of our supported versions of OS X can run on 64-bit hardware[1] though AFAICT. [1] Platforms:IA-32, x86-64[2] https://en.wikipedia.org/wiki/Mac_OS_X_Snow_Leopard But Only 10.7 and later can NOT run on 32-bits hardware. Which mean that unless we require 10.7, there is still a possibility the users run a machine that is not 64-bits capable, hence not able to run a 64-bits build of Firefox. Hub ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Use of 'auto'
On 02/08/15 07:17 AM, smaug wrote: Probably we should generally avoid using constructor directly for those cases. Instead, use helper functions like MakeUnique() or MakeAndAddRef(), which is much safer. MakeAndAddRef would have the same problem as MakeUnique. Doesn't really tell what type is returned. makeSomeRefCountedFoo(), newSomeRefCountedFoo() or SomeRefCountedFoo::make() returning an nsRefPtrSomeRefCountedFoo. It is a matter of having an enforced convention for naming them. And when you're dealing with lifetime management issues, you really want to know what kind of type you're playing with. This is also part of why I'd suggest having an construction method that will return a smart pointer - preventing the use of raw pointers. So that there is no ambiguity in what we deal with and its ownership. This is probably not something trivial in our codebase. Hub ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Use of 'auto'
On 02/08/15 04:55 AM, smaug wrote: A new type of error 'auto' seems to cause, now seen on m-i, is auto foo = new SomeRefCountedFoo(); That hides that foo is a raw pointer but we should be using nsRefPtr. So please, consider again when about to use auto. It usually doesn't make the code easier to read, and it occasionally just leads to errors. In this case it clearly made the code harder to read so that whoever reviewed that patch didn't catch the issue. Shouldn't we, instead, ensure that SomeRefCountedFoo() returns a nsRefPtr? Hub ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Use of 'auto'
On 02/08/15 05:57 AM, Kyle Huey wrote: On Sun, Aug 2, 2015 at 2:56 AM, Hubert Figuière h...@mozilla.com wrote: On 02/08/15 04:55 AM, smaug wrote: A new type of error 'auto' seems to cause, now seen on m-i, is auto foo = new SomeRefCountedFoo(); That hides that foo is a raw pointer but we should be using nsRefPtr. So please, consider again when about to use auto. It usually doesn't make the code easier to read, and it occasionally just leads to errors. In this case it clearly made the code harder to read so that whoever reviewed that patch didn't catch the issue. Shouldn't we, instead, ensure that SomeRefCountedFoo() returns a nsRefPtr? How do you do that with a constructor? Uh oh, my bad. As suggested by Xidorn, having a construction method (class static) and making the constructor protected, is the right way to do it. Hub ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++
On 06/07/15 11:12 PM, Jeff Gilbert wrote: I propose that we stop recommending the universal use of an 'a' prefix for arguments to functions in C and C++. If the prefix helps with disambiguation, that's fine. However, use of this prefix should not be prescribed in general. `aFoo` does not provide any additional safety that I know of.[1] As a superfluous prefix, it adds visual noise, reducing immediate readability of all function declarations and subsequent usage of the variables within the function definition. [...] I propose we strike the `aFoo` recommendation from the Mozilla style guide. I agree with this. However, if we proceed to remove this from the style guide, will we run a pass at removing the 'a' prefix or will we just let them be and have individual code change eventually clean them up? Do we have -Wshadow (or equivalent) enabled across the code base and insurance that the warnings get dealt with? Cheers, Hub ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: GTK3 linux builds
On 16/06/15 05:13 PM, Jeff Muizelaar wrote: Is there any reason not to support all the way back to the version of GTK (3.4) on the test machines? Between 3.10 and 3.14 there are bugs in the drag and drop code in Gtk3 that make Firefox (for Gtk3) unusable. https://bugzilla.mozilla.org/show_bug.cgi?id=983843 See upstream https://bugzilla.gnome.org/show_bug.cgi?id=728183 This was why I actually suggested bumping to 3.14. Also Gtk3 API story and deprecations is quite (I don't have a polite word that is appropriate) interesting: They deprecated API created in early 3.x to replace with API from later. So you get deprecation notice (there for possibly more bugs) despite the claim of API stability. And the theme support broke on a very regular basis. This would (IMHO) help the developers as well. That's just my 2¢. Hub ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Fwd: [blink-dev] Intent to Ship: Plugin Power Saver Poster Images
On 07/02/15 05:24 AM, Kyle Huey wrote: Why don't we just click to play everything? Filed this last year: https://bugzilla.mozilla.org/show_bug.cgi?id=980939 Good to see the idea finally gets traction. Hub ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: e10s is now enabled by default for Nightly!
On 06/11/14 07:27 PM, Chris Peterson wrote: [1] btw, BugzillaJS is seeking a new maintainer: https://www.yammer.com/mozillians/#/threads/show?threadId=454089406 Sadly this link require a login. Hub ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: -remote is no more
On 14/10/14 03:34 AM, Mike Hommey wrote: Hi, I landed earlier today, on mozilla-inbound, the death of the -remote option on Linux (and some other Unix). See http://hg.mozilla.org/integration/mozilla-inbound/rev/8044e5199fe2 for the detailed rationale. I invite third-party application developers to remove the part of their command line handler that handles the -remote argument for their application, if they have such support. This just break opening URL here on Fedora 20. See details at https://bugzilla.mozilla.org/show_bug.cgi?id=1080319#c12 Hub ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Disabling auto-play videos on mobile networks/devices?
On 21/08/14 01:29 PM, Wesley Johnston wrote: Summary: We've had some complaints at times about videos autoplaying on mobile devices when sites request autoplay. Just on mobile? I filed this a while ago. https://bugzilla.mozilla.org/show_bug.cgi?id=980939 It doesn't seem to have gained traction until I saw this. Autoplay is annoying Autoplay waste bandwidth, whether mobile or wifi. In some case it is more serious than other. Autoplay disturb people. Since it is possible it gets abused. Etc. 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/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: Linux Build Prerequisites
On 12/03/14 08:25 AM, saulo.a.mor...@gmail.com wrote: XUL is using Gtk2 that is a little old. Is there any plan to support a universal toolkit in XUL, like Aura from Google Chrome ? I am building a linux box based in Qt and I dont want an old GTK package just to satisfy Firefox browser, more packages means more support... You see three other solutions. 1. use Chromium instead (or non-Free Chrome) 2. use the Gtk3 port of Firefox, with all the limitation that it entails 3. use the Qt port of Firefox, if it still builds, also with all the limitation it entails Hub ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Always brace your ifs
On 22/02/14 02:53 PM, Mike Hoye wrote: On 2/22/2014, 1:04 PM, Jet Villegas wrote: goto ftw; I have to admit, I was very surprised to learn that: - Using both -Wall and -Wextra doesn't get you -Wunreachable-code. - The Clang manual lists documenting any of that that as a todo. Now we talk about enabling more warning, yet Mozilla codebase is far from building warning free Maybe we should start with that first? Hub ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Should we disable autoplay feature of HTMLMediaElement on mobile?
On 09/12/13 08:44 PM, Tetsuharu OHZEKI wrote: For mobile, this delaying approach is well for saving power. I feel this approach make sense. Power? How about not blowing through your data cap allowance or paying and other hefty charges Very few countries have cheap unlimited data over cellular. Hub ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Should we disable autoplay feature of HTMLMediaElement on mobile?
On 08/12/13 04:49 AM, Robert O'Callahan wrote: Don't these arguments apply to desktop Firefox used at work, in an Internet cafe, or in a library, as well? I think it's important to have an easy way to mute/unmute the browser, but disabling autoplay is probably not the right way to address these issues. It should be noted that here on desktop I do have `media.autoplay.enabled=false` (I hate videos that autoplay) and this still doesn't stop YouTube. [1] So while I'm all for disabling video and sound autoplay across the board, that config flag isn't enough to get rid of that nuisance. [2] I'm not sure if it is a bug or a feature, but if you tell me it is a bug, then I'll gladly file one. Hub [1] before I get told CTP, I don't have Flash, so this is only for the case the video is playable without Flash. [2] I have already noted the disagreement of opinion here. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: how long are we continuing 32-bit OS X support?
On 22/10/13 07:54 AM, Henri Sivonen wrote: so our target audience is not just 10.6 users. s/10.6/first Intel Mac Mini and first MacBook/, right? 10.6 on 64-bit CPUs runs 64-bit apps even when the kernel runs as 32-bit. Yes. That's the case. Hub ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: how long are we continuing 32-bit OS X support?
On 21/10/13 07:07 PM, Chris Peterson wrote: On 10/21/13 3:28 PM, Mike Hommey wrote: Note OS X 10.6 runs in 32-bit mode*by default*, even on *64-bit capable* hardware. That's the whole problem. There are only a few Macbook models that aren't 64-bit capable. There are much more OSX installs that run in 32-bit mode. But the boat anchor is still OSX 10.6, not the hardware? If we drop 10.6, can we assume all 10.7 and 10.8 users are running in 64-bit mode? No. it is the non 64-bits compatible hardware the 10.6 still supports. The first Intel Mac still run ia32. Hub ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: how long are we continuing 32-bit OS X support?
On 21/10/13 07:27 PM, Mike Hommey wrote: AFAIK, running 10.7+ in 32-bit mode is something you have to do manually at boot time. I guess nobody does that except for testing purpose. Also, afaik 10.7+ doesn't support 32-bit-only mac hardware. You are confusing the kernel vs the userland. If the CPU is 64-bits capable you can run apps in 64-bits when they have been compiled for it. Proof: on 10.6 on a Core 2 Duo, apps can run in 64-bits if it is provided (I have Aperture and Lightroom to prove it) but the kernel still runing in 32-bits. Bottom line: as long as we want to support 10.6 we have to provide 32-bits binaries. Hub ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
