On May 11, 2012, at 2:21 PM, Ojan Vafai o...@chromium.org wrote:
The amount of spam we throw in the developer console has grown quite a bit.
spam == things logged to the console that web developers have no control over
Unlike uncaught javascript exceptions (which can easily just be
Pranke dpra...@chromium.org wrote:
On Sun, Apr 29, 2012 at 6:20 PM, Maciej Stachowiak m...@apple.com wrote:
On Apr 29, 2012, at 5:49 PM, Maciej Stachowiak m...@apple.com wrote:
Hi folks,
new-run-webkit-tests seems to mess with the system color profile on Mac,
even when not running
On May 3, 2012, at 8:54 AM, Dirk Pranke dpra...@chromium.org wrote:
On Thu, May 3, 2012 at 7:35 AM, Maciej Stachowiak m...@apple.com wrote:
Better naming/documentation may help. But I think the root problem here was
that the Chromium Android LayoutTestHelper does not exist in the WebKit
On May 2, 2012, at 11:48 AM, Jarred Nicholls jar...@webkit.org wrote:
On Wed, May 2, 2012 at 2:03 PM, Maciej Stachowiak m...@apple.com wrote:
On May 2, 2012, at 6:14 AM, Jarred Nicholls jar...@webkit.org wrote:
On Tue, May 1, 2012 at 7:39 PM, Maciej Stachowiak m...@apple.com wrote
On May 2, 2012, at 1:03 PM, Adam Barth aba...@webkit.org wrote:
One example from this case is seamless navigation. I implemented
seamless navigation in two steps:
1) Refactoring the existing codepaths to go through a common function.
2) Teaching the common function how to redirect
On May 1, 2012, at 12:20 PM, Eric Seidel e...@webkit.org wrote:
Work is complete, fully working. Passing all the tests I could come up with:
https://github.com/eseidel/webkit/compare/master...seamless
I'm uploading and landing patches once reviewed again in bugzilla.
I do not plan to
I'm
looking for is to disable the entire feature if necessary. However, I don't
expect that any ports Apple is involved with would leave it off indefinitely. I
hope that answers your questions.
Regards,
Maciej
On Tue, May 1, 2012 at 2:06 PM, Maciej Stachowiak m...@apple.com wrote:
On May
On May 1, 2012, at 4:04 PM, Adam Barth aba...@webkit.org wrote:
On Tue, May 1, 2012 at 3:50 PM, Maciej Stachowiak m...@apple.com wrote:
On May 1, 2012, at 3:31 PM, Eric Seidel e...@webkit.org wrote:
Is your goal to be able to disable the feature to prevent a late-known
security issue
On Apr 29, 2012, at 11:01 AM, Adam Barth aba...@webkit.org wrote:
I read https://trac.webkit.org/wiki/DeprecatingFeatures, but I'm
still unsure how to proceed with removing webkitPostMessage and
aligning postMessage with the spec. No one responded to my earlier
message, so I'm inclined to
On Apr 27, 2012, at 6:29 PM, Dirk Pranke dpra...@chromium.org wrote:
BTW, the page at https://trac.webkit.org/wiki/DeprecatingFeatures seems to
be using deprecate in the sense of remove entirely. Is that what is
meant? If so, I think it would be helpful to change the wording to removing
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.com wrote:
On Apr 29, 2012, at 11:01 AM, Adam Barth aba...@webkit.org wrote:
I read https://trac.webkit.org/wiki/DeprecatingFeatures, but I'm
still unsure how
On Apr 29, 2012, at 1:04 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Sun, Apr 29, 2012 at 12:37 PM, Maciej Stachowiak m...@apple.com wrote:
On Apr 27, 2012, at 6:29 PM, Dirk Pranke dpra...@chromium.org wrote:
BTW, the page at https://trac.webkit.org/wiki/DeprecatingFeatures seems
On Apr 29, 2012, at 1:18 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Sun, Apr 29, 2012 at 1:08 PM, Maciej Stachowiak m...@apple.com wrote:
On Apr 29, 2012, at 1:04 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Sun, Apr 29, 2012 at 12:37 PM, Maciej Stachowiak m...@apple.com wrote:
On Apr 27
On Apr 29, 2012, at 1:35 PM, Adam Barth aba...@webkit.org wrote:
There is very little cost on the WebKit project to maintain webkitPostMessage
in addition to postMessage. Instead, supporting webkitPostMessage imposes a
cost on the web platform at large by reducing interoperability
On Apr 29, 2012, at 1:25 PM, Ryosuke Niwa rn...@webkit.org wrote:
I'm actually curious as to how the session participants reached this
consensus (probably on a separate thread). It seems like the bar shouldn't
too high for removing prefixed APIs when they are unprefixed equivalents
Hi folks,
new-run-webkit-tests seems to mess with the system color profile on Mac, even
when not running pixel tests. Historically, I believe we did this only when
running pixel tests. I noticed that this is because it launches the
LayoutTestHelper tool unconditionally, and in addition to
On Apr 29, 2012, at 5:49 PM, Maciej Stachowiak m...@apple.com wrote:
Hi folks,
new-run-webkit-tests seems to mess with the system color profile on Mac, even
when not running pixel tests. Historically, I believe we did this only when
running pixel tests. I noticed that this is because
On Apr 29, 2012, at 6:42 PM, Adam Barth aba...@webkit.org wrote:
On Sun, Apr 29, 2012 at 2:25 PM, Maciej Stachowiak m...@apple.com wrote:
On Apr 29, 2012, at 1:35 PM, Adam Barth aba...@webkit.org wrote:
There is very little cost on the WebKit project to maintain
webkitPostMessage
On Apr 29, 2012, at 6:56 PM, Maciej Stachowiak m...@apple.com wrote:
I think the relevant question is how much (if any) content uses
webkitPostMessage (without unprefixed postMessage fallback). The fact that
postMessage incorporates the new functionality doesn't answer that question
I think the concern is that, due to lack of clear standards, we end up not
knowing when we can remove things. Thus, we end up with a lot of inconclusive
and frustrating conversations, and people may shy away from even trying to
remove things.
BTW, the page at
Hi everyone,
A while back, Apple's WebKit teams instituted a bot watching rotation to try to
get the bots for our ports to get and stay green. We've managed to consistently
stay around low single digits of failures, but the green doesn't seem to stick.
We think some folks in the community may
It would be more readable to use:
@media screen and (min-device-pixel-ratio: 2) { … }
The -webkit-image-set proposal explains why it is a useful shorthand despite
the existing device pixel ratio option.
Regards,
Maciej
On Apr 23, 2012, at 11:11 PM, Eric Seidel wrote:
Assuming I'm
If it's a global switch that ports can't opt out of, then we have to do this at
a time when it wouldn't disrupt anyone's release cycle. Let's say
hypothetically a vendor was going to branch from trunk and ship in two weeks
(not actually the case for us, but just to make it an extreme example).
On Apr 21, 2012, at 9:45 AM, Antti Koivisto wrote:
Sat, Apr 21, 2012 at 8:13 AM, John Yani van...@gmail.com wrote:
2316if (selector-relation() != CSSSelector::SubSelector)
2317break;
2318selector = selector-tagHistory();
2319};
Now selector
On Apr 19, 2012, at 10:35 PM, David Barr wrote:
On Fri, Apr 20, 2012 at 3:18 PM, Alexey Proskuryakov a...@webkit.org wrote:
I noticed a number of patches going in recently that add null checks, or
refactor the code under the premise of eliminating potential null
dereference. What does
On Apr 19, 2012, at 11:11 PM, David Levin wrote:
I think this all started with a lot of effort put into fixing an issue
reported by a user where they said the most popular online forum in Malaysia
is broken. Then folks had to do a lot of builds (bisecting) to track down
where the problem
Hi Luke,
I feel like you've been put on the defensive a bit here, which is unfortunate.
I do agree with the value of readable code and hackability is one of the core
values of the WebKit project. Code should indeed be meaningful to programmers.
One thing to keep in mind though is that, by
On Apr 20, 2012, at 12:05 PM, Kentaro Hara wrote:
+1 to the idea that we should try to add a test for each change. That
being said, as rniwa mentioned, it is sometimes difficult to make a
test because
(A) we do not come up with a test case
(B) we know that the code is unreachable (e.g.
On Apr 20, 2012, at 1:48 PM, Rachel Blum wrote:
I completely agree with Maciej here that if this is a reachable code, then
the patch author should put a reasonable effort into creating a test case.
And most importantly, these changes are clearly not code cleanup.
I'm disagreeing here.
A lot of folks have laptops, so perhaps someone could be convinced to give you
the scoop by IRC.
- Maciej
On Apr 19, 2012, at 10:11 PM, Patrick Gansterer wrote:
I'm very interested in that discussion, but I can't be physically there. :-(
Is there any any possibility for me to attend it
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 the pixel buffer is an expensive (blocking) operation. Had you
considered
On Apr 16, 2012, at 1:48 PM, Oliver Hunt wrote:
On Apr 16, 2012, at 1:44 PM, Darin Fisher da...@chromium.org wrote:
I'm not sure why developers would choose to ignore HiDPI. It seems like it
helps their apps/pages look better!
You really feel like you need to kowtow to developers to
On Apr 16, 2012, at 1:44 PM, Darin Fisher wrote:
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
On Apr 16, 2012, at 4:03 PM, Dirk Schulze wrote:
Different developers will have different priorities. HD image data and async
readback both have potential benefits in image quality and nonblocking
responsiveness respectively. Here is an example of an application using
getImageData which
On Apr 9, 2012, at 12:27 PM, Adam Barth wrote:
On Wed, Apr 15, 2009 at 2:21 PM, Maciej Stachowiak m...@apple.com wrote:
On Apr 15, 2009, at 1:29 PM, Sverrir Á. Berg wrote:
Hi Adam,
Thanks for the links. These are simply exposing the functions as a formal a
API's. I understand that you
On Mar 22, 2012, at 9:16 PM, Adam Barth wrote:
On Sat, Mar 10, 2012 at 12:49 PM, Maciej Stachowiak m...@apple.com wrote:
I made a bad choice of survey site. They want to charge me to see more than
100 responses or to export the data, but they won't take my money. Sadness.
Please try
On Mar 21, 2012, at 2:29 PM, Timothy Hatcher wrote:
Lately I have observed more and more and more changes going into WebKit that
lack any details about why a particular change was made. It is intended that
the ChangeLog (and commit message) contain some details about your change,
not just
On Mar 21, 2012, at 3:14 PM, Dirk Pranke wrote:
On Wed, Mar 21, 2012 at 2:33 PM, Maciej Stachowiak m...@apple.com wrote:
On Mar 21, 2012, at 2:29 PM, Timothy Hatcher wrote:
Lately I have observed more and more and more changes going into WebKit that
lack any details about why
I'm ok with removing this feature for the reasons you described. I concur with
others who think we should update the spec. I am also skeptical of state
sharing features that work via newer, less tested API surface instead of
latching onto existing features. That seems like a more risky
I think this feature is pretty far out relative to WebKit project goals, even
independent of spec maturity level.
We've had controversy (though ultimately tentative agreement on adding) APIs
for hardware found in some but not all classes of mainstream hardware that runs
a browser. For
On Mar 15, 2012, at 1:29 PM, Eric Seidel wrote:
It seems the New XML Parser hasn't been touched in about 8 months:
http://trac.webkit.org/browser/trunk/Source/WebCore/xml/parser
Are there any plans to continue work on such, or can it be removed?
The refactoring which was done to support
:
Where can we see the results to date? Also there should be a closing date
for the survey and it should also be announced to this DL.
Konrad
Sent from my BlackBerry on the Rogers Wireless Network
- Original Message -
From: Maciej Stachowiak [mailto:m...@apple.com]
Sent: Saturday
On Mar 10, 2012, at 10:56 AM, Ryosuke Niwa wrote:
On Sat, Mar 10, 2012 at 10:05 AM, Maciej Stachowiak m...@apple.com wrote:
Unfortunately SurveyMonkey sucks and I can't give everyone access to live
responses without paying them money. Current results:
- 97 people have answered
- About
, 2012, at 11:52 AM, Maciej Stachowiak wrote:
On Mar 10, 2012, at 10:56 AM, Ryosuke Niwa wrote:
On Sat, Mar 10, 2012 at 10:05 AM, Maciej Stachowiak m...@apple.com wrote:
Unfortunately SurveyMonkey sucks and I can't give everyone access to live
responses without paying them money. Current
Regards,
Maciej
On Mar 10, 2012, at 11:52 AM, Maciej Stachowiak wrote:
On Mar 10, 2012, at 10:56 AM, Ryosuke Niwa wrote:
On Sat, Mar 10, 2012 at 10:05 AM, Maciej Stachowiak m...@apple.com wrote:
Unfortunately SurveyMonkey sucks and I can't give everyone access to live
responses without
meant being listed on
this page http://trac.webkit.org/wiki/WebKit%20Team even though I've landed
10+ patches.
I don't want my vote to be discounted. I use git only.
Konrad
Sent from my BlackBerry on the Rogers Wireless Network
From: Maciej Stachowiak [mailto:m...@apple.com]
Sent
with svn, or making everyone switch to git. My
counter argument to git-svn is slow so we should all use git is git-svn is
slow and this annoys me so i'm going to contribute patches to git to fix
that.
--Oliver
On Mar 10, 2012, at 1:00 PM, Maciej Stachowiak wrote:
I will also post
I think one factor that makes many people stick with SVN is that emulating the
SVN-style workflow in Git is pretty complicated. Let's consider a typical SVN
user's process:
1) Develop one patch at a time.
2) During development, often update his sources to match the repository.
3) When done,
and (I think) from which
platforms. If there's interest, I can dig up what we did and see if we
can use the same technique on our tools.
-- Dirk
On Sat, Mar 10, 2012 at 12:49 PM, Maciej Stachowiak m...@apple.com wrote:
Hi folks,
I made a bad choice of survey site. They want to charge me
On Mar 10, 2012, at 9:55 PM, Kalle Vahlman wrote:
2012/3/11 Maciej Stachowiak m...@apple.com:
The interaction with the version-control system for each of these steps is
an obvious single step with SVN. With git, for at least some of these, you
will end up needing multiple non-obvious
Here's my thoughts based on this and other comments
On Mar 8, 2012, at 2:30 PM, Alexis Menard wrote:
To the global infrastructure :
- Local history for git. svn log access to the server every time you
call that command. Will improve the load of the server.
- Performance of checkouts/pull
Since the answer to this factual question seems to be of interest to some
people, here's a survey about what version control tools people use to access
the WebKit repository, and approximate contribution level.
http://www.surveymonkey.com/s/JQMW2QV
(Note that it doesn't ask about preference
wrote:
Can you add an option for folks who use both git and SVN? I use both
frequently.
Thanks,
Adam
On Fri, Mar 9, 2012 at 10:20 PM, Maciej Stachowiak m...@apple.com wrote:
Since the answer to this factual question seems to be of interest to some
people, here's a survey about what
It seems like there are a couple of different issues here that affect how we do
version control. Currently we have an SVN primary repository, some contributors
use SVN, and others use git via git-svn.
It seems like there are two possible changes we can make, and it is not really
clear to me
I'd prefer we not modify imported test suites. That will just make it more
confusing to update. Perhaps future CSS test suites will be changed to a
reftest model.
Regards,
Maciej
On Mar 7, 2012, at 1:41 PM, Ojan Vafai wrote:
I just did a first pass a greening the Chromium Lion bot:
I too am mildly concerned about references not being sufficiently independent
of the tests, which is why I hoped we could get the WG in the business of
reviewing references along with tests. However, another possibility is looking
at what Mozilla uses for reference for these tests, since those
On Mar 6, 2012, at 9:00 PM, Jon Lee wrote:
Whoops, I forgot to mention this also:
I would like to add a new ENABLE(LEGACY_NOTIFICATION_DEPRECATION) flag which
allows ports to deprecate the legacy API. This saves us from the hazards of
refactoring the code to use a different ENABLE flag
I agree with Hyatt.
It's not like this behavior is especially harmful or confusing. Authors are
unlikely to run into properties with hyphens in the names unless they go
looking. And it can be useful if you ever want to pass around actual CSS
property names by string in an API - no need to
I agree with Adam's remarks. The safety benefit seems great, but we should
investigate ways to get it at less performance cost (ideally no measurable
cost).
I'm also curious what impact this change has on less micro- but still
DOM-oriented benchmarks, such as Dromaeo's DOM tests, Peacekeeper,
Here's an update of my lists based on the notes from you, Adam and others:
== Existing Modules ==
gamepad
geolocation
indexeddb (work in progress)
intents
mediastream
vibration
websockets
== Likely Future Modules ==
filesystem
notifications
pagevisibility
protocolhandler
websql
webaudio
==
I think many of us in the WebKit community are skeptical of the value of
implementing RDFa on the client side, at least for now. The proposed API is
rather complicated, the processing rules are quite complicated, and it's not
clear there is demand for authors.
HTML Microdata is a similar
One thing that would be helpful to add is an explanation of what types of
subsystems should be turned into Modules and what types should not. Also
advantages and disadvantages of turning a particular piece of code into a
Module.
I think part of the confusion/controversy around these changes
On Feb 24, 2012, at 9:57 AM, Alexey Proskuryakov wrote:
22.02.2012, в 22:08, Kentaro Hara написал(а):
TL;DR: We are starting WebKit modularization. Self-contained features
like WebAudio, WebSocket, IndexedDB, File APIs ...etc will be moved
from WebCore/ to WebCore/Modules/.
Looking at
On Feb 24, 2012, at 10:27 AM, Adam Barth wrote:
2012/2/24 Maciej Stachowiak m...@apple.com:
I too am surprised that HTML-related APIs would be refactored as a result of
modularization. This change may be justifiable on its own merits, but it
doesn't seem like a logical part of a project
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.
There's unfortunately, the real possibility that there may be some
On Feb 24, 2012, at 11:58 AM, Adam Barth wrote:
On Fri, Feb 24, 2012 at 11:50 AM, Maciej Stachowiak m...@apple.com wrote:
On Feb 24, 2012, at 10:27 AM, Adam Barth wrote:
2012/2/24 Maciej Stachowiak m...@apple.com:
I too am surprised that HTML-related APIs would be refactored as a result
On Feb 24, 2012, at 12:06 PM, Darin Fisher wrote:
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
Would you move the interface objects or just the methods?
- Maciej
On Feb 21, 2012, at 12:15 PM, Ryosuke Niwa wrote:
Hi,
It appears to me window.internals is a superior solution to expose
cross-platform features to our test harness compared to other interfaces
implemented in
On Feb 21, 2012, at 1:21 PM, Ryosuke Niwa wrote:
I'd prefer getting rid of the entire interface when possible. We're obviously
removing layoutTestController, textInputController, etc... at the moment
though.
I think it's helpful to organize the methods by functional area instead of
On Feb 15, 2012, at 2:26 AM, Alexis Menard wrote:
The code we submit in WebKit has to be BSD or LGPL compatible code.
(/me remember how hard it is to find real world CSS BSD compatible
chunk to write a perf test)
I found http://msdn.microsoft.com/en-us/cc300389.aspx then you have to
see
On Feb 14, 2012, at 10:25 AM, Steven Young wrote:
(2) 50% of time spent painting images... This is a simple speed vs quality
tradeoff. If you down-sampled the images on the server, they'd download
and paint much faster.
Thanks. Downsampling sounds like a straightforward solution. We
This plan sounds reasonable to me. No disruption of Chrome extensions in the
short term, but we would better align with each other and with standards in 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
On Feb 10, 2012, at 4:09 PM, Ryosuke Niwa wrote:
Hi all,
In general, the decision of whether a given feature is enabled or not is made
by each port. However, at last year's W3C TPAC, there were complaints from
other participants about WebKit shipping half-baked implementations and
On Feb 10, 2012, at 4:20 PM, Dirk Pranke wrote:
I think at one point Adam indicated he wanted to use them for the
Apple Win port, but he is still using the Skipped files since the Win
port is still using ORWT on the bots.
That said, I understand why you're asking this (I think), but I
On Feb 13, 2012, at 1:40 PM, Ojan Vafai wrote:
On Mon, Feb 13, 2012 at 1:06 PM, Maciej Stachowiak m...@apple.com wrote:
On Feb 10, 2012, at 4:20 PM, Dirk Pranke wrote:
For example, we might want to use only Skipped files for tests that
are always planned to be skipped
On Feb 13, 2012, at 1:21 PM, Ryosuke Niwa wrote:
On Mon, Feb 13, 2012 at 1:02 PM, Maciej Stachowiak m...@apple.com wrote:
I think you raise a good point. Another point worth mentioning is that
sometimes a feature can be complete and useful in one port, but half-baked in
another
.
--
morrita
On Tue, Feb 14, 2012 at 8:11 AM, Maciej Stachowiak m...@apple.com wrote:
On Feb 13, 2012, at 1:21 PM, Ryosuke Niwa wrote:
On Mon, Feb 13, 2012 at 1:02 PM, Maciej Stachowiak m...@apple.com wrote:
I think you raise a good point. Another point worth mentioning
On Feb 8, 2012, at 6:15 PM, Aaron Boodman wrote:
On Wed, Feb 8, 2012 at 4:58 PM, Jon Lee jon...@apple.com 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
On Jan 28, 2012, at 8:01 PM, Darin Fisher wrote:
Right. In Firefox, the problem was that the cookie code used some hand-rolled
string parsing code instead of reusing the URL parsing code. That resulted in
a subtle bug that could be exploited to steal cookies. In Safari's case, I
, 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
WebKit-integrated URL library based on GoogleURL. If that is no longer
the
case, then certainly we should
On Jan 27, 2012, at 12:22 AM, Darin Fisher wrote:
On Fri, Jan 27, 2012 at 12:03 AM, Benjamin Poulain benja...@webkit.org
wrote:
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
On Jan 27, 2012, at 2:39 AM, Adam Barth 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
WebKit-integrated URL
Hi Dmitri!
I remember last time this came up, there was some controversy, both within the
WebKit community and among browser implementors more broadly. Kudos for writing
a much more comprehensive spec and taking more of the feedback into account.
For example, I am delighted to see that there
I think it would be good to limit the number of languages used for WebKit
development. We already have important tools that use all of Perl, Python and
Ruby. To date, we've been gradually converging on new scripts being mostly in
Python. I think it would be really valuable for the project.
On Nov 28, 2011, at 8:54 PM, DongWoo Im wrote:
Hi webkit-dev,
I would like to let you know that I'm planning to add a set of new APIs for
the Custom Scheme and Content Handler.
** Specification link :
http://dev.w3.org/html5/spec/Overview.html#custom-handlers
** Bugs
- Custom
On Nov 21, 2011, at 2:00 PM, Ojan Vafai wrote:
Just curious, how is it different from Access-Control-Allow-Headers?
Access-Control-Allow-Headers is a response header which signals that specific
custom request headers may be sent by the client.
Looks like I was mistaken and misread the spec, so I withdraw this comment.
Do other browsers that implement the register functions also implement the
related isRegistered and unregister functions?
- Maciej
On Nov 29, 2011, at 12:08 AM, Maciej Stachowiak wrote:
On Nov 28, 2011, at 8:54
On Oct 12, 2011, at 4:12 PM, Ryosuke Niwa wrote:
Given that Gecko is implementing the unprefixed getItems (see
https://bugzilla.mozilla.org/show_bug.cgi?id=591467), I don't see benefits in
implementing with webkit prefix. Also, it's still under a compile-time flag
so we can prefix it
On Sep 8, 2011, at 11:15 AM, Eric Seidel wrote:
It seems the sucessfullyParsed question could also be answered by
some intelligent onerror handler added to the right script tag.
The successfullyParsed thing was originally added to benefit JS tests running
in the browser. If you get a bunch
On Sep 8, 2011, at 2:28 PM, Roland Steiner wrote:
Hi all,
After several discussions on the whatwg@ mailing list and others, we would
like to go forward with adding style scoped to WebKit.
Overview:
Style rules within style scoped only apply to the parent element of style
scoped
On Sep 8, 2011, at 12:25 PM, Darin Adler wrote:
On Sep 8, 2011, at 11:49 AM, Alexey Proskuryakov wrote:
As discussed on IRC, I do not think that bots should run this test at all.
It has a non-trivial maintenance cost, but provides very little benefit.
Even the time spent by multiple
On Sep 7, 2011, at 4:58 PM, Ojan Vafai wrote:
On Wed, Sep 7, 2011 at 4:48 PM, Alexey Proskuryakov a...@webkit.org wrote:
16.08.2011, в 17:45, Alexey Proskuryakov написал(а):
I think that a style bot rule complaining about new files in script-tests
directories (outside fast/js) would
On Aug 31, 2011, at 3:31 PM, David Levin wrote:
Ignore me. I'm missing the .
I suppose if you want a RefPtr, then the style checker is wrong and the
parameter should be allowed to be a RefPtr.
Feel free to file a bug and I'll get to it (-- it may take me a week or two
at the moment).
On Aug 16, 2011, at 11:31 AM, Adam Barth wrote:
Hi WebKit,
In an effort to make the Chromium port more consistent across
platforms, we're moving the Chromium Mac port from CoreGraphics to
Skia. This should mostly have little effect on the rest of the WebKit
community, but you'll be
Hi Adam,
I have a hard time reading this wall of text, but it seems to me there were at
least three things wrong with what happened:
1) Patches mixing refactoring and behavior changes. This is bad. We should aim
whenever possible to separate behavior changes from refactoring. Reviewers
On Aug 5, 2011, at 1:39 PM, Adam Barth wrote:
My proposal is to revert all the patches that changed behavior without
incorporating tests, and we can decide how to proceed from there. If it's
hard to even tell which those are, then we should just revert the whole
patch set. Then we can
On Jul 10, 2011, at 12:11 PM, Adam Barth wrote:
On Sun, Jul 10, 2011 at 12:01 PM, James Robinson jam...@google.com wrote:
On Jul 10, 2011 10:53 AM, Adam Barth aba...@webkit.org wrote:
Hi webkit-dev,
In trying to understand how our LayoutTest results system works, I've
created a digram of
On Jul 7, 2011, at 10:39 AM, Dirk Pranke wrote:
On Thu, Jul 7, 2011 at 10:27 AM, Tony Chang t...@chromium.org wrote:
One difference with the chromium port is that we try to use a single
test_expectations.txt that covers all platforms and OS versions (win xp,
vista, 7, mac leopard, snow
On Jul 5, 2011, at 4:51 PM, Dirk Pranke wrote:
On Tue, Jul 5, 2011 at 3:46 PM, Ojan Vafai o...@chromium.org wrote:
We could simplify the syntax somewhat to not require the = PASS at the
end. We could also change the bug format to be actual links instead (e.g.
webkit.org/b/12345 and
On Jul 5, 2011, at 12:29 PM, Dirk Pranke wrote:
The problem with your idea is I think what brought this idea up in the
first place: if you just track that the test is failing using the
test_expectations.txt file, but don't track *how* it is failing (by
using something like the -failing.txt
501 - 600 of 1378 matches
Mail list logo
