Re: [webkit-dev] Eliminate potential null pointer dereference?

2012-04-19 Thread David Levin 
On Thu, Apr 19, 2012 at 11:36 PM, Ryosuke Niwa  wrote:

> On Thu, Apr 19, 2012 at 10:35 PM, David Barr  wrote:
>
>> Regarding style, the change homogenizes the loop constructs within that
>> method.
>
>
> I don't think that's necessary an improvement. e.g. we don't have a style
> guide that mandates it.
>
> 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".
>
> On Thu, Apr 19, 2012 at 11:11 PM, David Levin  wrote:
>
>> I understand the other side as well that it would be good to figure out
>> if it is really an issue and find a test to prove it. I guess this is more
>> of what I think of as a BSD type of approach. It seems to be an area where
>> reasonable people can disagree.
>
>
> The WebKit contribution guide lists this as a requirement (
> http://www.webkit.org/coding/contributing.html):
> For any feature that affects the layout engine, a new regression test must
> be constructed. If you provide a patch that fixes a bug, that patch should
> also include the addition of a regression test that would fail without the
> patch and succeed with the patch. If no regression test is provided, the
> reviewer will ask you to revise the patch, so you can save time by
> constructing the test up front and making sure it's attached to the bug.
>
> So I don't think we can "disagree" on this topic. I'm sympathetic to the
> argument that it's hard to come up with a test case for things like this,
> but then the patch author should clearly state that in the change log, and
> most importantly the reviewer should be asking that during the review.
>

You seem to be a bit confrontational here. I'm not sure why.

I was talking about about doing a patch for something where one wasn't able
to find a repro but it appeared like an issue might be there. Not whether
the changelog should say that or not. It may be good to ask a clarifying
question if something is unclear as opposed to responding like this.

dave
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Eliminate potential null pointer dereference?

2012-04-19 Thread Ryosuke Niwa 
On Thu, Apr 19, 2012 at 10:35 PM, David Barr  wrote:
>
> Regarding style, the change homogenizes the loop constructs within that
> method.


I don't think that's necessary an improvement. e.g. we don't have a style
guide that mandates it.

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

On Thu, Apr 19, 2012 at 11:11 PM, David Levin  wrote:

> I understand the other side as well that it would be good to figure out if
> it is really an issue and find a test to prove it. I guess this is more of
> what I think of as a BSD type of approach. It seems to be an area where
> reasonable people can disagree.


The WebKit contribution guide lists this as a requirement (
http://www.webkit.org/coding/contributing.html):
For any feature that affects the layout engine, a new regression test must
be constructed. If you provide a patch that fixes a bug, that patch should
also include the addition of a regression test that would fail without the
patch and succeed with the patch. If no regression test is provided, the
reviewer will ask you to revise the patch, so you can save time by
constructing the test up front and making sure it's attached to the bug.

So I don't think we can "disagree" on this topic. I'm sympathetic to the
argument that it's hard to come up with a test case for things like this,
but then the patch author should clearly state that in the change log, and
most importantly the reviewer should be asking that during the review.

- Ryosuke
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Eliminate potential null pointer dereference?

2012-04-19 Thread David Levin 
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 was introduced. Then they had to figure out
what had broken, etc.

It was mentioned (by gr...@chromium.org) that this very issue had already
been flagged by own internal runs of coverity on chromium (including
webkit). Now, it seemed a shame that we knew about issues in WebKit and
were just ignoring them. It would be nice to be able to catch these issues
faster rather than wait for a user to report it, etc. which makes the
expense overall go up.

So I believe there has been some effort invested in fixing some issues
pointed out by coverity which is what these changes are and I believe
coverity is mentioned in other changes of this sort.

I understand the other side as well that it would be good to figure out if
it is really an issue and find a test to prove it. I guess this is more of
what I think of as a BSD type of approach. It seems to be an area where
reasonable people can disagree.

oth, regarding the style of this particular change, I find it unusual as
well.

dave
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] How can I get some debug infomation in MediaPlayerPrivateGStreamer.cpp

2012-04-19 Thread ZiQiangHuan 
hi Terry,

In fact, I do something like this below:

MediaPlayerPrivateInterface*
MediaPlayerPrivateGStreamer::create(MediaPlayer* player)
{
printf("MediaPlayerPrivateGStreamer::create(MediaPlayer* player) is
called\n");// added by zqhuan
return new MediaPlayerPrivateGStreamer(player);
}

void MediaPlayerPrivateGStreamer::registerMediaEngine(MediaEngineRegistrar
registrar)
{

printf("MediaPlayerPrivateGStreamer::registerMediaEngine(MediaEngineRegistrar
registrar)\n");//added by zqhuan
if (isAvailable())
registrar(create, getSupportedTypes, supportsType);
}

bool MediaPlayerPrivateGStreamer::isAvailable()
{
printf("isAvailable() is called\n"); //added by zqhuan
if (!doGstInit())
return false;

GstElementFactory* factory = gst_element_factory_find("playbin2");
if (factory) {
gst_object_unref(GST_OBJECT(factory));
return true;
}
return false;
}

but when I test with this, got nothing output.

And then, I add ASSERT(false) after the printf statement in
registerMediaEngine function, I can see the output:
MediaPlayerPrivateGStreamer::registerMediaEngine(MediaEngineRegistrar
registrar)
isAvailable() is called

I don't know why this happen. Any ideas?

Best regards,
zqhuan



在 2012年4月20日 上午11:35，Terry Anderson 写道：

> Are you sure that the code is even being reached? Try an ASSERT(false); to
> make sure.
>
> Terry
> On Apr 19, 2012 7:42 PM, "ZiQiangHuan"  wrote:
>
>> hi，
>>
>> I build webkit with gstreamer support, but  I encountered a problem when
>> I test with it. When I write a simple statement "printf("*\n")" in the
>> function isAvailable() of MediaPlayerPrivateGStreamer.cpp, I got nothing
>> output. When I do the same thing with the function create of
>> MediaPlayerPrivateGStreamer.cpp, I got nothing output too. So I want to
>> know if I want to get some debug info in these functions, what should I do?
>> anyone has some experience with this? And I don't know why this happen.
>>
>> Any help would be appreciated.
>>
>> Best regards,
>> zqhuan
>>
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Eliminate potential null pointer dereference?

2012-04-19 Thread Maciej Stachowiak 

On Apr 19, 2012, at 10:35 PM, David Barr wrote:

> On Fri, Apr 20, 2012 at 3:18 PM, Alexey Proskuryakov  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 that mean, and why are we allowing such patches to 
>> be landed?
> 
> When there are known conditions for which a value is null that we
> would otherwise dereference, check first and take an alternate path in
> the null case.
> 
>> For example, this change doesn't look nice: 
>> .
>>  We should not try to confuse ourselves with unusual for loop forms, and 
>> there is no explanation at all of why these changes are needed. No 
>> regression tests either.
> 
> Style aside, it is quite clear that the one of the termination
> conditions for the first loop is selector == null.
> So the second loop ought to check selector != null before any
> dereference of selector.

If that code path is reachable, then it should be possible to construct a test, 
and the claim that there's no new tests because it's code cleanup only is 
wrong. If it is not reachable, then your argument does not apply

> 
> Regarding style, the change homogenizes the loop constructs within that 
> method.
> 

That seems subjective. Making a bunch of these tiny changes that are not tied 
to an actual change in behavior or a clear-cut broader goal has some downsides:
- Makes it harder to study history
- Causes needless extra build thrash for people and buildbots
- Creates risk of accidentally introducing a bug

I don't have a strong opinion on this one, but if a bunch of these changes are 
landing, then either they need tests if they fix real bugs, or they should be 
related to some more concrete goal than just "code cleanup".

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] CMake for Apple's Windows port

2012-04-19 Thread Maciej Stachowiak 

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 online or get a recording of 
> it?
> 
> -- Patrick
> 
> Am 20.04.2012 um 06:08 schrieb Eric Seidel:
> 
>> We're discussing reducing the number of build-systems at the WebKit
>> meeting tomorrow @ 10am.
>> 
>> Interested parties should definitely be there.  Especially ones who
>> know something about CMake (since I know nothing). :)
>> 
>> -eric
>> 
>> On Thu, Apr 12, 2012 at 5:41 AM, Patrick Gansterer  wrote:
>>> Hi,
>>> 
>>> it's more than a year since the last discussion about the build system of 
>>> Apple's Windows port. In the meantime I merged most of the general changes 
>>> into the CMake files in the repository and have a working patch with a few 
>>> CMake files at [1] as written in [2]. I don't think that it is ready to 
>>> replace the existing vcproj files already, but I like to hear all points 
>>> needed to do that.
>>> Adding CMake files for the WinCairo port (which uses the vcproj files too) 
>>> will be very easy when the Apple version has been added.
>>> 
>>> Here some benefits to the CMake version:
>>> 1) Shared build system: The shared files are already used by the 
>>> Blackberry, EFL and WinCE port, so only the list of platform specific files 
>>> needs to be maintained.
>>> 2) No dependency on cygwin [3]: The CMake build system searches for the 
>>> Win32 version of the required executables (bison, gperf, flex, perl and 
>>> python) like the WinCE port does already (see [4]).
>>> 3) Less Solution targets: Some of he current vcproj files only used for 
>>> triggering Makefiles. The vcproj generates more native vcproj files, which 
>>> e.g. allows clicking on one of the IDL files to generate the corresponding 
>>> files.
>>> 4) Easy creation of Visual Studio 2010 project files [5]: Using CMake 
>>> allows an easy transition to other (newer) Visual Studio versions, since 
>>> every developer can choose his preferred version.
>>> 5) It's possibe to create Makefiles: The output of the windows buildbots 
>>> shows much unwanted messages. Using Makefiles on the bots can produce 
>>> cleaner logs and take advantage of all cores when used with JOM [7].
>>> 
>>> Would be great if people who use the current VS Solution can give the CMake 
>>> version a try and provide some feedback about it.
>>> 
>>> BTW: There is also a patch to switch Wx to CMake at [8], but it did not get 
>>> a positive response.
>>> 
>>> [1] https://bugs.webkit.org/show_bug.cgi?id=72816
>>> [2] https://lists.webkit.org/pipermail/webkit-dev/2011-February/015831.html
>>> [3] https://bugs.webkit.org/show_bug.cgi?id=48166
>>> [4] http://trac.webkit.org/wiki/WinCE#Build
>>> [5] https://bugs.webkit.org/show_bug.cgi?id=53445
>>> [6] https://lists.webkit.org/pipermail/webkit-dev/2011-January/015815.html
>>> [7] http://qt-project.org/wiki/jom
>>> [8] https://bugs.webkit.org/show_bug.cgi?id=73100
>>> 
>>> -- Patrick
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org
>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Eliminate potential null pointer dereference?

