Rewards Tip Floating Dialog

[simonhong]

Web-ui dialog

• Similar to the certificate white popup when you click on Secure next to an https site.
• Can be fully customized with a webui content (html/js).
• Can specify location dynamically and can change it dynamically
• Support an api to dismiss it
• Can specify size
• Dismissed if the user clicks outside of it

[petemill]

Looks like there's two levels of API needed:

1. Open Popup for a tab.
   This is to enable direct donation to a site that is open in a tab.
   Url: chrome://donate
   Params needed: site origin
   Invocation source: c++ (backend of an extension popup, or a menu)

2. Open Popup for a portion of WebContents.
   This is to enable direct donation to a user of a site that is open in a tab.
   Url: chrome://tip
   Params needed: site origin (twitter), content creator (e.g. twitter handle), DOM element (for position anchor)
   Invocation source: Javascript, inside a content script

Therefore we can implement two levels of API:

Static c++ API (Donate and Tip)

static DonationDialogController::Donate(WebContents* initiator)
static TipDialogController::Tip(WebContents* initiator, Rect element_bounds)

• follows the pattern of PrintPreviewDialogController
• implements ui::WebDialogDelegate
• positions the dialog and handles opening and closing

Javascript API (Tip)

js: brave.rewards.showContentCreatorTipDialog(creatorName, element)

• Instantiated from content script which modifies behavior of site's buttons (twitter like, facebook like, youtube ThumbsUp)
• Works loosely similar to Autofill - render receives command and calculates coordinates which are passed via IPC to browser client
• Browser client calls static TipDialogController::Tip

[NejcZdovc]

@petemill for donate we need a lot more data. Will this data be fetched inside this dialog and we can use origin as to what data we need in the webui?

[petemill]

@NejcZdovc lots of data can be fetched from the WebContents, including origin. The WebUI can then have it's own API for actions and to fetch data from Rewards service. So I imagine everything you need unique to that invocation will be covered in the WebContents - do you agree with that?

[NejcZdovc]

yeah to get data from rewards service I only need origin. Based on that I can get all other data. Would it be possible to send in instead of origin publisher key? This way we don't need to calculate it from origin again?

[petemill]

@NejcZdovc that sounds possible if all triggers for the dialog know the Publisher Key. It is only the Rewards extension popup, and does that know it?

Edit: I'm just wondering if now or in the future we would have a unknowledgable trigger - such as a menu item that simply says 'Donate to this site'

[NejcZdovc]

@petemill yeah they know that key. For other options you could always call rewards service that will return publisher key based on origin and then you trigger donate

[petemill]

Sure we can support both 👍. What about tipping @NejcZdovc? Will it be enough to have origin / publisherId and the site-specific creator name. E.g. twitter.com and @twitterusername ?

[NejcZdovc]

yup as long as we know to who like/heart belong (twitter handler) we should be good

[petemill]

@rebron @mandar-brave please can we confirm which milestone we're currently targeting floating user tips, so I can prioritize work - is it still '1.0'?

[NejcZdovc]

@petemill it's targeted for 57 build

[petemill]

Just noting that we still don't have:

• A dialog which can:
  • Auto-size whilst being located in a specific position (though ConstrainedWebDialog is very close)
  • Have rounded borders via clipping the webview or via a transparent background, or a mix of native UI controls as well as the webview to achieve a similar look
  • Have custom shape (arrow pointing at popup anchor) via native UI controls
• An easy means of querying the DOM from the browser UI layer in order to get the dialog position, though this could be provided via JS content script.

[petemill]

For Donate dialog I did use ShowConstrainedWebDialogWithAutoResize. It's problems were:

• Could not overlay the rest of the content with a semi-transparent background (not a big priority though)
• Could not have it take 100% width of parent with auto-sized height
  • Can only give an autoresizing dialog initial min and max for both width and height, whereas we want to have a min and max for height, and a fixed width that changes on browser window resize. Whereas a non-auto-resize ShowConstrainedWebDialog can have its width and height changed at any time, but will not auto-resize. This fixed logic for both width and height seems to go down to the render layer.
    So for the Donate dialog, the main bug with this compromise only presents itself when resizing the browser window.

For the Tip dialog, we are considering using DOM injection for now, e.g. brave/brave-core#1040

[petemill]

Just found an interesting precedent in blink for displaying an overlay on the webcontent which is native (and hence not part of the host DOM) but contains web content with a custom js api, as well as exactly the custom popup shape we're looking for: InspectorOverlayPage.

InspectorOverlayAgent.cc
InspectorOverlayPage.html

cc @simonhong @pilgrim-brave @davidtemkin

(UX considerations aside)

[NejcZdovc]

closing as we implemented this in a different way