Re: [webkit-dev] "Magic Iframe" removal proposed

I actually do know of at least one WebKit-only application under development at Google that may be using this feature (I recently suggested it to them). Oh well. - a On Tue, Mar 20, 2012 at 8:07 AM, Adam Barth wrote: > Yeah, normally I would have waited longer, but the patch fixed a crash in >

Re: [webkit-dev] Moving to Git?

I think it would look the same, except for instead of monotonically increasing decimal numbers in the "revision" column, you'd see random hexadecimal ones (typically 6-8 digits long). On Thu, Mar 8, 2012 at 4:20 PM, Lucas Forschler wrote: > Could someone enlighten me on what this page would look

Re: [webkit-dev] Removing HTML notifications from WebKit (Was: Web Notifications API)

; the longer term. > > Jon? > > Regards, > Maciej > > On Feb 9, 2012, at 2:48 PM, Aaron Boodman wrote: > >> On Wed, Feb 8, 2012 at 7:50 PM, Maciej Stachowiak wrote: >>> >>> On Feb 8, 2012, at 6:15 PM, Aaron Boodman wrote: >>> >>>&

Re: [webkit-dev] Removing HTML notifications from WebKit (Was: Web Notifications API)

On Wed, Feb 8, 2012 at 7:50 PM, Maciej Stachowiak wrote: > > On Feb 8, 2012, at 6:15 PM, Aaron Boodman wrote: > >> On Wed, Feb 8, 2012 at 4:58 PM, Jon Lee wrote: >>> 2. Remove HTML notifications. >>> >>> It has been removed from the spec, and w

[webkit-dev] Removing HTML notifications from WebKit (Was: Web Notifications API)

On Wed, Feb 8, 2012 at 4:58 PM, Jon Lee wrote: > 2. Remove HTML notifications. > > It has been removed from the spec, and we don't intend on ever supporting > HTML notifications. I brought this issue up before; is there an update on > this front from any other platforms? HTML notifications are a

Re: [webkit-dev] Top 100 sites browsing tests proprosal

On Sun, Jan 22, 2012 at 12:00 PM, Peter Kasting wrote: > On Sun, Jan 22, 2012 at 11:55 AM, Balazs Kelemen wrote: >> >> As the goal is to test "real world" use case I think it can be even better >> to simply load the sites from network. >> I see only two disadvantage of that but neither of them ar

Re: [webkit-dev] coding style and comments

On Mon, Jan 31, 2011 at 7:18 PM, Peter Kasting wrote: > P.S. I agree with you about assertions being better than comments to > document pre- (and post-) conditions (where possible). Me too (where possible). - a ___ webkit-dev mailing list webkit-dev@li

Re: [webkit-dev] Fwd: coding style and comments

On Mon, Jan 31, 2011 at 5:48 PM, Aaron Boodman wrote: > void doA() { >  // We don't need to frobulate here because doC() already did that. > } I meant for doA() to call doB() obviously. - a ___ webkit-dev mailing list webkit-dev@lists.w

Re: [webkit-dev] Fwd: coding style and comments

On Mon, Jan 31, 2011 at 5:23 PM, Ryosuke Niwa wrote: > On Mon, Jan 31, 2011 at 4:54 PM, Aaron Boodman wrote: >> >> It seems like the one line patch to C just broke A. It had a >> dependency on the behavior of C that was worth documenting. Now you >> have changed

Re: [webkit-dev] Fwd: coding style and comments

On Mon, Jan 31, 2011 at 12:47 AM, Ryosuke Niwa wrote: > How can we ensure that all comments are up to do date?  For example, suppose > function A calls B, and B calls C.  Then in the call site of A, I comment > "Because A does X, we do Y."  Now suppose for the moment that the behavior X > of A is

Re: [webkit-dev] bugs.webkit.org autocomplete

Ojan could also autoupdate the extension to be a noop. - a On Tue, Sep 14, 2010 at 7:10 PM, Adam Barth wrote: > Hi webkit-dev, > > I just landed a change to bugs.webkit.org to autocomplete email > address for committers and reviewers.  If you've been using Ojan's > awesome extension, it's the sa

Re: [webkit-dev] Name nitpick: "layout tests"

On Tue, Aug 3, 2010 at 1:27 PM, Darin Adler wrote: > I don’t buy in to this at all. We have done many successful renaming projects > in the past. The future is bigger than the past and it’s worthwhile to do > maintenance like this. Okie. - a ___ webk

Re: [webkit-dev] Name nitpick: "layout tests"

On Mon, Aug 2, 2010 at 9:40 AM, Darin Fisher wrote: > On Mon, Aug 2, 2010 at 7:33 AM, Dan Bernstein wrote: >> >> On Aug 2, 2010, at 4:28 AM, Alexey Proskuryakov wrote: >> >> > >> > 29.07.2010, в 10:59, Darin Adler написал(а): >> > >> >> The directory should be eventually be named Tests or WebKitT

Re: [webkit-dev] Implementing the sizes attribute of the link tag from HTML5

On Mon, Apr 19, 2010 at 5:53 PM, Peter Kasting wrote: > On Thu, Apr 15, 2010 at 3:41 PM, Aaron Boodman wrote: >> >> I'm not sure what the path is for fetching favicons today. Does >> WebCore just implicitly do it, or does it expose the information to >> the hos

Re: [webkit-dev] Implementing the sizes attribute of the link tag from HTML5

On Thu, Apr 15, 2010 at 3:25 PM, Maciej Stachowiak wrote: > Well, it's hard to truly have consensus on adding feature without knowing > what it is. That being said, I at least would love to see a more specific > proposal for what we could do with . I want to support bigger icons for the tabs in C

Re: [webkit-dev] Implementing the sizes attribute of the link tag from HTML5

On Thu, Apr 15, 2010 at 3:09 PM, Maciej Stachowiak wrote: > > On Apr 15, 2010, at 2:22 PM, Aaron Boodman wrote: > >> I would like to do it. See bug: >> https://bugs.webkit.org/show_bug.cgi?id=37674 >> >> Thoughts? > > > Seems like a good idea in gene

[webkit-dev] Implementing the sizes attribute of the link tag from HTML5

I would like to do it. See bug: https://bugs.webkit.org/show_bug.cgi?id=37674 Thoughts? - a ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] Opinion requested on change to FrameView::adjustSize()

I'm not sure who else besides dhyatt is good to opine on this. I'd like to change FrameView::adjustSize() to use slightly different logic so that it works better for applications that want a WebView to atomically size to the content height. I'd like feedback on whether this is a good approach, or

Re: [webkit-dev] [V8] It's time for V8Proxy to come to Jesus

+1: Hooray for any attempts to tame V8Proxy. - a On Fri, Jul 3, 2009 at 12:23 PM, Adam Barth wrote: > If you're uninterested in the V8 bindings, you can skip this email. > > Clocking in at 3255 lines (plus a 682-line header file), V8Proxy is > out of control.  Historically a bridge from the V8 bi

Re: [webkit-dev] browser extensions

Hey Patrick, Extensions logically fall outside the boundary of the rendering engine, and that is the way we've approached in Chromium, too. But since Chromium extensions are basically just web pages with a few extra APIs added, there is a relatively obvious path to compatibility and even sharing c

Re: [webkit-dev] Allowing webkit clients to extend XHR security policy

be a fine direction. > > - WBR, Alexey Proskuryakov > > > On 12.04.2009, at 22:58, Aaron Boodman wrote: > >> It sounds to me like our current patch is the best fit because it fits >> our needs, will work with Chromium's out-of-process workers, plus it >> al

Re: [webkit-dev] Allowing webkit clients to extend XHR security policy

natively, can I get an idea for a different approach that would be accepted? Thanks, - a On Fri, Apr 10, 2009 at 10:23 AM, Aaron Boodman wrote: > On Thu, Apr 9, 2009 at 9:50 PM, David Levin wrote: >> >> On Thu, Apr 9, 2009 at 9:03 PM, Alexey Proskuryakov wrote: >>> >

Re: [webkit-dev] Allowing webkit clients to extend XHR security policy

On Thu, Apr 9, 2009 at 9:50 PM, David Levin wrote: > > On Thu, Apr 9, 2009 at 9:03 PM, Alexey Proskuryakov wrote: >> >> On 09.04.2009, at 22:38, Aaron Boodman wrote: >> >>> The local scheme feature is actually more powerful than just XHR >> >> If you

Re: [webkit-dev] Allowing webkit clients to extend XHR security policy

Adding back webkit-dev... On Thu, Apr 9, 2009 at 11:36 AM, Aaron Boodman wrote: > Ok, so if I may sum up the conversation so far: > > * A static call out to a client is ugly, but OK as a temporary measure > * You would like to see this mechanism replace the "local scheme"

Re: [webkit-dev] Allowing webkit clients to extend XHR security policy

On Wed, Apr 8, 2009 at 11:53 PM, Alexey Proskuryakov wrote: > > On 09.04.2009, at 1:23, Aaron Boodman wrote: > >> Rafael Weinstein, who is working with me, consulted with Adam Barth >> and submitted a patch based on his ideas >> <https://bugs.webkit.org/show_bug.cgi?

[webkit-dev] Allowing webkit clients to extend XHR security policy

Hello all, I'm working on adding extensions (aka "Add-Ons") to Chromium. One thing we want to enable these extensions to do is to make limited cross-origin XMLHttpRequests. Rafael Weinstein, who is working with me, consulted with Adam Barth and submitted a patch based on his ideas

Re: [webkit-dev] C++ callback at same-ish point as DOMContentLoaded javascript event?

On Sun, Nov 16, 2008 at 6:10 PM, Maciej Stachowiak <[EMAIL PROTECTED]> wrote: > In conclusion, I would say it is ok to change it. If we find some > third-party app that for some reason requires the old behavior, I think a > one-off compatibility hack for such an app would be an acceptable solution.

Re: [webkit-dev] C++ callback at same-ish point as DOMContentLoaded javascript event?

On Sun, Nov 16, 2008 at 5:33 PM, Maciej Stachowiak <[EMAIL PROTECTED]> wrote: > > On Nov 16, 2008, at 5:16 PM, Maciej Stachowiak wrote: > >> >> On Nov 16, 2008, at 2:53 PM, Aaron Boodman wrote: >> >>> Hello all, >>> >>> I'd l

[webkit-dev] C++ callback at same-ish point as DOMContentLoaded javascript event?

Hello all, I'd like to run some C++ around the same point as the DOMContentLoaded event is fired. Importantly, I need this to happen *before* the window's onload event fires. FrameLoaderClient::dispatchDidFinishDocumentLoad is usually fired at the right point, but it can sometimes happen after wi

Re: [webkit-dev] High Resolution Timer API proposal(s)

On Thu, Oct 2, 2008 at 7:08 PM, Alex Iskander <[EMAIL PROTECTED]> wrote: > I agree. "Repeating", it seems to me, should be an optional argument; the > callback and time, on the other hand, are completely necessary. Good point. > The default value for "repeating" is probably up for debate. Would m

Re: [webkit-dev] High Resolution Timer API proposal(s)

On Thu, Oct 2, 2008 at 5:05 PM, Maciej Stachowiak <[EMAIL PROTECTED]> wrote: > Timer startTimer(double delayInSeconds, bool repeating, Function > callback); > > interface Timer { > void stop(); > } One other random idea. What about mixing up the param order for parallelism with the existing ti

Re: [webkit-dev] High Resolution Timer API proposal(s)

On Thu, Oct 2, 2008 at 5:05 PM, Maciej Stachowiak <[EMAIL PROTECTED]> wrote: > - Starts a timer that will call function "callback" after > "delayInSeconds", which may be a fractional number of seconds. It seems safe to assume that a large number of timers are going to be on the order of 1-10ms. Be

Re: [webkit-dev] High Resolution Timer API proposal(s)

On Thu, Oct 2, 2008 at 5:05 PM, Maciej Stachowiak <[EMAIL PROTECTED]> wrote: > I don't really like the overengineered version. I like the "fairly > minimalist" version best, but is there anything from the > overengineered version that should be added to it? I like the "fairly minimalist" version b