chrome/blink: Add functionality for in-product help for media elements.

third_party/WebKit/Source/core/dom/MediaIPHManager.h

+// Copyright 2017 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+#ifndef MediaIPHManager_h
+#define MediaIPHManager_h
+
+#include "core/CoreExport.h"
+#include "platform/heap/GarbageCollected.h"
+#include "platform/heap/Heap.h"
+#include "platform/heap/Member.h"
+#include "public/web/WebMediaIPH.h"
+
+namespace blink {
+class HTMLMediaElement;
+class WebMediaIPH;
+
+class CORE_EXPORT MediaIPHManager final

[chrishtr, 2017/06/23 00:39:44]

I'm not so sure you need this class at all. Proposal:

There is only one in-product help promo shown for the whole WebView. Any media
element can request to show it, and provide its Element* as a key.

The WebView handles these requests. If the in-product help is already shown for
that
Element*, or is keyed by another Element*, it does nothing. Otherwise it shows
it and stores off that Element* as an active key.

The WebView also listens for signals to hide the in-product help due to
non-Blink
signals like touch gesture.

When media controls want to hide, they query the WebView about whether there
is an active in-product help for it, and if so ask the WebView to dismiss it,
then schedule hiding. I don't think you will need the logic around calls back
into Blink to dismiss the in-product help before hiding the controls. If a
layout
occurs without user gesture that messes things up, it's ok for a brief delay of
IPC (if visible at all).

[Khushal, 2017/06/23 02:11:06]

The reason I put it on Document was because I thought this should be per-frame.
Each frame knows if the in-product help is active for an element in the frame
and has an IPC bridge to the browser, which knows if its active for any frame.
This fits with the OOPIF model too. Putting it on WebView/RenderViewImpl, I am
not sure which frame to tie the mojo service to.
We will definitely need a way for the browser to inform the renderer when the UI
is dismissed because the renderer does not receive all signals that could
initiate it. The user could touch any browser UI, like the toolbar, which would
also initiate hiding it.

Also the process of showing the in-product help itself needs the browser to
allow the request. There are heuristics which limit the number of times we can
show it over a period, so the renderer needs to be informed if the request is
rejected in order to not keep the controls visible indefinitely.
There is no logic here that waits for the in-product help to be dismissed before
hiding here. The state tracking in this class is because both the browser and
renderer could have events that dismiss the UI, so the renderer waits for an ack
to its hide notification to come to a consistent state. My bad with the naming,
may be kHideRequested should be kNotifyControlsHidden.

[chrishtr, 2017/06/27 18:22:20]

That sounds like waiting for the browser to me...

[Khushal, 2017/06/28 05:32:38]

Restructured like you suggested except the tracking is on LocalFrame instead of
WebView.

I just restricted showing the UI to once per frame to simplify all of this. I'm
sure the heuristics on the browser would have done that anyway.

+    : public GarbageCollectedFinalized<MediaIPHManager>,
+      public WebMediaIPHClient {
+ public:
+  static MediaIPHManager* Create(std::unique_ptr<WebMediaIPH>);
+  ~MediaIPHManager();
+
+  DECLARE_TRACE();
+
+  bool IPHTriggerObservedOnElement(HTMLMediaElement&);
+  void LayoutUpdated();
+
+ private:
+  enum class IPHState { kShowing, kHideRequested, kNotShowing };
+
+  MediaIPHManager(std::unique_ptr<WebMediaIPH>);
+
+  // WebMediaIPHClient implementation.
+  void DidHideMediaIPHWidget() override;
+
+  WeakMember<HTMLMediaElement> active_element_;
+  std::unique_ptr<WebMediaIPH> media_iph_;
+  IPHState state_ = IPHState::kNotShowing;
+};
+
+}  // namespace blink
+
+#endif