Silencing a couple of dchecks that occur when running the debug version of th...

Silencing a couple of dchecks that occur when running the debug version of the *TabCrashReload* tests.

TEST=Run debug versions of *TabCrashReload* tests.  There should be no more dchecks.
BUG=none


Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=58067

[robertshield, 2010-08-31 20:12:08]

LGTM

http://codereview.chromium.org/3241008/diff/1/2
File chrome_frame/chrome_frame_automation.cc (right):

http://codereview.chromium.org/3241008/diff/1/2#newcode620
chrome_frame/chrome_frame_automation.cc:620: hr =
security_manager_.CreateInstance(CLSID_InternetSecurityManager);
microscopic nit: I don't like the syntax
if (!x) x.Something();
when using smart pointer type classes because in the condition check x is being
used like a pointer and in the body of the statement x is being used like an
object (at first glance, I thought this statement would dereference a null
pointer). I'd prefer

if (security_manager_.get() == NULL) ...

It's a tiny nit though, probably smarter people than me will be reading this, so
ignore me if you want.

http://codereview.chromium.org/3241008/diff/1/3
File chrome_frame/chrome_frame_plugin.h (right):

http://codereview.chromium.org/3241008/diff/1/3#newcode80
chrome_frame/chrome_frame_plugin.h:80: DCHECK_EQ(profile_name,
launch_params_->profile_name());
should we check the extra_chrome_arguments as well?

[tommi, 2010-08-31 20:24:12]

Regarding your second comment, I found a better way to avoid that check. I have
reverted that file and add another instead.  Please take a look.

http://codereview.chromium.org/3241008/diff/1/2
File chrome_frame/chrome_frame_automation.cc (right):

http://codereview.chromium.org/3241008/diff/1/2#newcode620
chrome_frame/chrome_frame_automation.cc:620: hr =
security_manager_.CreateInstance(CLSID_InternetSecurityManager);
On 2010/08/31 20:12:08, robertshield wrote:
> microscopic nit: I don't like the syntax
> if (!x) x.Something();
> when using smart pointer type classes because in the condition check x is
being
> used like a pointer and in the body of the statement x is being used like an
> object (at first glance, I thought this statement would dereference a null
> pointer). I'd prefer
> 
> if (security_manager_.get() == NULL) ...
> 
> It's a tiny nit though, probably smarter people than me will be reading this,
so
> ignore me if you want.

Done.

[tommi, 2010-08-31 20:24:19]

Regarding your second comment, I found a better way to avoid that check. I have
reverted that file and add another instead.  Please take a look.

[robertshield, 2010-08-31 20:38:47]

On 2010/08/31 20:24:19, tommi wrote:
> Regarding your second comment, I found a better way to avoid that check. I
have
> reverted that file and add another instead.  Please take a look.

Looks Grotesque To Most