[chromium-dev] Re: Enabling --disable-hang-monitor for new windows when Chrome is already running

[John Tamplin]

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, etc.).
>
> The problem is that 30 seconds later, Chrome detects this as a hang
> (which it is, but it's a deliberate one), and puts up the usual
> message:
>
>The following plug-in is unresponsive: Shockwave Flash
>Would you like to stop it?
>
> Even if I say No, the message keeps reappearing every 30 seconds or
> so.
>
> I'd like to disable the message during debugging.  It's easy to launch
> chrome with --disable-hang-monitor, and that does work, but only if
> Chrome wasn't already running before I began my debugging session.  If
> Chrome *was* already running, then that flag has no effect.  (I
> suspect probably the new instance of chrome.exe just passed control
> over to the existing instance, or something like that, and did not
> tell Chrome to use this flag.)
>
> I realize this is somewhat tricky to do.  Ideally, that flag would
> apply to just the one tab or window that I tried to open, but not to
> all the other already-existing windows.  I have not yet looked at the
> Chrome/Chromium source code, but I wouldn't be surprised if this is
> currently implemented as a global setting.
>
> Is this feasible?  Is there some other way to do what I want?  Should
> I log an enhancement request?
>

I have the same problem in the GWT Development Mode plugin.  You could set a
breakpoint in your Java code in Eclipse, and as far as the browser sees the
NPAPI plugin is just hanging until the server lets it continue.
It seems like this might be a feature that a number of plugins would like to
control, yet you want to make sure it isn't abused by malicious plugins.
 What about an API call to disable/re-enable it, and control access to that
API with permissions in the manifest?

-- 
John A. Tamplin
Software Engineer (GWT), Google

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Enabling --disable-hang-monitor for new windows when Chrome is already running

[John Tamplin]

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 (substitute appropriate
method names):
NPN_SetPluginWarning(false);
processSocketMessages();
NPN_SetPluginWarning(true);

and trying to call NPN_SetPluginWarning where you didn't request that
permission in the manifest would fail.

-- 
John A. Tamplin
Software Engineer (GWT), Google

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Enabling --disable-hang-monitor for new windows when Chrome is already running

[John Tamplin]

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 work.  I get that you want to
> prevent malicious plugins from abusing this, but how does a plugin become
> "trusted"?  What sort of manifest is this, and where is it (is it in the
> plugin, or in Chrome, or somewhere else)?
>

In 
manifest.json,
you already have a permissions entry.  If that were extended to include a
disable-plugin-warning permission, then presumably at install time the
installer would warn you that the extension was requesting this ability,
much like installing an Android app.   If you are installing something that
you don't think should need that ability, then you might think twice about
installing it.

-- 
John A. Tamplin
Software Engineer (GWT), Google

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Enabling --disable-hang-monitor for new windows when Chrome is already running

[John Tamplin]

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 to tell them to go create a directory if it doesn't exist, and copy
the file there, and you don't want to have to write a platform-specific
installer to do that either.

-- 
John A. Tamplin
Software Engineer (GWT), Google

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Enabling --disable-hang-monitor for new windows when Chrome is already running

[John Tamplin]

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.


That would be awkward, but doable, as in my case I couldn't use blocking
socket reads but would have to do polling so I could call the heartbeat
function.

-- 
John A. Tamplin
Software Engineer (GWT), Google

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Enabling --disable-hang-monitor for new windows when Chrome is already running

[John Tamplin]

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 plugin is once again responsive and then
> becomes unresponsive again. (Or maybe even until the plugin
> terminates.)
>

In the case of debugging something remote, I don't think that buys you
anything over the current model unless it is for the lifetime of the plugin.
 Also, I think it will be annoying to users who expect when they are using
debugging the Java code associated with their app that the browser side is
going to hang (and better than other browsers where the UI locks up
entirely) -- I still think some way for it to always be disabled for the
given plugin with the user's consent.

-- 
John A. Tamplin
Software Engineer (GWT), Google

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Enabling --disable-hang-monitor for new windows when Chrome is already running

[John Tamplin]

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_PushPluginHangDetectorState(NPP instance, NPBool enabled);
> void NPN_Pop PluginHangDetectorState(NPP instance);
>

Sounds fine to me.

-- 
John A. Tamplin
Software Engineer (GWT), Google

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Enabling --disable-hang-monitor for new windows when Chrome is already running

[John Tamplin]

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 now".  The plug-in hits the breakpoint,
> calls that function, and on successful return falls into the blocking
> mode.  The browser could cache the response so that the user only has
> to be asked once per tab (or browser session).
>

I still like the plugin being in control of when the warning is disabled --
let's say the user has code which actually has an infinite loop in JS which
gets called by the plugin -- even if I am debugging the Java code and know
the plugin will be unresponsive during that time, I still want to catch the
hang in what to me is user code.

-- 
John A. Tamplin
Software Engineer (GWT), Google

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Enabling --disable-hang-monitor for new windows when Chrome is already running

[John Tamplin]

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 plugins in a separate thread, they don't
have this issue.  Is that list still relevant then?

-- 
John A. Tamplin
Software Engineer (GWT), Google

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Enabling --disable-hang-monitor for new windows when Chrome is already running

[John Tamplin]

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 plugins can be installed via
XPI files just like XPCOM components, so it seems appropriate to use the
analogous construct here.

-- 
John A. Tamplin
Software Engineer (GWT), Google

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Chromium and ssl3

[John Tamplin]

On Sat, Nov 7, 2009 at 8:32 AM, giacomo.arcangeli <
giacomo.arcang...@gmail.com> wrote:
>
> Some days ago I found a courious behaviour of Chromium (4.0.237.0
> under ubuntu Linux) and Firefox on Paypal site.
> Chromium tell me that the connection is under 112-bit ecnryption.
> Firefox tell me that the connection is under a 168-bit encryption.
> Paypal use 3DES (Triple Des) and that 3DES can be used with 3
> different 56bit keys (168bit total encryption) or 2 different keys
> (always 3 keys but 2 are the same - 112bit total encryption).
> I search for known issue but I don't find anything and I don't file a
> bug becuase I don't know exactly if it's a bug or common Chromium
> behaviour.
>

My understanding is the brute-force strength of 3DES is only 112 bits, even
in the case where all three 56-bit keys are different.

-- 
John A. Tamplin
Software Engineer (GWT), Google

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] scrolling a text area with shift-pgdn

