The "unexpectedly" part is not actionable without a way to reproduce. In general SolveSpace switches to the free in 3d mode by itself in one case: when there isn't a workplane available.

Okay, I found one case where this happens: I have a sketch without issues (that I know of). In this sketch there is an arc with both endpoints fixed. I set the center with a point-to-point coincidence, which over-constrains the sketch and I get an error. At this point I'm still in the workplane.

Now I undo. After the undo, I'm in 3D.

There must be some additional condition to make this happen, since I get the uncommanded transition to 3D under the above circumstances when deep in editing an-top.slvs, but not when I try this on a new sketch.

The plot thickens: the "undo" also changed the group (from g01f-sk-minus-base waaay out to g02d-balance). No surprise it doesn't find my old workplane there. The group change may in turn have been caused by reporting a transient SOLVE FAILURE of the #182 type.

Yes, that seems likely.

What are the exact steps to reproduce?

I put a snapshot where I stopped editing at the right moment into
https://gitlab.com/anelok/mexp.git at ebb4a394 (branch "193")

• solvespace alt13/an-top.slvs
• select g01f-sk-minus-base
• activate sk-minus-base workplane
• find r0b7-arc-of-circle (selected in picture)
• make center coincide (O) with "center of everything" (seleced in picture)
  
• sketch is now over-constrained: SOLVE FAILED!
• check that Sketch > still says "In Workplane"
• undo
• we're now greeted by a undo deletion leads to alarming complaints #182 type SOLVE FAILED!
  In the text window, we have transitioned to group g02d-balance (which is probably okay).
  In the group list, g01f-sk-minus-base is still active (also okay).
  And we're in Sketch > Workplane in 3d (surprise !)

Can you try this patch?

diff --git a/src/generate.cpp b/src/generate.cpp
index 00ec3708..9d62199c 100644
--- a/src/generate.cpp
+++ b/src/generate.cpp
@@ -499,6 +499,7 @@ void SolveSpaceUI::SolveGroupAndReport(hGroup hg, bool andFindFree) {
     bool isOkay = g->solved.how == SolveResult::OKAY ||
                   (g->allowRedundant && g->solved.how == SolveResult::REDUNDANT_OKAY);
     if(!isOkay || (isOkay && !g->IsSolvedOkay())) {
+        g->Activate();
         TextWindow::ReportHowGroupSolved(g->h);
     }
 }

Seems to have no effect. I.e., sk-minus-base is still the active group after the "undo" and #182.

Sorry, incomplete patch.

diff --git a/src/generate.cpp b/src/generate.cpp
index 00ec3708..8498033d 100644
--- a/src/generate.cpp
+++ b/src/generate.cpp
@@ -499,6 +499,8 @@ void SolveSpaceUI::SolveGroupAndReport(hGroup hg, bool andFindFree) {
     bool isOkay = g->solved.how == SolveResult::OKAY ||
                   (g->allowRedundant && g->solved.how == SolveResult::REDUNDANT_OKAY);
     if(!isOkay || (isOkay && !g->IsSolvedOkay())) {
+        SS.GW.activeGroup.v = hg.v;
+        g->Activate();
         TextWindow::ReportHowGroupSolved(g->h);
     }
 }

Now it works, thanks ! However, it makes #182 also a little weirder:

Activating the problem group (g02d-balance here) also clears the transient errors of #182 (all of them in this case, though I don't know if this would always be the reason). So the poor user gets teleported to another group for no apparent reason, i.e., there is no error page or any other indication anymore.

Upon returning to sk-minus-base, the workplane is set properly. So, while still confusing while #182 is around, it is an improvement.

@wpwrak Does this still happen after #182 is fixed? I'm not sure if this will ever appear without some other underlying bug.

@Evil-Spirit can you chime in?

@whitequark, ofc. Also, I have an opinion what we should not change 2d/3d (by pressing 2-3 keys) for the current group once we have choosen this.

@whitequark, this happens because of graphicswin.cpp:657. This is called from GenerateAll->SolveGroupAndReport->ReportHowGroupSolved->ClearSuper. It seems there is no reason to call EnsureValidActivities here. This function looks strange and perfrom a lot of strange things. I think this function needs to be refactored/split/renamed. At least one of part can be called "UpdateMenuCheckboxes". For now I have no idea how to properly fix it.

@Evil-Spirit thanks for investigation, I'll handle this from now on.