Bugzilla

(In reply to :Gijs (he/him) from comment #12)

> You closed this out, can you add a small comment about what your conclusion / next steps are, so that future finders of this bug understand some of the context? :-)

Sure! Thanks for following up here. 

Ultimately we've decided that the idea of implementing a shortcut that appears near to selected text (when relevant conditions are met for a supported translation) is possible and worth exploring. 

However, we are implementing the Select Translations feature to be accessible via the right-click context menu first and foremost, likely with an initial release consisting of only that functionality, and a follow-up release that would enable the shortcut. 

---

> (In reply to Erik Nordin [:nordzilla] from comment #8)
> 
> Note that you're calling `PanelMultiView.openPopup` and that is very different from calling [openPopupAtScreen](https://searchfox.org/mozilla-central/rev/8b5d93d099b5b501cf5bd2b606c59afcf88bef1c/browser/base/content/nsContextMenu.js#106) as the context menu code is doing.
> 
> PanelMultiView has really only been used and tested anchored to buttons, but I don't think that a priori there is any reason it could not be made to work without (probably on an opt-in basis given none of the other consumers want this).
> 
> If you're still interested in this, then yes filing a bug would be helpful.
> 

I'd like to file a bug for this. I think, at the very least, that the `PanelMultiView.openPopup()` documentation is a bit misleading because it implies to me that it should be able to [forward the same set of `..args`](https://searchfox.org/mozilla-central/rev/0f39860036f9b6339e65d485aeb6b6be73d9dbda/browser/components/customizableui/PanelMultiView.sys.mjs#477-479) as other `openPopup` functions, which do [allow for `x` and `y` to be specified](https://searchfox.org/mozilla-central/rev/0f39860036f9b6339e65d485aeb6b6be73d9dbda/dom/chrome-webidl/XULPopupElement.webidl#77-78). 

However, I don't think that fixing this will be relevant to the implementation of Select Translations. It was relevant during my exploration, because as a path of least resistance, I was trying to open up the Translations Panel at a specific location using `PanelMultiView`, but in the actual implementation, the Select Translations panel will either be anchored to the context menu, or to the floating shortcut button. So there shouldn't be any need to open `PanelMultiView` at an x-y location for this feature.

(In reply to :Gijs (he/him) from comment #12)

> You closed this out, can you add a small comment about what your conclusion / next steps are, so that future finders of this bug understand some of the context? :-)

Sure! Thanks for following up here. 

Ultimately we've decided that the idea of implementing a shortcut that appears near to selected text (when relevant conditions are met for a supported translation) is possible and worth exploring. 

However, we are implementing the Select Translations feature to be accessible via the right-click context menu first and foremost, likely with an initial release consisting of only that functionality, and a follow-up release that would enable the shortcut. 

---

> (In reply to Erik Nordin [:nordzilla] from comment #8)
> 
> Note that you're calling `PanelMultiView.openPopup` and that is very different from calling [openPopupAtScreen](https://searchfox.org/mozilla-central/rev/8b5d93d099b5b501cf5bd2b606c59afcf88bef1c/browser/base/content/nsContextMenu.js#106) as the context menu code is doing.
> 
> PanelMultiView has really only been used and tested anchored to buttons, but I don't think that a priori there is any reason it could not be made to work without (probably on an opt-in basis given none of the other consumers want this).
> 
> If you're still interested in this, then yes filing a bug would be helpful.
> 

I'd like to file a bug for this. I think, at the very least, that the `PanelMultiView.openPopup()` documentation is a bit misleading because it implies to me that it should be able to [forward the same set of `...args`](https://searchfox.org/mozilla-central/rev/0f39860036f9b6339e65d485aeb6b6be73d9dbda/browser/components/customizableui/PanelMultiView.sys.mjs#477-479) as other `openPopup` functions, which do [allow for `x` and `y` to be specified](https://searchfox.org/mozilla-central/rev/0f39860036f9b6339e65d485aeb6b6be73d9dbda/dom/chrome-webidl/XULPopupElement.webidl#77-78). 

However, I don't think that fixing this will be relevant to the implementation of Select Translations. It was relevant during my exploration, because as a path of least resistance, I was trying to open up the Translations Panel at a specific location using `PanelMultiView`, but in the actual implementation, the Select Translations panel will either be anchored to the context menu, or to the floating shortcut button. So there shouldn't be any need to open `PanelMultiView` at an x-y location for this feature.