As a user, I would like to send the web page that I’m browsing on my Firefox for Android browser to the TV browser for bigger screen enjoyment

I checked the current share overlay implementation. |SendTab.java| [1] is probably the place we can put related code. However, currently the |SendTab| doesn't have an architecture to mix device list from FxAccount and Presentation API. Need Margaret's advice on the implementation details. [1] https://dxr.mozilla.org/mozilla-central/source/mobile/android/base/overlays/service/sharemethods/SendTab.java#52

IIRC Anthony has thought a lot about how to combine the various exit points from the browser. No UX change should move forward without his strong and early involvement. Trying to bake TVs into the Firefox Sync device list is probably the wrong approach (unless you want to ship a Sync client!). But the broader question is: why does this need to be new UI at all? We already support casting/flinging to Roku, and used to support Chromecast. What's different here? (Also removing bug metadata that doesn't mean what you think it means in this component.)

How is this different from bug 1189832? Do you have a mock-up for what you intend to implement in this bug? I agree with Richard that it would be much easier to integrate with our existing TV integration UX to add a "page action" icon in the URL bar. I also think it would be less confusing for users who expect to see their synced devices in that share list.

For video casting we are going to follow the UX for Roku and Chromecast and the related patch is on bug 1129785. However, the current UX design for the casting icon in URL bar is design for sharing video content only. They way we share a web page on Fennec is via Share Plane icon. From user's POV, opening a URL on desktop browser or TV browser should be in the same UI despite difference of the underlying technology (Sync and Presentation API). That's why I think we can integrate presentation-API-supported device into SendTab.java. I'll let Anthony to decide which UI we should use for implementing "send page to TV", then we can continue the engineering discussion.

(In reply to Shih-Chiang Chien [:schien] (UTC+8) (use ni? plz) from comment #5) > They way we share a web page on Fennec is via Share Plane icon. From user's > POV, opening a URL on desktop browser or TV browser should be in the same UI > despite difference of the underlying technology (Sync and Presentation API). > That's why I think we can integrate presentation-API-supported device into > SendTab.java. Please do not try to integrate the presentation API into the Sync-specific send tab system. This will create a maintenance issue. It will also create future problems because a Sync-device and a TV are different things, limiting how we could extend or modify this UI. > I'll let Anthony to decide which UI we should use for implementing "send > page to TV", then we can continue the engineering discussion. If anything, we should create a top-level TV share target, as though the TV is a native app. This is essentially what we do for the Share Plane. It's not a real native app, but it magically acts like one.

(In reply to Mark Finkle (:mfinkle) from comment #6) > > I'll let Anthony to decide which UI we should use for implementing "send > > page to TV", then we can continue the engineering discussion. > > If anything, we should create a top-level TV share target, as though the TV > is a native app. This is essentially what we do for the Share Plane. It's > not a real native app, but it magically acts like one. I should note that now of this (your solution or mine) is available to add-ons. My solution has a better chance of getting add-on support as well.

(In reply to Mark Finkle (:mfinkle) from comment #7) > (In reply to Mark Finkle (:mfinkle) from comment #6) > > > > I'll let Anthony to decide which UI we should use for implementing "send > > > page to TV", then we can continue the engineering discussion. > > > > If anything, we should create a top-level TV share target, as though the TV > > is a native app. This is essentially what we do for the Share Plane. It's > > not a real native app, but it magically acts like one. > > I should note that now of this (your solution or mine) is available to > add-ons. My solution has a better chance of getting add-on support as well. Do you mean adding an add-on API for creating one more item for TV in the Share Plane and implement this functionality in add-on? Just want to confirm if I understand you correctly.

(In reply to Shih-Chiang Chien [:schien] (UTC+8) (use ni? plz) from comment #8) > (In reply to Mark Finkle (:mfinkle) from comment #7) > > (In reply to Mark Finkle (:mfinkle) from comment #6) > > > > > > I'll let Anthony to decide which UI we should use for implementing "send > > > > page to TV", then we can continue the engineering discussion. > > > > > > If anything, we should create a top-level TV share target, as though the TV > > > is a native app. This is essentially what we do for the Share Plane. It's > > > not a real native app, but it magically acts like one. > > > > I should note that now of this (your solution or mine) is available to > > add-ons. My solution has a better chance of getting add-on support as well. > > Do you mean adding an add-on API for creating one more item for TV in the > Share Plane and implement this functionality in add-on? Just want to confirm > if I understand you correctly. I do not. I mean adding an add-on API to create a new item, like the Share Plane. This item would be a peer to the Share Plane.

We do currently have an add-on API to add new regular menu items. You could use that to create a new menu item under the Page sub-menu (and these can be dynamic, such that they're hidden/disabled if there isn't a FxOS TV nearby): https://developer.mozilla.org/en-US/Add-ons/Firefox_for_Android/API/NativeWindow/menu/add We could talk about creating a new add-on API for new share list entries, but I'm not sure what the technical details for that would look like. Mike, do you think this is something that would be possible without too much effort?

(In reply to :Margaret Leibovic from comment #10) > We could talk about creating a new add-on API for new share list entries, > but I'm not sure what the technical details for that would look like. Mike, > do you think this is something that would be possible without too much > effort? If we don't integrate it with our quick share system and don't sort it with the existing activities (e.g. we always show it as one of the top items), it should be simple: we just call subMenu.add with a different menu item click listener in GeckoActionProvider.onPrepareSubmenu [1]. Integration with our quick share & sorting most recent activities is a lot more work and hairy – there are multiple methods in GeckoActionProvider that assume we're just using the ActivityChooserModel (and thus activities), which opens activities. Some possibilities: * Wrap ActivityChooserModel to integrate both ActivityChooserModel items and addon items into the menu * Pretend the newly added addon items are Activities and implement some of those APIs, but attach a different click handler. [1]: https://mxr.mozilla.org/mozilla-central/source/mobile/android/base/widget/GeckoActionProvider.java?rev=a9738e5f636a#147

Resolved as add-on is implemented in bug 1187845.