Thanks for the heads up!
-Darin
On Sun, Feb 10, 2013 at 1:53 PM, Maciej Stachowiak m...@apple.com wrote:
Here is a list all iOS-specific changes in WebCore and below that are due
to the iOS WebKit threading model, from an exhaustive review of diffs to
the downstream source. I'm not sure
On Fri, Feb 8, 2013 at 2:05 PM, Maciej Stachowiak m...@apple.com wrote:
On Feb 8, 2013, at 1:41 PM, Adam Barth aba...@webkit.org wrote:
Context: https://bugs.webkit.org/show_bug.cgi?id=109071
Adam Barth said:
It's not clear to me that running WebCore on multiple interlocked
threads is
On Sat, Feb 2, 2013 at 4:16 PM, James Robinson jam...@google.com wrote:
On Fri, Feb 1, 2013 at 5:12 PM, Balazs Kelemen kbal...@webkit.org wrote:
On 02/01/2013 02:28 AM, Darin Fisher wrote:
It would be nice if, in the shared library build of chromium, webcore
and perhaps the modules
It would be nice if, in the shared library build of chromium, webcore and
perhaps the modules and platform were separate DLLs.
On Jan 31, 2013 4:15 PM, Eric Seidel e...@webkit.org wrote:
I believe that it's a design mistake for WebCore to need to know
anything about it's embedder, more than
Has anyone reviewed the Stream API proposal from Microsoft?
Here's the spec:
http://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm
I see only a little mention of it on webapps-public:
http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1494.html
(I haven't looked over the
I agree with what Adam wrote in
https://bugs.webkit.org/show_bug.cgi?id=99116#c5. Even if a lot of sites
will magically failover to the unprefixed API, we can't know for sure that
this change won't break sites. We need to give them a chance to update.
(I don't know if one Chrome release cycle
On Thu, Sep 13, 2012 at 6:16 PM, Adam Barth aba...@webkit.org wrote:
On Thu, Sep 13, 2012 at 5:13 PM, Adam Barth aba...@webkit.org wrote:
Another metric we have is for Blob.webkitSlice:
Ratio of Blob.webkitSlice calls to Blob.slice: 14.87%
Ratio of Blob.webkitSlice calls to Document
, Jun 11, 2012 at 3:34 PM, Darin Fisher da...@chromium.org wrote:
Happy to see us support unprefixed too. With other vendors on board, it
seems like a straightforward addition to the platform.
I'm not sure if you are proposing to also remove the prefixed form. I'm
not sure what it would take
https://developer.mozilla.org/en/XmlHttpRequest#Non-standard_propertiessays
that elevated privileges are required to access mozBackgroundRequest.
That suggests that it is only there for use by Firefox and Firefox
extensions.
At the very least, it seems like in Chromium, if we cannot suppress
At least DOMInterface::interfaceName() is no where near as bad as COM's
QueryInterface.
Provided we don't end up with any diamond inheritance hierarchies, we
shouldn't need
something as complicated as QueryInterface.
-Darin
On Wed, Jul 25, 2012 at 2:33 PM, Adam Barth aba...@webkit.org wrote:
On Mon, Jul 16, 2012 at 2:57 AM, Jochen Eisinger joc...@chromium.orgwrote:
On Fri, Jul 13, 2012 at 11:15 PM, Darin Fisher da...@chromium.org wrote:
On Fri, Jul 13, 2012 at 2:10 PM, Adam Barth aba...@webkit.org wrote:
Yeah, EventSender is likely a good place to start. Here are some more
On Fri, Jul 13, 2012 at 10:59 AM, Eric Seidel e...@webkit.org wrote:
bikeshedding
Just like we don't call the class DOMDocument, there is no need to add
the CSS prefix where there aren't collisions (IMO).
I do think we should drop the WebKit prefix from all classes, and
use InterfaceName=
Happy to see us support unprefixed too. With other vendors on board, it
seems like a straightforward addition to the platform.
I'm not sure if you are proposing to also remove the prefixed form. I'm
not sure what it would take to remove the prefixed version. We'd need some
way to know when it
On Fri, Jun 8, 2012 at 12:51 PM, Jochen Eisinger joc...@chromium.orgwrote:
On Fri, Jun 8, 2012 at 9:41 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Fri, Jun 8, 2012 at 12:18 PM, Jochen Eisinger joc...@chromium.orgwrote:
I've implemented initial support for running layout tests using
On Sun, Apr 29, 2012 at 3:44 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Fri, Apr 27, 2012 at 1:49 AM, Nat Duca nd...@chromium.org wrote:
I'm concerned at how well this would work graphics performance tests.
Consider:
http://web.archive.org/web/20110111083848/http://techcrunch.com/
On Sun, Apr 29, 2012 at 1:25 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Sun, Apr 29, 2012 at 1:06 PM, Maciej Stachowiak m...@apple.com wrote:
On Apr 29, 2012, at 12:53 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Sun, Apr 29, 2012 at 12:34 PM, Maciej Stachowiak m...@apple.comwrote:
On Apr
On Mon, Apr 16, 2012 at 12:55 PM, Maciej Stachowiak m...@apple.com wrote:
On Apr 16, 2012, at 10:52 AM, Darin Fisher wrote:
Could this be an opportunity to design an asynchronous API for fetching
the pixel buffer? It seems like many implementations are GPU backed now,
and fetching
On Mon, Apr 16, 2012 at 1:42 PM, Oliver Hunt oli...@apple.com wrote:
On Apr 16, 2012, at 1:00 PM, Darin Fisher da...@chromium.org wrote:
On Mon, Apr 16, 2012 at 12:55 PM, Maciej Stachowiak m...@apple.com wrote:
On Apr 16, 2012, at 10:52 AM, Darin Fisher wrote:
Could
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.
-Darin
On Wed, Apr 4, 2012 at 1:31 AM, Jochen Eisinger joc...@chromium.org wrote:
Hey,
Firefox restricts the
On Wed, Apr 4, 2012 at 10:58 AM, Jochen Eisinger joc...@chromium.orgwrote:
On Wed, Apr 4, 2012 at 7:53 PM, Darin Fisher da...@chromium.org wrote:
Matching Firefox behavior likely means that we won't have to worry about
breaking sites. We may have to worry about breaking Chrome Extensions
On Wed, Apr 4, 2012 at 11:17 AM, Jochen Eisinger joc...@chromium.orgwrote:
On Wed, Apr 4, 2012 at 8:01 PM, Darin Fisher da...@chromium.org wrote:
On Wed, Apr 4, 2012 at 10:58 AM, Jochen Eisinger joc...@chromium.orgwrote:
On Wed, Apr 4, 2012 at 7:53 PM, Darin Fisher da...@chromium.org
revisit this question next Friday?
(It's also probably better to discuss this on webkit-dev, but I didn't
know if you had intended this email as private.)
-eric
On Fri, Mar 30, 2012 at 4:59 PM, Darin Fisher da...@chromium.org wrote:
On Fri, Mar 30, 2012 at 4:01 PM, Eric Seidel e
Hrm, if the test expectations are customized already for different ports of
WebKit, then why not support replacing a PNG file with a HTML file that is
intended to generate exactly the same result? How does this impair our
ability to update the tests?
(I realize that our current reftest system
Nice. Is there a plan for modularizing Settings?
On Feb 28, 2012 12:30 AM, Adam Barth aba...@webkit.org wrote:
I wrote up a short wiki page explaining how the modules system works
and how to use it when building new features:
https://trac.webkit.org/wiki/Modules
We've been making good
boilerplate in the WebKit layer) from an in file.
Adam
On Tue, Feb 28, 2012 at 7:40 AM, Darin Fisher da...@chromium.org wrote:
Nice. Is there a plan for modularizing Settings?
On Feb 28, 2012 12:30 AM, Adam Barth aba...@webkit.org wrote:
I wrote up a short wiki page explaining how
Settings (do we still need them all?), and if we do, perhaps to break it up
somehow.
Simon
On Feb 28, 2012, at 10:27 AM, Darin Fisher wrote:
Good idea!
-Darin
On Tue, Feb 28, 2012 at 8:46 AM, Adam Barth aba...@webkit.org wrote:
We haven't done anything about Settings yet, but Setting is also
On Tue, Feb 28, 2012 at 11:11 AM, Alexey Proskuryakov a...@webkit.org wrote:
Having read the wiki page, I'm even more unhappy with the approach that
has been taken than I used to be. In fact, it is harmful even to the goals
of the refactoring.
If a single #ifdefed line in DOMWindow.idl is a
As I mentioned in the bug, it is encouraging news that Mozilla has already
removed these attributes (for a couple releases now). I would like to see
them go away too.
There's unfortunately, the real possibility that there may be some existing
webkit-specific or chrome-specific (extensions)
On Fri, Feb 24, 2012 at 12:00 PM, Maciej Stachowiak m...@apple.com wrote:
On Feb 24, 2012, at 11:52 AM, Darin Fisher wrote:
As I mentioned in the bug, it is encouraging news that Mozilla has already
removed these attributes (for a couple releases now). I would like to see
them go away too
Proskuryakov a...@webkit.org
wrote:
24.02.2012, в 12:20, Darin Fisher написал(а):
Perhaps a concrete good first step is to log a console warning when
they are
used? Warning, blahBlah is a deprecated attribute. Use fluxCapacitor
instead.
I'm not much in favor of such warnings
webkitRequestAnimationFrame may be helpful to you.
Regards,
-Darin
On Fri, Feb 17, 2012 at 11:00 AM, Ian Johnson enja...@gmail.com wrote:
Hi all,
I'm looking for the ability to synchronize my javascript calls with DOM
rendering. I want to do calculations based on the rendered size of an
The other concern I have is about the stability of the API to the URL
guts that GURL living in the chromium repository would depend on. Anyone
changing the URL guts would need to be careful not to break that contract.
This seems like it might be annoying for those who do not work on chromium.
On
On Sat, Jan 28, 2012 at 6:01 PM, Adam Barth aba...@webkit.org wrote:
On Sat, Jan 28, 2012 at 5:51 PM, Benjamin Poulain benja...@webkit.org
wrote:
On Sat, Jan 28, 2012 at 4:59 PM, Brett Wilson bre...@chromium.org
wrote:
So to clarify, I think we need to keep the current architecture.
On Fri, Jan 27, 2012 at 12:03 AM, Benjamin Poulain benja...@webkit.orgwrote:
On Thu, Jan 26, 2012 at 11:17 PM, Darin Fisher da...@chromium.org wrote:
Instead of doing all of this work, have you considered just treating
GoogleURL in much the same way as WebKit treats ANGLE? You could perhaps
On Fri, Jan 27, 2012 at 2:39 AM, Adam Barth aba...@webkit.org wrote:
On Fri, Jan 27, 2012 at 1:49 AM, Maciej Stachowiak m...@apple.com wrote:
That said, this plan was based on the premise that Chromium folks were
willing to cooperate with the unforking effort, and would be happy to
use a
On Thu, Jan 26, 2012 at 6:11 PM, Benjamin Poulain benja...@webkit.orgwrote:
Hello,
I would like to give another shot at the URL implementation Adam
started some times ago.
There are a few problems with the current KURL:
-there are two implementations: WebKit and Google URL
-some stuff are
Worst case, if you needed to keep String::adopt(Vector), it seems like you
could
use a bit in StringImpl::m_hashAndFlags to record the fact that the buffer
requires
special free handling.
-Darin
On Wed, Dec 7, 2011 at 10:24 AM, Adam Barth aba...@webkit.org wrote:
We originally used
Hi all,
Alexey appears to strongly dislike the name of this API specification (
http://dvcs.w3.org/hg/webevents/raw-file/default/gamepad.html), so much so
that he is blocking development of the API behind a flag.
As a reminder, this API is being developed through the WebEvents WG jointly
with
This proposal has matured somewhat, so an update is in order.
FYI:
http://dvcs.w3.org/hg/webevents/raw-file/default/gamepad.html
http://www.w3.org/2010/webevents/charter/2011/Overview.html
We are working behind the ENABLE(GAMEPAD) flag at the moment. Mozilla is
also building a prototype of this
I agree that this seems like something to #ifdef. Out of curiosity, did you
just stumble upon this, or did you actually notice a measurable performance
regression from this?
-Darin
On Thu, Oct 6, 2011 at 10:07 AM, Dan Bernstein m...@apple.com wrote:
On Oct 6, 2011, at 9:40 AM,
On Mon, Sep 26, 2011 at 10:47 AM, Alexey Proskuryakov a...@webkit.org wrote:
In the wake of Geoff's work to simplify threading ifdefs, and Adam's review
of supported ports, I'm curious what people think about maintaining many
platform branches in our WTF and JavaScriptCore threading code.
On Thu, Sep 22, 2011 at 2:23 PM, Alexey Proskuryakov a...@webkit.org wrote:
21.09.2011, в 12:52, Darin Fisher написал(а):
True, although there are still questions about how the user experience will
work for non-fullscreen. I think we only feel confident that we have a
decent fullscreen
On Thu, Sep 22, 2011 at 2:38 PM, Alexey Proskuryakov a...@webkit.org wrote:
22.09.2011, в 14:25, Darin Fisher написал(а):
Our next step is to extend this to non-fullscreen, so I think it would be
counter-productive to preclude non-fullscreen at this time.
I think that adding an API
Do you know if anyone is working to add this to the spec for Canvas? It
seems like it may not take much to get it added, given that FF already has
an implementation.
-Darin
On Thu, Sep 22, 2011 at 7:31 PM, Young Han Lee joybro...@gmail.com wrote:
Hi all,
I have a patch to add webkitLineDash
is only desirable
in full screen. I think that the spec has the goal of enabling it in browser
windows.
21.09.2011, в 11:22, Darin Fisher написал(а):
basing APIs largely on how Windows used to work up to version 7 may not be
future proof.
Yes, but 90% of internet users are not familiar
On Wed, Sep 21, 2011 at 12:46 PM, Peter Kasting pkast...@chromium.orgwrote:
On Wed, Sep 21, 2011 at 12:05 PM, Alexey Proskuryakov a...@webkit.orgwrote:
Anyway, I'm not sure if we already agreed that mouse lock is only
desirable in full screen. I think that the spec has the goal of enabling it
On Wed, Sep 14, 2011 at 3:40 PM, Adam Barth aba...@webkit.org wrote:
I've updated the spreadsheet of all ENABLE flags to match TOT (as of
this afternoon):
https://docs.google.com/spreadsheet/ccc?key=0AlC4tS7Ao1fIdHFVNUpFSDBudEF5WGM3WDNzQjI3Yncauthkey=CJCDiooKhl=en_US#gid=0
I've gone
Perhaps related to this thread, shouldn't we be basing SVG animations off of
the same animation scheduler that drives requestAnimationFrame and soon CSS
animations (https://bugs.webkit.org/show_bug.cgi?id=64591)? It seems less
than ideal to use a Timer.
-Darin
On Wed, Jul 27, 2011 at 11:14 AM,
Hello WebKit!
I just wanted to inform the list that we are working to develop a new
feature that will enable web pages to force a navigation to act like it was
served with a Content-Disposition: attachment response header.
We want to solve several use cases:
1- Support for initiating downloads
Are any other browsers implementing it?
On Jul 14, 2011 5:47 PM, Ryosuke Niwa rn...@webkit.org wrote:
Hi all,
I have a patch to add selectionDirection property on HTMLInputElement and
HTMLTextAreaElement on https://bugs.webkit.org/show_bug.cgi?id=60403.
The purpose of this property is to let
implementer?
-Darin
On Fri, Jul 15, 2011 at 11:26 AM, Ryosuke Niwa rn...@webkit.org wrote:
No, as far as I know.
- Ryosuke
On Fri, Jul 15, 2011 at 11:04 AM, Darin Fisher da...@chromium.org wrote:
Are any other browsers implementing it?
On Jul 14, 2011 5:47 PM, Ryosuke Niwa rn...@webkit.org wrote
On Fri, Jul 15, 2011 at 2:08 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Fri, Jul 15, 2011 at 2:01 PM, Darin Fisher da...@chromium.org wrote:
I should have also asked: do you have the support of other browser
vendors for this feature? Or, is it possible that when they set out to
solve
On Tue, Jul 12, 2011 at 10:25 AM, Darin Adler da...@apple.com wrote:
Hi folks.
The key to fast use of WTF::String is to avoid creating temporary
WTF::StringImpl objects or temporary copies of string data.
With the latest enhancements to WTF::String, here are the preferred fast
ways to
Vendor prefixing has proven to be vital to allowing one vendor to experiment
with an idea before it has broad support for implementation by other
vendors. It also means that we don't need to have coordination between
vendors about release schedules for new APIs. Related to that, it also
means
On Fri, Jul 1, 2011 at 3:04 PM, Darin Adler da...@apple.com wrote:
On Jul 1, 2011, at 2:54 PM, Dirk Pranke wrote:
Does that apply to -expected.txt files in the base directories, or just
platform-specific exceptions?
Base directories.
Expected files contain output reflecting the behavior
On Fri, Jul 1, 2011 at 3:37 PM, Dirk Pranke dpra...@chromium.org wrote:
On Fri, Jul 1, 2011 at 3:24 PM, Darin Fisher da...@chromium.org wrote:
On Fri, Jul 1, 2011 at 3:04 PM, Darin Adler da...@apple.com wrote:
On Jul 1, 2011, at 2:54 PM, Dirk Pranke wrote:
Does that apply
On Mon, Jun 27, 2011 at 1:40 PM, Alexey Proskuryakov a...@webkit.org wrote:
26.06.2011, в 19:37, Sreeram Ramachandran написал(а):
I'm not sure if historically browsers were often taking the liberty of
crippling widely used features in this way. We didn't kill marquee, for
instance. For
On Sun, Jun 26, 2011 at 1:53 PM, Sreeram Ramachandran
sree...@chromium.orgwrote:
On Sun, Jun 26, 2011 at 13:40, Ryosuke Niwa rn...@webkit.org wrote:
On Sun, Jun 26, 2011 at 1:37 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Sun, Jun 26, 2011 at 1:34 PM, Sreeram Ramachandran
On Fri, Jun 17, 2011 at 4:11 AM, Anssi Kostiainen
anssi.kostiai...@nokia.com wrote:
Hi,
On 16.6.2011, at 19.02, ext Darin Fisher wrote:
On Thu, Jun 16, 2011 at 5:12 AM, Anssi Kostiainen
anssi.kostiai...@nokia.com wrote:
On 15.6.2011, at 21.29, ext Darin Fisher wrote
On Fri, Jun 17, 2011 at 10:27 AM, Andrei Popescu andr...@google.com wrote:
On Fri, Jun 17, 2011 at 4:21 PM, Darin Fisher da...@chromium.org wrote:
On Fri, Jun 17, 2011 at 4:11 AM, Anssi Kostiainen
anssi.kostiai...@nokia.com wrote:
Hi,
On 16.6.2011, at 19.02, ext Darin Fisher
here, and that smarter
people than I have already hashed this all out on the spec list...
-eric
On Fri, Jun 17, 2011 at 10:40 AM, Darin Fisher da...@chromium.org wrote:
On Fri, Jun 17, 2011 at 10:27 AM, Andrei Popescu andr...@google.com
wrote:
On Fri, Jun 17, 2011 at 4:21 PM, Darin
to handle that case, and that's why the above-mentioned
requirement is in the spec.
On 15.6.2011, at 21.29, ext Darin Fisher wrote:
There should probably be a way to poll the current state. Much as you
can poll the document.readyState and respond to progress events, it would
seem to make
There should probably be a way to poll the current state. Much as you can
poll the document.readyState and respond to progress events, it would seem
to make sense to have a way to poll the battery state as well as respond to
battery state change events.
-Darin
On Wed, Jun 15, 2011 at 10:25 AM,
Good point! Maybe we can use a term that is derived from the name of the
spec? ENABLE_CSS3_FLEXBOX?
-Darin
On Mon, Jun 13, 2011 at 10:50 AM, Simon Fraser simon.fra...@apple.comwrote:
Using terms like 'new' in code is rarely a good idea. In a year, the
context has gone, and 'new' no longer
Is it possible for this feature to be enabled at runtime?
On Jun 8, 2011 11:38 AM, Adam Barth aba...@webkit.org wrote:
New features should be tested incrementally as they are developed.
That means running them on build.webkit.org. The decision to ship a
feature is separate.
Adam
On Wed,
.
Ojan
On Wed, Jun 8, 2011 at 11:41 AM, Darin Fisher da...@chromium.org
wrote:
Is it possible for this feature to be enabled at runtime?
On Jun 8, 2011 11:38 AM, Adam Barth aba...@webkit.org wrote:
New features should be tested incrementally as they are developed.
That means
On Wed, Jun 8, 2011 at 4:59 PM, James Robinson jam...@google.com wrote:
On Wed, Jun 8, 2011 at 4:55 PM, Darin Fisher da...@chromium.org wrote:
Oh, okay. Why do we have override_features.gypi then?
We don't, Adam tried to remove it earlier this week and was foiled by some
weird complex
, 2011 at 5:13 PM, Darin Fisher da...@chromium.org wrote:
On Wed, Jun 8, 2011 at 4:59 PM, James Robinson jam...@google.com wrote:
On Wed, Jun 8, 2011 at 4:55 PM, Darin Fisher da...@chromium.org wrote:
Oh, okay. Why do we have override_features.gypi then?
We don't, Adam tried to remove
where and to ship
where, not how to do the configuring.
Adam
On Jun 8, 2011 5:25 PM, Darin Fisher da...@chromium.org wrote:
Are you referring to the additional cost of maintaining different test
expectations between the two configs? Agreed, that would suck.
So, how painful would
I'm concerned that implementing this will only encourage more use of
localStorage. The API is very poor because it requires synchronous IO and
synchronization between browser contexts, which may live on different
threads. (Note: Chrome does not implement the required synchronization.)
If we
On Wed, May 18, 2011 at 2:35 PM, Ojan Vafai o...@chromium.org wrote:
On Wed, May 18, 2011 at 2:25 PM, Brent Fulgham bfulg...@gmail.com wrote:
Hi Peter,
On Wed, May 18, 2011 at 2:09 PM, Peter Kasting pkast...@google.com
wrote:
Google used this same approach with their Chromium port, the
On Fri, May 13, 2011 at 1:48 PM, Lucas De Marchi
lucas.demar...@profusion.mobi wrote:
On Fri, May 13, 2011 at 5:35 PM, Holger Freyther ze...@selfish.org
wrote:
On 05/12/2011 05:16 PM, Lucas De Marchi wrote:
Hi Holger Freyther,
I'm glad to hear you will use CMake as the build system.
I believe both maruel and jcivelli have had experience contributing changes
to gtest.
While I wouldn't characterize its code as simple, I haven't had trouble
understanding it. It is a fairly mature project, having been used
internally at Google for ages. It seems to be fairly well maintained,
As you know, I'm a very strong advocate of this change. I think even if
other
ports aren't interested in experimenting with this change at the current
time,
that we should proceed to experiment with it in Chromium. I would very much
like us to have data about how many sites are impacted, so that
On Thu, Feb 10, 2011 at 9:16 AM, Antonio Gomes toniki...@gmail.com wrote:
It was very common to use this approach on bugzilla.mozilla.org, with each
component in the system having its own dummy email address auto-added. This
allows developers to subscribe / unsubscribe from receiving email
You can also introduce a dummy email address, and then interested folks can
use bugzilla's email preferences to watch that email address. This is
perhaps a more lightweight version of using a mailing list as there is no
mailing list.
It was very common to use this approach on
Chromium-specific note:
link rel=icon is loaded externally to WebKit, which will likely complicate
matters here.
-Darin
On Wed, Jan 12, 2011 at 8:52 AM, Ojan Vafai o...@chromium.org wrote:
On Wed, Jan 12, 2011 at 8:05 AM, Gavin Peters (蓋文彼德斯) gav...@chromium.org
wrote:
1. Should HTML
Firefox definitely supports rel=prefetch in HTTP Link headers. I believe it
also supports other rel types, like stylesheet. The rel=subresource bit is
something new.
Supporting the Link header enables web servers to inject link tags without
modifying the document, which can be useful,
On Fri, Jan 7, 2011 at 9:12 AM, Ojan Vafai o...@chromium.org wrote:
On Thu, Jan 6, 2011 at 8:57 PM, Ryosuke Niwa ryosuke.n...@gmail.comwrote:
On Thu, Jan 6, 2011 at 8:31 PM, Darin Fisher da...@chromium.org wrote:
Using svn revision numbers has the downside of not reflecting branches
very
On Fri, Jan 7, 2011 at 9:30 AM, Ojan Vafai o...@chromium.org wrote:
On Fri, Jan 7, 2011 at 9:24 AM, Darin Fisher da...@chromium.org wrote:
On Fri, Jan 7, 2011 at 9:12 AM, Ojan Vafai o...@chromium.org wrote:
Right. Having a shared version number across WebKit builds will never
catch every
On Thu, Jan 6, 2011 at 12:47 PM, Darin Adler da...@apple.com wrote:
On Jan 6, 2011, at 12:41 PM, Joe Mason wrote:
I took a look at CodeGeneratorJS.pm to see how hard it would be to port
this over. I have no idea where to start… The structure of
CodeGeneratorJS.pm and CodeGeneratorV8.pm
On Thu, Jan 6, 2011 at 4:39 PM, Ojan Vafai o...@chromium.org wrote:
On Wed, Jan 5, 2011 at 9:38 AM, Darin Adler da...@apple.com wrote:
The user agent string in Chromium cites, for example,
AppleWebKit/534.10. Does this refer directly to the /tags/Safari-534.10
code base? In other words,
Correction: you meant pure virtual functions.
(I'm adding a note to the README file about these rules by the way.)
-Darin
On Fri, Dec 3, 2010 at 8:55 AM, Darin Fisher da...@chromium.org wrote:
Yes, indeed. Thanks Jeremy!
On Fri, Dec 3, 2010 at 3:13 AM, Jeremy Orlow jor...@chromium.org
I'm working on fixing some session history bugs related to a HistoryItem's
URL property changing.
See for example the call to HistoryItem::setURL in
HistoryController::updateForReload [1].
I'm curious about the platform specific fields on WebCore::HistoryItem. ***
Do any of those need to
be
On Tue, Dec 21, 2010 at 11:46 AM, Brady Eidson beid...@apple.com wrote:
On Dec 21, 2010, at 11:39 AM, Darin Fisher wrote:
I'm working on fixing some session history bugs related to a HistoryItem's
URL property changing.
See for example the call to HistoryItem::setURL in
HistoryController
On Tue, Dec 21, 2010 at 11:49 AM, Darin Fisher da...@chromium.org wrote:
On Tue, Dec 21, 2010 at 11:46 AM, Brady Eidson beid...@apple.com wrote:
On Dec 21, 2010, at 11:39 AM, Darin Fisher wrote:
I'm working on fixing some session history bugs related to a HistoryItem's
URL property
On Tue, Dec 21, 2010 at 2:56 PM, Brady Eidson beid...@apple.com wrote:
On Dec 21, 2010, at 1:57 PM, Darin Fisher wrote:
On Tue, Dec 21, 2010 at 11:49 AM, Darin Fisher da...@chromium.org wrote:
On Tue, Dec 21, 2010 at 11:46 AM, Brady Eidson beid...@apple.com wrote:
On Dec 21, 2010
On Tue, Dec 21, 2010 at 3:59 PM, Darin Fisher da...@chromium.org wrote:
On Tue, Dec 21, 2010 at 2:56 PM, Brady Eidson beid...@apple.com wrote:
On Dec 21, 2010, at 1:57 PM, Darin Fisher wrote:
On Tue, Dec 21, 2010 at 11:49 AM, Darin Fisher da...@chromium.orgwrote:
On Tue, Dec 21, 2010
Yes, indeed. Thanks Jeremy!
On Fri, Dec 3, 2010 at 3:13 AM, Jeremy Orlow jor...@chromium.org wrote:
You forgot to mention virtual functions, which is another case where you do
_not_ use WEBKIT_API.
J
On Thu, Dec 2, 2010 at 9:27 PM, Darin Fisher da...@chromium.org wrote:
If you do
On Fri, Dec 3, 2010 at 1:28 PM, Eric Seidel e...@webkit.org wrote:
It seems to me, that using bool types for function arguments is strictly
worse than using an enum. An enum is always clearer and can be easily
casted to a bool if needed.
doSomething(something, false);
Is much less
If you do not work on the Chromium port of WebKit, you can stop reading now.
I've noticed that there is some confusion about how to use WEBKIT_API
properly.
WEBKIT_API causes a function to be exported from WebKit when it is built as
a DLL,
allowing Chromium to call the function.
The rule is
The solution for .responseBlob was to add an .asBlob attribute that would
need to be set to true before calling .send(). We could do the same for
.responseArrayBuffer.
-Darin
On Mon, Oct 25, 2010 at 12:17 PM, Geoffrey Garen gga...@apple.com wrote:
Hi Chris.
I like the efficiency of this
How do you address the discoverability issue that I raised? asBlob and
asArrayBuffer have the benefit of being detectable at runtime. but, a
settable responseType does not support detection of supported values.
-Darin
On Mon, Oct 25, 2010 at 2:54 PM, Chris Rogers crog...@google.com wrote:
I think we're just coming at this from the point of view of trying to avoid
UA-specific APIs exposed to web content. It seems risky to build APIs
outside of WebKit that may be adopted by other UAs. We can certainly
revisit this if that ever becomes reality.
(Our current implementation exists on
On Tue, Oct 12, 2010 at 10:39 PM, Maciej Stachowiak m...@apple.com wrote:
On Oct 12, 2010, at 10:03 PM, Darin Fisher wrote:
On Tue, Oct 12, 2010 at 3:46 PM, Maciej Stachowiak m...@apple.com wrote:
On Oct 12, 2010, at 2:37 PM, Darin Fisher wrote:
On Tue, Oct 12, 2010 at 1:20 PM, Maciej
On Tue, Oct 12, 2010 at 1:20 PM, Maciej Stachowiak m...@apple.com wrote:
On Oct 12, 2010, at 12:44 PM, James Robinson wrote:
On Tue, Oct 12, 2010 at 9:47 AM, Chris Marrin cmar...@apple.com wrote:
On Oct 11, 2010, at 5:15 PM, Maciej Stachowiak wrote:
On Oct 11, 2010, at 4:03 PM, Chris
On Tue, Oct 12, 2010 at 3:46 PM, Maciej Stachowiak m...@apple.com wrote:
On Oct 12, 2010, at 2:37 PM, Darin Fisher wrote:
On Tue, Oct 12, 2010 at 1:20 PM, Maciej Stachowiak m...@apple.com wrote:
Hmm, I've found weak pointer abstractions to be very useful. The issue
with reference counting
On Tue, Oct 12, 2010 at 6:37 PM, James Robinson jam...@google.com wrote:
On Tue, Oct 12, 2010 at 3:46 PM, Maciej Stachowiak m...@apple.com wrote:
On Oct 12, 2010, at 2:37 PM, Darin Fisher wrote:
On Tue, Oct 12, 2010 at 1:20 PM, Maciej Stachowiak m...@apple.com wrote:
Hmm, I've found weak
Caused more harm than good?
-Darin
On Tue, Oct 12, 2010 at 10:06 PM, Darin Adler da...@apple.com wrote:
Not sure it is relevant to this discussion, but WebKit had a weak pointer
class back in 2002 and I removed it.
-- Darin
___
webkit-dev
I don't think it is the norm. This one is special for the reasons already
stated.
-Darin
On Mon, Oct 4, 2010 at 11:17 PM, Dirk Pranke dpra...@chromium.org wrote:
Keeping it off by default until it has some mainstream acceptance
seems like a bit of a self-defeating policy for new features; is
1 - 100 of 243 matches
Mail list logo
