Re: Flash and e10s
On Wed, Aug 7, 2013 at 6:05 PM, Markus Stange 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.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
Re: Flash and e10s
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? Markus ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Flash and e10s
On Wed, Aug 7, 2013 at 4:31 PM, Justin Lebar wrote: > On Tue, Aug 6, 2013 at 5:46 PM, Robert O'Callahan > wrote: > > I was talking to people about plans for Flash on e10s. > > > > 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. > > Just to be clear about our assumptions here: You think it would be a > lot of work to do anything with Flash and content processes, including > running Flash within the content process itself? > Yes. Running windowed Flash within the content process itself would mean giving that content process access to the main window's HWND. That's not really an option for sandboxing, AIUI. Also, running windowed Flash within the content process would not work with multiple content processes, AIUI. Also, running Flash in the same process as content sucks more than running it in its own process. The best option for "proper" support of Flash would probably be a Flash process hanging off the master process, with content processes granted channels to the Flash process via IPDL trickery, plus some extra work to have the content process tell the master process how to position and clip each Flash window. It's going to be complex. 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
Re: Flash and e10s
On Tue, Aug 6, 2013 at 5:46 PM, Robert O'Callahan wrote: > I was talking to people about plans for Flash on e10s. > > 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. Just to be clear about our assumptions here: You think it would be a lot of work to do anything with Flash and content processes, including running Flash within the content process itself? > 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.) > Then suppose we allowed click-to-play to reload the page. We would then be > able to ensure that any page where Flash is enabled is loaded directly in > the master process and everything would just work. That's not ideal, but > it's a fine stop-gap approach IMHO. > > As Shumway matures we could whitelist common sites where Shumway is known > to work, so those sites wouldn't need to be hoisted to the master process. > > One problem with these ideas is H.264 video sites on Windows XP. We're > stuck with using Flash there for now. We might need to impose a different > policy on Windows XP, backing off e10s more there perhaps. > > 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
Flash and e10s
I was talking to people about plans for Flash on e10s. 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. 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.) Then suppose we allowed click-to-play to reload the page. We would then be able to ensure that any page where Flash is enabled is loaded directly in the master process and everything would just work. That's not ideal, but it's a fine stop-gap approach IMHO. As Shumway matures we could whitelist common sites where Shumway is known to work, so those sites wouldn't need to be hoisted to the master process. One problem with these ideas is H.264 video sites on Windows XP. We're stuck with using Flash there for now. We might need to impose a different policy on Windows XP, backing off e10s more there perhaps. 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
Re: reminder: content processes (e10s) are now used by desktop Firefox
On 6/08/2013 2:30 AM, Robert Kaiser wrote: We also get worse thumbnails than before on pages that are basically just a big login screen when you aren't actually logged in. In the short-term, bug 897880 might help with that - it will arrange so that an error response (roughly, a non 2XX response) will not cause an existing thumbnail to be overwritten. Thus, any thumbnails taken while actually visiting the page (ie, by the "foreground" thumbnail service) should continue to be used. We make no attempt to handle sites using purely cookie-based auth (ie, sites that always return 200 responses, but still render a "please log in" page based purely on cookies). Also, I mention it may only help in the short-term as it seems possible we will end up removing the foreground service completely to avoid jank and keep all thumbnailing off the main thread/process. However, AFAIK there are no concrete plans for this. Cheers, Mark ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: nsIDownloadManager replaced by Downloads.jsm
On Saturday, August 3, 2013 8:21:57 AM UTC-4, Paolo Amadini wrote: > Hello, > > > > if you are maintaining an add-on or a Mozilla product that interacts > > with downloads, you should look into updating your code to use the new > > Downloads.jsm module instead of nsIDownloadManager as soon as possible. > > > > While other Mozilla products may migrate at different times, Firefox > > for Desktop will do so starting from version 26, meaning that add-ons > > that use methods of nsIDownloadManager will no longer be compatible > > unless updated. Firefox 26 will reach the Beta channel on October 29th, > > and will go to release on December 10th, 2013. > > > > *Overview* > > > > We have been working on this new module over the past few months, with > > the goal of eliminating any temporary unresponsiveness that could be > > observed when downloads are started, as well as making the browser more > > responsive in general while there are downloads in progress. > > > > To make this possible, we removed all access to the "downloads.sqlite" > > database, replacing it with an in-memory representation of the state > > of current downloads. In Firefox for Desktop, the history of past > > downloads is handled separately, using the "places.sqlite" database. > > > > *Changes* > > > > The new API is fully asynchronous and works somewhat differently from > > the old one. It has the advantage of being designed for JavaScript from > > the start, and is much simpler than the old XPCOM API. In particular, > > listing and handling current downloads may be done using JavaScript > > objects, without any special code for database access. > > > > The complete documentation of the module can be found here: > > > > https://developer.mozilla.org/Mozilla/JavaScript_code_modules/Downloads.jsm > > > > We may still update existing methods to address specific needs or > > new requirements, but the general mechanisms will remain the same. > > > > *Testing* > > > > A new about:config preference named "browser.download.useJSTransfer" > > enables the browser and the Downloads Panel to use the Downloads.jsm > > module instead of nsIDownloadManager as the back-end. The browser must > > be restarted for the preference to take effect. > > > > Support for this preference will be available in Nightly today or > > tomorrow. This means that it will be ready for testing in the Aurora > > channel starting from version 25, on August 8th. > > > > In the Firefox 26 release train, nsIDownloadManager will not be used > > anymore. The preference will be removed and there will be no way to > > revert to the old system that caused potential performance issues. > > We will finally be able to remove a lot of front-end code that is > > complex to maintain and only needed for backwards compatibility. > > > > *Feedback* > > > > The version of the module in Firefox 25 is still in development, and > > while the interface is complete, some features like restoring downloads > > after a restart and the related prompts are not implemented yet. The > > remaining work is tracked with dependencies of bug 847863: > > > > https://bugzilla.mozilla.org/showdependencytree.cgi?id=847863&hide_resolved=1 > > > > If you notice any unexpected behavior with the new preference that is > > not already listed there, feel free to file a new bug and mark it as > > blocking bug 847863. For any other question or need, feel free to > > reply to this thread in the relevant list (extensions or platform), > > or contact myself directly. Any relevant information emerging from > > the discussion will be summarized in a new project update. > > > > Cheers, > > Paolo I flipped on 'browser.download.useJSTransfer' and downloaded some zip files from Fx inbound and they all were zero byte files. This was done in safe mode. Hope this is a WIP ;-) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: nsIDownloadManager replaced by Downloads.jsm
Paolo Amadini schrieb: The Downloads back-end will not call any method of nsIDownloadManagerUI anymore So I cannot implement an alternative download manager any more? Robert Kaiser ___ 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
Asa Dotzler schrieb: 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. I saw a bug in a recent triage that said we are (or have been) overwriting thumbnails created before with less useful background thumbnails. That might be just a real bug, though. :) Robert Kaiser ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
WebAPI Meeting: **NEW TIME** Tuesday 6 August @ *8* AM Pacific [1]
We've moved the meeting 2 hours earlier! 8 AM in California 11 AM in Toronto and New York, etc. 16:00 in the UK and Portugal 17:00 in most parts of Europe 23:00 in Taipei http://www.timeanddate.com/worldclock/fixedtime.html?msg=WebAPI+meeting&iso=20130806T08&p1=224&am=30 Meeting Details: * Agenda: https://etherpad.mozilla.org/webapi-meetingnotes * WebAPI Vidyo room * A room we can find, San Francisco office * Spadina conf. room, Toronto office * Allo Allo conf. room, London office * Vidyo Phone # +1-650-903-0800 x92 Conference #98413 (US/INTL) * US Vidyo Phone # 1-800-707-2533 (PIN 369) Conference #98413 (US) * Join irc.mozilla.org #webapi for back channel All are welcome. Andrew [1] http://www.timeanddate.com/worldclock/fixedtime.html?msg=WebAPI+meeting&iso=20130806T08&p1=224&am=30 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Removing support for OS/2
Hi, sorry for the delay to reply. My change was performed mechanically without any tests. So, I don't know if the OS/2 widget is actually alive. However, I was requested a review of IME code for OS/2 on this June. https://bugzilla.mozilla.org/show_bug.cgi?id=768742 Therefore, I was thinking that it's alive. On 2013/08/02 8:39, Mike Hommey wrote: CCing the last two persons who submitted patches for OS/2 On Thu, Aug 01, 2013 at 04:13:23PM -0700, Gregory Szorc wrote: We have a number of references to OS/2 throughout the build system and source tree. According to Kyle Huey OS/2 has likely broken since we removed --disable-ipc (bug 638755) in March 2011. While OS/2 is a tier-3 supported build configuration [1], we will shortly be rewriting a bunch of the build rules to handle non-recursive compilation. Since OS/2 is effectively dead as an operating system and since it apparently hasn't been able to build mozilla-central since 2011 without many people complaining AFAIK, I'm proposing that we remove traces of OS/2 from the build system. This likely plays out as not carrying OS/2 support forward as we change things. If the OS/2 community wishes to submit patches to re-add support, we can accept them, just like any tier-3 platform. Just to be clear, I don't believe other tier-3 operating systems may fall victim during refactors. OS/2 is special in that the OS is officially dead and sufficiently different from other supported platforms. It therefore is a non-trivial burden for us to attempt support as we perform large refactors to the build system. Are there any objections to this proposal? Gregory Szorc Build Config Module Owner [1] https://developer.mozilla.org/en-US/docs/Supported_build_configurations ___ 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 -- Masayuki Nakano Manager, Internationalization, Mozilla Japan. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
