The current CL in review ( https://codereview.chromium.org/2943983003/ ) does the following things:
- Checks whether we should show IPH through a call to Tracker::ShouldShowHelpUI().
- Calls from Blink renderer process through the browser process all the way up to Tab.java with the rects of where the button should be (showMediaDownloadInProductHelp(int x, int y, int width, int height)), and shows the TextBubble.
- Calls Tracker::NotifyEvent("download_button_shown") when the IPH is displayed.
- Calls Dismissed() whenever the popup is dismissed.
However, even after that CL lands, there are a couple of things we need to implement:
1) Add pulsating dot in UI.
We already know where the rectangle is for the button, so hopefully this would only have to be implemented on the Java UI side.
2) Tell the tracker whenever a video is in fact downloaded.
This basically means calling Tracker::NotifyEvent("...event_used...") in the browser process. The question here is mostly how to plumb the fact that the user initiated a video download to the browser process.
Hopefully, there's already a trigger we can re-use for this "user-initiated download of video". If not, we might have to add some new IPC. If we have to add new IPC, hopefully we can re-use the mojo-service MediaDownloadInProductHelp that is already being added in the CL mentioned above.
Regarding #2, we do not notify anyone about the download starting or finishing at the moment. It might be tricky to figure out when the download is finished as the download from the controls is no different from a download initiated by a web page today. It is actually implemented as <a download> pointing to the source file.
Assigning to shaktisahu@ for implemmeting part 2 of comment #3.
The thought would be to add a new method to MediaDownloadInProductHelp that would be invoked from the renderer every time the user clicks the download-video-button, regardless of whether IPH was displayed or not.
More from an offline discussion about sending video-button-click event to server :
The current issue is that we cannot use the existing mojo pipe to send this event, because the pipe is created only when we have to show the IPH and reset after the IPH is dismissed.
There are a few options we can take :
1- Send the event along with the download source attribution data. However, currently we don't have a way to differentiate media downloads from <a> downloads and this will be worked on soon as part of collecting download source attribution data.
2- Create a generic mojo pipe for FeatureEngagement which will always be kept alive. This can be reused in future when there are more similar IPH needs to communicate between renderer and browser.
3- Third alternative is to keep the existing pipe MediaDownloadInProductHelp always alive and use this for sending the button click events.
Comment 1 by mlamouri@chromium.org
, May 11 2017