Created attachment 151983 [details] Bugdoc Open attached bugdoc. The frame has an interaction which opens libreoffice.org Now try to edit the frame content. Actual: If you don't click directly on the text, you will trigger the interaction and libreoffice.org will be opened. Expected: Interactions should only be active when in presentation mode so that editing is still possible/usable.
Reproduced in Version: 6.4.0.0.alpha0+ Build ID: 0d6ec494f83fb26524bf3a5fc7af27c225293e87 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US Calc: threaded
You need to use Alt+Click to avoid following the action. Doesn't that work for you? Besides that, the behavior is connected to the "text selection"-settings in toolbar "Options".
(In reply to Regina Henschel from comment #2) > You need to use Alt+Click to avoid following the action. Doesn't that work > for you? Oh, didn't know that, but true, that works. But usually you want the interaction to open when you click on it in presentation mode, not when you edit it. So the default behavior when clicking on a frame in edit mode should be that the frame is selected, not that an interaction is executed. Maybe we should switch defaults so that Alt-Click triggers the interaction. But still I don't know if that's necessary. You can always preview the current slide to test it. > Besides that, the behavior is connected to the "text selection"-settings in > toolbar "Options". Ok right. But we should make sure that editing works flawlessly with the default options there.
Alt+click is intended to select an object behind another. Only that here the hyperlink-active area works as an additional layer. I personally do not like the idea to disable interactions in edit mode totally. It would be inconvenient, if you need to switch to presentation mode only to test, if the interaction works as desired. You need interactions not only to external apps, but to navigate in non-linear presentations too. I think, UX should discuss it. It is really difficult to find a solution that is suitable for both Eve and Benjamin and does not destroy existing features.
(In reply to Regina Henschel from comment #4) > ... > I personally do not like the idea to disable interactions in edit mode > totally. My comment from Gerrit: > ... > If you are afraid of users who wants to interact while in edit mode, we could provide a content menu item.
(In reply to Regina Henschel from comment #4) > I personally do not like the idea to disable interactions in edit mode > totally. It would be inconvenient, if you need to switch to presentation > mode only to test, if the interaction works as desired. You need > interactions not only to external apps, but to navigate in non-linear > presentations too. Thanks, that sounds like a valid use case. So maybe we can do the same as we do with links, that you can do Ctrl-Click to follow the link (while a single click edits the link). So Ctrl-Click would execute the interaction while single click enters the frame edit mode. We also have an option to toggle that behavior (for links), maybe we can reuse that (or create a different option) if there is a need for people to have interactions executed with single click.
(In reply to Samuel Mehrbrodt (CIB) from comment #6) > So maybe we can do the same as we > do with links, that you can do Ctrl-Click to follow the link (while a single > click edits the link). Good idea and I'm always for consistency but wouldn't it be annoying when every time you click on such a frame the dialog pops up? So maybe ctrl+click in both edit and presentation mode, single click just selects, and to edit the reference you have to do it per main/context menu.
(In reply to Heiko Tietze from comment #7) > wouldn't it be annoying when every time you click on such a frame the dialog pops up? Ah what I meant that single click just enters the frame edit mode, like it places the cursor in the frame so that you can edit the text. Sure we don't want the hyperlink dialog each time you click on a hyperlink in a frame :)
Samuel Mehrbrodt committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/41a1a91b6ec08d78449a199ec300ff73c85dd148%5E%21 tdf#125748 Only execute frame interactions in presentation mode It will be available in 6.4.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
[ Ah fun - how can it be that I never stumbled over this issue ;) ]
I'm still not completely sure which solution is best here. I understand that these interactions are used to navigate in complex documents; so there is the requirement to be able to also execute them in edit mode. But if we use Ctrl-Click like we do for hyperlinks, we might get into issues when the textbox has an underlying link - which one should be activated in that case? The interaction on the frame, or the link inside the frame? Maybe having "Execute interaction" in the contextmenu would make more sense?
(In reply to Samuel Mehrbrodt (CIB) from comment #11) > Maybe having "Execute interaction" in the contextmenu would make more sense? +1, would call it "Open hyperlink".
(In reply to Heiko Tietze from comment #12) > (In reply to Samuel Mehrbrodt (CIB) from comment #11) > > Maybe having "Execute interaction" in the contextmenu would make more sense? > > +1, would call it "Open hyperlink". What about the other interaction types?
(In reply to Samuel Mehrbrodt (CIB) from comment #13) > What about the other interaction types? You mean Edit and Remove? Tbink we have those in other menus too. No concerns to add them when it's contextual.
(In reply to Heiko Tietze from comment #14) > (In reply to Samuel Mehrbrodt (CIB) from comment #13) > > What about the other interaction types? > > You mean Edit and Remove? Tbink we have those in other menus too. No > concerns to add them when it's contextual. Please go to the interaction dialog and see which interaction types you can select there.
(In reply to Samuel Mehrbrodt (CIB) from comment #15) > > You mean Edit and Remove? Tbink we have those in other menus too. No > > concerns to add them when it's contextual. > > Please go to the interaction dialog and see which interaction types you can > select there. You mean the various types of interaction such as jumping to slide <n> or play audio <s>? Don't see any reason to allow changing the properties outside the dialog. Edit opens this dialog, Remove sets it to None, and Open (when available) executes.
(In reply to Heiko Tietze from comment #16) > (In reply to Samuel Mehrbrodt (CIB) from comment #15) > > > You mean Edit and Remove? Tbink we have those in other menus too. No > > > concerns to add them when it's contextual. > > > > Please go to the interaction dialog and see which interaction types you can > > select there. > > You mean the various types of interaction such as jumping to slide <n> or > play audio <s>? Don't see any reason to allow changing the properties > outside the dialog. Edit opens this dialog, Remove sets it to None, and Open > (when available) executes. You suggested to name the execute action "Open hyperlink". That obviously would work only for one type of interaction. How would you deal with the other interaction types?
(In reply to Samuel Mehrbrodt (CIB) from comment #17) > You suggested to name the execute action "Open hyperlink". That obviously > would work only for one type of interaction. Good point - we cannot just copy what's used on other modules. So how about "Execute interaction" (to not have individual stings)? I dislike to alliteration of _E_xecute and _E_dit, so alternatively Start/Run/Execute Interaction.
Samuel Mehrbrodt committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/a08725165dfefa01dd491b3bd935d7a7d34b1877%5E%21 tdf#125748 Add context menu entry to execute interaction It will be available in 6.4.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Cherry-pick as late feature or resolve as fixed?
(In reply to Heiko Tietze from comment #20) > Cherry-pick as late feature or resolve as fixed? I would leave this only for 6.4 as I expect some more issues around this
Samuel Mehrbrodt committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/58f0144ae2136e07f6a6b9c22b6c0059fc4cb0c6%5E%21 Related tdf#125748 Reintroduce clickable image maps in sd It will be available in 6.4.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.