On Nov 11, 2011, at 4:24 AM, Tor Arne Vestbø wrote:
On 07.11.11 15:44, Alan Stearns wrote:
What if we defer some of the W3C metadata work until tests were actually
submitted to the W3C?
1. Tests we pull from W3C can run from manifests, since they are provided.
2. Tests we develop
Julien Chaffraix asked me about API breakage in
https://bugs.webkit.org/show_bug.cgi?id=71423 Remove all releaseRef
implementations except for RetainPtr.
I realize now that JSRetainPtr.h is in the API directory. Is it part of the
public API on some platforms? I know it’s not on Mac.
-- Darin
On Nov 3, 2011, at 10:24 AM, Marshall Greenblatt wrote:
It appears that EditorClient::handleKeyboardEvent() is only called for
keydown and keypress events (the exclusion starts in
HTMLInputElement::defaultEventHandler). Is there a specific reason why we
don't want to call
On Nov 3, 2011, at 10:51 AM, Marshall Greenblatt wrote:
EditorClient::handleKeyboardEvent() eventually calls
WebViewClient::handleCurrentKeyboardEvent() in the Chromium WebKit API. I
have an application that would like to intercept certain key up events and
perform application-specific
On Nov 2, 2011, at 4:09 PM, Mark Rowe wrote:
There are a few related goals here that I'm aware of:
a) Separate WTF out of JavaScriptCore since it doesn't logically belong
there, but was simply a convenient home for it.
b) Separate WebCore/platform out of WebCore to help avoid layering
On Nov 2, 2011, at 4:42 PM, Darin Adler wrote:
Step (2) here involves coming up with a good solution for export control in
both the WTF and platform cases. Today we use an explicit .exp file for
JavaScriptCore and WebCore on Mac and I believe a .def file in the Apple
Windows WebKit port
On Oct 26, 2011, at 12:59 AM, Adam Barth wrote:
Should more features have PageGroup-associated objects or should fewer?
I’m thinking more. The point of a PageGroup is to make it so a single process
can use WebKit for separate purposes without intertwining things such as frame
names and
The guideline is not to disallow anonymous namespaces.
It’s to prefer “static” over anonymous namespaces when either one would work.
Debugging tools on at least some of the platforms work better with functions
that are given internal linkage by using the “static” keyword rather than
functions
On Oct 19, 2011, at 3:47 PM, Ryosuke Niwa wrote:
How about classes that are only used in one cpp file? Should we be wrapping
those in an anonymous namespace?
I’d suggest not wrapping them in an anonymous namespace. Debugging tools work
better when classes have unique names.
Can anyone name
I’m open to changing our style.
The compiler many of us used in the past, gcc, had problems generating correct
debug information for code in anonymous namespaces. Given that most uses didn’t
accomplish anything more than putting static in front of functions did, we
decided to stick with that.
On Oct 19, 2011, at 3:58 PM, Ryosuke Niwa wrote:
On Wed, Oct 19, 2011 at 3:51 PM, Darin Adler da...@apple.com wrote:
How about classes that are only used in one cpp file? Should we be
wrapping those in an anonymous namespace?
I’d suggest not wrapping them in an anonymous namespace
I think it’s worth going further — when can we remove this #if altogether?
-- Darin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Hi folks.
Something’s wrong with the style bot and its adding comments about the failures
to every bug we upload a patch to:
Here’s an example https://bugs.webkit.org/show_bug.cgi?id=70276#c2.
Is there someone who knows how to fix this?
-- Darin
We prefer index style. In the past I believe we could not measure a difference
in performance.
One benefit of the index style is that it is more terse, and often easier to
read than the iterator style, which requires repeating the type name twice to
declare the start and end value of the
On Oct 11, 2011, at 3:32 AM, Xianzhu Wang (王显著) wrote:
add a StringImpl::reallocate() method
Sounds good.
Before StringBuilder, StringImpl objects were never resized, so this is a
recently-introduced issue.
-- Darin
___
webkit-dev mailing
On Oct 10, 2011, at 4:46 AM, Xianzhu Wang (王显著) wrote:
malloc_good_size() can get the rounded-up size of a required size, but it
seems not available on all platforms. It's easy to implementation it over
tcmalloc. On platforms that malloc_good_size() is not available, it's
possible to get
Hi folks.
It really helps frequent reviewers like me if you use platform prefixes on
bugs. A platform prefix indicates that the bug only affects code on a
particular platform. For example:
[Mac] Use four more named cursors if present
The above title tells you the patch is Mac-specific.
On Oct 5, 2011, at 5:47 PM, James Robinson wrote:
On Wed, Oct 5, 2011 at 5:43 PM, Simon Fraser simon.fra...@apple.com wrote:
Why don't we just fix bugzilla to have a useful lists of ports in one of the
Platform popups?
That would certainly be nice, but it wouldn't be as useful as having
On Oct 4, 2011, at 2:14 PM, James Robinson wrote:
Could you explain why? Is it to document the nullity of the out-param?
Sure, one reason is to document the non-nullity of the out parameter.
I personally find pointers for out parameters to be appropriate in many
situations. It makes the
On Oct 4, 2011, at 2:06 PM, Ryosuke Niwa wrote:
It came to my attention that some people are using raw pointers to pass
out-arguments (e.g. bug 69366). In my understanding, we use pass by reference
for out arguments when they have to be modified in callees.
If there's no objection, I'm
On Oct 4, 2011, at 6:14 PM, Eric Seidel wrote:
I thought historical policy was universally against the word get in
function names.
The policy has been to reserve the word get to mean a function that gets a
value in an out argument, as opposed to a function that returns a value, which
we
On Oct 3, 2011, at 6:35 AM, Balazs Kelemen wrote:
I think we lack a consistent way for setting up the set of feature defines.
Some of them are handled via Platform.h and some of them via the build
systems. Don't you think all should be handled the same way? This has came up
in my mind in
On Sep 29, 2011, at 1:40 PM, Andreas Kling wrote:
Good idea in general, though it doesn't work for InlineBox since its bits are
spread across public, protected and private.
I'm not sure it's worth losing those classifications for the sake of the
anti-bloat mechanism.
We wouldn’t have to
On Sep 29, 2011, at 1:48 PM, Andreas Kling wrote:
Right, but those keywords would pertain to the struct containing the
bitfields, not InlineBox itself. Or maybe I'm misunderstanding you?
Yes, I was wrong, you are right.
I had lost the thread. I’m not sure we need to group bit fields in a
On Sep 25, 2011, at 12:20 AM, James Robinson wrote:
The TIMER based support for RAF is very new (only a few weeks old) and still
has several major bugs. I'd suggest letting it bake for a bit before
considering turning it on for all ports.
Got it.
Fundamentally I don't think this feature
The settings in TOT are the settings for nightly builds. They don't necessarily
make it clear what Apple does for releases. There are features like this one
that we’ve been turning off on release branches.
-- Darin
___
webkit-dev mailing list
The biggest question for me for this feature is what locale-specific formatting
we plan for these dates and times. Will we be adding more code to the WebCore
platform layer to do this? Will we use locale-specific formatting code already
present in JavaScriptCore, perhaps moving it to WTF for
On Sep 12, 2011, at 4:23 PM, Maciej Stachowiak wrote:
Notwithstanding all the later discussion, I think run-bindings-tests would
still be more effective as a build step that updates a source file rather
than a test step.
I see, a build step that updates a checked-in source file. Sounds like
On Sep 10, 2011, at 1:44 AM, Xianzhu Wang (王显著) wrote:
No. It only tells you that the original symbol in the current def file is
missing in the binary, not the new symbol need to be in the def file.
That’s correct, if you submit a patch that doesn’t touch the .def file. But if
you submit a
On Sep 9, 2011, at 9:07 AM, Adam Barth wrote:
run-layout-tests?
Sorry in advance for bikeshed'ing this:
That would be a good name if we thought LayoutTests was the right name for our
main regression test suite. Since I think it’s not, I would love to figure out
that new name and have the
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 engineers on IRC today discussing bot complaints
is
On Sep 8, 2011, at 12:29 PM, Eric Seidel wrote:
I'm happy to write a run-all-tests script which runs all known tests that
platform can handle. :)
I think run-webkit-tests should be this. We can come up with a new name for the
“just run the tests in the LayoutTests directory” tool.
A bigger
On Sep 6, 2011, at 6:24 PM, Maciej Stachowiak wrote:
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
Seems more like a Windows question rather than a WebKit question. Can you get
the stack size for a Windows thread or not?
On platforms where we don’t know how to get the stack size we just have a fixed
guess in StackBounds.cpp.
-- Darin
___
On Aug 29, 2011, at 12:45 AM, prince goyal wrote:
Does community is having any plan for thread model or is any patch available
for thread model?
Early in the development of WebKit2 the thread model was working on Mac OS X
and Windows.
Those of us at Apple stopped maintaining and using the
On Aug 26, 2011, at 1:50 AM, Xianzhu Wang (王显著) wrote:
I'm developing on Linux. One of my patch failed to build on Windows because I
haven't changed the related .exp file (e.g. JavaScriptCore.exp).
I just did the following on Linux to update the file:
1. nm xx.o | grep T | sed
On Aug 26, 2011, at 10:14 AM, Scott Graham wrote:
Maybe there's a better way someone can point out though.
I believe that using the Windows EWS server you can get error messages that
tell you the symbols that need to be in the def files.
-- Darin
On Aug 4, 2011, at 6:40 PM, TAMURA, Kent wrote:
Like INPUT_COLOR, I'd like to introduce feature flags for date, datetime,
datetime-local, month, time, and week types.
* We're going to implement dedicated UIs for them, and will want to disable
it temporarily.
* Their current implementations
Hi Mark.
I assume that the legacy argument refactoring you are doing right now has a
goal of no behavior changes. But I’ve noticed some cases where arguments are
not marked optional in a few of the patches. Possibly I misunderstood the
patch. One example was arguments in canvas rendering
Mark, Adam, thanks for your replies.
It seems obviously OK to do this for new APIs that have not been around long,
especially ones that never shipped in a production browser, for the same reason
that we decided to do this for new functions from this point forward. I have no
quibble with that.
On Jul 22, 2011, at 2:16 AM, Shkrablyuk, Pavel wrote:
Is there really a reason to check for ‘isnan’ of integer values in
WebGLRenderingContext::viewport?
No.
If there is a need to handle non-numeric values in the JavaScript binding, then
that has to be done in the JavaScript binding
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 build a new string:
- A single expression with the + operator and
On Jul 12, 2011, at 10:31 AM, Darin Fisher wrote:
On Tue, Jul 12, 2011 at 10:25 AM, Darin Adler da...@apple.com wrote:
I would not be surprised if at least some of these will show up immediately
with the right kind of performance test. The CSS parsing and serialization
functions seem
On Jul 12, 2011, at 11:15 AM, Mossman, Paul (Paul) wrote:
But can anyone see a good reason why a browser would refuse to play a .wav
file, but happily render .html, .jpg, .css, etc?
This is not an appropriate question for webkit-dev as it is not a question
about the development of WebKit.
A
On Jul 12, 2011, at 4:42 PM, Luke Macpherson wrote:
As a follow-up to this question, should Webkit support WCSS now that WML has
been removed?
Seems an obvious no.
-- Darin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
On Jul 8, 2011, at 1:53 PM, Ryosuke Niwa wrote:
I don't fully understand how we're transforming small ß to SS in rendering
engine.
The function that does it is RenderText::transformText. It is called in
RenderText::setTextInternal but also in RenderText::textWithoutTranscoding.
-- Darin
For help building WebKit, please use the webkit-help mailing list.
This list is for discussion of development of WebKit.
-- Darin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
On Jul 1, 2011, at 1:54 PM, Dirk Pranke wrote:
I do not believe that -expected should be used to track incorrect results
A huge percentage of our expected results are incorrect in one sense or
another. It’s a massive project to rename them all to reflect the fact that
they reflect some amount
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 of WebKit at the time the
test was checked in. The expected result
On Jul 1, 2011, at 3:24 PM, Darin Fisher wrote:
The granular annotations (more than just SKIP) in test_expectations.txt was
something we introduced back when Chrome was failing a large percentage of
layout tests, and we needed a system to help us triage the failures.
I do think that a
I don’t think it’s a good idea to add yet another thing to every change log
entry.
I do think that given the tools behavior you described, we should move the
reviewer text after the bug title and patch description paragraph, even though
you explicitly said that’s not what you are proposing.
On Jun 23, 2011, at 1:12 PM, Łukasz Ślachciak wrote:
Personally, I like approach of putting logging related code into #if
!LOG_DISABLED macro instead of #ifndef NDEBUG.
As I remember it, my original design for LOG was:
1) Control with LOG_DISABLED, not NDEBUG.
2) Turn off for
On Jun 23, 2011, at 2:43 PM, Ryosuke Niwa wrote:
I think we need a PersistentPosition that auto-corrects itself and survives
DOM mutations without being orphaned; similar to how Range is automatically
updated.
I’m not sure that auto-correction has a simple unambiguous meaning. There are
On Jun 22, 2011, at 7:29 AM, Grzesiek Czajkowski wrote:
I am wondering why webkit has the most documentation in cpp files. In header
files only classes, structures are documented. Is there any reason to do it
in that way?
If we will have all documentation in header files client programmer
On Jun 22, 2011, at 11:38 AM, Eric Seidel wrote:
I think it's better for our reviewers to review only things they're
comfortable with.
It might be worth going back to this patch, figuring out who reviewed it, and
making sure that person understands that they did not look sufficiently at the
We should probably turn off the UNCONFIRMED state. At this time in the WebKit
project there is no useful distinction between UNCONFIRMED and NEW.
I haven’t seen any useful distinction between UNCONFIRMED, NEW, ASSIGNED, and
REOPENED in the WebKit bug database. While I can imagine projects where
On Jun 20, 2011, at 12:30 PM, Ryosuke Niwa wrote:
For all practical purposes, NEW has been equivalent to AVAILABLE in WebKit.
To me it seems that WebKit’s closer equivalent of AVAILABLE is Assigned To =
webkit-unassig...@lists.webkit.org
-- Darin
PS: Apologies to everyone for hijacking
On Jun 18, 2011, at 9:01 PM, Antonio Gomes wrote:
I actually do not like the way the review flags are cleared today only in
order to make the tools and pending-xxx pages happier. IMO the review flags
give much about the history of the bug. In that matter, I dislike
webkit-patch's ways of
The arguments about abandoning PassRefPtr for arguments entirely are attacking
a straw man. We know PassRefPtr offers an important optimization and do not
want to drop that!
On Jun 18, 2011, at 10:58 PM, Maciej Stachowiak wrote:
(1) Use PassRefPtr for every parameter that takes ownership.
I
On Jun 19, 2011, at 2:03 PM, Ryosuke Niwa wrote:
One of the most common security bugs I have seen in editing is that we keep a
raw pointer to a node and call some helper method that modifies DOM
(therefore invoking scripts).
I'm sometimes tempted to replace all instances of Node* in the
There seems to be some confusion about what to do when you discover that a code
change caused a bug.
Please do *not* reopen the original bug report to say that the code change
caused a problem. This makes the bug database state that the original bug is
not fixed, and also makes the patch to
I noticed these three roll-outs:
http://trac.webkit.org/changeset/89190
http://trac.webkit.org/changeset/89191
http://trac.webkit.org/changeset/89192
Were all of these necessary? Was there a way to fix the problem instead of
rolling out in any of these cases?
-- Darin
On Jun 17, 2011, at 10:56 PM, Adam Barth wrote:
There are a 194 open bugs with an R+ patches attached to them:
I worked on this and some others must have been working on it as well. The
number is down to 105 now, with quite a few in the commit queue. I ran out of
steam. I hope more others can
1:
Recently, Alexey has encouraged me to use PassRefPtr less for function
arguments.
The PassRefPtr optimization pays off when the object in question is possibly
being handed off from one PassRefPtr to another. For an argument, that can
happen in two ways: 1) The argument can be the result of
On Jun 17, 2011, at 1:58 AM, Mihnea-Vlad Ovidenie wrote:
We have seen some patterns for handling properties and we are not sure which
one to follow.
It would be helpful if you were more specific here. What were the patterns you
have seen? If you give a specific bug number or revision number
Figuring out how to get WebKit to build is a topic for webkit-help, not
webkit-dev.
-- Darin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
On Jun 16, 2011, at 7:21 AM, song.7@nokia.com wrote:
Could some share what’s the design consideration about the DOM tree and
Render tree separation?
CSS styling makes it easy for almost any DOM node to render as almost anything.
To give one trivial example, a paragraph element can be
This is probably not the right place to ask Adobe about what they’ve done. I
don’t think Adobe engineers answer those kinds questions on this list, and they
historically haven’t participated here much.
-- Darin
___
webkit-dev mailing list
On Jun 16, 2011, at 4:30 PM, song.7@nokia.com wrote:
Thanks, but why not generate a tree according to document ang css style at
the same time? Or why is the post style decision needed?
I can see from your question that you didn’t understand, but I’m not sure how
to clear things up.
The
HTML5 defines this scrolling attribute. It defines it in terms of a CSS
overflow property on the frame below. The value scrolling=no turns into
overflow: hidden. Such overflow areas should not be scrolled.
As I understand it, generally speaking, if we have something like a find
feature or
On Jun 13, 2011, at 10:49 AM, Simon Fraser wrote:
On Jun 13, 2011, at 8:30 AM, Darin Adler wrote:
As I understand it, generally speaking, if we have something like a find
feature or autoscrolling code that scrolls outside the normal mechanism, it
still should not scroll such an area
On Jun 13, 2011, at 10:52 AM, Darin Fisher wrote:
On Mon, Jun 13, 2011 at 10:50 AM, Simon Fraser simon.fra...@apple.com wrote:
Using terms like 'new' in code is rarely a good idea. In a year, the context
has gone, and 'new' no longer means anything.
Good point! Maybe we can use a term
On Jun 13, 2011, at 11:05 AM, Ojan Vafai wrote:
On Mon, Jun 13, 2011 at 10:51 AM, Darin Adler da...@apple.com wrote:
Even though we need to prevent find or autoscrolling from scrolling, it
seems we must not prevent explicit programmatic scrolling. I’ll add a
comment to the bug about
On Jun 12, 2011, at 8:10 PM, Ojan Vafai wrote:
On Sun, Jun 12, 2011 at 1:30 PM, Adam Barth aba...@webkit.org wrote:
Does anyone click the Preview button? If not, we should probably remove
it.
I often use the Preview button to look over my individual comments and decide
whether review+ or
On Jun 8, 2011, at 11:48 AM, Peter Kasting wrote:
On Tue, Jun 7, 2011 at 11:18 PM, Maciej Stachowiak m...@apple.com wrote:
1) We definitely have consensus to fix the broken non-logically-const
accessors by making them non-const; consensus on also adding const accessors
is less clear.
On Jun 8, 2011, at 11:56 AM, Peter Kasting wrote:
What I thought Maciej was saying was that we should remove const on all the
existing accessors, in both categories, which sounded different than what you
were saying (which I read as remove const on the accessors in the first
category).
On Jun 2, 2011, at 1:32 AM, Ryosuke Niwa wrote:
All functions passed to enclosingNodeOfType in htmlediting.cpp are such
clients:
Node* enclosingNodeOfType(const Position p, bool (*nodeIsOfType)(const
Node*), EditingBoundaryCrossingRule rule)
It takes a boolean function that takes const
On Jun 3, 2011, at 9:28 AM, Maciej Stachowiak wrote:
On Jun 3, 2011, at 7:50 AM, Darin Adler wrote:
On Jun 2, 2011, at 1:32 AM, Ryosuke Niwa wrote:
All functions passed to enclosingNodeOfType in htmlediting.cpp are such
clients:
Node* enclosingNodeOfType(const Position p, bool
On Jun 3, 2011, at 5:46 PM, Peter Kasting wrote:
From the perspective of Node itself, I'm not sure why this would be a big
task. There shouldn't be any const accessors that return non-const pointers.
Simply removing the const qualifier on all the above accessors would make
things correct,
On May 31, 2011, at 11:49 PM, Karthik wrote:
However, the following comment was mentioned in GraphicsType.h (// Note:
These constants exactly match the NSCompositeOperator constants of // AppKit
on Mac OS X Tiger. If these ever change, we'll need to change the // Mac OS X
Tiger
On Jun 1, 2011, at 10:14 AM, Mustafizur Rahaman wrote:
Therefore, we submitted another patch where we are returning from the canvas
code itself if the compositing mode is highlight.
That’s not a good idea. We should keep looking into the real fix; that kind of
hack is unneeded here.
On May 28, 2011, at 5:15 PM, Geoffrey Garen wrote:
This came up in https://bugs.webkit.org/show_bug.cgi?id=59604.
My personal preference is against const member functions because they force
many error-prone code changes: introducing a const forces the transitive
closure of all potential
On May 26, 2011, at 9:52 AM, Adam Barth wrote:
The original reason why I was excited about changing to locating the
DocumentLoader via the Document was to avoid confusing where the Frame now
contains a different active DocumentLoader.
Sure, that will be great eventually; I think a document
On May 24, 2011, at 6:56 AM, Raphael Kubo da Costa wrote:
Darin Adler da...@apple.com writes:
Also, there is a Document::setDocumentLoader function, but nobody ever calls
it.
I could submit a patch to remove it, if that's desirable.
Yes, we do want to remove it.
What we need are some
On May 23, 2011, at 1:34 PM, Raphael Kubo da Costa wrote:
While working on the EFL port, I've noticed that sometimes a FrameLoader's
DocumentLoader ends up being deleted too early
(FrameLoader::setDocumentLoader causes the current DocumentLoader to be
deref'ed and freed), in the sense that
On May 17, 2011, at 9:03 AM, Gregor Richards wrote:
In the uninstrumented branch (both JIT and interpreter), the lastIndexOf
property of Array.prototype (which we set) is marked as enumerable, so a
for...in loop outputs it.
That sounds like a bug. You should file a bug report with the test
On May 15, 2011, at 3:33 AM, Benjamin Poulain wrote:
If during the conversion people find any short comings in the JSC API that's
useful too, as it's likely that those problems would impact other users of
the JSC API and we would welcome bugs being filed on those them (CC'ing me
:) ).
I’ll be on vacation and mostly away from my email and computers for two weeks
starting tomorrow. I wanted to mention this to the WebKit community so you
understand why I’m not doing patch review for a while!
-- Darin
___
webkit-dev mailing list
On Apr 8, 2011, at 2:09 AM, Ryosuke Niwa wrote:
We have been discussing the possibility of dropping WML support in WebKit on
IRC for a while now because
• None of core ports (Mac, Windows, GTK, Qt, Chromium) use it by
default
• Maintenance cost is high
I’ll just add one other
On Apr 8, 2011, at 2:09 AM, Ryosuke Niwa wrote:
Are there are other folks who are actively using WML?
I realized that I pushed us off topic a little and wanted to remind everyone of
the real point of this thread. Ryosuke specifically said he wants to get the
data about who is using WML. So
WebKit2 has only one web process at this time.
-- Darin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
On Apr 5, 2011, at 9:52 PM, Charles Pritchard wrote:
Long-story-short, can we please expose some of the CSS pixel scaling, either
through window.devicePixelRatio
I typed javascript:alert(devicePixelRatio) in Safari on my iPhone 4, and got
the value 2.
Isn’t this what you are asking for?
Sounds like a great idea, as long as reading the checksum is still fast.
I couldn’t tell when you mentioned run-webkit-tests in your steps what your
specific plans are for old-run-webkit-tests and new-run-webkit-tests.
-- Darin
___
webkit-dev
On Mar 27, 2011, at 1:31 AM, Jeremy Orlow wrote:
I'd even go a bit further and say that if something is worth a review (even
if it's over the shoulder), it's worth a bug + a bug number.
This is where I do not agree. Review is a requirement, but I don’t think
bugs.webkit.org should be.
On Mar 28, 2011, at 10:44 AM, Jeremy Orlow wrote:
If the issue is simply one of overhead, then we should allow committers to
omit change logs when they're not necessary as well.
Sure I am open to discussion about that. I think that some check-ins,
especially LayoutTest ones, don’t need
On Mar 28, 2011, at 9:59 AM, Antonio Gomes wrote:
Darin, could you explain your reasons?
I think the burden for supplying a reason goes in the other direction, on
people who want to require a bug for each check-in.
Generally speaking, I want to keep paperwork and overhead to a minimum. We
On Mar 27, 2011, at 10:37 AM, Dan Bernstein wrote:
I think Eric is not asking about the unicode-bidi property, but rather about
the isolate value, which is not in CSS 2.1. I don’t know that there’s a
guideline, but there is precedent for prefixing values (for example, display:
box and
On Mar 26, 2011, at 3:24 AM, Patrick Gansterer wrote:
Sometimes folks commit changes without bug numbers. If those changes breaks
things it's hard to find the correct context for the change.
Can we make the bug number a requirement for a commit when it has a
corresponding bug?
IMHO it
On Mar 21, 2011, at 4:48 PM, Per Bothner wrote:
Some Googling found references to webkit_web_frame_get_global_context() and
WebFrame::globalContext() but I didn't find these - maybe they're
Cacoa-specific?
webkit_web_frame_get_global_context is a GTK WebKit call.
I think
On Mar 19, 2011, at 10:10 AM, Adam Barth wrote:
Sorry to resurrect this old thread, but what are the DOM APIs in Safari that
are accessible only to search providers?
Two functions on the window object, getSearchEngine and setSearchEngine. They
take and return strings that are the names of
401 - 500 of 1086 matches
Mail list logo
