#9205 NORM 1.5-fut: Session hangs when Measure Activity is closed

[Zarro Boogs per Child]

#9205: Session hangs when Measure Activity is closed
---------------------------------+------------------------------------------
           Reporter:  mikus      |       Owner:  marco                            
               Type:  defect     |      Status:  reopened                         
           Priority:  normal     |   Milestone:  1.5-future                       
          Component:  sugar      |     Version:  Development build as of this date
         Resolution:             |    Keywords:                                   
        Next_action:  reproduce  |    Verified:  0                                
Deployment_affected:             |   Blockedby:                                   
           Blocking:             |  
---------------------------------+------------------------------------------
Changes (by Quozl):

  * priority:  blocker => normal
  * status:  closed => reopened
  * next_action:  never set => reproduce
  * resolution:  fixed =>
  * milestone:  Not Triaged => 1.5-future


Comment:

 Reopening following feedback by e-mail.

 Mikus wrote:
 > From the perspective of milestones, the problem was described on
 Joyride.  It is legitimate to close that ticket on the grounds that more
 recent builds have different code, so the *specific* situation (by a
 specific Activity, on a specific build) has been superseded.

 > From the perspective of usability, the *real* problem was that the
 system (not the Activity) had put up two dialog panels - and they
 deadlocked.  The second panel (which asked the user about "naming" the
 Journal __entry__) gave the user NO escape/abort provision; neither would
 it close itself as long as the Activity had not closed.  But that could
 not happen until the user answered the first panel (an error had occurred
 in saving the Activity's __data__; the first panel asked the user for an
 'ok').  The catch was that the second panel physically OBSCURED the first
 panel, such that the user could *NOT* access (on screen) the place in that
 first panel where his response was expected.

 > I was the originator of bug report #9205.  In my mind, I would have
 considered it justification for closing this bug report when the
 developers could assure system users that (in decreasing order of
 preference):  1) the "name this Journal entry" panel had been provided
 with a 'cancel' button;  or  2) the "name this Journal entry" panel had
 been re-positioned on the screen so that it would not obscure potential
 error notifications;  or  3) the "name this Journal entry" panel would be
 'serialized' so that it would not appear as long as there were other
 panels on screen.

-- 
Ticket URL: <http://dev.laptop.org/ticket/9205#comment:2>
One Laptop Per Child <http://laptop.org/>
OLPC bug tracking system