Re: [webkit-dev] Uint8ClampedArray: subtype of Uint8Array or not? (Was: Heads up: large typed array rewrite)

2013-08-14 Thread Jochen Eisinger
Adding Dmitry who recently updated the V8/blink implementation.

-jochen


On Wed, Aug 14, 2013 at 9:19 AM, Filip Pizlo fpi...@apple.com wrote:

 What WebKit previously did: Uint8ClampedArray is a subtype of Uint8Array,
 i.e. Uint8ClampedArray.prototype.__proto__ === Uint8Array.prototype.

 I believe that Chrome still does what WebKit does.

 What Firefox does: Uint8ClampedArray is not a subtype of Uint8Array, i.e.
 Uint8ClampedArray.prototype.__proto__ === Object.prototype.

 What http://www.khronos.org/registry/typedarray/specs/latest/ says:
 Uint8ClampedArray implements ArrayBufferView; but that says nothing about
 its subtype relationship, or lack thereof, with Uint8Array.

 I prefer the Firefox semantics.  Any objections?

 -Filip


 On Aug 13, 2013, at 11:19 AM, Filip Pizlo fpi...@apple.com wrote:

 Hi everyone!

 For the past week or so I've been working on making typed arrays faster,
 use less memory, and GC better.  It involves moving typed arrays entirely
 into JSC, and rewriting them so that they benefit from JSC object model
 optimizations.

 Link: https://bugs.webkit.org/show_bug.cgi?id=119064

 The short story is, if you're not on the Mac port, then I'll try to do my
 best to make things work but I'm probably going to make some mistakes.  I'm
 probably about 48 hours away from landing this and I'll try to make myself
 available to fix any fall-out.  The things I'm most likely to get wrong
 are: ensuring that the various code generators work on all build systems;
 ensuring that the ~20-some files I've added and the ~20-sime files I've
 deleted, are actually added/deleted correctly on all builds; and making
 sure that some of the crazy template hacks that I've used work on all
 compilers.

 Why this is all worth it:

 It makes typed arrays faster: you can now allocate typed arrays up to 8x
 faster if they're small, and up to 6x faster if they're big.  Neutering no
 longer requires walking all worlds. Wrapping and unwrapping an array buffer
 no longer requires hash look-ups for the normal world.  And some other
 stuff, too.

 It makes typed arrays use less memory: previously a typed array could use
 as many as 7 objects for each allocation; at best you'd get 5 (JS array
 buffer view wrapper, native array buffer view wrapper, weak handle to link
 the two, native array buffer, native array buffer contents).  Now, it takes
 just 2 objects in the common case (JS array buffer view and a copy-space
 backing store) and 3 in the case of large ones (JS array buffer view, weak
 handle for a finalizer, and a malloc'd backing store).  You'll still get
 all of the crazy objects - at most 6 of them - if you use the full power of
 typed array APIs.  With all of this in place, a typed array carries only 32
 bytes of overhead on 64-bit systems and 20 bytes of overhead on 32-bit
 systems.  It was *a lot* more than that before.

 It makes typed arrays manage memory properly: previously the GC didn't
 know that typed arrays use memory.  So, although the GC could free the
 memory that typed arrays used, it wouldn't kick in properly in some cases.
  See https://bugs.webkit.org/show_bug.cgi?id=119049 and
 https://bugs.webkit.org/show_bug.cgi?id=114824.  This patch fixes these
 issues comprehensively.

 It makes the code more hackable: previously any attempt to optimize any
 typed array hack required grappling with binding code generation, layering
 violations that exposed the typed arrays to JSC JITs despite not being
 defined in JSC, and a grab-back of helper code that the bindings magically
 invoked.  There was a lot of duplicated code to deal with the various types
 of typed arrays.  Now, typed arrays are all templatized; you usually only
 write a piece of code once thanks to the wonders of template polymorphism.

 This also fixes a bunch of semantics issues, with how typed array fields
 work in JS and when/where exceptions ought to be thrown.  In this regard,
 I'm basically attempting to match Firefox behavior since that's where the
 standards appear to be going.

 I hope that I get all of this to work on all platforms on the first try.
  If I don't, I apologize in advance, and I'll try to be around to help the
 fall-out.

 -Filip___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev



 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] restricting the number of new windows created in response to a user gesture

2013-04-12 Thread Jochen Eisinger
Hi,

currently, WebKit allows for an arbitrary number of new windows to be
created in response to a single user gesture. This is used for example to
create pop-unders.

In order to restrict the number of new windows to one per user gesture, a
port needs to invoke UserGestureIndicator::consumeUserGesture() in it's
ChromeClient::createWindow method.

In https://bugs.webkit.org/show_bug.cgi?id=114379 I add this for WK2 and
for WK1 mac/win.

Are other ports interested in this behavior? If not, I'd just skip the
corresponding tests.

There are some gotchas: e.g. if your port is using out of process plugins,
and the plugin wants to react to a user gesture, you're probably storing
whether WebKit is processing a user gesture before calling out to the
plugin, and restore a UserGestureIndicator once the plugin replies. To make
sure a plugin cannot use this to generate additional user gestures (after
the original user gesture was already consumed), you should store the
UserGestureIndicator::currentToken() and use that to create the
UserGestureIndicator (it's basically a ref-counted integer of how many
gestures are left to consume).

best
-jochen
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] restricting the number of new windows created in response to a user gesture

2013-04-12 Thread Jochen Eisinger
On Fri, Apr 12, 2013 at 10:40 PM, Brady Eidson beid...@apple.com wrote:


 On Apr 12, 2013, at 5:05 AM, Jochen Eisinger joc...@chromium.org wrote:

 Hi,

 currently, WebKit allows for an arbitrary number of new windows to be
 created in response to a single user gesture. This is used for example to
 create pop-unders.

 In order to restrict the number of new windows to one per user gesture, a
 port needs to invoke UserGestureIndicator::consumeUserGesture() in it's
 ChromeClient::createWindow method.

 In https://bugs.webkit.org/show_bug.cgi?id=114379 I add this for WK2 and
 for WK1 mac/win.

 Are other ports interested in this behavior? If not, I'd just skip the
 corresponding tests.


 I'm not sure it's the right move to force this on any port.  Some ports
 might be interested, for example, in not breaking legitimate intranet tools
 that use multiple pop-ups/unders.


Right, that was my question: which ports are not interested, so I don't
enable it for them.




 There are some gotchas: e.g. if your port is using out of process plugins,
 and the plugin wants to react to a user gesture, you're probably storing
 whether WebKit is processing a user gesture before calling out to the
 plugin, and restore a UserGestureIndicator once the plugin replies. To make
 sure a plugin cannot use this to generate additional user gestures (after
 the original user gesture was already consumed), you should store the
 UserGestureIndicator::currentToken() and use that to create the
 UserGestureIndicator (it's basically a ref-counted integer of how many
 gestures are left to consume).


 Skipping tests is one thing.  It's definitely not okay to break
 functionality in a port like this.


I guess the paragraph was unclear: it's not breaking functionality. The out
of process plugin code already has the logic to create a
UserGestureIndicator.

I tried to explain that by using a plugin, a website can work around the
restriction (which is already true now).



 ~Brady


 best
 -jochen
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev



___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] restricting the number of new windows created in response to a user gesture

2013-04-12 Thread Jochen Eisinger
On Fri, Apr 12, 2013 at 10:58 PM, Benjamin Poulain benja...@webkit.orgwrote:

 On Fri, Apr 12, 2013 at 5:05 AM, Jochen Eisinger joc...@chromium.orgwrote:

 currently, WebKit allows for an arbitrary number of new windows to be
 created in response to a single user gesture. This is used for example to
 create pop-unders.

 In order to restrict the number of new windows to one per user gesture, a
 port needs to invoke UserGestureIndicator::consumeUserGesture() in it's
 ChromeClient::createWindow method.

 In https://bugs.webkit.org/show_bug.cgi?id=114379 I add this for WK2 and
 for WK1 mac/win.

 Are other ports interested in this behavior? If not, I'd just skip the
 corresponding tests.


 I am confused.
 Why do you want to add something even in the case no port would be
 interested?


If indeed no port is interested, I would instead remove the consumable user
gesture code (since it was only used by chromium).

-jochen



 Benjamin

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Somewhat painful AppEngine transitions coming [Caution: Message contains Suspicious URL content]

2013-04-11 Thread Jochen Eisinger
At least the test-results.appspot.com instance is also used by chromium and
blink bots.

best
-jochen


