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

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

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

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

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

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 actua

Re: [webkit-dev] Removing deprecatedFrameEncoding

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 ab

Re: [webkit-dev] Removing obsolete File attributes

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

[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

Re: [webkit-dev] Adding to WebCore

gt; 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.

Re: [webkit-dev] Moving to Git?

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 pat

[webkit-dev] number of wrapped objects in JSC

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

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

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 o

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

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 t

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

nt 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() (

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

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 >

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

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 po

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

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

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

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

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

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

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

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 ch

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

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

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

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

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

n 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: >>&g

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

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

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

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 th

[webkit-dev] Updates on Chromium's content_shell

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

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

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

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

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

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

us 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

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

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

[webkit-dev] Chromium TestRunner API

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 a

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

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

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

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] Can we remove Notification.show()?

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

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

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

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

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

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

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

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

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

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

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 >

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

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 decor

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

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

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

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

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

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

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

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

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

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 disabl

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

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

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

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 S

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

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

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

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 scriptin

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

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?

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

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

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

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

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

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

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

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 Chro