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

[Jochen Eisinger]

Adding Dmitry who recently updated the V8/blink implementation.

-jochen


On Wed, Aug 14, 2013 at 9:19 AM, Filip Pizlo  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  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

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

[Jochen Eisinger]

On Fri, Apr 12, 2013 at 10:58 PM, Benjamin Poulain wrote:

> On Fri, Apr 12, 2013 at 5:05 AM, Jochen Eisinger wrote:
>>
>> 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] restricting the number of new windows created in response to a user gesture

[Jochen Eisinger]

On Fri, Apr 12, 2013 at 10:40 PM, Brady Eidson  wrote:

>
> On Apr 12, 2013, at 5:05 AM, Jochen Eisinger  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

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

[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] Somewhat painful AppEngine transitions coming [Caution: Message contains Suspicious URL content]

[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 wrote:

> 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.**comand
>> http://webkit-commit-queue.**appspot.comto
>>  Apple owned
>> http://webkit-test-results.**appspot.comand
>> http://webkit-queues.appspot.**com 
>> respectively.
>>
>> Ojan and I have already moved the flakiness dashboard to
>> http://webkit-test-results.**appspot.comso
>>  builders on
>> build.webkit.org  have started uploading
>> results there.  Unfortunately, the historical results are still on
>> 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.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-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

[Jochen Eisinger]

On Tue, Mar 19, 2013 at 2:50 PM, Geoffrey Garen  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

[Jochen Eisinger]

On Tue, Mar 19, 2013 at 11:42 AM, Maciej Stachowiak  wrote:

>
> On Mar 19, 2013, at 11:12 AM, Geoffrey Garen  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 

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

[Jochen Eisinger]

On Mon, Mar 18, 2013 at 9:49 AM, Elliott Sprehn wrote:

>
> On Sun, Mar 17, 2013 at 8:26 PM, Geoffrey Garen  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

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

[Jochen Eisinger]

On Mon, Mar 18, 2013 at 7:27 AM, Arunprasad Rajkumar  wrote:

>
>
> On 18 March 2013 13:00, Jochen Eisinger  wrote:
>
>>
>>
>>
>> On Sun, Mar 17, 2013 at 8:26 PM, Geoffrey Garen  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

[Jochen Eisinger]

On Sun, Mar 17, 2013 at 8:26 PM, Geoffrey Garen  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

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

[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?

[Jochen Eisinger]

On Mon, Feb 11, 2013 at 8:19 AM, Benjamin Poulain wrote:

> On Sun, Feb 10, 2013 at 10:56 PM, Jochen Eisinger wrote:
>
>> 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] Can Qt use some of the common DRT code?

[Jochen Eisinger]

On Mon, Feb 11, 2013 at 3:37 AM, Benjamin Poulain wrote:

> 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] Exporting symbols (was Re: Common build system (was Re: WebKit Wishes))

[Jochen Eisinger]

On Sun, Feb 3, 2013 at 7:29 AM, Benjamin Poulain wrote:

> On Sat, Feb 2, 2013 at 10:23 PM, Eric Seidel  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)

[Jochen Eisinger]

On Thu, Jan 31, 2013 at 10:37 AM, Ryosuke Niwa  wrote:

> On Thu, Jan 31, 2013 at 1:17 AM, Jochen Eisinger wrote:
>
>> 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  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)

[Jochen Eisinger]

On Thu, Jan 31, 2013 at 10:12 AM, Mark Rowe  wrote:

>
> On 2013-01-31, at 00:59, Jochen Eisinger  wrote:
>
>
>
> On Thu, Jan 31, 2013 at 9:53 AM, Mark Rowe  wrote:
>
>>
>> On 2013-01-31, at 00:48, Adam Barth  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)

[Jochen Eisinger]

On Thu, Jan 31, 2013 at 9:53 AM, Mark Rowe  wrote:

>
> On 2013-01-31, at 00:48, Adam Barth  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)

[Jochen Eisinger]

On Thu, Jan 31, 2013 at 1:15 AM, Maciej Stachowiak  wrote:

>
> On Jan 30, 2013, at 3:24 PM, Dirk Pranke  wrote:
>
> > On Wed, Jan 30, 2013 at 1:50 PM, Filip Pizlo  wrote:
> >> Thanks for sharing this.
> >>
> >> On Jan 30, 2013, at 1:28 PM, Eric Seidel  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()?

[Jochen Eisinger]

On Mon, Jan 28, 2013 at 11:33 PM, John Gregg  wrote:

>
>
>
>
>
> On Mon, Jan 28, 2013 at 2:24 PM, Jochen Eisinger wrote:
>
>>
>>
>> On Mon, Jan 28, 2013 at 11:19 PM, Elliott Sprehn wrote:
>>
>>> 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 wrote:
>>>
>>>> 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] Can we remove Notification.show()?

[Jochen Eisinger]

On Mon, Jan 28, 2013 at 11:19 PM, Elliott Sprehn wrote:

> 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 wrote:
>
>> 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] Do any ports still disable SVG?

[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

[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  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

[webkit-dev] Chromium TestRunner API

[Jochen Eisinger]

Hi,

the chromium port is now exposing a new public API defined in
Tools/DumpRenderTree/chromium/TestRunner/public

Chromium's content_shell and DumpRenderTree(*) are depending on this API to
instantiate almost all (+) test runner methods required to run layout
tests. Therefore, the same rules as for the other chromium public APIs
apply: https://trac.webkit.org/wiki/ChromiumWebKitAPI

best
-jochen

(*) DumpRenderTree/chromium/DRTTestRunner.* still includes some private
files of the TestRunner API. I'm working on fixing this - please don't add
new layering violations in the meanwhile.
(+) I'm currently working on moving DRTTestRunner to the TestRunner library
as well
___
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

[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  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

[Jochen Eisinger]

On Fri, Jul 13, 2012 at 11:15 PM, Darin Fisher  wrote:

>
>
> On Fri, Jul 13, 2012 at 2:10 PM, Adam Barth  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 wrote:
>>
>>> 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  wrote:
>>>
>>>> On Fri, Jul 13, 2012 at 1:10 PM, Jochen Eisinger 
>>>> wrote:
>>>>
>>>>> On Fri, Jul 13, 2012 at 7:46 PM, Ryosuke Niwa wrote:
>>>>>
>>>>>> On Fri, Jul 13, 2012 at 4:16 AM, Jochen Eisinger >>>>> > 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

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

[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  wrote:

> On Fri, Jul 13, 2012 at 1:10 PM, Jochen Eisinger wrote:
>
>> On Fri, Jul 13, 2012 at 7:46 PM, Ryosuke Niwa  wrote:
>>
>>> On Fri, Jul 13, 2012 at 4:16 AM, Jochen Eisinger 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

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

[Jochen Eisinger]

On Fri, Jul 13, 2012 at 7:46 PM, Ryosuke Niwa  wrote:

> On Fri, Jul 13, 2012 at 4:16 AM, Jochen Eisinger 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

-jochen


>
> - Ryosuke
>
>
___
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

[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] [patch] fix webkit-gtk build with automake 1.12

[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
wrote:

>  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 
>
> 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

[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  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

[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  wrote:

>
>
> On Fri, Jun 8, 2012 at 12:51 PM, Jochen Eisinger wrote:
>
>>
>>
>> On Fri, Jun 8, 2012 at 9:41 PM, Ryosuke Niwa  wrote:
>>
>>> On Fri, Jun 8, 2012 at 12:18 PM, Jochen Eisinger wrote:
>>>
>>>> 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.js&exact_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

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

[Jochen Eisinger]

On Fri, Jun 8, 2012 at 9:55 PM, Ryosuke Niwa  wrote:

> On Fri, Jun 8, 2012 at 12:51 PM, Jochen Eisinger wrote:
>
>>  On Fri, Jun 8, 2012 at 9:41 PM, Ryosuke Niwa  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

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

[Jochen Eisinger]

On Fri, Jun 8, 2012 at 9:41 PM, Ryosuke Niwa  wrote:

> On Fri, Jun 8, 2012 at 12:18 PM, Jochen Eisinger wrote:
>
>> 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.js&exact_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

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

[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] Changes to window.focus/window.blur controlled by a setting?

[Jochen Eisinger]

On Mon, May 21, 2012 at 9:16 PM, Andrew Wilson  wrote:

>
>
> On Mon, May 21, 2012 at 2:17 AM, Jochen Eisinger 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.
>>
>
> 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

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

[Jochen Eisinger]

On Mon, May 21, 2012 at 8:17 PM, Eric Seidel  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 
> wrote:
> >
> >
> > On Mon, May 21, 2012 at 1:16 PM, Eric Seidel  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 
> >> 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?

[Jochen Eisinger]

On Mon, May 21, 2012 at 1:16 PM, Eric Seidel  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 
> 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

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

[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] feature proposal: restricting window.blur/focus

[Jochen Eisinger]

On Wed, Apr 4, 2012 at 8:01 PM, Darin Fisher  wrote:

> On Wed, Apr 4, 2012 at 10:58 AM, Jochen Eisinger wrote:
>
>>
>> On Wed, Apr 4, 2012 at 7:53 PM, Darin Fisher  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 wrote:
>>>
>>>> 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

[Jochen Eisinger]

On Wed, Apr 4, 2012 at 7:53 PM, Darin Fisher  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 wrote:
>
>> 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] feature proposal: restricting window.blur/focus

[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] number of wrapped objects in JSC

[Jochen Eisinger]

On Mon, Mar 19, 2012 at 9:47 PM, Geoffrey Garen  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

[webkit-dev] number of wrapped objects in JSC

[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] Moving to Git?

[Jochen Eisinger]

On Thu, Mar 8, 2012 at 9:12 PM, Ryosuke Niwa  wrote:

> On Thu, Mar 8, 2012 at 12:04 PM, Adam Treat  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  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

Re: [webkit-dev] Adding to WebCore

[Jochen Eisinger]

On Tue, Mar 6, 2012 at 5:31 PM, Joe Mason  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  to WebCore
>
> Hey all,
>
> this is a belated announcement of the  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

[webkit-dev] Adding to WebCore

[Jochen Eisinger]

Hey all,

this is a belated announcement of the  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] Removing obsolete File attributes

[Jochen Eisinger]

On Fri, Feb 24, 2012 at 10:38 PM, Eric Seidel  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 
> 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

[Jochen Eisinger]

On Sun, Jan 15, 2012 at 9:52 PM, Adam Barth  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

[Jochen Eisinger]

On Mon, Jan 9, 2012 at 7:47 AM, Simon Fraser  wrote:

> This could have been me:
>
> 
>

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

[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  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

[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  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

[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  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  
>
> 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