2012-04-19 Thread David Barr 
On Fri, Apr 20, 2012 at 3:18 PM, Alexey Proskuryakov  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 that mean, and why are we allowing such patches to be 
> landed?

When there are known conditions for which a value is null that we
would otherwise dereference, check first and take an alternate path in
the null case.

> For example, this change doesn't look nice: 
> .
>  We should not try to confuse ourselves with unusual for loop forms, and 
> there is no explanation at all of why these changes are needed. No regression 
> tests either.

Style aside, it is quite clear that the one of the termination
conditions for the first loop is selector == null.
So the second loop ought to check selector != null before any
dereference of selector.

Regarding style, the change homogenizes the loop constructs within that method.

--
David Barr
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] Eliminate potential null pointer dereference?

2012-04-19 Thread Alexey Proskuryakov 

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 that mean, and why are we allowing such patches to be 
landed?

For example, this change doesn't look nice: 
.
 We should not try to confuse ourselves with unusual for loop forms, and there 
is no explanation at all of why these changes are needed. No regression tests 
either.

- WBR, Alexey Proskuryakov

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] CMake for Apple's Windows port

2012-04-19 Thread Patrick Gansterer 
I'm very interested in that discussion, but I can't be physically there. :-(
Is there any any possibility for me to attend it online or get a recording of 
it?

-- Patrick

Am 20.04.2012 um 06:08 schrieb Eric Seidel:

> We're discussing reducing the number of build-systems at the WebKit
> meeting tomorrow @ 10am.
> 
> Interested parties should definitely be there.  Especially ones who
> know something about CMake (since I know nothing). :)
> 
> -eric
> 
> On Thu, Apr 12, 2012 at 5:41 AM, Patrick Gansterer  wrote:
>> Hi,
>> 
>> it's more than a year since the last discussion about the build system of 
>> Apple's Windows port. In the meantime I merged most of the general changes 
>> into the CMake files in the repository and have a working patch with a few 
>> CMake files at [1] as written in [2]. I don't think that it is ready to 
>> replace the existing vcproj files already, but I like to hear all points 
>> needed to do that.
>> Adding CMake files for the WinCairo port (which uses the vcproj files too) 
>> will be very easy when the Apple version has been added.
>> 
>> Here some benefits to the CMake version:
>> 1) Shared build system: The shared files are already used by the Blackberry, 
>> EFL and WinCE port, so only the list of platform specific files needs to be 
>> maintained.
>> 2) No dependency on cygwin [3]: The CMake build system searches for the 
>> Win32 version of the required executables (bison, gperf, flex, perl and 
>> python) like the WinCE port does already (see [4]).
>> 3) Less Solution targets: Some of he current vcproj files only used for 
>> triggering Makefiles. The vcproj generates more native vcproj files, which 
>> e.g. allows clicking on one of the IDL files to generate the corresponding 
>> files.
>> 4) Easy creation of Visual Studio 2010 project files [5]: Using CMake allows 
>> an easy transition to other (newer) Visual Studio versions, since every 
>> developer can choose his preferred version.
>> 5) It's possibe to create Makefiles: The output of the windows buildbots 
>> shows much unwanted messages. Using Makefiles on the bots can produce 
>> cleaner logs and take advantage of all cores when used with JOM [7].
>> 
>> Would be great if people who use the current VS Solution can give the CMake 
>> version a try and provide some feedback about it.
>> 
>> BTW: There is also a patch to switch Wx to CMake at [8], but it did not get 
>> a positive response.
>> 
>> [1] https://bugs.webkit.org/show_bug.cgi?id=72816
>> [2] https://lists.webkit.org/pipermail/webkit-dev/2011-February/015831.html
>> [3] https://bugs.webkit.org/show_bug.cgi?id=48166
>> [4] http://trac.webkit.org/wiki/WinCE#Build
>> [5] https://bugs.webkit.org/show_bug.cgi?id=53445
>> [6] https://lists.webkit.org/pipermail/webkit-dev/2011-January/015815.html
>> [7] http://qt-project.org/wiki/jom
>> [8] https://bugs.webkit.org/show_bug.cgi?id=73100
>> 
>> -- Patrick
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] CMake for Apple's Windows port

