#6825 BLOC 8.2.0 (: 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:  blocker          |   Milestone:  8.2.0 (was Update.2)             
  Component:  browse-activity  |     Version:  Development build as of this date
 Resolution:                   |    Keywords:  blocks:8.2.0, 8.2.0:? r?         
Next_action:  diagnose         |    Verified:  0                                
  Blockedby:                   |    Blocking:  7421                             
-------------------------------+--------------------------------------------

Comment(by Eben):

 This should be a pretty reliable solution in ''nearly'' all cases.
 Unfortunately,  we can't reliably tell the difference between windows
 invoked with the JS window.open method and those created with a targeted
 link.  The two things we know are
  1. The title of the window, either passed as a required argument to
 window.open, or specified as the target parameter on an <a> tag.
  2. A features string - containing size, position, chrome, and other
 window properties - passed as an optional parameter to window.open.

 The first of these allows us to detect when a special target (_blank,
 _top, etc.) is passed, in which case we assume that the window was opened
 from an <a> tag (and can be safely opened in place, since there is no JS
 communication between child/parent.).  However, we can't tell the
 difference between a named target and a window.open call.

 So the choice to make is whether we show anything window with a custom
 name in a popup (which is overly eager), or make the assumption that any
 window.open call that intends to facilitate further communication will
 include a features specification (which could miss some cases which depend
 on that communication).  This patch, and the opinion on Marco and I at
 present, is that the likelihood of these edge cases we could miss is
 ''extremely'' small, and so we take the risk.

 However, if it turns out that real-life experiences illustrate that is not
 the case, it should be a trivial task to err in the other direction.

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