On Thu, Apr 11, 2013 at 8:48 AM, Osztrogonác Csaba o...@inf.u-szeged.huwrote:

 Hi,

 Just out of curiosity, isn't simpler deliver the ownership of
 these apps from Google to Apple instead of starting new apps?

 Ossy

 Ryosuke Niwa írta:

 Hi,

 I've started moving Google owned 
 http://test-results.appspot.**comhttp://test-results.appspot.comand
 http://webkit-commit-queue.**appspot.comhttp://webkit-commit-queue.appspot.comto
  Apple owned
 http://webkit-test-results.**appspot.comhttp://webkit-test-results.appspot.comand
 http://webkit-queues.appspot.**com 
 http://webkit-queues.appspot.comrespectively.

 Ojan and I have already moved the flakiness dashboard to
 http://webkit-test-results.**appspot.comhttp://webkit-test-results.appspot.comso
  builders on
 build.webkit.org http://build.webkit.org have started uploading
 results there.  Unfortunately, the historical results are still on
 http://test-results.appspot.**com http://test-results.appspot.com so
 we probably need to use both websites for the next couple of weeks.

 Moving 
 http://webkit-commit-queue.**appspot.comhttp://webkit-commit-queue.appspot.comis
  a little tricker because it involves moving off EWS bots as well.  My
 current plan is to modify Bugzilla so that it'll show two sets of bubbles
 for both websites during the transition.

 I expect this transition to be somewhat painful and you may feel cause a
 great disturbance in the force.  I'll do my best to minimize the damage.

 - R. Niwa

 __**_
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/**mailman/listinfo/webkit-devhttps://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Best way to disable JavaScript

2013-03-19 Thread Jochen Eisinger
On Tue, Mar 19, 2013 at 11:42 AM, Maciej Stachowiak m...@apple.com wrote:


 On Mar 19, 2013, at 11:12 AM, Geoffrey Garen gga...@apple.com wrote:

 In case it's not clear from this message (and my previous messages), I
 object to this change.


 Your objections seem to pertain to CSP. I've excluded CSP from the
 proposal.

 Do you still object in some way? If so, why?


 Adam also cited the Chromium WebKit
 allowScriptFromSource/didNotAllowScript API.

 From looking at how it hooks into WebCore, it appears to require the
 decision to execute a script to be dynamic, even when scripting is
 generally disabled.


We implement a rule system (called content settings) where script execution
(but also e.g. cookies) can be controlled depending on the security origin
of the frame, and the security origin of the main frame. This allows for
allow scripts from the main frame's security origin to run, while
third-party scripts are blocked.

FrameLoaderClient::allowScript implements this check.

Now if the script is from a third-party, it might still be executed in the
context of the main frame (because it was loaded via a script tag from a
third-party site). This seems undesirable, and so we added
allowScriptFromSource to control this behavior.

didNotAllowScript is used to notify the browser that script execution was
blocked. In that case, we show a small icon in the location bar which
hopefully gives the user a hint at why everything is broken, and offers a
quick option to enable javascript for this site.

best
-jochen



 Regards,
 Maciej


 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Best way to disable JavaScript

2013-03-19 Thread Jochen Eisinger
On Tue, Mar 19, 2013 at 2:50 PM, Geoffrey Garen gga...@apple.com wrote:

 Hi Jochen.

  Adam also cited the Chromium WebKit
 allowScriptFromSource/didNotAllowScript API.

 From looking at how it hooks into WebCore, it appears to require the
 decision to execute a script to be dynamic, even when scripting is
 generally disabled.


 We implement a rule system (called content settings) where script
 execution (but also e.g. cookies) can be controlled depending on the
 security origin of the frame, and the security origin of the main frame.
 This allows for allow scripts from the main frame's security origin to run,
 while third-party scripts are blocked.


 To clarify, do you expect both allowScriptFromSource and didNotAllowScript
 to fire when JavaScript is disabled? If JavaScript is disabled,
 but allowScriptFromSource returns true, do you expect the script to execute
 or not?


What can happen is that in ScriptElement::prepareScript() the call to
canExecuteScript (which calls allowScript internally) returns false. In
that case, we don't load the external script, and so allowScriptFromSource
is not invoked. didNotAllowScript however was already invoked by
canExecuteScript after allowScript returned false.

Does that answer your question?

-jochen



 Thanks,
 Geoff

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Best way to disable JavaScript

2013-03-18 Thread Jochen Eisinger
On Sun, Mar 17, 2013 at 8:26 PM, Geoffrey Garen gga...@apple.com wrote:

 Hi folks.

 Currently, we have two different ways to disable JavaScript execution:

 (1) Paste / Drag n Drop / editing: Remove script elements and script
 attributes from untrusted source markup at parse time.

 (2) JavaScript disabled setting / Content Security Policy: Check settings
 and/or CSP at runtime.

 There are problems with mode (2):

 * It breaks features that are implemented in JavaScript.

 The Web Inspector, bookmarklets, extensions, Safari Reader, and Safari
 autofill all run JavaScript. This means that they break when users disable
 JavaScript.


I'm not sure I understand:

We only invoke canExecuteScript for scripts in the main world, so running
extensions (or anything else that's running in an isolated world) should
not be affected.

Also, the actual permission check is done via
FrameLoaderClient::allowScript and ::allowScriptFromSource, so blocking
e.g. only scripts from the web, but not from the inspector should also be
possible.

best
-jochen


 As a defense against phishing attacks, mail clients and other web content
 readers disable JavaScript. This means that they can't implement pieces of
 their UI in JavaScript.

 (FWIW, WebKit violates the CSP specification in this regard: Enforcing a
 CSP policy should not interfere with the operation of user-supplied scripts
 such as third-party user-agent add-ons and JavaScript bookmarklets.)

 * It subjects users to XSS attacks.

 Runtime checking mode leaves inert JavaScript in the untrusted document.
 This is a risky proposition. Operations that clone or adopt nodes from the
 untrusted document unwittingly re-vivify that inert JavaScript, subjecting
 the user to attack. Experience shows that this is a difficult programming
 model to get right.

 * It's hard to verify.

 We have 18 different call sites to canExecuteScripts() in WebKit, not
 counting the call sites that pertain to plug-ins. Are you confident we've
 caught all the right places? Do you know if the feature you just added
 needs to call canExecuteScripts()?

 * It's two different ways to do the same thing.

 Simplicity is a goal of the WebKit project.


 Proposal:

 If -- for any reason -- JavaScript is disabled in a given document, the
 document parser will elide all JavaScript. This means that runtime checks
 can be removed.

 One potential downside to this proposal is that it changes the document's
 internal structure. Since the changes are not generally observable, since
 they only take place when we're already making much bigger changes by
 preventing whole scripts from running, and since we haven't seen any
 compatibility problems from our paste / drag n drop / editing behavior in
 this regard, I think this downside is acceptable.

 Another potential downside is that CSP errors will be reported at parse
 time instead of runtime. FWIW, some authors might see this as an upside.

 Any objections?

 Thanks,
 Geoff
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Best way to disable JavaScript

2013-03-18 Thread Jochen Eisinger
On Mon, Mar 18, 2013 at 7:27 AM, Arunprasad Rajkumar ararunpra...@gmail.com
 wrote:



 On 18 March 2013 13:00, Jochen Eisinger joc...@chromium.org wrote:




 On Sun, Mar 17, 2013 at 8:26 PM, Geoffrey Garen gga...@apple.com wrote:

 Hi folks.

 Currently, we have two different ways to disable JavaScript execution:

 (1) Paste / Drag n Drop / editing: Remove script elements and script
 attributes from untrusted source markup at parse time.

 (2) JavaScript disabled setting / Content Security Policy: Check
 settings and/or CSP at runtime.

 There are problems with mode (2):

 * It breaks features that are implemented in JavaScript.

 The Web Inspector, bookmarklets, extensions, Safari Reader, and Safari
 autofill all run JavaScript. This means that they break when users disable
 JavaScript.


 I'm not sure I understand:

 We only invoke canExecuteScript for scripts in the main world, so running
 extensions (or anything else that's running in an isolated world) should
 not be affected.


 Inspector injected scripts will be in main-world right? Sorry in-case I'm
 wrong :)



AFAIK they're in an isolated world (of course unless you type some
javascript into the console, that would be executed in the main world and
then be blocked)

If the inspector scripts were injected into the main world, the page could
mess with them

And the inpsector frontend is also running its scripts in the main world,
but that is easy to whitelist.

-jochen



  Also, the actual permission check is done via
 FrameLoaderClient::allowScript and ::allowScriptFromSource, so blocking
 e.g. only scripts from the web, but not from the inspector should also be
 possible.

 best
 -jochen


 As a defense against phishing attacks, mail clients and other web
 content readers disable JavaScript. This means that they can't implement
 pieces of their UI in JavaScript.

 (FWIW, WebKit violates the CSP specification in this regard: Enforcing
 a CSP policy should not interfere with the operation of user-supplied
 scripts such as third-party user-agent add-ons and JavaScript
 bookmarklets.)

 * It subjects users to XSS attacks.

 Runtime checking mode leaves inert JavaScript in the untrusted document.
 This is a risky proposition. Operations that clone or adopt nodes from the
 untrusted document unwittingly re-vivify that inert JavaScript, subjecting
 the user to attack. Experience shows that this is a difficult programming
 model to get right.

 * It's hard to verify.

 We have 18 different call sites to canExecuteScripts() in WebKit, not
 counting the call sites that pertain to plug-ins. Are you confident we've
 caught all the right places? Do you know if the feature you just added
 needs to call canExecuteScripts()?

 * It's two different ways to do the same thing.

 Simplicity is a goal of the WebKit project.


 Proposal:

 If -- for any reason -- JavaScript is disabled in a given document, the
 document parser will elide all JavaScript. This means that runtime checks
 can be removed.

 One potential downside to this proposal is that it changes the
 document's internal structure. Since the changes are not generally
 observable, since they only take place when we're already making much
 bigger changes by preventing whole scripts from running, and since we
 haven't seen any compatibility problems from our paste / drag n drop /
 editing behavior in this regard, I think this downside is acceptable.

 Another potential downside is that CSP errors will be reported at parse
 time instead of runtime. FWIW, some authors might see this as an upside.

 Any objections?

 Thanks,
 Geoff
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev



 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev




 --
 *Arunprasad Rajkumar*
 http://in.linkedin.com/in/ararunprasad

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Best way to disable JavaScript

2013-03-18 Thread Jochen Eisinger
On Mon, Mar 18, 2013 at 9:49 AM, Elliott Sprehn espr...@chromium.orgwrote:


 On Sun, Mar 17, 2013 at 8:26 PM, Geoffrey Garen gga...@apple.com wrote:

 ...

 There are problems with mode (2):

 * It breaks features that are implemented in JavaScript.

 The Web Inspector, bookmarklets, extensions, Safari Reader, and Safari
 autofill all run JavaScript. This means that they break when users disable
 JavaScript.


 The web inspector works even with JS disabled in Safari (I filed the very
 first bug about this actually back when it crashed :)) and I just tested
 and Reader works fine too.

 Are there any examples of browser provided UI that actually breaks with JS
 disabled? I'm pretty sure those all run in different worlds.


in chromium, e.g. the ftp directory listing is generating by javascript
running on the page in the main world (so we whitelist directory listings
for javascript blocking)

-jochen


 - E

 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Chromium's TestRunner library is now a component!

2013-02-11 Thread Jochen Eisinger
Hi,

the TestRunner library used by chromium's DumpRenderTree is now a component
(i.e. it builds as a DLL on Windows). It defines all the test runner
objects such as testRunner or eventSender and is implemented entirely in
terms of the public chromium WebKit API (i.e. it has no dependencies on WTF
or WebCore, nor chromium's webkit_support for that matter).

If you need to add a method to e.g. eventSender, and it's only using the
public WebKit API, you can just add it to
Tools/DumpRenderTree/chromium/TestRunner/src/EventSender.cpp.

If your method needs to interact with a WebFrameClient or WebViewClient
callback or return a mock from such a callback, you can modify the
WebTestProxy, a template that is injected between the WebView / WebFrame
and the actual implementation in TestShell / ContentShell.

If you want to add something that depends on interactions with the embedder
(TestShell / ContentShell), you should add a callback to the
WebTestDelegate.

best
-jochen
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Can Qt use some of the common DRT code?

2013-02-10 Thread Jochen Eisinger
On Mon, Feb 11, 2013 at 3:37 AM, Benjamin Poulain benja...@webkit.orgwrote:

 Hi,

 Today, adding a support for a new function in TestRunner requires
 (painfully) changing:
 -WebKitTestRunner.
 -Common DRT + 6 implementations (Mac, Win, GTK, EFL, WX, Blackberry).
 -Chromium DRT.
 -Qt DRT.
 I think we can do much better. A first step is to have more common code in
 DRT.


Another option is to add the new functionality to window.internals, and
only change DRT for test code that is port specific or supposed to test a
port's WebKit API.

best
-jochen



 One of the differences is the way the Qt port works. Instead of using the
 JSC binding APIs, it uses its own JS Qt bindings.
 Would it be possible for Qt to move to the common code? It would make
 future refactoring easier as there would be one less difference to care
 about.

 Benjamin

 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Can Qt use some of the common DRT code?

2013-02-10 Thread Jochen Eisinger
On Mon, Feb 11, 2013 at 8:19 AM, Benjamin Poulain benja...@webkit.orgwrote:

 On Sun, Feb 10, 2013 at 10:56 PM, Jochen Eisinger joc...@chromium.orgwrote:

 Today, adding a support for a new function in TestRunner requires
 (painfully) changing:
 -WebKitTestRunner.
 -Common DRT + 6 implementations (Mac, Win, GTK, EFL, WX, Blackberry).
 -Chromium DRT.
 -Qt DRT.
 I think we can do much better. A first step is to have more common code
 in DRT.


 Another option is to add the new functionality to window.internals, and
 only change DRT for test code that is port specific or supposed to test a
 port's WebKit API.


 Isn't that what we already do?
 If someone intentionally choose DRT over internals, she/he is courageous :)


I'm not sure I understand. In what cases do you then add something to DRT
and need to change all of them?

best
-jochen



 Benjamin

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Exporting symbols (was Re: Common build system (was Re: WebKit Wishes))

2013-02-04 Thread Jochen Eisinger
On Sun, Feb 3, 2013 at 7:29 AM, Benjamin Poulain benja...@webkit.orgwrote:

 On Sat, Feb 2, 2013 at 10:23 PM, Eric Seidel e...@webkit.org wrote:

 What I've learned from this thread, is that AppleWin and AppleMac are the
 only two ports which require lists of exported symbols.  If both were to
 convert to using EXPORT decorators instead, then we could remove needs for
 fixing export lists.

 Please correct me if I've misunderstood.


 There is also iOS. The export file contains both Mac and iOS, they do not
 export the same symbols.

  There is unfortunately a need to have different exports for per platform;
 the syntax will probably have to account for that.


Just to clarify: there's code that is used on e.g. Mac but not iOS, but
it's still compiled into the iOS port (i.e. not disabled by some feature
macro anyway)?

best
-jochen




 Benjamin

 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Common build system (was Re: WebKit Wishes)

2013-01-31 Thread Jochen Eisinger
On Thu, Jan 31, 2013 at 9:53 AM, Mark Rowe mr...@apple.com wrote:


 On 2013-01-31, at 00:48, Adam Barth aba...@webkit.org wrote:

  I would consider changing or improving gyp's syntax to be on the table
  if it was needed to reach the goal.
 
  For what it’s worth, I also find the gyp syntax to be unpleasant. It
 feels as though it was optimized for being processed by a machine rather
 than for being written and maintained by humans.
 
  Unlike xcodeproj files.  :)

 Don’t get me wrong, Xcode projects suck for hand-editing too. However,
 they’re not intended to be edited by hand. Gyp files are, and so the
 expected level of human readability is much higher.


Many of us are actually editing the Xcode projects by hand, either because
they don't have Xcode or don't know how to use it. (Yes, that includes
coming up with a bunch of new UUIDs by hand)

best
-jochen
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Common build system (was Re: WebKit Wishes)

2013-01-31 Thread Jochen Eisinger
On Thu, Jan 31, 2013 at 10:12 AM, Mark Rowe mr...@apple.com wrote:


 On 2013-01-31, at 00:59, Jochen Eisinger joc...@chromium.org wrote:



 On Thu, Jan 31, 2013 at 9:53 AM, Mark Rowe mr...@apple.com wrote:


 On 2013-01-31, at 00:48, Adam Barth aba...@webkit.org wrote:

  I would consider changing or improving gyp's syntax to be on the table
  if it was needed to reach the goal.
 
  For what it’s worth, I also find the gyp syntax to be unpleasant. It
 feels as though it was optimized for being processed by a machine rather
 than for being written and maintained by humans.
 
  Unlike xcodeproj files.  :)

 Don’t get me wrong, Xcode projects suck for hand-editing too. However,
 they’re not intended to be edited by hand. Gyp files are, and so the
 expected level of human readability is much higher.


 Many of us are actually editing the Xcode projects by hand, either because
 they don't have Xcode or don't know how to use it. (Yes, that includes
 coming up with a bunch of new UUIDs by hand)


 I wasn’t trying to suggest that current situation is a good one, only that
 if it would be easier to get momentum on switching to something like gyp if
 the replacement’s syntax was friendlier. Particularly when the people that
 need to be convinced to switch, and who’ll have to adapt their workflow,
 are those that are editing the project files in a nice GUI.


Agreed.

Another option is to add a webkit-patch command for modifying the build
files. That way, the syntax doesn't need to be overly human friendly. There
was also some attempt to write a tool to add files automatically:
https://bugs.webkit.org/show_bug.cgi?id=61772  I would expect that such a
tool becomes easier if it would only modify one source of truth and
generates all other artifacts such as Xcode projects from it.

best
-jochen




 - Mark


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Common build system (was Re: WebKit Wishes)

2013-01-31 Thread Jochen Eisinger
On Thu, Jan 31, 2013 at 10:37 AM, Ryosuke Niwa rn...@webkit.org wrote:

 On Thu, Jan 31, 2013 at 1:17 AM, Jochen Eisinger joc...@chromium.orgwrote:

 Another option is to add a webkit-patch command for modifying the build
 files. That way, the syntax doesn't need to be overly human friendly. There
 was also some attempt to write a tool to add files automatically:
 https://bugs.webkit.org/show_bug.cgi?id=61772  I would expect that such
 a tool becomes easier if it would only modify one source of truth and
 generates all other artifacts such as Xcode projects from it.


 I don't want build file's syntax to be so human unfriendly that I need a
 tool for it.

 Often times, these syntax problems can be improved dramatically by simple
 changes. e.g. we had a similar discussion about TestExpectation syntax, and
 I'm much happier with the new syntax even though the new syntax is
 functionally equivalent to the old one, and two syntaxes are very similar.


I totally agree. I guess I just failed at finding the right words.

-jochen



 On Thu, Jan 31, 2013 at 1:17 AM, Mark Rowe mr...@apple.com wrote:

 I’ve experimented with this in the past and you’re right that it
 shouldn’t be particularly difficult to do. However, I suspect that the task
 would be similar in scope to defining an improved syntax for gyp. And if
 the syntax is the primary sticking point with gyp then it’d seem preferable
 to tackle initially.


 Yeah. In fact, we can just come up with whatever syntax we like and
 convert it to the existing gyp format if the syntax was the biggest issue.

 - R. Niwa


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Common build system (was Re: WebKit Wishes)

2013-01-30 Thread Jochen Eisinger
On Thu, Jan 31, 2013 at 1:15 AM, Maciej Stachowiak m...@apple.com wrote:


 On Jan 30, 2013, at 3:24 PM, Dirk Pranke dpra...@chromium.org wrote:

  On Wed, Jan 30, 2013 at 1:50 PM, Filip Pizlo fpi...@apple.com wrote:
  Thanks for sharing this.
 
  On Jan 30, 2013, at 1:28 PM, Eric Seidel e...@webkit.org wrote:
 
  I wish we only had one build system (it were easy to add/remove/move
 files).
 
  I believe changes like http://trac.webkit.org/changeset/74849 are an
  unhealthy sign for the project.  Adam is not the only person who has
 chosen
  to empty files instead of removing them.  The pain of updating 8 build
  system is so great, we jump through hoops to avoid it.  Which means it
 took
  us months to move JavaScriptCore/wtf to WTF, and will take us years to
 kill
  WebCore/platform.
 
 
  +1
 
  This is a hard problem.  It is a problem worth solving.
 
  Do you have more thoughts on this, particularly since you know quite
 well
  how both Xcode and gyp work?
 
  I suspect this is one of those things that it would be hard to achieve
  consensus on since there are so many stakeholders.  But it may be
 fruitful
  to have a what if discussion about what this might look like.
 
 
  I think we can solve this problem if we agree that we want to. I think
  we haven't in the past mostly because we couldn't reach a consensus
  that it was worth solving enough to really try.
 
  I would love to see this fixed and would be glad to work on it. I
  think we should at least pursue this far enough to fully understand
  what our options are and what the costs and tradeoffs might be; does
  anyone disagree, and is anyone else willing to help pitch in?
 
  I think there are several possible ways we could solve this. One would
  be to switch to a common meta-build system. My understanding is that
  Apple's internal production build processes impose certain constraints
  here that I don't fully understand, but I know we've discussed the
  possibility of checking in generated project files as a workaround.
  Maybe there are other options as well to those constraints? I would
  love to discuss this further w/ someone from Apple ...

 It's far simplest for us if:
 (a) There is an Xcode project (or a Makefile) that builds the Mac port
 checked in to source control.
 (b) The generated project invokes only tools that are part of the default
 Mac OS X install.


Another desirable property would be to move to a more automatic way of
handling exported symbols: Currently each port that depends on this feature
has its own .exp file or similar. I think if we could move to something
that would allow for changing WebCore API without having to touch all those
files, e.g. by consistently using WEBCORE_EXPORT macros would be a big win

best
-jochen



 It may not be completely impossible to violate these requirements but it
 will require a lot of bureaucracy.

  (Also, just to get this out of the way, I don't think gyp needs to be
  the solution).
 
  Another alternative would be to write a script that did support at
  least the common use cases (add/move/delete files). There have been
  attempts in the past, but they have foundered on at least some
  perceived skepticism over how well this would work w/ XCode. That
  said, I don't think we've really pushed this to see. At some point
  this script might turn into a meta-meta-build system, which might be
  silly but also be the shortest path to the finish line.
 
  I suggest if there is interest in this we can start a new thread to
  discuss further ...

 My preference would be to use a common meta-build system with a
 comfortably human-readable and human-editable syntax, and checked in
 generated project files for those ports that need them.

 I think a key to making this work is to get Chromium and the Apple Mac
 port onto a common build system, which will probably require both Google
 and Apple ponying up at least one person to work on this project for a
 reasonable period of time.

 I think the plausible meta-build-systems to use would be CMake and Gyp,
 but in both cases it may be necessary to modify them to work well for
 everyone.

 I'd also like to add that I think a key related issue to common build
 system is common feature configuration. The many different ways ports
 control their feature flags is super confusing. I've long wanted to
 implement common configuration management, but have not had time.

 Cheers,
 Maciej



 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Can we remove Notification.show()?

2013-01-28 Thread Jochen Eisinger
On Mon, Jan 28, 2013 at 11:19 PM, Elliott Sprehn espr...@chromium.orgwrote:

 This seems like a badly designed API, constructors shouldn't have side
 effects and not having show() means after calling close() the notification
 object is useless which is silly.


In the new API, there's also no close() method...

-jochen




 On Mon, Jan 28, 2013 at 4:35 AM, Andrew Wilson atwil...@google.comwrote:

 So, we've recently landed some fixes to address permissions handling for
 Notification.show(): http://trac.webkit.org/changeset/140927

 Turns out, the notifications specification does not have a show() API
 (the notification is automatically shown from the constructor --
 http://notifications.spec.whatwg.org/#api). Does anyone have any
 objections to moving the show() API under the ENABLE_LEGACY_NOTIFICATIONS
 flag to bring us under compliance with the spec?

 Also, it looks like if a platform enables ENABLE_LEGACY_NOTIFICATIONs,
 not only do they get support for the old webkitNotifications API, but also
 some of the old API (like show() and cancel()) is exposed on the new
 Notifications objects, because we share the same interface for
 webkitNotifications and Notifications. Do we care (will this make it harder
 to eventually turn off ENABLE_LEGACY_NOTIFICATIONS since web apps may start
 using those APIs on the new Notifications objects)?

 -atw

 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo/webkit-dev



 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Can we remove Notification.show()?

2013-01-28 Thread Jochen Eisinger
On Mon, Jan 28, 2013 at 11:33 PM, John Gregg john...@google.com wrote:






 On Mon, Jan 28, 2013 at 2:24 PM, Jochen Eisinger joc...@chromium.orgwrote:



 On Mon, Jan 28, 2013 at 11:19 PM, Elliott Sprehn espr...@chromium.orgwrote:

 This seems like a badly designed API, constructors shouldn't have side
 effects and not having show() means after calling close() the notification
 object is useless which is silly.


 There was a discussion a while ago which resulted in removing the show
 method and making show implicit in construction.
 http://lists.w3.org/Archives/Public/public-web-notification/2011Jun/0005.html.
  The reasoning was that there typically isn't much value in reusing a
 notification.


A side-effect of that decision is that permission is a static attribute,
which we can't currently implement in V8 :-/

Instead, you'll need to use new Notification().permission in Chrome. Since
that API is unfortunately already part of the stable chrome release website
authors started to use this syntax which will inevitably lead to breakage
when we fix the implementation.






 In the new API, there's also no close() method...


 There is still a close() method in the latest spec:
 http://notifications.spec.whatwg.org/#api


ah, true.. my fault. Sorry.





 -jochen




 On Mon, Jan 28, 2013 at 4:35 AM, Andrew Wilson atwil...@google.comwrote:

 So, we've recently landed some fixes to address permissions handling
 for Notification.show(): http://trac.webkit.org/changeset/140927

 Turns out, the notifications specification does not have a show() API
 (the notification is automatically shown from the constructor --
 http://notifications.spec.whatwg.org/#api). Does anyone have any
 objections to moving the show() API under the ENABLE_LEGACY_NOTIFICATIONS
 flag to bring us under compliance with the spec?

 Also, it looks like if a platform enables ENABLE_LEGACY_NOTIFICATIONs,
 not only do they get support for the old webkitNotifications API, but also
 some of the old API (like show() and cancel()) is exposed on the new
 Notifications objects, because we share the same interface for
 webkitNotifications and Notifications. Do we care (will this make it harder
 to eventually turn off ENABLE_LEGACY_NOTIFICATIONS since web apps may start
 using those APIs on the new Notifications objects)?

 -atw

 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo/webkit-dev



 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev



 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev



___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Do any ports still disable SVG?

2013-01-25 Thread Jochen Eisinger
Many chromium developers disable svg for faster building.

Jochen
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Proposal: Make Ninja the default build-system for build-webkit --chromium

2012-12-10 Thread Jochen Eisinger
Will the buildbots use ninja or the native build tools?

My only concern is that we're catching problems with e.g. MSVS only after
we roll the WebKit deps in chromium and one of the MSVS bots starts failing.

Otherwise, I'm all for switching to ninja.

best
-jochen

On Sat, Dec 8, 2012 at 9:29 AM, Eric Seidel e...@webkit.org wrote:

 If you don't work on the Chromium port, feel free to ignore.


 If you work on the Chromium port of WebKit and do not use Ninja as you
 build system (GYP_GENERATORS='ninja' or update-webkit --chromium
 --ninja) I want to hear from you!

 As far as I can tell, the vast majority of Chromium contributors use
 Ninja as their build system of choice.  Particularly for
 Chromium-Android contributors this seems to be true.

 With that knowledge, I have posted a patch to make update-webkit
 ---chromium/--chromium-android generate Ninja build files instead of
 platform-native build files (XCode, Visual Studio, Make, etc.) by
 default.  This of course only affects the chromium port.

 https://bugs.webkit.org/show_bug.cgi?id=104434

 Thanks!


 p.s. If you don't already know:
 update-webkit --chromium --ninja
 build-webkit --chromium
 is all you need to use Ninja today.  You don't even need to have
 installed/built your own copy of ninja (Chromium has done that for
 you).

 p.p.s. Ninja is awesome. Awesomely quiet. Awesomely fast.
 http://martine.github.com/ninja/
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Discussing bug 98539 - Refactor resource loading to allow for out-of-process loading and memory caching

2012-10-08 Thread Jochen Eisinger
Hey,

can you share your plan how to prioritize network requests in the network
process?

It's a long standing issue of the chromium port (and I believe the
blackberry port is affected as well) that a ResourceRequest doesn't know
whether it was created for e.g. an XHR or a main document load, which makes
it difficult to prioritize the requests.

We currently work around that issue by adding a TargetType to
ResourceRequest which is however a layering violation which I'd like to get
rid of.

best
-jochen

On Mon, Oct 8, 2012 at 7:39 PM, Brady Eidson beid...@apple.com wrote:

 A bit of background:

 A few of us have been working on enhancing WebKit2's support for multiple
 WebProcesses.  As part of this effort I'm working on
 https://bugs.webkit.org/show_bug.cgi?id=98537 - Add a NetworkProcess to
 WebKit2

 One benefit of the NetworkProcess will be to have a single shared process
 doing network i/o on behalf of all attached WebProcesses.

 Another benefit we've identified is the ability to have that process also
 act as custodian for a shared memory cache amongst the attached
 WebProcesses.

 While this effort is primarily about WebKit 2, making it possible will
 obviously involve some changes to the WebCore memory cache and resource
 loading.

 I don't plan to shoehorn in changes, but rather to make sensical
 refactoring that cleans up the code for all ports.  Anyone familiar with
 the CachedResource and ResourceLoader mechanisms probably know they're not
 really up to the clarity and quality standards we strive for, and I'm
 excited about being able to focus on them for awhile and make them better
 for everyone.

 I have a few patches lined up locally to do this and have attached the
 first of these to https://bugs.webkit.org/show_bug.cgi?id=98539

 Feel free to share concerns here or in the collection of bugzillas that
 will slowly be growing as I make progress.

 ~Brady
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Updates on Chromium's content_shell

2012-07-16 Thread Jochen Eisinger
On Fri, Jul 13, 2012 at 11:15 PM, Darin Fisher da...@chromium.org wrote:



 On Fri, Jul 13, 2012 at 2:10 PM, Adam Barth aba...@webkit.org wrote:

 Yeah, EventSender is likely a good place to start.  Here are some more
 details about what I had in mind:

 1) We'll need to create a new target that builds a TestRunner.a (or
 LayoutTestController.a, whatever name is currently in fashion).  This
 target is allowed to depend on WTF, WebKit (via the WebKit API), and
 probably webkit_support.

 2) This target will contain LayoutTestController.cpp, EventSender.cpp,
 and all the other code that's needed to support the objects we inject when
 running LayoutTests.

 3) To move code into this target, we'll need to abstract any dependencies
 on the rest of DumpRenderTree into a delegate interface.  For example,
 EventSender has a #include TestShell.h, which we'll need to remove.
  Today, EventSender gets the WebView is by asking m_shell for it.  Instead,
 it will need to ask the delegate.

 One of the trickier things in this project will be WebViewHost.
  TestRunner.a will need some object like that to subclass a bunch of WebKit
 API clients, but the design might need to change a bit.  I haven't studied
 it carefully yet.


 TestRunner.a could just provide the WebViewClient and WebFrameClient
 implementations.  The delegate you mention could just be a createWebView
 function.

 When Jochen and I discussed this topic before, I suggested just adding
 CreateWebView to webkit_support, but as a delegate function seems even
 better.  We'd probably like to minimize dependencies on webkit_support
 since that is Chromium specific.


I think these are two separate issues: one is reusing the bindings for the
test objects. This is what creating a TestRunner library would achieve. The
other is to create the webkit objects without too egregious layering
violations. This is a yet to solve problem :)

-jochen




 -Darin





 Once this is done, but DumpRenderTree and ContentShell can link
 in TestRunner.a and implement the delegate.  Hopefully the bulk of the
 interactions will be between TestRunner.a and the WebKit API so that the
 delegate will mostly be able providing the WebView and getting out of the
 way.

 Adam


 On Fri, Jul 13, 2012 at 1:56 PM, Jochen Eisinger joc...@chromium.orgwrote:

 What about keeping the discussion here, so others that might want to
 join the effort later can read it up?

 In general, I agree with your proposal. I guess starting with something
 small like EventSender might be a good first step.

 best
 -jochen


 On Fri, Jul 13, 2012 at 10:20 PM, Adam Barth aba...@webkit.org wrote:

 On Fri, Jul 13, 2012 at 1:10 PM, Jochen Eisinger 
 joc...@chromium.orgwrote:

 On Fri, Jul 13, 2012 at 7:46 PM, Ryosuke Niwa rn...@webkit.orgwrote:

 On Fri, Jul 13, 2012 at 4:16 AM, Jochen Eisinger joc...@chromium.org
  wrote:

 I wanted to share some updates about content_shell (a
 multi-processed version of chromium's test shell): meanwhile, it is
 possible to generate pixel results.

 Out of 31431 tests that are executed on chromium-linux, 6234 did not
 match the expected results using content_shell, all others passed 
 (80.17%)!


 This is a great news! Thanks a lot for working on this effort. Let us
 know if you needed a help in implementing testRunner methods.


 At this point, there are two things I could use help with: in general,
 moving methods to window.internals (and addressing the current 
 shortcomings
 of that approach) helps a lot, as I can just instantiate this object in
 content_shell.

 The other thing is to work towards making layoutTestController (of
 chromium's DRT) a library.

 Adam mentioned a while ago that he'd be interested with helping with
 the latter as well


 Yes.  The idea is to implement LayoutTestController in terms of the
 WebKit API and a (hopefully simple) delegate.
  Currently LayoutTestController knows too much about DumpRenderTree.  That
 will let us share the implementation of LayoutTestController and avoid
 having to maintain yet another copy.

 Upstreaming the chromium-android port is at the top of
 my priority list, but I should be able to help out with this work as well.
  Should we talk off-list about how to approach this work?

 Adam




 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo/webkit-dev



___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Updates on Chromium's content_shell

2012-07-13 Thread Jochen Eisinger
Hey,

I wanted to share some updates about content_shell (a multi-processed
version of chromium's test shell): meanwhile, it is possible to generate
pixel results.

Out of 31431 tests that are executed on chromium-linux, 6234 did not match
the expected results using content_shell, all others passed (80.17%)!

The biggest issue is that almost all testController methods are not yet
implemented.

If you're interested in running content_shell tests yourself, I've put
together a small description here:
http://dev.chromium.org/developers/testing/webkit-layout-tests/content-shell

The next step will be to put an API between the test controllers defined
for chromium's DRT, so content_shell can reuse those.

best
-jochen
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Updates on Chromium's content_shell

2012-07-13 Thread Jochen Eisinger
On Fri, Jul 13, 2012 at 7:46 PM, Ryosuke Niwa rn...@webkit.org wrote:

 On Fri, Jul 13, 2012 at 4:16 AM, Jochen Eisinger joc...@chromium.orgwrote:

 I wanted to share some updates about content_shell (a multi-processed
 version of chromium's test shell): meanwhile, it is possible to generate
 pixel results.

 Out of 31431 tests that are executed on chromium-linux, 6234 did not
 match the expected results using content_shell, all others passed (80.17%)!


 This is a great news! Thanks a lot for working on this effort. Let us know
 if you needed a help in implementing testRunner methods.


At this point, there are two things I could use help with: in general,
moving methods to window.internals (and addressing the current shortcomings
of that approach) helps a lot, as I can just instantiate this object in
content_shell.

The other thing is to work towards making layoutTestController (of
chromium's DRT) a library.

Adam mentioned a while ago that he'd be interested with helping with the
latter as well

-jochen



 - Ryosuke


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Updates on Chromium's content_shell

2012-07-13 Thread Jochen Eisinger
What about keeping the discussion here, so others that might want to join
the effort later can read it up?

In general, I agree with your proposal. I guess starting with something
small like EventSender might be a good first step.

best
-jochen


On Fri, Jul 13, 2012 at 10:20 PM, Adam Barth aba...@webkit.org wrote:

 On Fri, Jul 13, 2012 at 1:10 PM, Jochen Eisinger joc...@chromium.orgwrote:

 On Fri, Jul 13, 2012 at 7:46 PM, Ryosuke Niwa rn...@webkit.org wrote:

 On Fri, Jul 13, 2012 at 4:16 AM, Jochen Eisinger joc...@chromium.orgwrote:

 I wanted to share some updates about content_shell (a multi-processed
 version of chromium's test shell): meanwhile, it is possible to generate
 pixel results.

 Out of 31431 tests that are executed on chromium-linux, 6234 did not
 match the expected results using content_shell, all others passed (80.17%)!


 This is a great news! Thanks a lot for working on this effort. Let us
 know if you needed a help in implementing testRunner methods.


 At this point, there are two things I could use help with: in general,
 moving methods to window.internals (and addressing the current shortcomings
 of that approach) helps a lot, as I can just instantiate this object in
 content_shell.

 The other thing is to work towards making layoutTestController (of
 chromium's DRT) a library.

 Adam mentioned a while ago that he'd be interested with helping with the
 latter as well


 Yes.  The idea is to implement LayoutTestController in terms of the WebKit
 API and a (hopefully simple) delegate.  Currently LayoutTestController
 knows too much about DumpRenderTree.  That will let us share the
 implementation of LayoutTestController and avoid having to maintain yet
 another copy.

 Upstreaming the chromium-android port is at the top of my priority list,
 but I should be able to help out with this work as well.  Should we talk
 off-list about how to approach this work?

 Adam


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] [patch] fix webkit-gtk build with automake 1.12

2012-07-10 Thread Jochen Eisinger
Please see http://www.webkit.org/coding/contributing.html for how to
contribute patches to WebKit.

best
-jochen


On Tue, Jul 10, 2012 at 12:46 PM, Kamble, Nitin A
nitin.a.kam...@intel.comwrote:

  automake 1.12 has deprecated use of mkdir_p, and it recommends

 use of MKDIR_P instead. Changed the code to avoid these kind

 of warning-errors.

 ** **

 ./.deps/DerivedSources

 make[1]: ./.deps/DerivedSources: Command not found

 make[1]: *** [all-local] Error 127

 ** **

 Signed-Off-By: Nitin A Kamble nitin.a.kam...@intel.com

 2012/07/10

 ** **

 Index: webkit-gtk-1.7.2+svnr101488-r6/GNUmakefile.am

 ===

 --- webkit-gtk-1.7.2+svnr101488-r6.orig/GNUmakefile.am

 +++ webkit-gtk-1.7.2+svnr101488-r6/GNUmakefile.am

 @@ -255,7 +255,7 @@ MAINTAINERCLEANFILES += \

 # Older automake versions (1.7) place Plo files in a different place so we
 need

 # to create the output directory manually.

 all-local: stamp-po

 -   $(mkdir_p) $(top_builddir)/$(DEPDIR)/DerivedSources

 +   $(MKDIR_P) $(top_builddir)/$(DEPDIR)/DerivedSources

 ** **

 # remove built sources and program directories

 clean-local:

 Index: webkit-gtk-1.7.2+svnr101488-r6/Source/WebKit/gtk/po/GNUmakefile.am*
 ***

 ===

 --- webkit-gtk-1.7.2+svnr101488-r6.orig/Source/WebKit/gtk/po/GNUmakefile.am
 

 +++ webkit-gtk-1.7.2+svnr101488-r6/Source/WebKit/gtk/po/GNUmakefile.am

 @@ -132,13 +132,13 @@ DISTCLEANFILES += \

 $(top_builddir)/Source/WebKit/gtk/po/$(DOMAIN).pot

 ** **

 po-install-data-local: all

 -   $(mkdir_p) $(DESTDIR)$(datadir)

 +   $(MKDIR_P) $(DESTDIR)$(datadir)

 @catalogs='$(MOFILES)'; \

 for cat in $$catalogs; do \

   cat=`basename $$cat`; \

   lang=`echo $$cat | sed -e 's/\.mo$$//'`; \

   dir=$(localedir)/$$lang/LC_MESSAGES; \

 - $(mkdir_p) $(DESTDIR)$$dir; \

 + $(MKDIR_P) $(DESTDIR)$$dir; \

   if test -r Source/WebKit/gtk/po/$$cat; then
 realcat=Source/WebKit/gtk/po/$$cat; else realcat=$(srcdir)/$$cat; fi; \***
 *

   $(INSTALL_DATA) $$realcat $(DESTDIR)$$dir/$(DOMAIN).mo; \

   echo installing $$realcat as $(DESTDIR)$$dir/$(DOMAIN).mo; \**
 **

 @@ -173,13 +173,13 @@ po-install-data-local: all

 done

 ** **

 po-installdirs-data-local:

 -   $(mkdir_p) $(DESTDIR)$(datadir)

 +   $(MKDIR_P) $(DESTDIR)$(datadir)

 @catalogs='$(MOFILES)'; \

 for cat in $$catalogs; do \

   cat=`basename $$cat`; \

   lang=`echo $$cat | sed -e 's/\.gmo$$//'`; \

   dir=$(localedir)/$$lang/LC_MESSAGES; \

 - $(mkdir_p) $(DESTDIR)$$dir; \

 + $(MKDIR_P) $(DESTDIR)$$dir; \

   for lc in '' $(EXTRA_LOCALE_CATEGORIES); do \

 if test -n $$lc; then \

   if (cd $(DESTDIR)$(localedir)/$$lang  LC_ALL=C ls -l -d
 $$lc 2/dev/null) | grep ' - ' /dev/null; then \

 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] How to access page GroupSettings from WorkerThread

2012-06-20 Thread Jochen Eisinger
As I mentioned in https://bugs.webkit.org/show_bug.cgi?id=88338, another
possibility would be to add the required information (in this case a path)
to the WorkerContext, as it seems to already contain such fields, e.g.
m_userAgent.

-jochen

On Wed, Jun 20, 2012 at 2:48 AM, David Levin le...@google.com wrote:

 A few possibilities, in order of increasing complexity and work
 1. If it can't change, you could pass it in when the worker is created.
 2. If it can change, you do a postMessage to the main thread to get the
 value.
 3. If you can't get the value in an async manner, perhaps you can make a
 method to allow thread safe access.



 On Wed, Jun 13, 2012 at 6:42 PM, Charles Wei 
 charles@torchmobile.com.cn wrote:

 Hi, Webkit-dev,

 I am working on JSC binding for IndexedDB. One problem I am facing now is
 to access the page groupsettings from the WorkerContext(especially the
 SharedWorkerContext) for IndexedDB file path settings to access the
 database when the indexeddb code runs in the workerthread.  Anybody can
 guide me what's the best way to do this: access the page groupsettings from
 a workcontext?

 Thanks
 --Charles

 
 From My BlackBerry
 -
 This transmission (including any attachments) may contain confidential
 information, privileged material (including material protected by the
 solicitor-client or other applicable privileges), or constitute non-public
 information. Any use of this information by anyone other than the intended
 recipient is prohibited. If you have received this transmission in error,
 please immediately reply to the sender and delete this information from
 your system. Use, dissemination, distribution, or reproduction of this
 transmission by unintended recipients is not authorized and may be unlawful.
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev



 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Running layout tests for the chromium port, using the multi-processing architecture and fully sandboxed

2012-06-14 Thread Jochen Eisinger
I created a page with instructions how to use content_shell here:
https://sites.google.com/a/chromium.org/dev/developers/testing/webkit-layout-tests/content-shell

At the bottom, I summarized next steps, esp. how we can reuse chromium's
test controller for the content shell

best
-jochen

On Mon, Jun 11, 2012 at 1:53 AM, Darin Fisher da...@chromium.org wrote:



 On Fri, Jun 8, 2012 at 12:51 PM, Jochen Eisinger joc...@chromium.orgwrote:



 On Fri, Jun 8, 2012 at 9:41 PM, Ryosuke Niwa rn...@webkit.org wrote:

 On Fri, Jun 8, 2012 at 12:18 PM, Jochen Eisinger joc...@chromium.orgwrote:

 I've implemented initial support for running layout tests using
 chromium's content_shell instead of test_shell as the current DRT
 implementation does. It's still a very experimental, but might already be
 interesting for some of you to try.


 This is great! Thanks a lot on working this.

 1. Make sure your WebKit is at least at r119852 (see
 http://trac.webkit.org/wiki/Chromium for prerequisites)
 2. Apply the attachment from
 https://bugs.webkit.org/show_bug.cgi?id=87045
 3. In Source/WebKit/chromium run gclient sync
 4. build webkit as usual

 E.g. for a debug build on Linux, this should give you
 out/Debug/content_shell

 You can now run layout tests like this:

 new-run-webkit-tests --chromium --debug --driver-name=content_shell
 --additional-drt-flag=--dump-render-tree LayoutTests/storage/indexeddb/*

 You'll notice that not all tests are passing yet, mainly because not
 all (or actually, almost none of the) layoutTestController features are
 implemented yet.


  Where is layoutTestController implemented? We definitely need to move
 the implementation of layoutTestController, eventSender, etc... into WebKit
 repository because we often rename functions, etc... in WebKit. It's
 unacceptable to require having to modify Chromium code in order to do this
 refactoring in the future.


 It's currently here:
 http://code.google.com/searchframe#OAMlx_jo-ck/src/content/shell/layout_test_controller.jsexact_package=chromium

 Per my other thread about sharing IDLs between DumpRenderTree and
 WebKitTestRunner, I would like to see us sharing IDL with WebKitTestRunner
 instead of adding yet another binding code.

 Another missing feature is producing pixel results. However, I'm
 currently concentrating on text results, as I think the biggest benefit is
 the ability to run storage tests on the real storage implementation.


 That sounds great to me but we definitely need to support pixel results
 eventually. I'm more than happy to help you on that but that requires the
 codebase to be moved into WebKit repository.


 Here's the basic problem: content_shell depends on content, so moving
 this on the webkit repository would mean that webkit depended on content.

 Another solution would be to formalize the test shell API our current
 layout test controller in webkit uses (Tools/DumpRenderTree/chromium), and
 add a method to chromium's webkit support library that returns a webview
 that supports all the hooks required. The webview could then either be
 implemented by test_shell or by content_shell


 ^^^ This second solution seems like it will work well.  It will enable the
 guts of layoutTestController to remain in the WebKit repository.  This is
 just a variation of exactly what we do today.  You only need to move
 creation of WebView to Chromium so that we can eliminate WebViewHost.cpp
 (and other simple application shell bits).

 -Darin



 best
 -jochen

 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev



___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


[webkit-dev] Running layout tests for the chromium port, using the multi-processing architecture and fully sandboxed

2012-06-08 Thread Jochen Eisinger
Hey,

I've implemented initial support for running layout tests using chromium's
content_shell instead of test_shell as the current DRT implementation does.
It's still a very experimental, but might already be interesting for some
of you to try.

The main advantage is that content_shell includes chromium's full storage
implementation, so layout tests for indexed db are running against the
multi-processed IDB implementation instead of the simple stub used for DRT.

Here's how to build webkit with content_shell:

1. Make sure your WebKit is at least at r119852 (see
http://trac.webkit.org/wiki/Chromium for prerequisites)
2. Apply the attachment from https://bugs.webkit.org/show_bug.cgi?id=87045
3. In Source/WebKit/chromium run gclient sync
4. build webkit as usual

E.g. for a debug build on Linux, this should give you
out/Debug/content_shell

You can now run layout tests like this:

new-run-webkit-tests --chromium --debug --driver-name=content_shell
--additional-drt-flag=--dump-render-tree LayoutTests/storage/indexeddb/*

You'll notice that not all tests are passing yet, mainly because not all
(or actually, almost none of the) layoutTestController features are
implemented yet.

Another missing feature is producing pixel results. However, I'm currently
concentrating on text results, as I think the biggest benefit is the
ability to run storage tests on the real storage implementation.

Let me know if you have any feedback, comments, or questions. If somebody
is implemented in helping adding features (e.g. to get your favorite part
of the layout tests passing), I'm happy to point you at the code locations!

best
-jochen
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Running layout tests for the chromium port, using the multi-processing architecture and fully sandboxed

2012-06-08 Thread Jochen Eisinger
On Fri, Jun 8, 2012 at 9:41 PM, Ryosuke Niwa rn...@webkit.org wrote:

 On Fri, Jun 8, 2012 at 12:18 PM, Jochen Eisinger joc...@chromium.orgwrote:

 I've implemented initial support for running layout tests using
 chromium's content_shell instead of test_shell as the current DRT
 implementation does. It's still a very experimental, but might already be
 interesting for some of you to try.


 This is great! Thanks a lot on working this.

 1. Make sure your WebKit is at least at r119852 (see
 http://trac.webkit.org/wiki/Chromium for prerequisites)
 2. Apply the attachment from
 https://bugs.webkit.org/show_bug.cgi?id=87045
 3. In Source/WebKit/chromium run gclient sync
 4. build webkit as usual

 E.g. for a debug build on Linux, this should give you
 out/Debug/content_shell

 You can now run layout tests like this:

 new-run-webkit-tests --chromium --debug --driver-name=content_shell
 --additional-drt-flag=--dump-render-tree LayoutTests/storage/indexeddb/*

 You'll notice that not all tests are passing yet, mainly because not all
 (or actually, almost none of the) layoutTestController features are
 implemented yet.


  Where is layoutTestController implemented? We definitely need to move the
 implementation of layoutTestController, eventSender, etc... into WebKit
 repository because we often rename functions, etc... in WebKit. It's
 unacceptable to require having to modify Chromium code in order to do this
 refactoring in the future.


It's currently here:
http://code.google.com/searchframe#OAMlx_jo-ck/src/content/shell/layout_test_controller.jsexact_package=chromium

Per my other thread about sharing IDLs between DumpRenderTree and
 WebKitTestRunner, I would like to see us sharing IDL with WebKitTestRunner
 instead of adding yet another binding code.

 Another missing feature is producing pixel results. However, I'm currently
 concentrating on text results, as I think the biggest benefit is the
 ability to run storage tests on the real storage implementation.


 That sounds great to me but we definitely need to support pixel results
 eventually. I'm more than happy to help you on that but that requires the
 codebase to be moved into WebKit repository.


Here's the basic problem: content_shell depends on content, so moving this
on the webkit repository would mean that webkit depended on content.

Another solution would be to formalize the test shell API our current
layout test controller in webkit uses (Tools/DumpRenderTree/chromium), and
add a method to chromium's webkit support library that returns a webview
that supports all the hooks required. The webview could then either be
implemented by test_shell or by content_shell

best
-jochen
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Running layout tests for the chromium port, using the multi-processing architecture and fully sandboxed

2012-06-08 Thread Jochen Eisinger
On Fri, Jun 8, 2012 at 9:55 PM, Ryosuke Niwa rn...@webkit.org wrote:

 On Fri, Jun 8, 2012 at 12:51 PM, Jochen Eisinger joc...@chromium.orgwrote:

  On Fri, Jun 8, 2012 at 9:41 PM, Ryosuke Niwa rn...@webkit.org wrote:

 Per my other thread about sharing IDLs between DumpRenderTree and
 WebKitTestRunner, I would like to see us sharing IDL with WebKitTestRunner
 instead of adding yet another binding code.

 Another missing feature is producing pixel results. However, I'm
 currently concentrating on text results, as I think the biggest benefit is
 the ability to run storage tests on the real storage implementation.


 That sounds great to me but we definitely need to support pixel results
 eventually. I'm more than happy to help you on that but that requires the
 codebase to be moved into WebKit repository.


 Here's the basic problem: content_shell depends on content, so moving
 this on the webkit repository would mean that webkit depended on content.

 Another solution would be to formalize the test shell API our current
 layout test controller in webkit uses (Tools/DumpRenderTree/chromium), and
 add a method to chromium's webkit support library that returns a webview
 that supports all the hooks required. The webview could then either be
 implemented by test_shell or by content_shell


 I don't know any architectural details of content_shell so it's hard for
 me to comment on this matter, but I don't see a problem in
 WebKitChromiumTestRunner (hypothetical name to be consistent with
 WebKitTestRunner) depending on content_shell given that WebKitTestRunner
 also depends on WebKit2 API.


Today, when somebody adds e.g. a new callback to LayoutTestController, they
can just patch DumpRenderTree. If our test runner lived (in large parts) in
chromium's repository, such a change would require a patch to chromium.
This would either put an additional burden on all WebKit developers, or our
test runner constantly gets out of sync.



 - Ryosuke


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


[webkit-dev] Changes to window.focus/window.blur controlled by a setting?

2012-05-21 Thread Jochen Eisinger
Hey,

in https://bugs.webkit.org/show_bug.cgi?id=86969 I'm changing window.focus
and window.blur to match Firefox's behavior: window.blur does nothing, and
window.focus only works when invoked from the window that actually opened
the former.

The goal is to thwart so-called pop unders.

Does any port want to have this new behavior configurable by e.g. a setting?

Feel free to directly comment on the bug.

best
-jochen
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Changes to window.focus/window.blur controlled by a setting?

2012-05-21 Thread Jochen Eisinger
On Mon, May 21, 2012 at 1:16 PM, Eric Seidel esei...@google.com wrote:

 So this would just make pop-unders turn into pop-overs correct?


Correct. Keep in mind that at this point, our logic already decided that
it's ok for the page to show a popup

-jochen



 On Mon, May 21, 2012 at 2:17 AM, Jochen Eisinger joc...@chromium.org
 wrote:
  Hey,
 
  in https://bugs.webkit.org/show_bug.cgi?id=86969 I'm changing
 window.focus
  and window.blur to match Firefox's behavior: window.blur does nothing,
 and
  window.focus only works when invoked from the window that actually opened
  the former.
 
  The goal is to thwart so-called pop unders.
 
  Does any port want to have this new behavior configurable by e.g. a
 setting?
 
  Feel free to directly comment on the bug.
 
  best
  -jochen
 
  ___
  webkit-dev mailing list
  webkit-dev@lists.webkit.org
  http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Changes to window.focus/window.blur controlled by a setting?

2012-05-21 Thread Jochen Eisinger
On Mon, May 21, 2012 at 8:17 PM, Eric Seidel e...@webkit.org wrote:

 So the goal (FF's goal) is to guilt the site into not using pop-ups
 anymore? Since they don't want to take you away from their content (as
 pop-unders allow them to do?)



I don't think this changed a lot since FF started to do this (quite a while
ago). However, I think it's less annoying this just hit Cmd-W vs hunting
down the popup on my desktop before I can actually close it.



 My first thought was that we might as well just nuke/block the pop-up
 if it calls blur() (and log to the console somewhere).  But perhaps we
 can try that in a year if this fails to produce results. :)


I agree that popup blocking per se (even it's up or under doesn't really
matter) could be improved, and maybe calls to window.blur() are a good
signal.

-jochen




 On Mon, May 21, 2012 at 4:17 AM, Jochen Eisinger joc...@chromium.org
 wrote:
 
 
  On Mon, May 21, 2012 at 1:16 PM, Eric Seidel esei...@google.com wrote:
 
  So this would just make pop-unders turn into pop-overs correct?
 
 
  Correct. Keep in mind that at this point, our logic already decided that
  it's ok for the page to show a popup
 
  -jochen
 
 
 
  On Mon, May 21, 2012 at 2:17 AM, Jochen Eisinger joc...@chromium.org
  wrote:
   Hey,
  
   in https://bugs.webkit.org/show_bug.cgi?id=86969 I'm changing
   window.focus
   and window.blur to match Firefox's behavior: window.blur does nothing,
   and
   window.focus only works when invoked from the window that actually
   opened
   the former.
  
   The goal is to thwart so-called pop unders.
  
   Does any port want to have this new behavior configurable by e.g. a
   setting?
  
   Feel free to directly comment on the bug.
  
   best
   -jochen
  
   ___
   webkit-dev mailing list
   webkit-dev@lists.webkit.org
   http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
  
 
 

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Changes to window.focus/window.blur controlled by a setting?

2012-05-21 Thread Jochen Eisinger
On Mon, May 21, 2012 at 9:16 PM, Andrew Wilson atwil...@google.com wrote:



 On Mon, May 21, 2012 at 2:17 AM, Jochen Eisinger joc...@chromium.orgwrote:

 Hey,

 in https://bugs.webkit.org/show_bug.cgi?id=86969 I'm changing
 window.focus and window.blur to match Firefox's behavior: window.blur does
 nothing, and window.focus only works when invoked from the window that
 actually opened the former.

 The goal is to thwart so-called pop unders.


 The new behavior you describe will break notifications, since many pages
 will want to bring themselves to the front when someone clicks on their
 notification, and your patch prevents this. I suspect that the Firefox
 behavior will need to change when they add support for notifications.

 I still think that a superior change would be to prevent applications from
 calling window.focus() or window.blur() in the context of a user gesture
 once they've opened a new window. This would address popunders, while still
 allowing notifications to work.


The web page could just use setTimeout your restriction to work around
this, no?

-jochen




 Does any port want to have this new behavior configurable by e.g. a
 setting?

 Feel free to directly comment on the bug.

 best
 -jochen

 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev



___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


[webkit-dev] feature proposal: restricting window.blur/focus

2012-04-04 Thread Jochen Eisinger
Hey,

Firefox restricts the use of window.blur() and window.focus() (by default).
window.blur() is just doing nothing, and window.focus() only works if the
caller is running in the same window.

Should we implement similar rules for WebKit? The purpose of this is to
make pop-unders more difficult to achieve.

I think this can be implemented in such a way the the chrome implementation
which is doing the actual focusing/bluring anyway has enough information to
let each port control what they want to do.

wdyt?

-jochen
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] feature proposal: restricting window.blur/focus

2012-04-04 Thread Jochen Eisinger
On Wed, Apr 4, 2012 at 7:53 PM, Darin Fisher da...@chromium.org wrote:

 Matching Firefox behavior likely means that we won't have to worry about
 breaking sites.  We may have to worry about breaking Chrome Extensions or
 other browser-specific content.


We could add a method to ChromeClient that would enable an embedder to
override the restriction under certain circumstances

-jochen



 -Darin



 On Wed, Apr 4, 2012 at 1:31 AM, Jochen Eisinger joc...@chromium.orgwrote:

 Hey,

 Firefox restricts the use of window.blur() and window.focus() (by
 default). window.blur() is just doing nothing, and window.focus() only
 works if the caller is running in the same window.

 Should we implement similar rules for WebKit? The purpose of this is to
 make pop-unders more difficult to achieve.

 I think this can be implemented in such a way the the chrome
 implementation which is doing the actual focusing/bluring anyway has enough
 information to let each port control what they want to do.

 wdyt?

 -jochen

 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev



___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] feature proposal: restricting window.blur/focus

2012-04-04 Thread Jochen Eisinger
On Wed, Apr 4, 2012 at 8:01 PM, Darin Fisher da...@chromium.org wrote:

 On Wed, Apr 4, 2012 at 10:58 AM, Jochen Eisinger joc...@chromium.orgwrote:


 On Wed, Apr 4, 2012 at 7:53 PM, Darin Fisher da...@chromium.org wrote:

 Matching Firefox behavior likely means that we won't have to worry about
 breaking sites.  We may have to worry about breaking Chrome Extensions or
 other browser-specific content.


 We could add a method to ChromeClient that would enable an embedder to
 override the restriction under certain circumstances


 Or, perhaps something like UserGestureIndicator.  I'm not sure which is
 better.


Not sure I understand?

Are you suggesting to allowing focusing/blurring in response to a user
action? I think that's undesirable, as the site that wants to pop-under a
window probably stole a click to be able to run window.open already.

-jochen


 -Darin



 -jochen



 -Darin



 On Wed, Apr 4, 2012 at 1:31 AM, Jochen Eisinger joc...@chromium.orgwrote:

 Hey,

 Firefox restricts the use of window.blur() and window.focus() (by
 default). window.blur() is just doing nothing, and window.focus() only
 works if the caller is running in the same window.

 Should we implement similar rules for WebKit? The purpose of this is to
 make pop-unders more difficult to achieve.

 I think this can be implemented in such a way the the chrome
 implementation which is doing the actual focusing/bluring anyway has enough
 information to let each port control what they want to do.

 wdyt?

 -jochen

 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev





___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


[webkit-dev] number of wrapped objects in JSC

2012-03-19 Thread Jochen Eisinger
Hey,

I intend to add a graph in the inspector's timeline panel that shows the
number of global handles for V8. The V8 bindings use maps for WebCore
objects to global handles to V8 wrapper objects. A steady increase of
global handles is often a sign of a memory leak within v8 bindings.

My question to the JSC folks is, is there a similar counter in JSC? I.e.
something that corresponds to the number of wrapped WebCore objects (and
potentially other objects that are kept alive without necessarily being
reachable from javascript)?

thanks
-jochen
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] number of wrapped objects in JSC

2012-03-19 Thread Jochen Eisinger
On Mon, Mar 19, 2012 at 9:47 PM, Geoffrey Garen gga...@apple.com wrote:

  I intend to add a graph in the inspector's timeline panel that shows the
 number of global handles for V8. The V8 bindings use maps for WebCore
 objects to global handles to V8 wrapper objects. A steady increase of
 global handles is often a sign of a memory leak within v8 bindings.

 Are you sure that all wrappers go into a map? What about wrappers for
 ScriptWrappable objects?


That's right, not all objects are kept in maps, but all objects have a
global handle somewhere.



  My question to the JSC folks is, is there a similar counter in JSC? I.e.
 something that corresponds to the number of wrapped WebCore objects (and
 potentially other objects that are kept alive without necessarily being
 reachable from javascript)?

 You could read the length of JSC::HandleHeap::m_weakList. Since that's an
 expensive operation, I'd suggest computing the length during garbage
 collection and then caching it.


awesome, thanks

-jochen




 Geoff

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Moving to Git?

2012-03-08 Thread Jochen Eisinger
On Thu, Mar 8, 2012 at 9:12 PM, Ryosuke Niwa rn...@webkit.org wrote:

 On Thu, Mar 8, 2012 at 12:04 PM, Adam Treat atr...@rim.com wrote:

 There is nothing about git that forces you to have multiple branches
 locally.  Good practice, yes, but nothing forcing it.  As for the
 difficulty of resolving conflicts between patches you've made locally and
 changes made on the shared repository since you started making your local
 patches... nothing about git makes this any harder.  Unless you have a lock
 based source control system you'll have to resolve conflicts.


 On Thu, Mar 8, 2012 at 12:05 PM, Joe Mason jma...@rim.com wrote:

 It seems to me that there's no need to use multiple local branches in git
 if you find it confusing - it's an additional feature, but I don't see
 anything that requires it.

 What workflow do you have that requires you to have multiple branches
 locally in git, and how do you solve it in svn without using branches?

 What precisely do you find difficult about merging remote changes, and
 how is the svn equivalent easier?


 The simplicity. In git, I have to worry about things like committing local
 changes before rebasing to master, or stashing, etc... In svn, all I have
 to do is to run svn up.


I wonder, do you really run svn up that much? I'd expect that this breaks
your checkout every now and then if some dependencies change. I usually run
update-webkit, which should hide the rebasing actions from you

-jochen


 - Ryosuke


 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


[webkit-dev] Adding meta name=referrer to WebCore

2012-03-06 Thread Jochen Eisinger
Hey all,

this is a belated announcement of the meta name=referrer feature. It
allows web sites to specify different policies for sending referrers,
without resorting to ugly redirect hacks. This feature is currently a
proposal: http://wiki.whatwg.org/wiki/Meta_referrer

The implementation of the feature was tracked here:
https://bugs.webkit.org/show_bug.cgi?id=72674

I'm sorry that this mail goes out after the feature has landed. Thank
you, Maciej, for pointing this out.

The feature is also not behind a flag. If any of the ports would prefer, I
can add such a flag.

In order to make the feature work with your port, you might need to add
some extra plumbing. Here's a list of changes that were required for
Chromium (AFAIK it works out of the box for Safari):

- the chromium out-of-process network stack would enforce the referrer
policy on redirects, so the referrer policy needed to be plumbed there
- context menus in chromium are also out-of-process, so the referrer policy
needed to be plumbed there for open in new tab etc
- the tab navigation history in chromium is out-of-process, as well as
storing the navigation history on disk for session restore, so the policy
had to be plumbed there as well

The feature is covered by layout tests in
http/tests/security/referrer-policy-*html

Looking forward to your comments

best
-jochen
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Adding meta name=referrer to WebCore

2012-03-06 Thread Jochen Eisinger
On Tue, Mar 6, 2012 at 5:31 PM, Joe Mason jma...@rim.com wrote:

 What happens if this extra plumbing isn't one? Is the tag just ignored?


The ResourceRequest objects generated by WebCore will contain the correct
header according to the referrer policy, e.g. if you click on a link, the
generated ResourceRequest will have the right referrer header according
to the policy.

If you generate requests outside of WebCore, the header will have whatever
value you set for it, e.g. in chromium, when you right click on a link and
select open in new tab, this would open a new tab with the default
referrer policy which might be incorrect. To set the correct referrer
header, I added the current frame's referrer policy to the context menu
parameters that are passed over the chromium WebKit API, so the header for
the request stemming from the context menu can now be set correctly.

A port like Safari that uses WebKit to handle context menus won't have this
problem, because the request is generated from within WebCore.

Does that answer your question?

best
-jochen


 
 From: webkit-dev-boun...@lists.webkit.org [
 webkit-dev-boun...@lists.webkit.org] on behalf of Jochen Eisinger [
 joc...@chromium.org]
 Sent: Tuesday, March 06, 2012 10:58 AM
 To: WebKit Development
 Subject: [webkit-dev] Adding meta name=referrer to WebCore

 Hey all,

 this is a belated announcement of the meta name=referrer feature. It
 allows web sites to specify different policies for sending referrers,
 without resorting to ugly redirect hacks. This feature is currently a
 proposal: http://wiki.whatwg.org/wiki/Meta_referrer

 The implementation of the feature was tracked here:
 https://bugs.webkit.org/show_bug.cgi?id=72674

 I'm sorry that this mail goes out after the feature has landed. Thank you,
 Maciej, for pointing this out.

 The feature is also not behind a flag. If any of the ports would prefer, I
 can add such a flag.

 In order to make the feature work with your port, you might need to add
 some extra plumbing. Here's a list of changes that were required for
 Chromium (AFAIK it works out of the box for Safari):

 - the chromium out-of-process network stack would enforce the referrer
 policy on redirects, so the referrer policy needed to be plumbed there
 - context menus in chromium are also out-of-process, so the referrer
 policy needed to be plumbed there for open in new tab etc
 - the tab navigation history in chromium is out-of-process, as well as
 storing the navigation history on disk for session restore, so the policy
 had to be plumbed there as well

 The feature is covered by layout tests in
 http/tests/security/referrer-policy-*html

 Looking forward to your comments

 best
 -jochen

 -
 This transmission (including any attachments) may contain confidential
 information, privileged material (including material protected by the
 solicitor-client or other applicable privileges), or constitute non-public
 information. Any use of this information by anyone other than the intended
 recipient is prohibited. If you have received this transmission in error,
 please immediately reply to the sender and delete this information from
 your system. Use, dissemination, distribution, or reproduction of this
 transmission by unintended recipients is not authorized and may be unlawful.

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Removing obsolete File attributes

2012-02-24 Thread Jochen Eisinger
On Fri, Feb 24, 2012 at 10:38 PM, Eric Seidel e...@webkit.org wrote:

 My 2¢:

 - I'm glad to see these properties go.
 - I think Darin is correct to be concerned about a potential
 web-compat risk.  (But, I suspect grepping extensions for .fileSize
 and .fileName might actually turn up useful data.  Assuming that's
 easy to do?)
 - I agree with ap that warnings are mostly useless.  Firefox has a
 zillion such warnings, and most page authors seem to ignore them.


Is it really useless, or does it help to decrease the number of new pages
using the feature? At the very least, it would make it seem more fair if
the feature is eventually removed to give some warning.


 - I agree with Jian Li, that if/when we add warnings (or any other
 form of deprecation) notating such in the IDL and autogenerating is a
 Good Idea™.


I agree that this would be useful.

-jochen



 How much work is it to collect how many unique pages grab these
 numbers from nightlies?  Have we done such in the past? (Do we have
 other studies to compare against?)  It feels a bit odd for WebKit to
 depend on Chromium to collect such numbers, but Chromium does seem
 well suited to the task.

 -eric

 On Fri, Feb 24, 2012 at 1:30 PM, Alexey Proskuryakov a...@webkit.org
 wrote:
 
  24.02.2012, в 12:20, Darin Fisher написал(а):
 
  Perhaps a concrete good first step is to log a console warning when they
 are
  used?  Warning, blahBlah is a deprecated attribute.  Use fluxCapacitor
  instead.
 
 
  I'm not much in favor of such warnings - from all I heard (second or
 third
  hand, without hard data), they are not effective. FWIW, this is what I'd
  expect - developers don't check console logs for sites they've delivered
 and
  were paid for long ago.
 
  I should point out that replacement standard attributes have been
  implemented in WebKit for a long time.
 
  - WBR, Alexey Proskuryakov
 
 
  ___
  webkit-dev mailing list
  webkit-dev@lists.webkit.org
  http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Removing deprecatedFrameEncoding

2012-01-16 Thread Jochen Eisinger
On Sun, Jan 15, 2012 at 9:52 PM, Adam Barth aba...@webkit.org wrote:

 We've previously discussed this topic in Bug 67882 and Bug 75905.

 We should remove deprecatedFrameEncoding.  Removing the code has the
 following benefits:

 1) Standards compliance.  There was a discussion in the HTTP working
 group about whether the requesting context should be a factor in
 determining the character set used to decode the Content-Disposition
 header.  The working group decided that we shouldn't use that
 information for several reasons:

  a) Varying the interpretation of an HTTP response based on the
 context of the request is contrary to the stateless nature of HTTP.
 The fact that HTTP request/response pairs can be understood
 irrespective of context is core to the design of HTTP.

  b) Most user agents, including most browsers, do not have this
 behavior.  That means the compatibility risk for dropping the behavior
 in other user agents (e.g., Safari) is relatively low, especially for
 a feature likes this one that is not widely used on the mobile web.

 2) Stability.  This code crashes.  For example, in the most recent
 release of Chrome Canary on Windows, deprecatedFrameEncoding accounts
 for 3.5% of all renderer crashes.  While we could invest effort in
 fixing these crashes, we'd be better off removing this code and
 spending that effort improving stability elsewhere.


For the sake of completeness: The crashes I've seen end in

[DocumentWriter.cpp:246] WebCore::DocumentWriter::deprecatedFrameEncoding()
[FrameLoader.cpp:2591] WebCore::FrameLoader::addExtraFieldsToRequest()
[FrameLoader.cpp:1191] WebCore::FrameLoader::loadURL()

implying that the FrameLoader doesn't have an active document loader at
that point.

-jochen



 If removing deprecatedFrameEncoding isn't possible at this time, we
 should revert http://trac.webkit.org/changeset/104723 because it
 causes crashes.  Rather than get into a revert war, however, I believe
 the project would be better served by talking out this issue.

 Adam
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] chromium image tests on lion

2012-01-09 Thread Jochen Eisinger
On Mon, Jan 9, 2012 at 7:47 AM, Simon Fraser simon.fra...@apple.com wrote:

 This could have been me:

 http://trac.webkit.org/changeset/104351


That changeset does not affect the chromium port

-jochen



 Ideally we'd turn on mock scrollbars everywhere and then regenerate all
 the results (checking for actual failures). Not sure if I'll have time to
 do that though.

 Simon

 On Jan 7, 2012, at 8:44 AM, Jarred Nicholls wrote:

  Hey all,
 
  I'm running the layout tests for chromium on lion, and pretty much all
 of them is failing.  LayoutTestHelper fails to set the generic RGB color
 profile, but after setting it manually the image diffs are very subtle
 (mostly around test rendering, but not too much on color).  Related to Skia
 change and/or just outdated expectations?
 
  Given that Lion isn't a core test runner for chromium and it's been red
 since who knows when, I suppose this is to be expected for now.
 
  Appreciate any comments so I can safely overlook this, thanks!
  Jarred
  ___
  webkit-dev mailing list
  webkit-dev@lists.webkit.org
  http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] chromium image tests on lion

2012-01-07 Thread Jochen Eisinger
Here's a patch to fix the LayoutTestHelper:
https://bugs.webkit.org/show_bug.cgi?id=75618, however, as you already
noted, this doesn't help with the other issues

-jochen

On Sat, Jan 7, 2012 at 5:44 PM, Jarred Nicholls jar...@webkit.org wrote:

 Hey all,

 I'm running the layout tests for chromium on lion, and pretty much all of
 them is failing.  LayoutTestHelper fails to set the generic RGB color
 profile, but after setting it manually the image diffs are very subtle
 (mostly around test rendering, but not too much on color).  Related to Skia
 change and/or just outdated expectations?

 Given that Lion isn't a core test runner for chromium and it's been red
 since who knows when, I suppose this is to be expected for now.

 Appreciate any comments so I can safely overlook this, thanks!
  Jarred

 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] setting http referrer using webkit

2010-06-07 Thread Jochen Eisinger
(using correct sender...)

In chromium, we use willSendRequest to remove the referer header from the
request. This also hides the referer from javascript. The test
http/tests/security/no-referer.html checks this

On Mon, Jun 7, 2010 at 3:21 PM, kizilbas ki2il...@web.de wrote:


 hi mates,

 can anybody tell me how i can set the http referrer using webkit?
 i am exercising anonymizing techniques by  extending the suckless browser
 surf.
 obfuscating the user-agent was pretty easy but i don't have any idea how
 the
 referer can be set using the webkit libraries.
 i'm developing on linux.

 thanks for your help.

 cheers,
 kizilbas


 --
 View this message in context:
 http://old.nabble.com/setting-http-referrer-using-webkit-tp28804028p28804028.html
 Sent from the Webkit mailing list archive at Nabble.com.

 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] [webkit-changes] [55234] trunk/JavaScriptCore

2010-02-25 Thread Jochen Eisinger
Here's a bit of context. When a database is opened, right now you
don't have any context from where it is opened. The problem is that
the actual calls that open a database go through the sqlite3 vfs
layer, so there's no easy way to pass this function down to to
platform/sql/chromium/SQLFileSystemChromium*.cpp

This patch will allow you to get from anywhere within webkit a pointer
to the Thread object that actually created the thread you're currently
on (in case of the database, this can be either a thread forked of
from the main thread or from a worker thread), and query the object
for context information.

I hope this explains this.

best
-jochen

On Thu, Feb 25, 2010 at 6:31 PM, Alexey Proskuryakov a...@webkit.org wrote:

 There is not a single word explaining this change - neither in ChangeLog,
 nor in the bug. Such a patch shouldn't have been accepted. Is there any
 reason not to roll it out?
 - WBR, Alexey Proskuryakov
 On 25.02.2010, at 6:49, e...@webkit.org wrote:

 revision55234authore...@webkit.orgdate2010-02-25 06:49:12 -0800 (Thu, 25 Feb
 2010)

 Log Message

 2010-02-25  Jochen Eisinger  joc...@chromium.org

 Reviewed by Jeremy Orlow.

 Make the context that was passed to the ThreadFunction accessible.
 https://bugs.webkit.org/show_bug.cgi?id=35379

 * wtf/Threading.h:
 * wtf/ThreadingNone.cpp:
 (WTF::threadContext):
 * wtf/ThreadingPthreads.cpp:
 (WTF::):
 (WTF::identifierByPthreadHandle):
 (WTF::establishIdentifierForPthreadHandle):
 (WTF::pthreadHandleForIdentifier):
 (WTF::contextForIdentifier):
 (WTF::createThreadInternal):
 (WTF::currentThread):
 (WTF::threadContext):
 * wtf/ThreadingWin.cpp:
 (WTF::):
 (WTF::threadMap):
 (WTF::storeThreadHandleByIdentifier):
 (WTF::threadHandleForIdentifier):
 (WTF::contextForIdentifier):
 (WTF::createThreadInternal):
 (WTF::threadContext):


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev