Bug 125748 - Interaction on frame should only be executed in presentation mode
Summary: Interaction on frame should only be executed in presentation mode
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Samuel Mehrbrodt (CIB)
URL:
Whiteboard: target:6.4.0
Keywords:
Depends on:
Blocks:
 
Reported: 2019-06-06 14:46 UTC by Samuel Mehrbrodt (CIB)
Modified: 2019-06-28 12:23 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments
Bugdoc (14.44 KB, application/vnd.oasis.opendocument.presentation)
2019-06-06 14:46 UTC, Samuel Mehrbrodt (CIB)
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Samuel Mehrbrodt (CIB) 2019-06-06 14:46:42 UTC
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.
Comment 1 Xisco Faulí 2019-06-06 16:08:15 UTC
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
Comment 2 Regina Henschel 2019-06-11 12:58:19 UTC
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".
Comment 3 Samuel Mehrbrodt (CIB) 2019-06-11 14:50:11 UTC
(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.
Comment 4 Regina Henschel 2019-06-11 15:49:15 UTC
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.
Comment 5 Heiko Tietze 2019-06-11 18:52:33 UTC
(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.
Comment 6 Samuel Mehrbrodt (CIB) 2019-06-12 06:54:17 UTC
(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.
Comment 7 Heiko Tietze 2019-06-12 07:14:04 UTC
(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.
Comment 8 Samuel Mehrbrodt (CIB) 2019-06-12 07:16:16 UTC
(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 :)
Comment 9 Commit Notification 2019-06-15 00:17:58 UTC
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.
Comment 10 Cor Nouws 2019-06-15 07:16:52 UTC
[ Ah fun - how can it be that I never stumbled over this issue ;) ]
Comment 11 Samuel Mehrbrodt (CIB) 2019-06-19 10:35:49 UTC
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?
Comment 12 Heiko Tietze 2019-06-19 12:16:40 UTC
(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".
Comment 13 Samuel Mehrbrodt (CIB) 2019-06-21 07:25:02 UTC
(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?
Comment 14 Heiko Tietze 2019-06-21 08:17:53 UTC
(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.
Comment 15 Samuel Mehrbrodt (CIB) 2019-06-21 08:20:57 UTC
(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.
Comment 16 Heiko Tietze 2019-06-21 15:33:19 UTC
(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.
Comment 17 Samuel Mehrbrodt (CIB) 2019-06-24 05:51:03 UTC
(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?
Comment 18 Heiko Tietze 2019-06-24 11:29:51 UTC
(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.
Comment 19 Commit Notification 2019-06-28 07:39:29 UTC
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.
Comment 20 Heiko Tietze 2019-06-28 09:24:13 UTC
Cherry-pick as late feature or resolve as fixed?
Comment 21 Samuel Mehrbrodt (CIB) 2019-06-28 09:55:55 UTC
(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
Comment 22 Commit Notification 2019-06-28 12:23:09 UTC
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.