[John Tamplin]

One thing that drives me nuts using GMail in Chrome compared to Firefox, is
the behavior of PgDn in a text area while holding shift.  In Firefox, PgDn
extends the selection as well as scrolling the text area.  In Chrome, it
leaves the selection alone and scrolls the text area.

Does anyone else find that behavior odd?  Is this intentional, or should I
file a bug/feature request?

-- 
John A. Tamplin
Software Engineer (GWT), Google

-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] class has virtual method but non-virtual destructor

[John Tamplin]

On Fri, Nov 20, 2009 at 4:31 PM, James Robinson  wrote:

> What's the benefit of omitting the virtual destructor?
>

There really shouldn't be any -- if you have any virtual functions at all,
you already have a vtbl entry and you are just adding at most one entry to a
single vtbl for the class.  In the cases where it was safe to not have a
virtual destructor (ie, the actual object type is statically known), the
compiler should make the destructor call static and possibly inline it
anyway.

-- 
John A. Tamplin
Software Engineer (GWT), Google

-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] class has virtual method but non-virtual destructor

[John Tamplin]

On Fri, Nov 20, 2009 at 6:00 PM, Mark Mentovai  wrote:

> James Robinson wrote:
> > What's the benefit of omitting the virtual destructor?
>
> The benefit is that the destructor stays out of the vtable, which will
> potentially reduce the vtable size and save a layer of indirection.  I
> don't consider either of these advantages compelling.  I agree that
> it's overshadowed by the bugs that occur when a caller expects virtual
> destructor semantics but they're not available.
>

In the cases where the type is statically known, I have seen GCC make the
destructor a static call (which can be inlined), so in the cases where there
isn't potentially a problem there is no indirection and therefore zero
runtime overhead.  If there is potentially a problem, then I would argue
against the optimization that is usually ok in favor of known correct code.

One vtbl entry per such class seems trivially insignificant.

-- 
John A. Tamplin
Software Engineer (GWT), Google

-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev