Introduce WebPluginContainerBase to abstract WebPluginContainerImpl.

Introduce WebPluginContainerBase to abstract WebPluginContainerImpl.

Many classes in web/ take a dependancy on WebPluginContainerImpl, in some cases
this dependency is cyclic. In order to break this dependency we introduce a new
temporary abstraction WebPluginContainerBase, that derives from PlugingView,
WebPluginContainer and ContextClient.

Classes that were taking a dependency on WebPluginContainerImpl now take a
dependency on WebPluginContainerBase. In cases where there we methods that
were only defined in WebPluginContainerImpl we make them pure virtual in
WebPluginContainerBase and override them in WebPluginContainerImpl.

As WebPluginContainerImpl is garbage collected, we move this to
WebPluginContainerBase and define a virtual trace method.

The intention is for this abstraction to be temporary, once we move all of the
dependencies into core/ we can remove it.

I put the new class in core/exported as it derives from WebPluginContainer.


BUG=712963
Review-Url: https://codereview.chromium.org/2886113002
Cr-Original-Commit-Position: refs/heads/master@{#472810}
Committed: https://chromium.googlesource.com/chromium/src/+/303acce5cc18d95d46342bd089e06957841bc21b
Review-Url: https://codereview.chromium.org/2886113002
Cr-Commit-Position: refs/heads/master@{#473111}
Committed: https://chromium.googlesource.com/chromium/src/+/7f10adc089153731d35a4a04956d7673342db2e4

[slangley, 2017-05-17 04:56:54]

Description was changed from

==========
Introduce WebPluginContainerBase to abstract WebPluginContainerImpl.

Many classes in web/ take a dependancy on WebPluginContainerImpl, in some cases
this dependency is cyclic. In order to break this dependency we introduce a new
temporary abstraction WebPluginContainerBase, that derives from PlugingView,
WebPluginContainer and ContextClient.

Classes that were taking a dependency on WebPluginContainerImpl now take a
dependency on WebPluginContainerBase. In cases where there we methods that
were only defined in WebPluginContainerImpl we make them pure virtual in
WebPluginContainerBase and override them in WebPluginContainerImpl.

As WebPluginContainerImpl is garbage collected, we move this to
WebPluginContainerBase and define a virtual trace method.

The intention is for this abstraction to be temporary, once we move all of the
dependencies into core/ we can remove it.


BUG=
==========

to

==========
Introduce WebPluginContainerBase to abstract WebPluginContainerImpl.

Many classes in web/ take a dependancy on WebPluginContainerImpl, in some cases
this dependency is cyclic. In order to break this dependency we introduce a new
temporary abstraction WebPluginContainerBase, that derives from PlugingView,
WebPluginContainer and ContextClient.

Classes that were taking a dependency on WebPluginContainerImpl now take a
dependency on WebPluginContainerBase. In cases where there we methods that
were only defined in WebPluginContainerImpl we make them pure virtual in
WebPluginContainerBase and override them in WebPluginContainerImpl.

As WebPluginContainerImpl is garbage collected, we move this to
WebPluginContainerBase and define a virtual trace method.

The intention is for this abstraction to be temporary, once we move all of the
dependencies into core/ we can remove it.

I put the new class in core/exported as it derives from WebPluginContainer.


BUG=712963
==========

[slangley, 2017-05-17 04:57:42]

slangley@chromium.org changed reviewers:
+ sashab@chromium.org

[slangley, 2017-05-17 06:39:19]

slangley@chromium.org changed reviewers:
+ dcheng@chromium.org, tkent@chromium.org

[dcheng, 2017-05-17 07:19:41]

LGTM

https://codereview.chromium.org/2886113002/diff/1/third_party/WebKit/Source/c...
File third_party/WebKit/Source/core/exported/WebPluginContainerBase.h (right):

https://codereview.chromium.org/2886113002/diff/1/third_party/WebKit/Source/c...
third_party/WebKit/Source/core/exported/WebPluginContainerBase.h:72: true);
Optional nit: newline for consistency =P

[slangley, 2017-05-17 07:21:37]

Thanks!

https://codereview.chromium.org/2886113002/diff/1/third_party/WebKit/Source/c...
File third_party/WebKit/Source/core/exported/WebPluginContainerBase.h (right):

https://codereview.chromium.org/2886113002/diff/1/third_party/WebKit/Source/c...
third_party/WebKit/Source/core/exported/WebPluginContainerBase.h:72: true);
On 2017/05/17 at 07:19:41, dcheng (in AEST) wrote:
> Optional nit: newline for consistency =P

