Re: [tor-bugs] #2781 [Torbutton]: Review Robert Hogan's WebKit patches

["Tor Bug Tracker & Wiki" <torproject-admin@xxxxxxxxxxxxxx>]

#2781: Review Robert Hogan's WebKit patches
-------------------------------------------------------------------+--------
 Reporter:  mikeperry                                              |          Owner:  mikeperry
     Type:  task                                                   |         Status:  new      
 Priority:  normal                                                 |      Milestone:           
Component:  Torbutton                                              |        Version:           
 Keywords:  MikePerryIteration20110403 TorbuttonIteration20110403  |         Parent:           
   Points:  3                                                      |   Actualpoints:           
-------------------------------------------------------------------+--------

Comment(by mwenge):

 Replying to [comment:2 mikeperry]:
 > First off, it looks like the primary use of these APIs is for C++ front
 ends implementing the ChromeClient interface, right?

 Yes, and they could delegate it further, e.g. to extensions. This is the
 only way I can think of that allows a client, or a component in the
 client, to make decisions about DOM objects *and* CSS. I think the first
 two patches stand on their own in that regard. There may be better ways of
 delegating them to the client than I have come up with, but routing them
 to a part of WebKit that can at least talk to a WebKit browser is a good
 first step.


 >So each implementation would have to re-implement the QWebUserEnvironment
 interface in order to get their versions called by ChromeClient?

 Yes. A Qt-based browser would reimplement QWebUserEnvironment. But
 exposing stuff to ChromeClient and FrameLoaderClient means other WebKit
 ports, including Chromium's, could also delegate them to their clients.


 >
 > What was the discussion about Private APIs about? What is the difference
 between public and private APIs? Are private APIs only available to C++?

 In this case, it's an API that's exported but not documented. There are a
 couple of Qt-style ways of doing this, but it would be a useful of way
 putting the API to use, getting a feel for whether it works, before
 committing to it in public API which is often very hard to roll back from
 it's wrong.


 >
 > Does WebKit also provide window.screen.*? In Firefox, those values
 mirror a lot of the top level values here, including desktop resolution.

 They're the same object in WebKit.

 >
 > Also, I do not see you doing anything about screenX, screenY, and
 page[XY]Offset. You only appear to touch scrollX and Y? Is there a reason
 for this?

 Yes, they're already sourced from ChromeClient, so can be delegated from
 there to a public API.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/2781#comment:3>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs