Re: Flash on Firefox Win64 runs on windowless mode only
On Thursday, February 4, 2016 at 8:08:56 AM UTC+3:30, Makoto Kato wrote: > Hi all. > > NPAPI on Firefox for Windows still supports both windowed mode and > windowless mode. Since protected mode is unimplemented on Flash Win64, > Firefox Win64 uses our sandbox (sandbox level = 2) for plugin process > (Flash only). But this sandbox setting causes some issues on window > mode (IME and file dialog etc). > > So we decide that Flash on Firefox Win64 runs only windowless mode > (bug 1201904). > > This change is only Win64 version and Flash. We can still use windowed > mode for Flash when using Firefox Win32. > > > -- Makoto ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: new code to help with cross-process windows/workers (and Clients API)
On Dec 9, 2017 8:25 AM, "Gijs Kruitbosch" wrote: On 08/12/2017 20:23, Ben Kelly wrote: > Please let me know if you have any question or if you think you have a > feature that could integrate with the clients infrastructure. While the > initial implementation is limited to Clients API needs, I've tried to > design it to support other internal uses. I'd be very happy to help get > new features added to support browser chrome or native code. > Sorry if this was answered by implication somewhere in the OP already (I looked, but must have missed it!), but is this infrastructure exposed/available to Chrome JS, and message manager messages (as opposed to C++-based IPC with ipdl etc.) ? Not yet, but I have designed it to support that. Probably the first step would be to expose the Clients WebAPI to browser chrome script. We could then add more chrome-only features as use cases arise. Can you file a bug in Core:DOM and describe a bit more how you would like to use it? I just want to make sure anything we expose fits our browser chrome use cases well. In particular, in situations where we currently have content scripts that need to go ask the parent process something, and the parent then needs to go back to the content process with an answer, without losing the "reference" to the frame concerned (which may be a subframe, so just knowing the target browser is not enough), that is currently annoying to implement (requires e.g. manual window id tracking in the content process). It sounds like this API might make this type of thing easier to implement if we could use it from chrome JS. The Clients API is all promise based and I expect any future API would be as well. So hopefully that will make things easier. Thanks. Ben ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: new code to help with cross-process windows/workers (and Clients API)
On 08/12/2017 20:23, Ben Kelly wrote: Please let me know if you have any question or if you think you have a feature that could integrate with the clients infrastructure. While the initial implementation is limited to Clients API needs, I've tried to design it to support other internal uses. I'd be very happy to help get new features added to support browser chrome or native code. Sorry if this was answered by implication somewhere in the OP already (I looked, but must have missed it!), but is this infrastructure exposed/available to Chrome JS, and message manager messages (as opposed to C++-based IPC with ipdl etc.) ? In particular, in situations where we currently have content scripts that need to go ask the parent process something, and the parent then needs to go back to the content process with an answer, without losing the "reference" to the frame concerned (which may be a subframe, so just knowing the target browser is not enough), that is currently annoying to implement (requires e.g. manual window id tracking in the content process). It sounds like this API might make this type of thing easier to implement if we could use it from chrome JS. ~ Gijs ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