Done

[tkent, 2017-05-17 07:38:03]

lgtm

[slangley, 2017-05-18 10:08:10]

The CQ bit was checked by slangley@chromium.org

[slangley, 2017-05-18 10:08:11]

The patchset sent to the CQ was uploaded after l-g-t-m from dcheng@chromium.org
Link to the patchset: https://codereview.chromium.org/2886113002/#ps20001
(title: "Fix code review comments.")

[commit-bot: I haz the power, 2017-05-18 10:08:41]

CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-05-18 12:27:42]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-05-18 12:27:42]

Try jobs failed on following builders:
  win_chromium_x64_rel_ng on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_x64_...)

[sashab, 2017-05-18 12:37:34]

The CQ bit was checked by sashab@chromium.org

[commit-bot: I haz the power, 2017-05-18 12:38:06]

CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-05-18 15:03:57]

CQ is committing da patch.

Bot data: {"patchset_id": 20001, "attempt_start_ts": 1495111054215330,
"parent_rev": "c694a817a95ab321d824235acacebaebc6277e1b", "commit_rev":
"303acce5cc18d95d46342bd089e06957841bc21b"}

[commit-bot: I haz the power, 2017-05-18 15:04:11]

Description was changed from

==========
Introduce WebPluginContainerBase to abstract WebPluginContainerImpl.

Many classes in web/ take a dependancy on WebPluginContainerImpl, in some cases
this dependency is cyclic. In order to break this dependency we introduce a new
temporary abstraction WebPluginContainerBase, that derives from PlugingView,
WebPluginContainer and ContextClient.

Classes that were taking a dependency on WebPluginContainerImpl now take a
dependency on WebPluginContainerBase. In cases where there we methods that
were only defined in WebPluginContainerImpl we make them pure virtual in
WebPluginContainerBase and override them in WebPluginContainerImpl.

As WebPluginContainerImpl is garbage collected, we move this to
WebPluginContainerBase and define a virtual trace method.

The intention is for this abstraction to be temporary, once we move all of the
dependencies into core/ we can remove it.

I put the new class in core/exported as it derives from WebPluginContainer.


BUG=712963
==========

to

==========
Introduce WebPluginContainerBase to abstract WebPluginContainerImpl.

Many classes in web/ take a dependancy on WebPluginContainerImpl, in some cases
this dependency is cyclic. In order to break this dependency we introduce a new
temporary abstraction WebPluginContainerBase, that derives from PlugingView,
WebPluginContainer and ContextClient.

Classes that were taking a dependency on WebPluginContainerImpl now take a
dependency on WebPluginContainerBase. In cases where there we methods that
were only defined in WebPluginContainerImpl we make them pure virtual in
WebPluginContainerBase and override them in WebPluginContainerImpl.

As WebPluginContainerImpl is garbage collected, we move this to
WebPluginContainerBase and define a virtual trace method.

The intention is for this abstraction to be temporary, once we move all of the
dependencies into core/ we can remove it.

I put the new class in core/exported as it derives from WebPluginContainer.


BUG=712963

Review-Url: https://codereview.chromium.org/2886113002
Cr-Commit-Position: refs/heads/master@{#472810}
Committed:
https://chromium.googlesource.com/chromium/src/+/303acce5cc18d95d46342bd089e0...
==========

[commit-bot: I haz the power, 2017-05-18 15:04:12]

Committed patchset #2 (id:20001) as
https://chromium.googlesource.com/chromium/src/+/303acce5cc18d95d46342bd089e0...

[jbroman, 2017-05-18 20:19:49]

A revert of this CL (patchset #2 id:20001) has been created in
https://codereview.chromium.org/2888283004/ by jbroman@chromium.org.

The reason for reverting is: Causes leak failure in
editing/selection/selection-plugin-clear-crash.html.

https://build.chromium.org/p/chromium.webkit/builders/WebKit%20Linux%20Trusty...

(and locally, I get crashes in debug).

[slangley, 2017-05-19 00:22:55]

The CQ bit was checked by slangley@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-05-19 00:24:28]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-05-19 00:30:34]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-05-19 00:30:35]

Dry run: Try jobs failed on following builders:
  android_arm64_dbg_recipe on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_arm6...)
  android_clang_dbg_recipe on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_clan...)
  android_n5x_swarming_rel on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_n5x_...)
  chromeos_daisy_chromium_compile_only_ng on master.tryserver.chromium.linux
(JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromeos_daisy_...)
  linux_chromium_compile_dbg_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  linux_chromium_tsan_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  ios-device on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-device/builds...)
  ios-device-xcode-clang on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-device-xcode-...)
  ios-simulator on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-simulator/bui...)
  ios-simulator-xcode-clang on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-simulator-xco...)
  mac_chromium_rel_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[slangley, 2017-05-19 00:46:05]

Failure was caused because USING_PRE_FINALIZER does not support virtual
dispatch.

Fix is in place.

[slangley, 2017-05-19 00:48:38]

The CQ bit was checked by slangley@chromium.org

[slangley, 2017-05-19 00:48:39]

The patchset sent to the CQ was uploaded after l-g-t-m from tkent@chromium.org,
dcheng@chromium.org
Link to the patchset: https://codereview.chromium.org/2886113002/#ps60001
(title: "Rebase")

[commit-bot: I haz the power, 2017-05-19 00:50:00]

CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[dcheng, 2017-05-19 02:24:01]

On 2017/05/19 00:46:05, slangley wrote:
> Failure was caused because USING_PRE_FINALIZER does not support virtual
> dispatch.
> 
> Fix is in place.

Sorry if this is dumb, but why don't virtual methods work with
USING_PRE_FINALZER? Why does going through a non-virtual that calls a virtual
fix it?

[slangley, 2017-05-19 02:38:24]

On 2017/05/19 at 02:24:01, dcheng wrote:
> On 2017/05/19 00:46:05, slangley wrote:
> > Failure was caused because USING_PRE_FINALIZER does not support virtual
> > dispatch.
> > 
> > Fix is in place.
> 
> Sorry if this is dumb, but why don't virtual methods work with
USING_PRE_FINALZER? Why does going through a non-virtual that calls a virtual
fix it?

Because the code expands out to use the qualified name of the base class when
invoking the method. According to
http://en.cppreference.com/w/cpp/language/qualified_lookup "A call to a
qualified member function is never virtual". 

See:
https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/heap/...

We can try and remove the qualifier in another CL - not sure if this behavior is
intentional or not.

[dcheng, 2017-05-19 02:44:05]

dcheng@chromium.org changed reviewers:
+ haraken@chromium.org

[dcheng, 2017-05-19 02:44:06]

On 2017/05/19 02:38:24, slangley wrote:
> On 2017/05/19 at 02:24:01, dcheng wrote:
> > On 2017/05/19 00:46:05, slangley wrote:
> > > Failure was caused because USING_PRE_FINALIZER does not support virtual
> > > dispatch.
> > > 
> > > Fix is in place.
> > 
> > Sorry if this is dumb, but why don't virtual methods work with
> USING_PRE_FINALZER? Why does going through a non-virtual that calls a virtual
> fix it?
> 
> Because the code expands out to use the qualified name of the base class when
> invoking the method. According to
> http://en.cppreference.com/w/cpp/language/qualified_lookup "A call to a
> qualified member function is never virtual". 
> 
> See:
>
https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/heap/...
> 
> We can try and remove the qualifier in another CL - not sure if this behavior
is
> intentional or not.

Ah... I didn't realize that the macro qualified the method with the class name.
Doh =/

We should document it at least in a followup (or fix it).

LGTM

[commit-bot: I haz the power, 2017-05-19 04:06:06]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-05-19 04:06:08]

Try jobs failed on following builders:
  win_chromium_rel_ng on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)

[slangley, 2017-05-19 04:18:39]

The CQ bit was checked by slangley@chromium.org

[commit-bot: I haz the power, 2017-05-19 04:19:07]

CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-05-19 06:54:23]

CQ is committing da patch.

Bot data: {"patchset_id": 60001, "attempt_start_ts": 1495167519576280,
"parent_rev": "653344bc2486f15443939ac75a99c07cc79496aa", "commit_rev":
"7f10adc089153731d35a4a04956d7673342db2e4"}

[commit-bot: I haz the power, 2017-05-19 06:54:34]

Description was changed from

==========
Introduce WebPluginContainerBase to abstract WebPluginContainerImpl.

Many classes in web/ take a dependancy on WebPluginContainerImpl, in some cases
this dependency is cyclic. In order to break this dependency we introduce a new
temporary abstraction WebPluginContainerBase, that derives from PlugingView,
WebPluginContainer and ContextClient.

