#6825 HIGH Retriag: Problems with email webfrontend www.adinet.com.uy

[Zarro Boogs per Child]

#6825: Problems with email webfrontend www.adinet.com.uy
------------------------------+---------------------------------------------
  Reporter:  epastorino       |       Owner:  erikos                           
      Type:  defect           |      Status:  new                              
  Priority:  high             |   Milestone:  Retriage, Please!                
 Component:  browse-activity  |     Version:  Development build as of this date
Resolution:                   |    Keywords:  javascript browse activity bug   
  Verified:  0                |    Blocking:                                   
 Blockedby:                   |  
------------------------------+---------------------------------------------

Comment(by Eben):

 Unfortunately, this is a really hard problem for us.  Does anyone know how
 web kiosks handle this?  Looking around online, I found several references
 which state that they just don't at all, which is discouraging.

 Opening a new window in fullscreen isn't an attractive solution.  We tried
 this before and it led to a ''very'' confusing user experience, in large
 part because the fullscreen nature of the window prevented the user from
 understanding that it was a new instance.  The page nav stack got lost,
 and when the window was closed, the user wouldn't necessarily end up back
 in the previous instance.  It was quite disorienting.  It also goes
 against the session model, creating a separate instance, with separate
 sharing scope, and a separate Journal entry, counter to the goals of the
 Sugar activity model.  For that matter, does this even support the use
 case of parent/child window communication?  Under Rainbow, it shouldn't by
 definition.

 The next option we tried, and what I believe we do now, is simply ignore
 the request for a blank window and open the link within the current browse
 instance, simply adding it to the navigation stack like any other link.
 This has decent behavior someof the time, but obviously breaks when the
 site places dependency on child windows, requiring interaction between
 them and the parent.  I assume this is what gets us in trouble in both of
 the instances mentioned in this ticket.

 An option I would approve of (but which I admit might not even be
 possible...) would be to create a pseudo-window of some kind, which
 behaves in most ways like a popup window, but without actually being one.
 As a for instance, consider creating a DIV containing and IFRAME at the
 top level of the document, specifying a target for the iframe based on the
 name specified in the link, and subsequently aliasing this in some fashion
 such that any javascript references or link targets wind up referring to
 the IFRAME instead.  Special support could be added to this "wrapper" DIV
 to support drag'n'drop, resizing, etc.  The intended goal here is to
 provide a popup-like experience with a floating child window, without
 breaking from the single-window fullscreen model in actuality.

 Another option which relates closely to the above would be to achieve a
 similar, though slightly less elegant effect, by using frames split the
 page in two, keeping the parent on top and revealing the child window
 below.  I don't really like this solution much.

 Finally, if we decide to add true tab support, we ''might'' be able to get
 away with simply opening the popup in a new tab.  This has a few user
 experience problems akin to the first solution mentioned above, but at
 least it doesn't break the activity instance model, and it isn't quite as
 contradictory to the navigation stack, since the new tab will show up in
 context, and the parent page remains visibly accessible.  Unfortunately,
 even this might not always solve the problem.  I know Gmail does some
 magic which forces a popup for me in Safari, even when I explicitly hold
 down the command key to request that Safari open the link in a new tab...

 Obviously I'm nowhere close to solving this problem on my own.  It's a
 tricky one.  Thoughts on the pros/cons/feasibility of the above proposals
 are welcome.

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