Gijs, > **Regarding**: "We anchor the context menu, autofill menus, select dropdowns, the date picker (ie <input type=date/time> implementation), colorpicker, and probably other things I'm not thinking of, to web content already." Thank you! I'll definitely have a look at some of those implementations in terms of prior art. --- > **Regarding**: "if you wanted to not disable scrolling, you'd need to continuously pass scroll information across processes... So honestly I think solving this is both technically hard and has inescapable UX issues." I agree. I think that would be a very difficult problem to solve both technically and with regard to UX. --- Mike, Thanks, that video is a helpful demonstration of the kind of thing we're looking for. --- > **Regarding**: "You don't need the invisible box, you can pass positioning arguments to the relevant XUL panel opening methods (you don't need an element to anchor to, you can open a popup using just coordinates)." I tried this approach first and I couldn't get it to work. In this particular case, I was trying to get it to work with [`PanelMultiView.openPopup()`](https://searchfox.org/mozilla-central/rev/f78093864e287014db7ac9383bb76c45edbf8559/browser/components/customizableui/PanelMultiView.sys.mjs#258-278) I tried invoking it like this: ```javascript PanelMultiView.openPopup(panel, /* anchor */ null, {}, /* x */ 50, /* y */ 50); ``` But it seems to always call the [`_calculateMaxHeight()`](https://searchfox.org/mozilla-central/rev/f78093864e287014db7ac9383bb76c45edbf8559/browser/components/customizableui/PanelMultiView.sys.mjs#1267) function, which seems to [assume that the panel has a non-null anchor](https://searchfox.org/mozilla-central/rev/f78093864e287014db7ac9383bb76c45edbf8559/browser/components/customizableui/PanelMultiView.sys.mjs#1189-1191). In any case, I couldn't get it to work while I was trying to make my quick prototype, so I used an anchor instead. Perhaps you could confirm if I've misunderstood something or not, and if not, I'll file a bug that this behavior should be fixed. --- > **Regarding**: "if there is supposed to be a way of opening the panel that isn't the URL bar that is closer to the text, the context menu seems the natural place to do it. Then you can just have a (sub)menu item for the UI that you currently have in the panel - you don't actually need the panel, the UI could just live inside the menu itself. Then you also don't need to reinvent passing text selection or coordinates across processes, and it solves the positioning woes because the menu implementation takes care of this." You're right, the UX designs intend to have potentially three ways to open this menu. 1) Right clicking the selected text. 2) Clicking the Translations button while text is selected. 3) The "call-to-action icon" that I mentioned in the original description, which would be a clickable icon that floats next to selected text if the selection meets translation requirements. Option 3) is one of the primary reasons I'm doing this exploration in the first place. Please do not take the literal example of my mock-up solution as intended behavior. I was only attempting to use existing elements to test the "idea" of opening them next to a text selection as a path of least resistence. Even in the case of Option 2), the panel would not be floating in that case, it would just open at the button where it was clicked. --- > **Regarding:** "There are ways of showing browser UI inside the content process, as Jamie alluded to. The devtools and screenshots component code use this to provide overlays on web content that interact with the web content. There are security implications though, because it means that we'd need to allow content processes to tell the parent process "translate this site from X to Y" and/or "never translate this site" and/or "never translate this language". I don't know the security properties of the translation process and if this would be considered problematic (ie if it'd help a potentially compromised content process escalate its privileges). Also, any such UI would potentially scroll and either way it cannot overlap the chrome, which means there are some line-of-death issues (though the usefulness of that concept is disputed, so ymmv) in terms of how users know they can trust the content that is more or less indistinguishable from (untrusted) web content." Definitely, this seems like a security risk to me. --- > **Regarding:** "in terms of where to position things... to me, it's confusing that the argument is that (a) the panel should be next to the selection/text and (b) the way to open the panel should still be in the URL bar. This is more mouse movement, not less, so it seems strictly worse than the status quo." As I mention in one of the previous responses, the behavior in my mock-up solution is not actual behavior, but rather an exploration of opening a UI panel near to selected text. In the event that the user invokes the Select Translations Panel via the button, it will open at the button. But we may still need this capability as a whole for the feature, so I used the existing panel in my exploration. --- > **Regarding:** "from a personal perspective, having extra UI (the described "Call-to-action icon" appearing on mouseup) appear floating next to text selection for a feature I don't use seems really annoying. This is feedback we've had before for e.g. the PiP control on videos." Do you have any links to specific negative feedback about this pattern? I think those would be worthwhile to read. I'm happy to go digging myself, but a link is welcome if you know exactly where it is or how to find it easily. --- > **Regarding**: "If we were going to offer this type of UX, it also seems like other functionality (search for selection, copy selection, take a screenshot) would be more high value than translation." Perhaps, but that's not really my decision to make. I'm working on Translations right now. --- > **Regarding**: "although it seems 'cool' to offer in-context translation, I'm not sure I understand the situation where a user both doesn't speak a language and so needs a translation, yet understands a page in another language well enough to select a specific bit that they want translating (apparently not caring about anything else). Is the text selection really critical here, or do users "just" want a page context menu integration because that's where they expect this type of functionality (even when there's no selection on the page) ?" I think this is a question more for the UX team and their user research. My understanding is that select translations is one of the most desired translation features after full-page translation. Though, as someone who is learning a second language myself as an adult, I certainly see value this capability. It is not uncommon for me to be reading a page in Spanish, at which point I come across a particular sentence of paragraph that has new vocabulary or unusual-to-me grammar structures. In that case, I'd likely want to translate that selection. Language learning is not binary, where learners have either 0% comprehension or 100% comprehension. If it were, I would agree with you that full-page translation is wholly sufficient. This is just one example from my personal experience where I think the feature has value, but I'm sure that there are others, even unrelated to learning languages. --- > **Regarding**: "In terms of a generically reusable thing here... any reusable thing would need code in both processes and need a pluggable way of finding the right anchor in the child process's content area (be it selection or a containing / "from point" node of some kind) and the right panel/popup/whatever in the parent. I guess it's possible to add an abstraction here, but I don't think the abstraction will help super lots - the only thing it'd abstract is going from the content point to the screen position for the panel in the parent. Effectively I think any abstraction you come up with would probably be more code than cargo-culting "compute coordinates, send to parent" from any of the existing solutions. But perhaps my imagination is too narrow here. :-)" Sure, there may not be a reason to make a general abstraction. I was only offering to do such a thing if it seemed both feasible and useful to do. --- Thank you so much for all of the detailed feedback. This is incredibly helpful to me and to the Translations team.
Bug 1865002 Comment 8 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Gijs, > **Regarding**: "We anchor the context menu, autofill menus, select dropdowns, the date picker (ie <input type=date/time> implementation), colorpicker, and probably other things I'm not thinking of, to web content already." Thank you! I'll definitely have a look at some of those implementations in terms of prior art. --- > **Regarding**: "if you wanted to not disable scrolling, you'd need to continuously pass scroll information across processes... So honestly I think solving this is both technically hard and has inescapable UX issues." I agree. I think that would be a very difficult problem to solve both technically and with regard to UX. --- Mike, Thanks, that video is a helpful demonstration of the kind of thing we're looking for. --- > **Regarding**: "You don't need the invisible box, you can pass positioning arguments to the relevant XUL panel opening methods (you don't need an element to anchor to, you can open a popup using just coordinates)." I tried this approach first and I couldn't get it to work. In this particular case, I was trying to get it to work with [`PanelMultiView.openPopup()`](https://searchfox.org/mozilla-central/rev/f78093864e287014db7ac9383bb76c45edbf8559/browser/components/customizableui/PanelMultiView.sys.mjs#258-278) I tried invoking it like this: ```javascript PanelMultiView.openPopup(panel, /* anchor */ null, {}, /* x */ 50, /* y */ 50); ``` But it seems to always call the [`_calculateMaxHeight()`](https://searchfox.org/mozilla-central/rev/f78093864e287014db7ac9383bb76c45edbf8559/browser/components/customizableui/PanelMultiView.sys.mjs#1267) function, which seems to [assume that the panel has a non-null anchor](https://searchfox.org/mozilla-central/rev/f78093864e287014db7ac9383bb76c45edbf8559/browser/components/customizableui/PanelMultiView.sys.mjs#1189-1191). In any case, I couldn't get it to work while I was trying to make my quick prototype, so I used an anchor instead. Perhaps you could confirm if I've misunderstood something or not, and if not, I'll file a bug that this behavior should be fixed. --- > **Regarding**: "if there is supposed to be a way of opening the panel that isn't the URL bar that is closer to the text, the context menu seems the natural place to do it. Then you can just have a (sub)menu item for the UI that you currently have in the panel - you don't actually need the panel, the UI could just live inside the menu itself. Then you also don't need to reinvent passing text selection or coordinates across processes, and it solves the positioning woes because the menu implementation takes care of this." You're right, the UX designs intend to have potentially three ways to open this menu. 1) Right clicking the selected text. 2) Clicking the Translations button while text is selected. 3) The "call-to-action icon" that I mentioned in the original description, which would be a clickable icon that floats next to selected text if the selection meets translation requirements. Option 3) is one of the primary reasons I'm doing this exploration in the first place. Please do not take the literal example of my mock-up solution as intended behavior. I was only attempting to use existing elements to test the "idea" of opening them next to a text selection as a path of least resistence. Even in the case of Option 2), the panel would not be floating in that case, it would just open at the button where it was clicked. --- > **Regarding:** "There are ways of showing browser UI inside the content process, as Jamie alluded to. The devtools and screenshots component code use this to provide overlays on web content that interact with the web content. There are security implications though, because it means that we'd need to allow content processes to tell the parent process "translate this site from X to Y" and/or "never translate this site" and/or "never translate this language". I don't know the security properties of the translation process and if this would be considered problematic (ie if it'd help a potentially compromised content process escalate its privileges). Also, any such UI would potentially scroll and either way it cannot overlap the chrome, which means there are some line-of-death issues (though the usefulness of that concept is disputed, so ymmv) in terms of how users know they can trust the content that is more or less indistinguishable from (untrusted) web content." Definitely, this seems like a security risk to me. --- > **Regarding:** "in terms of where to position things... to me, it's confusing that the argument is that (a) the panel should be next to the selection/text and (b) the way to open the panel should still be in the URL bar. This is more mouse movement, not less, so it seems strictly worse than the status quo." As I mention in one of the previous responses, the behavior in my mock-up solution is not actual behavior, but rather an exploration of opening a UI panel near to selected text. In the event that the user invokes the Select Translations Panel via the button, it will open at the button. But we may still need this capability as a whole for the feature, so I used the existing panel in my exploration. --- > **Regarding:** "from a personal perspective, having extra UI (the described "Call-to-action icon" appearing on mouseup) appear floating next to text selection for a feature I don't use seems really annoying. This is feedback we've had before for e.g. the PiP control on videos." Do you have any links to specific negative feedback about this pattern? I think those would be worthwhile to read. I'm happy to go digging myself, but a link is welcome if you know exactly where it is or how to find it easily. --- > **Regarding**: "If we were going to offer this type of UX, it also seems like other functionality (search for selection, copy selection, take a screenshot) would be more high value than translation." Perhaps, but that's not really my decision to make. I'm working on Translations right now. --- > **Regarding**: "although it seems 'cool' to offer in-context translation, I'm not sure I understand the situation where a user both doesn't speak a language and so needs a translation, yet understands a page in another language well enough to select a specific bit that they want translating (apparently not caring about anything else). Is the text selection really critical here, or do users "just" want a page context menu integration because that's where they expect this type of functionality (even when there's no selection on the page) ?" I think this is a question more for the UX team and their user research. My understanding is that select translations is one of the most desired translation features after full-page translation. Though, as someone who is learning a second language myself as an adult, I certainly see value this capability. It is not uncommon for me to be reading a page in Spanish, at which point I come across a particular sentence of paragraph that has new vocabulary or unusual-to-me grammar structures. In that case, I'd likely want to translate that selection. Language learning is not binary, where learners have either 0% comprehension or 100% comprehension. If it were, I would agree with you that full-page translation is wholly sufficient. This is just one example from my personal experience where I think the feature has value, but I'm sure that there are others, even unrelated to learning languages. --- > **Regarding**: "In terms of a generically reusable thing here... any reusable thing would need code in both processes and need a pluggable way of finding the right anchor in the child process's content area (be it selection or a containing / "from point" node of some kind) and the right panel/popup/whatever in the parent. I guess it's possible to add an abstraction here, but I don't think the abstraction will help super lots - the only thing it'd abstract is going from the content point to the screen position for the panel in the parent. Effectively I think any abstraction you come up with would probably be more code than cargo-culting "compute coordinates, send to parent" from any of the existing solutions. But perhaps my imagination is too narrow here. :-)" Sure, there may not be a reason to make a general abstraction. I was only offering to do such a thing if it seemed both feasible and useful to do. --- Thank you so much for all of the detailed feedback. This is incredibly helpful to me and to the Translations team.
Gijs, > **Regarding**: "We anchor the context menu, autofill menus, select dropdowns, the date picker (ie <input type=date/time> implementation), colorpicker, and probably other things I'm not thinking of, to web content already." Thank you! I'll definitely have a look at some of those implementations in terms of prior art. --- > **Regarding**: "if you wanted to not disable scrolling, you'd need to continuously pass scroll information across processes... So honestly I think solving this is both technically hard and has inescapable UX issues." I agree. I think that would be a very difficult problem to solve both technically and with regard to UX. --- > **Regarding**: "You don't need the invisible box, you can pass positioning arguments to the relevant XUL panel opening methods (you don't need an element to anchor to, you can open a popup using just coordinates)." I tried this approach first and I couldn't get it to work. In this particular case, I was trying to get it to work with [`PanelMultiView.openPopup()`](https://searchfox.org/mozilla-central/rev/f78093864e287014db7ac9383bb76c45edbf8559/browser/components/customizableui/PanelMultiView.sys.mjs#258-278) I tried invoking it like this: ```javascript PanelMultiView.openPopup(panel, /* anchor */ null, {}, /* x */ 50, /* y */ 50); ``` But it seems to always call the [`_calculateMaxHeight()`](https://searchfox.org/mozilla-central/rev/f78093864e287014db7ac9383bb76c45edbf8559/browser/components/customizableui/PanelMultiView.sys.mjs#1267) function, which seems to [assume that the panel has a non-null anchor](https://searchfox.org/mozilla-central/rev/f78093864e287014db7ac9383bb76c45edbf8559/browser/components/customizableui/PanelMultiView.sys.mjs#1189-1191). In any case, I couldn't get it to work while I was trying to make my quick prototype, so I used an anchor instead. Perhaps you could confirm if I've misunderstood something or not, and if not, I'll file a bug that this behavior should be fixed. --- > **Regarding**: "if there is supposed to be a way of opening the panel that isn't the URL bar that is closer to the text, the context menu seems the natural place to do it. Then you can just have a (sub)menu item for the UI that you currently have in the panel - you don't actually need the panel, the UI could just live inside the menu itself. Then you also don't need to reinvent passing text selection or coordinates across processes, and it solves the positioning woes because the menu implementation takes care of this." You're right, the UX designs intend to have potentially three ways to open this menu. 1) Right clicking the selected text. 2) Clicking the Translations button while text is selected. 3) The "call-to-action icon" that I mentioned in the original description, which would be a clickable icon that floats next to selected text if the selection meets translation requirements. Option 3) is one of the primary reasons I'm doing this exploration in the first place. Please do not take the literal example of my mock-up solution as intended behavior. I was only attempting to use existing elements to test the "idea" of opening them next to a text selection as a path of least resistence. Even in the case of Option 2), the panel would not be floating in that case, it would just open at the button where it was clicked. --- > **Regarding:** "There are ways of showing browser UI inside the content process, as Jamie alluded to. The devtools and screenshots component code use this to provide overlays on web content that interact with the web content. There are security implications though, because it means that we'd need to allow content processes to tell the parent process "translate this site from X to Y" and/or "never translate this site" and/or "never translate this language". I don't know the security properties of the translation process and if this would be considered problematic (ie if it'd help a potentially compromised content process escalate its privileges). Also, any such UI would potentially scroll and either way it cannot overlap the chrome, which means there are some line-of-death issues (though the usefulness of that concept is disputed, so ymmv) in terms of how users know they can trust the content that is more or less indistinguishable from (untrusted) web content." Definitely, this seems like a security risk to me. --- > **Regarding:** "in terms of where to position things... to me, it's confusing that the argument is that (a) the panel should be next to the selection/text and (b) the way to open the panel should still be in the URL bar. This is more mouse movement, not less, so it seems strictly worse than the status quo." As I mention in one of the previous responses, the behavior in my mock-up solution is not actual behavior, but rather an exploration of opening a UI panel near to selected text. In the event that the user invokes the Select Translations Panel via the button, it will open at the button. But we may still need this capability as a whole for the feature, so I used the existing panel in my exploration. --- > **Regarding:** "from a personal perspective, having extra UI (the described "Call-to-action icon" appearing on mouseup) appear floating next to text selection for a feature I don't use seems really annoying. This is feedback we've had before for e.g. the PiP control on videos." Do you have any links to specific negative feedback about this pattern? I think those would be worthwhile to read. I'm happy to go digging myself, but a link is welcome if you know exactly where it is or how to find it easily. --- > **Regarding**: "If we were going to offer this type of UX, it also seems like other functionality (search for selection, copy selection, take a screenshot) would be more high value than translation." Perhaps, but that's not really my decision to make. I'm working on Translations right now. --- > **Regarding**: "although it seems 'cool' to offer in-context translation, I'm not sure I understand the situation where a user both doesn't speak a language and so needs a translation, yet understands a page in another language well enough to select a specific bit that they want translating (apparently not caring about anything else). Is the text selection really critical here, or do users "just" want a page context menu integration because that's where they expect this type of functionality (even when there's no selection on the page) ?" I think this is a question more for the UX team and their user research. My understanding is that select translations is one of the most desired translation features after full-page translation. Though, as someone who is learning a second language myself as an adult, I certainly see value this capability. It is not uncommon for me to be reading a page in Spanish, at which point I come across a particular sentence of paragraph that has new vocabulary or unusual-to-me grammar structures. In that case, I'd likely want to translate that selection. Language learning is not binary, where learners have either 0% comprehension or 100% comprehension. If it were, I would agree with you that full-page translation is wholly sufficient. This is just one example from my personal experience where I think the feature has value, but I'm sure that there are others, even unrelated to learning languages. --- > **Regarding**: "In terms of a generically reusable thing here... any reusable thing would need code in both processes and need a pluggable way of finding the right anchor in the child process's content area (be it selection or a containing / "from point" node of some kind) and the right panel/popup/whatever in the parent. I guess it's possible to add an abstraction here, but I don't think the abstraction will help super lots - the only thing it'd abstract is going from the content point to the screen position for the panel in the parent. Effectively I think any abstraction you come up with would probably be more code than cargo-culting "compute coordinates, send to parent" from any of the existing solutions. But perhaps my imagination is too narrow here. :-)" Sure, there may not be a reason to make a general abstraction. I was only offering to do such a thing if it seemed both feasible and useful to do. --- Thank you so much for all of the detailed feedback. This is incredibly helpful to me and to the Translations team.
Gijs, > **Regarding**: "We anchor the context menu, autofill menus, select dropdowns, the date picker (ie <input type=date/time> implementation), colorpicker, and probably other things I'm not thinking of, to web content already." Thank you! I'll definitely have a look at some of those implementations in terms of prior art. --- > **Regarding**: "if you wanted to not disable scrolling, you'd need to continuously pass scroll information across processes... So honestly I think solving this is both technically hard and has inescapable UX issues." I agree. I think that would be a very difficult problem to solve both technically and with regard to UX. --- > **Regarding**: "You don't need the invisible box, you can pass positioning arguments to the relevant XUL panel opening methods (you don't need an element to anchor to, you can open a popup using just coordinates)." I tried this approach first and I couldn't get it to work. In this particular case, I was trying to get it to work with [`PanelMultiView.openPopup()`](https://searchfox.org/mozilla-central/rev/f78093864e287014db7ac9383bb76c45edbf8559/browser/components/customizableui/PanelMultiView.sys.mjs#258-278) I tried invoking it like this: ```javascript PanelMultiView.openPopup(panel, /* anchor */ null, {}, /* x */ 50, /* y */ 50); ``` But it seems to always call the [`_calculateMaxHeight()`](https://searchfox.org/mozilla-central/rev/f78093864e287014db7ac9383bb76c45edbf8559/browser/components/customizableui/PanelMultiView.sys.mjs#1267) function, which seems to [assume that the panel has a non-null anchor](https://searchfox.org/mozilla-central/rev/f78093864e287014db7ac9383bb76c45edbf8559/browser/components/customizableui/PanelMultiView.sys.mjs#1189-1191). In any case, I couldn't get it to work while I was trying to make my quick prototype, so I used an anchor instead. Perhaps you could confirm if I've misunderstood something or not, and if not, I'll file a bug that this behavior should be fixed. --- > **Regarding**: "if there is supposed to be a way of opening the panel that isn't the URL bar that is closer to the text, the context menu seems the natural place to do it. Then you can just have a (sub)menu item for the UI that you currently have in the panel - you don't actually need the panel, the UI could just live inside the menu itself. Then you also don't need to reinvent passing text selection or coordinates across processes, and it solves the positioning woes because the menu implementation takes care of this." You're right, the UX designs intend to have potentially three ways to open this menu. 1) Right clicking the selected text. 2) Clicking the Translations button while text is selected. 3) The "call-to-action icon" that I mentioned in the original description, which would be a clickable icon that floats next to selected text if the selection meets translation requirements. Option 3) is one of the primary reasons I'm doing this exploration in the first place. Please do not take the literal example of my mock-up solution as intended behavior. I was only attempting to use existing elements to test the "idea" of opening them next to a text selection as a path of least resistence. Even in the case of Option 2), the panel would not be floating in that case, it would just open at the button where it was clicked. --- > **Regarding:** "There are ways of showing browser UI inside the content process, as Jamie alluded to. The devtools and screenshots component code use this to provide overlays on web content that interact with the web content. There are security implications though, because it means that we'd need to allow content processes to tell the parent process "translate this site from X to Y" and/or "never translate this site" and/or "never translate this language". I don't know the security properties of the translation process and if this would be considered problematic (ie if it'd help a potentially compromised content process escalate its privileges). Also, any such UI would potentially scroll and either way it cannot overlap the chrome, which means there are some line-of-death issues (though the usefulness of that concept is disputed, so ymmv) in terms of how users know they can trust the content that is more or less indistinguishable from (untrusted) web content." Definitely, this seems like a security risk to me. --- > **Regarding:** "in terms of where to position things... to me, it's confusing that the argument is that (a) the panel should be next to the selection/text and (b) the way to open the panel should still be in the URL bar. This is more mouse movement, not less, so it seems strictly worse than the status quo." As I mention in one of the previous responses, the behavior in my mock-up solution is not actual behavior, but rather an exploration of opening a UI panel near to selected text. In the event that the user invokes the Select Translations Panel via the button, it will open at the button. But we may still need this capability as a whole for the feature, so I used the existing panel in my exploration. --- > **Regarding:** "from a personal perspective, having extra UI (the described "Call-to-action icon" appearing on mouseup) appear floating next to text selection for a feature I don't use seems really annoying. This is feedback we've had before for e.g. the PiP control on videos." Do you have any links to specific negative feedback about this pattern? I think those would be worthwhile to read. I'm happy to go digging myself, but a link is welcome if you know exactly where it is or how to find it easily. --- > **Regarding**: "If we were going to offer this type of UX, it also seems like other functionality (search for selection, copy selection, take a screenshot) would be more high value than translation." Perhaps, but that's not really my decision to make. I'm working on Translations right now. --- > **Regarding**: "although it seems 'cool' to offer in-context translation, I'm not sure I understand the situation where a user both doesn't speak a language and so needs a translation, yet understands a page in another language well enough to select a specific bit that they want translating (apparently not caring about anything else). Is the text selection really critical here, or do users "just" want a page context menu integration because that's where they expect this type of functionality (even when there's no selection on the page) ?" I think this is a question more for the UX team and their user research. My understanding is that select translations is one of the most desired translation features after full-page translation. Though, as someone who is learning a second language myself as an adult, I certainly see value this capability. It is not uncommon for me to be reading a page in Spanish, at which point I come across a particular sentence or paragraph that has new vocabulary or unusual-to-me grammar structures. In that case, I'd likely want to translate that selection. Language learning is not binary, where learners have either 0% comprehension or 100% comprehension. If it were, I would agree with you that full-page translation is wholly sufficient. This is just one example from my personal experience where I think the feature has value, but I'm sure that there are others, even unrelated to learning languages. --- > **Regarding**: "In terms of a generically reusable thing here... any reusable thing would need code in both processes and need a pluggable way of finding the right anchor in the child process's content area (be it selection or a containing / "from point" node of some kind) and the right panel/popup/whatever in the parent. I guess it's possible to add an abstraction here, but I don't think the abstraction will help super lots - the only thing it'd abstract is going from the content point to the screen position for the panel in the parent. Effectively I think any abstraction you come up with would probably be more code than cargo-culting "compute coordinates, send to parent" from any of the existing solutions. But perhaps my imagination is too narrow here. :-)" Sure, there may not be a reason to make a general abstraction. I was only offering to do such a thing if it seemed both feasible and useful to do. --- Thank you so much for all of the detailed feedback. This is incredibly helpful to me and to the Translations team.