Re: Flash and e10s
On Wed, Aug 7, 2013 at 6:05 PM, Markus Stange msta...@themasta.com wrote: On 07.08.13 06:39, Robert O'Callahan wrote: Running windowed Flash within the content process itself would mean giving that content process access to the main window's HWND. What would be the disadvantages of forcing wmode=transparent for content process flash? That might help. The other issues are still serious. 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
Re: Flash and e10s
On 8/6/2013 8:46 PM, Robert O'Callahan wrote: I was talking to people about plans for Flash on e10s. Who were you talking to? John Schoenick currently owns that bug, although I don't think he's working on it yet. We've talked about it on an off. Full support for windowed Flash on e10s is possible but would be a ton of work. Flash is on a downward trajectory and it would be a shame to do a ton of work to support something that may not be relevant for much longer. The primary reason I know for windowed Flash to be a huge PITA is because of the deadlock issues caused by attached input queues. I'd love to force Flash to be windowless and use our fullscreen support instead of their own windows, because this would fix many of the deadlock issues. What other issues are you concerned about specifically? One idea I had is this: suppose, independently of e10s, we make Flash click-to-play. (I understand this is already a goal, or at least a wish.) It is neither a goal nor feasible. We did user research into this at the beginning of the year, and there is enough hidden Flash out on the web that click to play is just too confusing for the average user. Having a master plugin process and connecting all the content processes to seems like a fairly well-understood problem. It's work, and it's not work I want do until we're sure we're committing to e10s in desktop Firefox. But I don't think it presents such a technical barrier that we should attempt to work around it so drastically in the UI. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Removing support for OS/2
пятница, 2 августа 2013 г., 3:13:23 UTC+4 пользователь Gregory Szorc написал: Are there any objections to this proposal? Hello everybody, I'm the person who's being actively working now on getting Mozilla build on OS/2 again with all the new IPC stuff in. As Peter said, at the present time we have no plans to push our patches but that's only because from my experience this process is very complex and we have very limited resources for working on that task (no surprise). So our idea is to get it all working again first, then create a smaller number of bigger (and logically consistent) patches and try to push them upstream — while still continuing development in our own repo so that we don't depend on how fast the patches are accepted etc. If anybody has a better idea, we are ready to consider it. What about switching the build system, it's not our primary task of course but it will be done sooner or later — this is all to have a more robust build environment and thus save some resources here too. An ideal solution for us in the future would be to put the build files of the new build system (Makefile.kmk, generally one per each subdir) upstream but I'm not sure if it will ever be accepted — this is another reason why we decided to stick to our own repo for the time being. In either case, removing OS/2 support from the existing makefiles - may be done (but better after we completely move away to kBuild). Regarding the main subject. There are many OS/2 parts that are still valid (e.g. the NSPR code) so if you will drop them we will have to reapply them back in our repo. And if we push it back later you will have to reapply them again. This doesn't make sense to me — if you are going to accept our patches at some later stage. If you are certainly not, then you may go on with that. I'm also ready to listen to any other ideas on how we can collaborate in this case. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Removing support for OS/2
On 8/7/13 1:00 PM, d...@dmik.org wrote: What about switching the build system, it's not our primary task of course but it will be done sooner or later — this is all to have a more robust build environment Why does the OS/2 port need a different build system? I'm not familiar with OS/2 development, but is GNU Make not an option? chris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Removing support for OS/2
четверг, 8 августа 2013 г., 0:48:04 UTC+4 пользователь Chris Peterson написал: Why does the OS/2 port need a different build system? I'm not familiar with OS/2 development, but is GNU Make not an option? If it were only GNU Make it wouldn't be such a problem (we have quite a recent GNU Make port). But it's not, most problems come from the autoconf side and the tool chain expected by it. OS/2 is not *nix and not all tools are at current versions (some are not maintained at all). There are also many problems related to the ltmain script hell as well. Also, things on OS/2 are pretty much constant to the extent that many configure tests are redundant and just waste build time. Besides that, there are several things about the way how the original build system is structured that I don't like. One of them is putting many headers to the build dir instead of including them from their original locations which requires to run the build process from the root when one of these headers is changed (in order to re-export it) which is quite time consuming. In general, partial building from subdirectories (which I use very often during my development) is not well supported. kBuild solves all these problems. It's a much more clean (and usually also a faster) solution. I'd wish to see Mozilla moved to it cross platform -) (well, it will actually be a piece of cake once the switch for OS/2 is done — kBuild is cross-platform per se and includes a tool chain for each supported platform). ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Flash and e10s
On Thu, Aug 8, 2013 at 2:14 AM, Benjamin Smedberg benja...@smedbergs.uswrote: The primary reason I know for windowed Flash to be a huge PITA is because of the deadlock issues caused by attached input queues. I'd love to force Flash to be windowless and use our fullscreen support instead of their own windows, because this would fix many of the deadlock issues. That would be nice. What other issues are you concerned about specifically? Managing window geometry from the master process is going to be a bit of a pain, since we'll have to combine information from the content process(es) with information about the geometry and visibility of the browsing context. It's doable though. One idea I had is this: suppose, independently of e10s, we make Flash click-to-play. (I understand this is already a goal, or at least a wish.) It is neither a goal nor feasible. We did user research into this at the beginning of the year, and there is enough hidden Flash out on the web that click to play is just too confusing for the average user. OK, that's very good to know. That scotches my idea. Thanks! 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
Re: Flash and e10s
Mozilla proposed the NPAPI changes to get rid of windowed plug-ins [1] but there wasn't a big enough reason to change the Flash Player at that time--the threat of content breakage wasn't that high. If content breakage is certain via multi-process with windowed plug-ins, then Adobe will likely be more motivated to make the changes. Should I get a call going over there? --Jet [1]https://wiki.mozilla.org/NPAPI:AsyncDrawing - Original Message - From: Robert O'Callahan rob...@ocallahan.org To: Benjamin Smedberg benja...@smedbergs.us Cc: dev-platform@lists.mozilla.org, John Schoenick jo...@mozilla.com, Bill McCloskey wmcclos...@mozilla.com Sent: Wednesday, August 7, 2013 2:20:05 PM Subject: Re: Flash and e10s On Thu, Aug 8, 2013 at 2:14 AM, Benjamin Smedberg benja...@smedbergs.uswrote: The primary reason I know for windowed Flash to be a huge PITA is because of the deadlock issues caused by attached input queues. I'd love to force Flash to be windowless and use our fullscreen support instead of their own windows, because this would fix many of the deadlock issues. That would be nice. What other issues are you concerned about specifically? Managing window geometry from the master process is going to be a bit of a pain, since we'll have to combine information from the content process(es) with information about the geometry and visibility of the browsing context. It's doable though. One idea I had is this: suppose, independently of e10s, we make Flash click-to-play. (I understand this is already a goal, or at least a wish.) It is neither a goal nor feasible. We did user research into this at the beginning of the year, and there is enough hidden Flash out on the web that click to play is just too confusing for the average user. OK, that's very good to know. That scotches my idea. Thanks! 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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Standard C/C++ and Mozilla
(Sorry for the late reply, please blame it on Canadian statutory holidays, and my birthday date!) On Fri, Aug 2, 2013 at 11:09 PM, Brian Smith br...@briansmith.org wrote: On Sat, Aug 3, 2013 at 12:47 AM, Ehsan Akhgari ehsan.akhg...@gmail.comwrote: On 2013-08-02 5:21 PM, Brian Smith wrote: 3. How should we handle bridge support for standardized features not yet universally-implemented? Generally, I would much rather we implement std::whatever ourselves than implement mozilla::Whatever, all other things being equal. Yes, but it's still not clear to me why you prefer this. 1. It avoids a phase of mass rewrites s/mozilla:Whatever/std::whatever/. (See below). 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. As Jeff mentioned, I think it's more important that we expect developers to read and believe the documentation where it exists. The MFBT code is very well documented, and the documentation is usually in sync with the implementation. That is already a huge improvement over the newer std::* stuff. std::auto_ptr is perhaps the biggest example of people not reading documentation about std::* stuff. ;-) But more importantly, as others mentioned, the fact that something lives in the std namespace doesn't mean that it adheres to the C++ standard. So it seems to me like you're assuming that code living in the std namespace is bug free, but that's not true. And when something lives in the std namespace, fixing it is very difficult. But for whatever it's worth, I think that in general, for the std replacement code living in MFBT, it's best for us to try really hard to match the C++ standard where it makes sense. We sometimes go through a crazy amount of pain to do that (see my patch in bug 802806 as an example!). But if something doesn't make sense in the C++ standard or is not fit for our needs, we should do the right thing, depending on the case at hand. This saves us from the massive rewrites later to s/mozilla::Whatever/std::**whatever/; while such rewrites are generally a net win, they are still disruptive enough to warrant trying to avoid them when possible. Disruptive in what sense? I recently did two of these kinds of conversions and nobody complained. You have to rebase all your patches in your patch queue and/or run scripts on your patches (that, IIRC, don't run on windows because mozilla-build doesn't have sed -i). I'm not complaining about the conversions you've done, because they are net wins. But, it's still less disruptive to avoid unnecessary rounds of rewrites when possible, and s/mozilla::Whatever/std::whatever/ seems unnecessary to me when we could have just named mozilla::Whatever std::whatever to start with. I agree that huge refactorings can be a pain. I've been trying to do that in smaller chunks to alleviate some of the pain (see bug 784739 as an example.) If you see people making unjustified huge changes without prior discussion, you should definitely object! But then again I don't find this argument very convincing in this particular case. I hope that this discussion has provided some good reasons why implementing out mozilla::Whatever sometimes makes sense. And later on when we decide to switch to std::whatever, I'd consider such a rewrite a net win because it makes our code easier to approach by people familiar with std::whatever. About the mozilla-build sed issue, that is really really surprising/disappointing -- I'd have expected that we ship GNU sed there? Even bsd sed on Mac supports -i. Please file a bug about this with more details. Cheers, -- Ehsan http://ehsanakhgari.org/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
