Okay, finally got around to starting this discussion on mozilla
plugin-futures.
- Mike
On Fri, Sep 11, 2009 at 4:53 PM, John Abd-El-Malek wrote:
>
>
> On Fri, Sep 11, 2009 at 4:52 PM, Mike Morearty wrote:
>
>> So, since Flash is installed by means other than as part of an Extension,
>> does
On Fri, Sep 11, 2009 at 4:52 PM, Mike Morearty wrote:
> So, since Flash is installed by means other than as part of an Extension,
> does that mean that John Tamplin's suggestion of giving permissions via
> manifest.json won't work for me? I take it manifest.json is something that
> only applies
So, since Flash is installed by means other than as part of an Extension,
does that mean that John Tamplin's suggestion of giving permissions via
manifest.json won't work for me? I take it manifest.json is something that
only applies to extensions, and not to the other methods of installing a
plug
On Fri, Sep 11, 2009 at 4:45 PM, John Abd-El-Malek wrote:
> On Fri, Sep 11, 2009 at 4:32 PM, John Tamplin wrote:
>>
>> On Fri, Sep 11, 2009 at 7:31 PM, John Abd-El-Malek
>> wrote:
>>>
>>> If this sounds good to you, the next step would be getting a broader
>>> discussion with other browser vend
On Fri, Sep 11, 2009 at 4:32 PM, John Tamplin wrote:
> On Fri, Sep 11, 2009 at 7:31 PM, John Abd-El-Malek wrote:
>
>> If this sounds good to you, the next step would be getting a broader
>> discussion with other browser vendors on the plugin-futures mailing list (
>> https://mail.mozilla.org/list
On Fri, Sep 11, 2009 at 4:34 PM, John Tamplin wrote:
> On Fri, Sep 11, 2009 at 7:28 PM, John Abd-El-Malek wrote:
>
>> Through whatever plugin installer they have (i.e. Flash's installer) or
>> the toolkit (i.e. Flash Builder).
>>
>
> So are you suggesting there is a better way to package an NPAPI
On Fri, Sep 11, 2009 at 7:28 PM, John Abd-El-Malek wrote:
> Through whatever plugin installer they have (i.e. Flash's installer) or the
> toolkit (i.e. Flash Builder).
>
So are you suggesting there is a better way to package an NPAPI plugin for
Chrome than to build a CRX? On Firefox, NPAPI plug
On Fri, Sep 11, 2009 at 7:31 PM, John Abd-El-Malek wrote:
> If this sounds good to you, the next step would be getting a broader
> discussion with other browser vendors on the plugin-futures mailing list (
> https://mail.mozilla.org/listinfo/plugin-futures).
>
Since the other browsers do not run
On Fri, Sep 11, 2009 at 4:01 PM, Mike Morearty wrote:
>
>
> On Fri, Sep 11, 2009 at 3:54 PM, John Tamplin wrote:
>
>> On Fri, Sep 11, 2009 at 6:37 PM, John Abd-El-Malek wrote:
>>
>>> For reference, something similar is done for popups:
>>> void NPN_PushPopupsEnabledState(NPP instance, NPBool ena
On Fri, Sep 11, 2009 at 4:03 PM, Mike Morearty wrote:
>
>
> On Fri, Sep 11, 2009 at 3:44 PM, John Tamplin wrote:
>
>> On Fri, Sep 11, 2009 at 6:38 PM, John Abd-El-Malek wrote:
>>
>>> I presume you're referring to Chrome extensions? I don't see the
>>> advantage of making this depend on the plug
On Fri, Sep 11, 2009 at 3:44 PM, John Tamplin wrote:
> On Fri, Sep 11, 2009 at 6:38 PM, John Abd-El-Malek wrote:
>
>> I presume you're referring to Chrome extensions? I don't see the
>> advantage of making this depend on the plugin being distributed via
>> extensions.
>>
>
> How else would an en
On Fri, Sep 11, 2009 at 3:44 PM, John Tamplin wrote:
> On Fri, Sep 11, 2009 at 6:38 PM, John Abd-El-Malek wrote:
>
>> I presume you're referring to Chrome extensions? I don't see the
>> advantage of making this depend on the plugin being distributed via
>> extensions.
>>
>
> How else would an en
On Fri, Sep 11, 2009 at 3:54 PM, John Tamplin wrote:
> On Fri, Sep 11, 2009 at 6:37 PM, John Abd-El-Malek wrote:
>
>> For reference, something similar is done for popups:
>> void NPN_PushPopupsEnabledState(NPP instance, NPBool enabled);
>> void NPN_PopPopupsEnabledState(NPP instance);
>>
>> Perha
On Fri, Sep 11, 2009 at 6:53 PM, Scott Hess wrote:
> Since the hang dialog comes up in the future after you've shifted your
> focus elsewhere, if we did any sort of user interaction at all I'd
> rather the plug-in could say "Ask user for permission to disable hang
> monitor for this context right
On Fri, Sep 11, 2009 at 6:37 PM, John Abd-El-Malek wrote:
> For reference, something similar is done for popups:
> void NPN_PushPopupsEnabledState(NPP instance, NPBool enabled);
> void NPN_PopPopupsEnabledState(NPP instance);
>
> Perhaps we can do the same thing here:
>
> void NPN_PushPluginHangD
Since the hang dialog comes up in the future after you've shifted your
focus elsewhere, if we did any sort of user interaction at all I'd
rather the plug-in could say "Ask user for permission to disable hang
monitor for this context right now". The plug-in hits the breakpoint,
calls that function
On Fri, Sep 11, 2009 at 6:50 PM, Mike Mammarella wrote:
> Perhaps rather than disabling the hang monitor altogether what that
> could do is add an additional option to the warning the first time:
> "don't notify me again." If you click that, then it will disable the
> hang monitor until the plugi
Perhaps rather than disabling the hang monitor altogether what that
could do is add an additional option to the warning the first time:
"don't notify me again." If you click that, then it will disable the
hang monitor until the plugin is once again responsive and then
becomes unresponsive again. (
On Fri, Sep 11, 2009 at 6:41 PM, Scott Hess wrote:
> Another alternative would be a "ping" type call to say "I'm
> unresponsive, and I mean it." Like a watchdog timer. The plug-in
> could still effectively be hung, but at least it has to have things
> together enough to call the watchdog.
Tha
On Fri, Sep 11, 2009 at 6:38 PM, John Abd-El-Malek wrote:
> I presume you're referring to Chrome extensions? I don't see the advantage
> of making this depend on the plugin being distributed via extensions.
>
How else would an end-user get a plugin installed for Chrome? I don't think
you want
Another alternative would be a "ping" type call to say "I'm
unresponsive, and I mean it." Like a watchdog timer. The plug-in
could still effectively be hung, but at least it has to have things
together enough to call the watchdog.
-scott
On Fri, Sep 11, 2009 at 3:37 PM, John Abd-El-Malek wro
On Fri, Sep 11, 2009 at 2:46 PM, John Tamplin wrote:
> On Fri, Sep 11, 2009 at 5:24 PM, Darin Fisher wrote:
>
>> I think that is a reasonable feature request. It would be nice however if
>> there were some way to know when to restore the old behavior.
>> Unfortunately, Chrome won't know when y
For reference, something similar is done for popups:
void NPN_PushPopupsEnabledState(NPP instance, NPBool enabled);
void NPN_PopPopupsEnabledState(NPP instance);
Perhaps we can do the same thing here:
void NPN_PushPluginHangDetectorState(NPP instance, NPBool enabled);
void NPN_Pop PluginHangDetec
I think this adds a lot of complexity.
On Fri, Sep 11, 2009 at 2:44 PM, Scott Hess wrote:
>
> Could it be like incognito mode, where the window is special and the
> tabs cannot be pooled with other modes? Then we'd know you were done
> when all your plugin-dev tabs were gone.
>
> -scott
>
>
> O
On Fri, Sep 11, 2009 at 6:12 PM, Mike Morearty wrote:
> That would work for us too. Seems pretty good -- an easy way for a plugin
> to say, "Temporarily disable the hang monitor, because we are going to be
> deliberately hung for a little while."
>
> But I don't understand how the manifest would
On Fri, Sep 11, 2009 at 2:46 PM, John Tamplin wrote:
> On Fri, Sep 11, 2009 at 5:24 PM, Darin Fisher wrote:
>
>> I think that is a reasonable feature request. It would be nice however if
>> there were some way to know when to restore the old behavior.
>> Unfortunately, Chrome won't know when y
On Fri, Sep 11, 2009 at 5:24 PM, Darin Fisher wrote:
> I think that is a reasonable feature request. It would be nice however if
> there were some way to know when to restore the old behavior.
> Unfortunately, Chrome won't know when you are done.
I was thinking something like this for my case
Could it be like incognito mode, where the window is special and the
tabs cannot be pooled with other modes? Then we'd know you were done
when all your plugin-dev tabs were gone.
-scott
On Fri, Sep 11, 2009 at 2:24 PM, Darin Fisher wrote:
> I think that is a reasonable feature request. It wo
Also, the inspector already disables the hang monitor dynamically when
it stops at a breakpoint since the renderer is stopped at that point,
so this may just be a case of exposing this on-off switch via some
API.
Erik
On Fri, Sep 11, 2009 at 2:26 PM, Evan Martin wrote:
>
> I guess there's a pr
I guess there's a precedent in the inspector where you can enable
various development-related bits (like "enable resource tracking").
Maybe there's a reasonable place to hook in UI for that there.
On Fri, Sep 11, 2009 at 2:24 PM, Darin Fisher wrote:
> I think that is a reasonable feature request
I think that is a reasonable feature request. It would be nice however if
there were some way to know when to restore the old behavior.
Unfortunately, Chrome won't know when you are done.
-Darin
On Fri, Sep 11, 2009 at 2:10 PM, Mike Morearty wrote:
> We just discussed that, and decided against
On Thu, Sep 10, 2009 at 5:40 PM, Mike Morearty wrote:
> Then let's say the Flash app hits the line where the breakpoint is.
> The Flash player notifies Flash Builder of the breakpoint, and then
> blocks, waiting on a socket until Flash Builder tells it what to do
> next (e.g. resume, single-step,
We just discussed that, and decided against using it, because it could be
potentially confusing. Most users would be unaware that we were launching
in a separate profile, and even someone who did know that we were doing this
would probably find it inconvenient. For example, if he does open anothe
You can try using the --user-data-dir flag to point the test instance
of Chrome at a dedicated testing profile. That will mean the
--disable-hang-monitor instance will actually stay around.
Adam
On Thu, Sep 10, 2009 at 2:40 PM, Mike Morearty wrote:
>
> Hi,
>
> I'm a developer at Adobe, on the
34 matches
Mail list logo