2012-04-19 Thread Eric Seidel 
We're discussing reducing the number of build-systems at the WebKit
meeting tomorrow @ 10am.

Interested parties should definitely be there.  Especially ones who
know something about CMake (since I know nothing). :)

-eric

On Thu, Apr 12, 2012 at 5:41 AM, Patrick Gansterer  wrote:
> Hi,
>
> it's more than a year since the last discussion about the build system of 
> Apple's Windows port. In the meantime I merged most of the general changes 
> into the CMake files in the repository and have a working patch with a few 
> CMake files at [1] as written in [2]. I don't think that it is ready to 
> replace the existing vcproj files already, but I like to hear all points 
> needed to do that.
> Adding CMake files for the WinCairo port (which uses the vcproj files too) 
> will be very easy when the Apple version has been added.
>
> Here some benefits to the CMake version:
> 1) Shared build system: The shared files are already used by the Blackberry, 
> EFL and WinCE port, so only the list of platform specific files needs to be 
> maintained.
> 2) No dependency on cygwin [3]: The CMake build system searches for the Win32 
> version of the required executables (bison, gperf, flex, perl and python) 
> like the WinCE port does already (see [4]).
> 3) Less Solution targets: Some of he current vcproj files only used for 
> triggering Makefiles. The vcproj generates more native vcproj files, which 
> e.g. allows clicking on one of the IDL files to generate the corresponding 
> files.
> 4) Easy creation of Visual Studio 2010 project files [5]: Using CMake allows 
> an easy transition to other (newer) Visual Studio versions, since every 
> developer can choose his preferred version.
> 5) It's possibe to create Makefiles: The output of the windows buildbots 
> shows much unwanted messages. Using Makefiles on the bots can produce cleaner 
> logs and take advantage of all cores when used with JOM [7].
>
> Would be great if people who use the current VS Solution can give the CMake 
> version a try and provide some feedback about it.
>
> BTW: There is also a patch to switch Wx to CMake at [8], but it did not get a 
> positive response.
>
> [1] https://bugs.webkit.org/show_bug.cgi?id=72816
> [2] https://lists.webkit.org/pipermail/webkit-dev/2011-February/015831.html
> [3] https://bugs.webkit.org/show_bug.cgi?id=48166
> [4] http://trac.webkit.org/wiki/WinCE#Build
> [5] https://bugs.webkit.org/show_bug.cgi?id=53445
> [6] https://lists.webkit.org/pipermail/webkit-dev/2011-January/015815.html
> [7] http://qt-project.org/wiki/jom
> [8] https://bugs.webkit.org/show_bug.cgi?id=73100
>
> -- Patrick
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] How can I get some debug infomation in MediaPlayerPrivateGStreamer.cpp

2012-04-19 Thread Terry Anderson 
Are you sure that the code is even being reached? Try an ASSERT(false); to
make sure.

Terry
On Apr 19, 2012 7:42 PM, "ZiQiangHuan"  wrote:

> hi，
>
> I build webkit with gstreamer support, but  I encountered a problem when I
> test with it. When I write a simple statement "printf("*\n")" in the
> function isAvailable() of MediaPlayerPrivateGStreamer.cpp, I got nothing
> output. When I do the same thing with the function create of
> MediaPlayerPrivateGStreamer.cpp, I got nothing output too. So I want to
> know if I want to get some debug info in these functions, what should I do?
> anyone has some experience with this? And I don't know why this happen.
>
> Any help would be appreciated.
>
> Best regards,
> zqhuan
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] How can I get some debug infomation in MediaPlayerPrivateGStreamer.cpp

2012-04-19 Thread ZiQiangHuan 
hi，

I build webkit with gstreamer support, but  I encountered a problem when I
test with it. When I write a simple statement "printf("*\n")" in the
function isAvailable() of MediaPlayerPrivateGStreamer.cpp, I got nothing
output. When I do the same thing with the function create of
MediaPlayerPrivateGStreamer.cpp, I got nothing output too. So I want to
know if I want to get some debug info in these functions, what should I do?
anyone has some experience with this? And I don't know why this happen.

