#11984 NORM Future : Re-implement click-to-flash in Browse using DOM access

[Zarro Boogs per Child]

#11984: Re-implement click-to-flash in Browse using DOM access
---------------------------------------+------------------------------------
           Reporter:  dsd              |       Owner:  manuq         
               Type:  task             |      Status:  new           
           Priority:  normal           |   Milestone:  Future Release
          Component:  browse-activity  |     Version:  not specified 
         Resolution:                   |    Keywords:                
        Next_action:  code             |    Verified:  0             
Deployment_affected:                   |   Blockedby:                
           Blocking:                   |  
---------------------------------------+------------------------------------

Comment(by manuq):

 The bad news is that DOM access is not possible in WebKit2 :(  Reasons
 follow below.  The way webkitgtk developers plan to do each time something
 like this appears, is to add specific API.

 The reason for this, in words of webkitgtk+ developers:

 > Hrm... that approach (modifying the DOM) is going to be an issue for
 > sure with WebKit2, since DOM bindings are not supported yet, and it's
 > not clear whether they will be in the near future, even for other ports
 > (e.g. the mac).
 >
 > The reason for this is that manipulating the DOM is something that
 > should happen in the web process (where the render and the DOM trees
 > live), but the API you use from the browser is in the UI process and so
 > some kind of inter-process communication should be needed for that.
 >
 > But that's not per-se an issue (we use IPC all the time anyway), the big
 > problem is that modifying the DOM from the UI process would probably
 > required synchronous calls to methods in the web process, and so far
 > synchronous methods are not allowed in WebKit2. As per the WebKit2 page
 > in the TRAC [1]

 > "WebKit2 will provide a stable C-based non-blocking API that
 > is mostly platform agnostic. In order to achieve the goal of
 > a non-blocking API, several techniques are used to make the
 > API usable while still providing a comprehensive set of
 > features to the embedder."

 > So far, the approaches to this problem seem to be implementing specific
 > API when needed for those requirements detected when porting apps to
 > WK2. That's what Apple does so far, IIRC.

 > So, if modifying the DOM was the only option for implementing this
 > feature, I think adding specific API for that might be the way to go (so
 > it's not impossible to fix in any case).

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