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.

In addition to answers the most handy quick fix is to add

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}

enter image description here


  If[CurrentValue["MouseOver"], Red, Blue], [email protected], Line[{{0, 0}, {.5, 0}}]}],
  If[CurrentValue["MouseOver"], Red, Blue], Disk[{.5, 0}, .2]}]
  }, PlotRange -> {{0, .6}, {-.3, .3}}]

enter image description here

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

enter image description here or enter image description here

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):

enter image description here

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.

  • $\begingroup$ @m_goldberg Thank you again :) $\endgroup$
    – Kuba
    Commented Mar 9, 2014 at 21:20
  • 1
    $\begingroup$ 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. $\endgroup$
    – m_goldberg
    Commented Mar 9, 2014 at 21:35
  • 1
    $\begingroup$ Maybe I didn't test this correctly earlier on. With OS X 10.9.1 I get the error with both V8 and V9. $\endgroup$ Commented Mar 9, 2014 at 21:46
  • 1
    $\begingroup$ I have reported this behavior to WRI tech support. I will post their response upon receiving it. $\endgroup$
    – m_goldberg
    Commented Mar 9, 2014 at 22:27
  • $\begingroup$ 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. $\endgroup$
    – m_goldberg
    Commented Mar 27, 2014 at 3:16

3 Answers 3


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


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.


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

 Graphics[{Dynamic[{If[CurrentValue["MouseOver"], Red, Blue], 
     [email protected], 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.

  • $\begingroup$ I wasn't aware I could do this :) I have to read "Notebooks" tutorial one time :) Thanks :) $\endgroup$
    – Kuba
    Commented Mar 10, 2014 at 7:41
  • $\begingroup$ @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 :) $\endgroup$ Commented Mar 10, 2014 at 9:00

Quick fix is to add

 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.

  Cell[#, "Output", Deployed -> True, Selectable -> False] &,
     {Dynamic[{If[CurrentValue["MouseOver"], Red, Blue], 
               [email protected], 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.

  • $\begingroup$ 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. $\endgroup$ Commented Apr 4, 2014 at 10:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.