Any help would be appreciated.

Best regards,
zqhuan
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] Contributor meeting hackathon: Move methods from layoutTestController

2012-04-19 Thread Alexey Proskuryakov 

We're capturing ideas for which LayoutTestController methods could be moved to 
Internals here: .

Even found some that are completely unused in tests!

- WBR, Alexey Proskuryakov

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] New feature: Implement command API in webkit

2012-04-19 Thread Eric Seidel 
It appears no consensus was reached?  The patch is still up for review:
https://bugs.webkit.org/show_bug.cgi?id=72955

On Thu, Nov 24, 2011 at 11:34 AM, Ryosuke Niwa  wrote:
> On Thu, Nov 24, 2011 at 9:32 AM, Ian Hickson  wrote:
>>
>> On Thu, 24 Nov 2011, Ryosuke Niwa wrote:
>> >
>> > For example, the current design doesn't allow a single command be
>> > associated with multiple UI components such as toolbar, pane, and
>> > context menu because a command is defined at wherever UI component that
>> > triggers the command.
>> >
>> > However, in practice, many web apps share the same command state across
>> > multiple UI widgets such as toolbars and context menu. Take, "bold"
>> > command as an example. "bold" command can be disabled or checked (i.e.
>> > the selected text is in bold) and this state needs to shared across many
>> > UI elements.
>>
>> Correct, though that is only a temporary limitation. I avoided adding this
>> because I figured adding too much at once would cause implementors to
>> avoid it. I'm happy to add it already if that is what it takes to get it
>> implemented. :-) The idea is to add a command="" attribute which takes an
>> ID and would then make the element defer to the element with that ID, so
>> that you only need define the command once and then refer to it from the
>> various places in the UI where you want to refer to it.
>
>
> (At this point, we should probably move this discussion to public-html or
> whatwg but I'll post it here for the sake of consistency)
>
> That's an interesting idea. When Erik, Alex, and I were talking about this,
> we thought each command can have a name and command content attribute can
> refer to that.
>
> One thing I really want to do is to tie command's name space with that of
> execCommand since they already have useful functions like queryCommandState,
> and queryCommandValue.
>
> One big problem I have with the current design is that when a command can
> take multiple values like foreColor, "checked" state doesn't make much
> sense. In fact, we probably just need a generic "command value" that can
> be coerced into boolean as needed (i.e. what queryCommandValue returns for
> editing commands). Once we have that, whether a radiobox or checkbox is
> checked or not can be determined by whether command value matches the value
> or is boolean equivalent to true.
>
> So I don't think command state should include checked.
>
>> > I also don't think UA should auto-generate toolbars as most of web apps
>> > want to have a fine-grained control over the look and feel of their
>> > toolbars.
>>
>> Agreed with the fine-grained control issue. I figured we would do that
>> using pseudo-elements and component decorators, but I haven't specced
>> anything out yet because those aren't ready yet.
>
>
> I'm very skeptical that any author, especially those building web apps,
> would start using menu + command if decorating them was harder than it is
> today. I'd think that authors much rather keep command an abstract concept,
> and define toolbars themselves.
>
> Another big problem with the current design is modularity. We've got to make
> sure any commands defined in a widget will not interfere (i.e. should be
> unavailable or disabled, or even overridden by page's commands) with the
> rest of the page.
>
> - Ryosuke
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] gardening status (mac10.5 build slave needs clobber)

2012-04-19 Thread Takashi Toyoshima 
Hi, I did WebKit roll to 114621 now.
This will be my last roll today (and of this my gardening cycle).

many webgl related layout tests failed, then I reverted a chromium side change.
It will fix failures, but you might see failures for a while because
of delayed test results.

svg/as-image/img-preserveAspectRatio-support-1.html was already rebaselined.
It will disappear from garden-o-matic soon.

In chromium waterfall, Mac 10.5 slave builder is missing.
I filed a ticket to clobber this, but I guess it's still have a problem.

-- 
Takashi Toyoshima
Software Engineer, Google
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] run-webkit-tests --pixel-tests and text-based tests

