# Passing mouse related events broken by Deploy / Deployed->True

Bug reproduced in V9.0.1 and fixed in V11.1

This bug affects every part of GUI which is wrapped with Deploy as well as every Cell/Notebook/whatever with option Deployed->True. So it will affect e.g. all dialogs. Keep that in mind if you care about details in your GUI.

BaseStyle -> {Deployed -> False, Editable -> False,  Selectable -> False}


instead of Deploy or to replace Deployed->True, in appropriate places.

Here are two small examples:

-

Through[{Deploy, Identity} @ Graphics @ Table[
Tooltip[{EdgeForm@Thin, Hue[i], Rectangle[{0, 0}, {2 - i, i}]}, i],
{i, 0, 1, .1}
]]


-

Graphics[{
Dynamic[{
If[CurrentValue["MouseOver"], Red, Blue], Thickness@.05, Line[{{0, 0}, {.5, 0}}]}],
Dynamic[{
If[CurrentValue["MouseOver"], Red, Blue], Disk[{.5, 0}, .2]}]
}, PlotRange -> {{0, .6}, {-.3, .3}}]


You can put cursor over the Disk or Line. As you can see the Disk covers the Line, so you can only get:

or

But as soon as we add Deploy (Deploy@Graphics[...), the Disk becomes transparent to the "MouseOver" event, and we can get the following result (with cursor on the right place):

This behaviour is so unexpected, I'm tempted to call it a bug. This change in behaviour is huge!

In this context, Deploy as a quick and nice function seems to be unreliable. :/

The walkaround is similar like there: Delay of events detection dependent of “MouseDown” position. But I doubt the reason is the same.

• @m_goldberg Thank you again :) – Kuba Mar 9 '14 at 21:20
• I can confirm this behavior on V9.0.1 running on OS X. Further, it persists even when I put the disk and line each in their own Graphics expression and then display the two separated graphics with Show. I would call this behavior a bug. – m_goldberg Mar 9 '14 at 21:35
• Maybe I didn't test this correctly earlier on. With OS X 10.9.1 I get the error with both V8 and V9. – Mike Honeychurch Mar 9 '14 at 21:46
• I have reported this behavior to WRI tech support. I will post their response upon receiving it. – m_goldberg Mar 9 '14 at 22:27
• Nothing satisfactory. I got an answer saying "Just wanted to keep you posted that I have received your question and am currently working on it. ... I need to work on this a little longer to figure out the difference in behavior. I will keep you posted on what I find." After that, no follow up. Didn't think this was worth posting. Perhaps I should ping them on this. – m_goldberg Mar 27 '14 at 3:16

The problem seems to be that a TagBox that is generated is handled incorrectly by the front end. The TagBox has the form TagBox[bigExpr, Deploy, DefaultBaseStyle -> "Deploy"]. In this expression the second argument Deploy is quite meaningless. I couldn't trace any further than this TagBox as I cannot see how the front end handles it.

How the kernel handles Deploy is not secret. You can remove the attribute ReadProtected from Deploy to see how it is handled. The definition is quite simple. It refers to WrappersDump'WrapperToBoxes, which always continues using the following definition

WrappersDumpWrapperToBoxes[Deploy[BoxForme_],BoxFormfmt_]:=
TagBox[MakeBoxes[BoxForme,BoxFormfmt],Deploy,DefaultBaseStyle->"Deploy"]


This is where the evil TagBox is created. The way this is coded also seems to generate some unnecessary tests, but that is a different matter.

Workaround

Anyway, a workaround is to never generate such TagBoxes and generate inline cells instead. You can use deploy below instead of Deploy.

deploy /: MakeBoxes[deploy[expr_], form_] :=
Cell[BoxData[MakeBoxes[expr, form]], Selectable -> False, Deployed -> True]


This then gives you what you want

deploy@
Graphics[{Dynamic[{If[CurrentValue["MouseOver"], Red, Blue],
Thickness@.05, Line[{{0, 0}, {.5, 0}}]}],
Dynamic[{If[CurrentValue["MouseOver"], Red, Blue],
Disk[{.5, 0}, .2]}]}, PlotRange -> {{0, .6}, {-.3, .3}}]


It is basically doing what you were doing you were doing yourself :), maybe you thought of inline cells already.

By the way, because the definitions of Deploy are known, redefining Deploy by Unprotecting it should be quite predictable. Note that not every symbol that is ReadProtected shows all of its code, but I think Deploy does.

• I wasn't aware I could do this :) I have to read "Notebooks" tutorial one time :) Thanks :) – Kuba Mar 10 '14 at 7:41
• @Kuba no problem, I hope the solution will not have unexpected side effects, e.g. when non rectangular clickable things overlap. Time will tell I suppose :) – Jacob Akkerboom Mar 10 '14 at 9:00

 ContentSelectable -> False, ImageSize -> Dynamic[Automatic, None]


to Graphics options. Now the it is behaving well with exeption of orange frame that appears to allow you to change ImageSize, which is supressed by Dynamic[#, None].

More generic approach

Something strange is happening. When we set Deployed -> True and Selectable -> False for the cell it is working like one is expected. Why not with Deployed then?

Keep in mind it is not general solution since you can Deploy individual parts of the cell while this will set those options for the whole cell.

Composition[
CellPrint,
Cell[#, "Output", Deployed -> True, Selectable -> False] &,
BoxData,
MakeBoxes
][
Graphics[
{Dynamic[{If[CurrentValue["MouseOver"], Red, Blue],
Thickness@.05, Line[{{0, 0}, {.5, 0}}]}],
Dynamic[{If[CurrentValue["MouseOver"], Red, Blue], Disk[{.5, 0}, .2]}]},
PlotRange -> {{0, .6}, {-.3, .3}}]
]
`

I reported this to WRI tech support on March 9th and, finally received an answer today. As I promised in a comment to the question, here it is (somewhat edited).

My apologies for the delay in getting back to you.

Just wanted to let you know that I was unable to find a resolution for this issue and have forwarded an incident report to the development team.

We will keep you posted if a resolution becomes available in a future release of Mathematica. Sorry we could not offer a more satisfactory resolution.

It appears to me the tech support person who handled my report thought that Kuba's finding was a correctable error or had a simple work around and tried to come up with a solution, but failed, and finally reported the problem to the developers as a bug, which is what my report suggested.

• m_goldberg, thank you for your efforts to reach out to support. I hope support is becoming more and more aware that your emails are a valuable source of information. – Jacob Akkerboom Apr 4 '14 at 10:49