Classes that were taking a dependency on WebPluginContainerImpl now take a
dependency on WebPluginContainerBase. In cases where there we methods that
were only defined in WebPluginContainerImpl we make them pure virtual in
WebPluginContainerBase and override them in WebPluginContainerImpl.

As WebPluginContainerImpl is garbage collected, we move this to
WebPluginContainerBase and define a virtual trace method.

The intention is for this abstraction to be temporary, once we move all of the
dependencies into core/ we can remove it.

I put the new class in core/exported as it derives from WebPluginContainer.


BUG=712963

Review-Url: https://codereview.chromium.org/2886113002
Cr-Commit-Position: refs/heads/master@{#472810}
Committed:
https://chromium.googlesource.com/chromium/src/+/303acce5cc18d95d46342bd089e0...
==========

to

==========
Introduce WebPluginContainerBase to abstract WebPluginContainerImpl.

Many classes in web/ take a dependancy on WebPluginContainerImpl, in some cases
this dependency is cyclic. In order to break this dependency we introduce a new
temporary abstraction WebPluginContainerBase, that derives from PlugingView,
WebPluginContainer and ContextClient.

Classes that were taking a dependency on WebPluginContainerImpl now take a
dependency on WebPluginContainerBase. In cases where there we methods that
were only defined in WebPluginContainerImpl we make them pure virtual in
WebPluginContainerBase and override them in WebPluginContainerImpl.

As WebPluginContainerImpl is garbage collected, we move this to
WebPluginContainerBase and define a virtual trace method.

The intention is for this abstraction to be temporary, once we move all of the
dependencies into core/ we can remove it.

I put the new class in core/exported as it derives from WebPluginContainer.


BUG=712963

Review-Url: https://codereview.chromium.org/2886113002
Cr-Original-Commit-Position: refs/heads/master@{#472810}
Committed:
https://chromium.googlesource.com/chromium/src/+/303acce5cc18d95d46342bd089e0...
Review-Url: https://codereview.chromium.org/2886113002
Cr-Commit-Position: refs/heads/master@{#473111}
Committed:
https://chromium.googlesource.com/chromium/src/+/7f10adc089153731d35a4a04956d...
==========

[commit-bot: I haz the power, 2017-05-19 06:54:36]

Committed patchset #4 (id:60001) as
https://chromium.googlesource.com/chromium/src/+/7f10adc089153731d35a4a04956d...

[haraken, 2017-05-19 07:44:15]

LGTM with a comment.

https://codereview.chromium.org/2886113002/diff/60001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/exported/WebPluginContainerBase.h (right):

https://codereview.chromium.org/2886113002/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/exported/WebPluginContainerBase.h:57: void
DispatchDispose() { Dispose(); }

This is confusing. Can we do something like:

- Move USING_PRE_FINALIZER to WebPluginContainerImpl.
- Make the pre-finalizer call WebPluginContainerImpl::PreFinalize (a non-virtual
method).
- Make WebPluginContainerImpl::PreFinalize call Dispose.

However, why do we need the pre-finalilzer in the first place? It looks weird
that there is no explicit timing to dispose the WebPluginContainerImpl.

[dcheng, 2017-05-19 08:38:23]

On 2017/05/19 07:44:15, haraken wrote:
> LGTM with a comment.
> 
>
https://codereview.chromium.org/2886113002/diff/60001/third_party/WebKit/Sour...
> File third_party/WebKit/Source/core/exported/WebPluginContainerBase.h (right):
> 
>
https://codereview.chromium.org/2886113002/diff/60001/third_party/WebKit/Sour...
> third_party/WebKit/Source/core/exported/WebPluginContainerBase.h:57: void
> DispatchDispose() { Dispose(); }
> 
> This is confusing. Can we do something like:
> 
> - Move USING_PRE_FINALIZER to WebPluginContainerImpl.
> - Make the pre-finalizer call WebPluginContainerImpl::PreFinalize (a
non-virtual
> method).
> - Make WebPluginContainerImpl::PreFinalize call Dispose.
> 
> However, why do we need the pre-finalilzer in the first place? It looks weird
> that there is no explicit timing to dispose the WebPluginContainerImpl.

The pre-finalizer was introduced in
https://chromium.googlesource.com/chromium/src/+/bc3e1557791eb247d7bb820e1f8e....
I think we can reconsider the need for this once joelhockey's work to clean up
the widget tree is done.