2012-04-19 Thread Milian Wolff 
On Wednesday 18 April 2012 14:03:51 Dirk Pranke wrote:
> On Wed, Apr 18, 2012 at 10:40 AM, Milian Wolff  
wrote:
> > Hey all,
> > 
> > I'm working on isPrinting() support for the Qt port and noticed that if I
> > do something like this:
> > 
> > ./Tools/Scripts/run-webkit-tests -p LayoutTests/printing/
> > 
> > Then I get lots of "failures" due to missing image baselines for tests
> > like
> > printing/page-rule-css-text-expected.html.
> > 
> > Thing is: Tests like the above are not pixel-based. So how do other test
> > suites detect this?
> 
> You should only get complaints about missing image baselines if DRT
> thinks that the test should generate a PNG. The way DRT detects that
> is if --pixel-tests is passed on the command line and
> layoutTestController.dumpAsText() is *not* called (i.e., PNGs are the
> default).

Ah, thanks!

> Assuming there's a typo in your email, and you meant to refer to
> printing/page-rule-css-text.html (not -expected.html, which is the
> convention we use for reference tests), that test is supposed to be a
> text-only test.

Yep, was a typo.

> *However*, it's possible that there's a bug occuring when you run the
> test such that dumpAsText() is not actually getting invoked. In that
> case, you'll get the MISSING baselines warning.
> 
> There is not a good way to fix this (i.e., to not get these false
> warnings) that I'm aware of.
> 
> I hope that's helpful,

Yes, very much. I've created a patch that fixes Qt's DRT according to your 
comments, i.e. to prevent pixel-dumps when dumpAsText was called.

See: https://bugs.webkit.org/show_bug.cgi?id=84327

Cheers
-- 
Milian Wolff | milian.wo...@kdab.com | Software Engineer
KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-independent software solutions


signature.asc
Description: This is a digitally signed message part.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev