Re: [webkit-dev] Can we disable "control reaches end of non-void function" warning on Qt?

2013-09-13 Thread Darin Adler 
On Sep 13, 2013, at 10:28 AM, Alexey Proskuryakov  wrote:

> 13 сент. 2013 г., в 10:13, Darin Adler  написал(а):
> 
>> Since there’s no runtime guarantee that the enum will have a valid value, I 
>> think there needs to be a return statement outside the switch, even if we 
>> have ASSERT_NOT_REACHED before it.
> 
> Should it be a RELEASE_ASSERT? If we have a bad value in an enum, it's likely 
> a memory smasher, so it's best to crash before it's exploited.

Sure, that’d be OK with me.

-- Darin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] (no subject)

2013-09-13 Thread Bem Jones-Bey 
On Sep 13, 2013, at 13:12 , Ryosuke Niwa 
mailto:rn...@webkit.org>> wrote:

Unsubscribe at https://lists.webkit.org/mailman/listinfo/webkit-dev

I'm getting really tired of seeing these emails.  How hard is it to open the 
URL attached on every email sent to this mailing list?

I wonder if this is a gmail problem: I think gmail hides that by default when 
you are reading mail from a mailing list, like it tries to be helpful by hiding 
people's signatures by default as well.

Maybe Kabeer can tell us if the footer on this message is visible in gmail.

(Unfortunately, I have no idea how one would go about fixing that.)

- Bem

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

Re: [webkit-dev] Changes in QtWebKit development

2013-09-13 Thread Brent Fulgham 

On Sep 13, 2013, at 10:22 AM, Benjamin Poulain  wrote:

> On 9/13/13, 4:50 AM, Albisser Zeno wrote:
>> As many of you have probably noticed already, we have recently been focusing 
>> on a project called Qt WebEngine. Our WebKit efforts have therefore been 
>> reduced significantly over the past weeks.
>> While we will keep shipping QtWebKit with Qt for the foreseeable future, we 
>> want to concentrate our efforts on Qt WebEngine.
>> Therefore we are planning some changes to our development setup. In 
>> particular we are planning to remove our QtWebKit/Mac and QtWebKit/Windows 
>> builds from WebKit trunk. We will keep maintaining these platforms in a 
>> separate branch through the Qt project’s gerrit infrastructure.
>> This essentially means our presence in trunk will be reduced to 
>> QtWebKit/Linux.
>> 
>> We are planning to gradually implement the required changes within the next 
>> month.
>> If this proves to bring significant issues for some development, please do 
>> let us know and we can sort out a way to work together on a phase-out 
>> process.
> This is sad.
> 
> When "modules" of Qt are put on "maintenance", it is basically a synonym to 
> "it's unmaintained, just let it die". I am very unexcited about having one of 
> those in the tree along the live development from everyone else.
> It is unfair for all the ports who put real efforts in the WebKit opensource 
> project.
> 
> Realistically, how much development will go in QtWebKit/Linux? Why does it 
> stay in WebKit trunk if the two other ports are "maintained" in a branch?

Why don’t they create a WebKit branch and label it as their maintenance branch, 
and then we can purge the Qt stuff to lighten the size of the LayoutTests 
repository.

I don’t see much benefit in keeping the code in place if their plan is to be 
gone shortly.

-Brent

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

Re: [webkit-dev] Changes in QtWebKit development

2013-09-13 Thread Benjamin Poulain 
On 9/13/13, 4:50 AM, Albisser Zeno wrote:
> As many of you have probably noticed already, we have recently been
> focusing on a project called Qt WebEngine. Our WebKit efforts have
> therefore been reduced significantly over the past weeks.
> While we will keep shipping QtWebKit with Qt for the foreseeable
> future, we want to concentrate our efforts on Qt WebEngine.
> Therefore we are planning some changes to our development setup. In
> particular we are planning to remove our QtWebKit/Mac and
> QtWebKit/Windows builds from WebKit trunk. We will keep maintaining
> these platforms in a separate branch through the Qt project's gerrit
> infrastructure.
> This essentially means our presence in trunk will be reduced to
> QtWebKit/Linux.
>
> We are planning to gradually implement the required changes within the
> next month.
> If this proves to bring significant issues for some development,
> please do let us know and we can sort out a way to work together on a
> phase-out process.
This is sad.

When "modules" of Qt are put on "maintenance", it is basically a synonym
to "it's unmaintained, just let it die". I am very unexcited about
having one of those in the tree along the live development from everyone
else.
It is unfair for all the ports who put real efforts in the WebKit
opensource project.

Realistically, how much development will go in QtWebKit/Linux? Why does
it stay in WebKit trunk if the two other ports are "maintained" in a branch?

Benjamin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Changes in QtWebKit development

2013-09-13 Thread Darin Adler 
Oh, I see, this is about Qt joining the Blink project. I am disappointed to 
hear it, but now I understand.

I think that once Qt WebKit reaches the point where it is not actively being 
worked on, it would be best to remove it.

-- Darin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Can we disable "control reaches end of non-void function" warning on Qt?

2013-09-13 Thread Darin Adler 
On Sep 12, 2013, at 2:07 PM, Ryosuke Niwa  wrote:

> http://trac.webkit.org/changeset/155643 broke Qt build with an error saying:
> 
> Source/JavaScriptCore/dfg/DFGGPRInfo.h:169:5: error: control reaches end of 
> non-void function [-Werror=return-type]
> cc1plus: all warnings being treated as errors
> 
> because of the following code:
> 
> GPRReg gpr(WhichValueWord which) const
> {
> switch (which) {
> case TagWord:
> return tagGPR();
> case PayloadWord:
> return payloadGPR();
> }
> }
> 
> But the code works just fine as is because WhichValueWord only takes two 
> values (TagWord and PayloadWord) and they're all handled in the switch 
> statement.
> 
> Can we disable this warning so that we don't have to add a bogus code like 
> the one I had to add in 
> http://trac.webkit.org/changeset/155649/trunk/Source/JavaScriptCore/dfg/DFGGPRInfo.h
>  ?

I don’t think disabling the warning is the right thing to do.

Since there’s no runtime guarantee that the enum will have a valid value, I 
think there needs to be a return statement outside the switch, even if we have 
ASSERT_NOT_REACHED before it.

-- Darin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Changes in QtWebKit development

2013-09-13 Thread Alexis Menard 
Hi Darin,

I think he forgot to paste the link which add a bit of meat to the
conversation.

http://blog.qt.digia.com/blog/2013/09/12/introducing-the-qt-webengine/

Thanks.


On Fri, Sep 13, 2013 at 2:03 PM, Darin Adler  wrote:

> On Sep 13, 2013, at 4:50 AM, Albisser Zeno 
> wrote:
>
> Qt WebEngine
>
>
> What is that? Is it based on a fork of WebKit?
>
> -- Darin
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>


-- 
Software Engineer @
Intel Open Source Technology Center
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Changes in QtWebKit development

2013-09-13 Thread Zeno Albisser 
Hi Benjamin,

On Sep 13, 2013, at 7:22 PM, Benjamin Poulain  wrote:
> This is sad.

I can understand very well, that you are not very happy about this. And I don't 
think anybody here took this decision lightly.

> 
> When "modules" of Qt are put on "maintenance", it is basically a synonym to 
> "it's unmaintained, just let it die". I am very unexcited about having one of 
> those in the tree along the live development from everyone else.
> It is unfair for all the ports who put real efforts in the WebKit opensource 
> project.

Real efforts is not something that can be define that simple, i think. It 
depends a lot on available resources as well.
However, I think we are doing exactly what you are asking for. With the pieces 
that we do not have enough people working on, we are getting out of the way, 
and will maintain it through our own gerrit.
For the builds we have actively people working on, we remain working upstream.

- Zeno


-- 
Zeno Albisser
Senior Software Engineer - Digia, Qt
Visit us on: http://qt.digia.com 

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

Re: [webkit-dev] Can we disable "control reaches end of non-void function" warning on Qt?

2013-09-13 Thread Darin Adler 
Can someone make this more concrete by pointing to an example in WebKit where 
we are getting that warning with gcc, but no warning with clang?

-- Darin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] (no subject)

2013-09-13 Thread Ryosuke Niwa 
Unsubscribe at https://lists.webkit.org/mailman/listinfo/webkit-dev

I'm getting really tired of seeing these emails.  How hard is it to open
the URL attached on every email sent to this mailing list?

On Fri, Sep 13, 2013 at 1:08 PM, Kabeer Kalra wrote:

> I DO NOT WANT TO BE IN THE MAILING LIST
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] (no subject)

2013-09-13 Thread Kabeer Kalra 
I DO NOT WANT TO BE IN THE MAILING LIST
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Can we disable "control reaches end of non-void function" warning on Qt?

2013-09-13 Thread Filip Pizlo 

On Sep 13, 2013, at 10:33 AM, Darin Adler  wrote:

> On Sep 13, 2013, at 10:31 AM, Oliver Hunt  wrote:
> 
>> We may want to hunt through the other cases of default: ASSERT_NOT_REACHED() 
>> and clobber those with RELEASE_ASSERT_NOT_REACHED() as well.
>> 
>> I wonder if it would be easier to have DEFAULT_NOT_REACHED() and 
>> DEFAULT_OKAY() macros, and convince the style bot to require ether a 
>> default: block or one of these two macros at the end of every switch?
> 
> 
> Maybe.
> 
> The advantage of doing the not-reached assertion after the switch is that we 
> get the compile time warning if we don’t enumerate one of the enum values. 
> Having a default case turns that warning off.

Yes.  I've already been moving towards this idiom.

-F

> 
> -- Darin
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

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

Re: [webkit-dev] Announcing new port: Nix

2013-09-13 Thread Anders Carlsson 

On Sep 12, 2013, at 1:58 PM, Hugo Lima  wrote:

> On Thu, Sep 12, 2013 at 4:14 PM, Ryosuke Niwa  wrote:
>> Interesting. That sounds a lot like Chromium's WebKit API layer.  If I
>> remember correctly, that layer had to be modified constantly as
>> WebCore/WebKit code was refactored so I'm a bit worried about this.
> 
> Yes, in fact we got some API from them.

This is my biggest concern with the Nix port; that it will end up exposing 
implementation details of our platform layer, making it harder for us to 
perform sweeping changes to said layer (for example, like what Darin is doing 
with his pasteboard cleanup patches).

In fact, it reminds me of the WebKit2 situation (before we instituted the build 
policy) where some changes that should in theory take days would end up taking 
weeks because of:

- Churn waiting for the EWS bots to do their thing.
- Churn due to patches being rolled out for breaking other ports (due to 
certain build flags being enabled in said ports).
- Churn due to patches being rolled out for breaking other ports (due to 
misconceptions about the correct WebKit2 semantics in said ports).

Maybe we would need a similar build policy for WebCore?

>> But it sounds like you're suggesting that Nix port's maintainers will be
>> responsible for making any code changes necessary to support
>> WebCore/WebKit/WebKit2 refactoring?
> 
> Yes, this is the idea, is our concern to keep our code working.

I am glad to hear that. Does that mean that we’re allowed to break the Nix port 
without having patches rolled out by members of the Nix team?

- Anders

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

Re: [webkit-dev] TimerWindowWndProc and dangling page instances

2013-09-13 Thread Brent Fulgham 
Hi Vincent,

On Sep 13, 2013, at 1:34 AM, Van Den Berghe, Vincent 
 wrote:

> I’m embedding the Wincairo build of WebKit to generate PDF files from web 
> pages in an ASP.NET application.

Yay!

> Webkit isn’t really designed for such a scenario but with some careful 
> patching, a solution can be constructed which is “reasonably reliable”.   
> However, these patches touch on WebKit’s fundamental design decisions and I’m 
> reluctant to submit them without first some validation of someone who knows 
> the code better.   Some are more hacks than patches.

I would still encourage you to file bugs about these items so that there is 
documented history about the issue, and how to work around the problem.

WebKit is designed to be embedded in other applications — that’s exactly why I 
put together the WInCairo port in the first place. However, it has been 
optimized and coded for specific scenarios that may not match your needs. If we 
can make WebKit work better in these other areas (without breaking the existing 
use cases) I would be very strongly in favor of integrating such changes.

> So I became a member of the webkit-dev list and submitted the result of my 
> last frustrating bug hunt to see what happens. And it looks like it’s not 
> totally worthless.

I have always found the webkit-dev list to be extremely helpful. However, we 
will expect you to do some work, too — namely filing bugs and documenting what 
you are doing.  And, hopefully, contributing code to fix the issue!

Also, please CC me on any such bugs you file.

Thanks,

-Brent___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Announcing new port: Nix

2013-09-13 Thread Hugo Lima 
On Fri, Sep 13, 2013 at 4:31 PM, Antonio Gomes  wrote:
> So will you advocate your users to use your external GitHub version or
> the one in
> WebKit?
>
> Please consider not being half upstream.

It wont be half upstream, but the github repository will be for
example a fallback for a working bleeding edge Nix just in case of
WebCore changes that break Nix on webkit.org. We can also push things
first there then on webkit.org if a faster development pace if needed,
as all Nix developers use git this also means that experimental
feature branches will exists on github repo too (don't tell me about
create svn branches).

The worst scenario is if a WK2 change doesn't get accepted at all, but
I don't think gonna happen if the change isn't wrong.

In other words, no, it's not our intent to do half upstream like IIRC
happened with Blackberry port.

> On Fri, Sep 13, 2013 at 2:37 PM, Hugo Lima  wrote:
>> On Fri, Sep 13, 2013 at 3:00 PM, Anders Carlsson  wrote:
>>>
>>> On Sep 12, 2013, at 1:58 PM, Hugo Lima  wrote:
>>>
 On Thu, Sep 12, 2013 at 4:14 PM, Ryosuke Niwa  wrote:
> Interesting. That sounds a lot like Chromium's WebKit API layer.  If I
> remember correctly, that layer had to be modified constantly as
> WebCore/WebKit code was refactored so I'm a bit worried about this.

 Yes, in fact we got some API from them.
>>>
>>> This is my biggest concern with the Nix port; that it will end up exposing 
>>> implementation details of our platform layer, making it harder for us to 
>>> perform sweeping changes to said layer (for example, like what Darin is 
>>> doing with his pasteboard cleanup patches).
>>>
>>> In fact, it reminds me of the WebKit2 situation (before we instituted the 
>>> build policy) where some changes that should in theory take days would end 
>>> up taking weeks because of:
>>>
>>> - Churn waiting for the EWS bots to do their thing.
>>> - Churn due to patches being rolled out for breaking other ports (due to 
>>> certain build flags being enabled in said ports).
>>> - Churn due to patches being rolled out for breaking other ports (due to 
>>> misconceptions about the correct WebKit2 semantics in said ports).
>>>
>>> Maybe we would need a similar build policy for WebCore?
>>>
> But it sounds like you're suggesting that Nix port's maintainers will be
> responsible for making any code changes necessary to support
> WebCore/WebKit/WebKit2 refactoring?

 Yes, this is the idea, is our concern to keep our code working.
>>>
>>> I am glad to hear that. Does that mean that we’re allowed to break the Nix 
>>> port without having patches rolled out by members of the Nix team?
>>
>> This already happen nowadays, so it would not change too much our
>> development. Even after nix upstream process we will probably keep a
>> copy on github with few additional patches that may not fit on e.g.
>> WebKit2 or need to be landed a bit faster on our tree due to some
>> customer needs.
>>
>> I didn't talk with other team members about it, but IMO it's not a big
>> deal to break it on these kind of WebCore changes that affect all
>> ports, I'm saying this because the chance of having these patches
>> breaking other ports as well is considerable too, besides if the
>> change get announced on this ML before get landed we'll have enough
>> time to adapt to it.
>>
>>> - Anders
>>>
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Changes in QtWebKit development

2013-09-13 Thread Darin Adler 
On Sep 13, 2013, at 4:50 AM, Albisser Zeno  wrote:

> Qt WebEngine

What is that? Is it based on a fork of WebKit?

-- Darin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Announcing new port: Nix

2013-09-13 Thread Antonio Gomes 
So will you advocate your users to use your external GitHub version or
the one in
WebKit?

Please consider not being half upstream.

On Fri, Sep 13, 2013 at 2:37 PM, Hugo Lima  wrote:
> On Fri, Sep 13, 2013 at 3:00 PM, Anders Carlsson  wrote:
>>
>> On Sep 12, 2013, at 1:58 PM, Hugo Lima  wrote:
>>
>>> On Thu, Sep 12, 2013 at 4:14 PM, Ryosuke Niwa  wrote:
 Interesting. That sounds a lot like Chromium's WebKit API layer.  If I
 remember correctly, that layer had to be modified constantly as
 WebCore/WebKit code was refactored so I'm a bit worried about this.
>>>
>>> Yes, in fact we got some API from them.
>>
>> This is my biggest concern with the Nix port; that it will end up exposing 
>> implementation details of our platform layer, making it harder for us to 
>> perform sweeping changes to said layer (for example, like what Darin is 
>> doing with his pasteboard cleanup patches).
>>
>> In fact, it reminds me of the WebKit2 situation (before we instituted the 
>> build policy) where some changes that should in theory take days would end 
>> up taking weeks because of:
>>
>> - Churn waiting for the EWS bots to do their thing.
>> - Churn due to patches being rolled out for breaking other ports (due to 
>> certain build flags being enabled in said ports).
>> - Churn due to patches being rolled out for breaking other ports (due to 
>> misconceptions about the correct WebKit2 semantics in said ports).
>>
>> Maybe we would need a similar build policy for WebCore?
>>
 But it sounds like you're suggesting that Nix port's maintainers will be
 responsible for making any code changes necessary to support
 WebCore/WebKit/WebKit2 refactoring?
>>>
>>> Yes, this is the idea, is our concern to keep our code working.
>>
>> I am glad to hear that. Does that mean that we’re allowed to break the Nix 
>> port without having patches rolled out by members of the Nix team?
>
> This already happen nowadays, so it would not change too much our
> development. Even after nix upstream process we will probably keep a
> copy on github with few additional patches that may not fit on e.g.
> WebKit2 or need to be landed a bit faster on our tree due to some
> customer needs.
>
> I didn't talk with other team members about it, but IMO it's not a big
> deal to break it on these kind of WebCore changes that affect all
> ports, I'm saying this because the chance of having these patches
> breaking other ports as well is considerable too, besides if the
> change get announced on this ML before get landed we'll have enough
> time to adapt to it.
>
>> - Anders
>>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Announcing new port: Nix

2013-09-13 Thread Hugo Lima 
On Fri, Sep 13, 2013 at 3:00 PM, Anders Carlsson  wrote:
>
> On Sep 12, 2013, at 1:58 PM, Hugo Lima  wrote:
>
>> On Thu, Sep 12, 2013 at 4:14 PM, Ryosuke Niwa  wrote:
>>> Interesting. That sounds a lot like Chromium's WebKit API layer.  If I
>>> remember correctly, that layer had to be modified constantly as
>>> WebCore/WebKit code was refactored so I'm a bit worried about this.
>>
>> Yes, in fact we got some API from them.
>
> This is my biggest concern with the Nix port; that it will end up exposing 
> implementation details of our platform layer, making it harder for us to 
> perform sweeping changes to said layer (for example, like what Darin is doing 
> with his pasteboard cleanup patches).
>
> In fact, it reminds me of the WebKit2 situation (before we instituted the 
> build policy) where some changes that should in theory take days would end up 
> taking weeks because of:
>
> - Churn waiting for the EWS bots to do their thing.
> - Churn due to patches being rolled out for breaking other ports (due to 
> certain build flags being enabled in said ports).
> - Churn due to patches being rolled out for breaking other ports (due to 
> misconceptions about the correct WebKit2 semantics in said ports).
>
> Maybe we would need a similar build policy for WebCore?
>
>>> But it sounds like you're suggesting that Nix port's maintainers will be
>>> responsible for making any code changes necessary to support
>>> WebCore/WebKit/WebKit2 refactoring?
>>
>> Yes, this is the idea, is our concern to keep our code working.
>
> I am glad to hear that. Does that mean that we’re allowed to break the Nix 
> port without having patches rolled out by members of the Nix team?

This already happen nowadays, so it would not change too much our
development. Even after nix upstream process we will probably keep a
copy on github with few additional patches that may not fit on e.g.
WebKit2 or need to be landed a bit faster on our tree due to some
customer needs.

I didn't talk with other team members about it, but IMO it's not a big
deal to break it on these kind of WebCore changes that affect all
ports, I'm saying this because the chance of having these patches
breaking other ports as well is considerable too, besides if the
change get announced on this ML before get landed we'll have enough
time to adapt to it.

> - Anders
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Can we disable "control reaches end of non-void function" warning on Qt?

2013-09-13 Thread Darin Adler 
On Sep 13, 2013, at 10:36 AM, Oliver Hunt  wrote:

> I guess there's no nice automate-able to handle everything magically.

We could require either default: or DEFAULT_NOT_REACHED at ends of switches. To 
use DEFAULT_NOT_REACHED after a switch the cases need to use return, not break. 
I’m sure we can teach the style checker to check this if we decide it’s the 
rule.

-- Darin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Can we disable "control reaches end of non-void function" warning on Qt?

2013-09-13 Thread Oliver Hunt 
Hurk :-/

I guess there's no nice automate-able to handle everything magically.

Still it would probably be good to replace the default:ASSERT_NOT_REACHED() 
cases at least.

--Oliver

On Sep 13, 2013, at 10:33 AM, Darin Adler  wrote:

> On Sep 13, 2013, at 10:31 AM, Oliver Hunt  wrote:
> 
>> We may want to hunt through the other cases of default: ASSERT_NOT_REACHED() 
>> and clobber those with RELEASE_ASSERT_NOT_REACHED() as well.
>> 
>> I wonder if it would be easier to have DEFAULT_NOT_REACHED() and 
>> DEFAULT_OKAY() macros, and convince the style bot to require ether a 
>> default: block or one of these two macros at the end of every switch?
> 
> 
> Maybe.
> 
> The advantage of doing the not-reached assertion after the switch is that we 
> get the compile time warning if we don’t enumerate one of the enum values. 
> Having a default case turns that warning off.
> 
> -- Darin

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

Re: [webkit-dev] Can we disable "control reaches end of non-void function" warning on Qt?

2013-09-13 Thread Darin Adler 
On Sep 13, 2013, at 10:31 AM, Oliver Hunt  wrote:

> We may want to hunt through the other cases of default: ASSERT_NOT_REACHED() 
> and clobber those with RELEASE_ASSERT_NOT_REACHED() as well.
> 
> I wonder if it would be easier to have DEFAULT_NOT_REACHED() and 
> DEFAULT_OKAY() macros, and convince the style bot to require ether a default: 
> block or one of these two macros at the end of every switch?


Maybe.

The advantage of doing the not-reached assertion after the switch is that we 
get the compile time warning if we don’t enumerate one of the enum values. 
Having a default case turns that warning off.

-- Darin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Can we disable "control reaches end of non-void function" warning on Qt?

2013-09-13 Thread Oliver Hunt 
We may want to hunt through the other cases of default: ASSERT_NOT_REACHED() 
and clobber those with RELEASE_ASSERT_NOT_REACHED() as well.

I wonder if it would be easier to have DEFAULT_NOT_REACHED() and DEFAULT_OKAY() 
macros, and convince the style bot to require ether a default: block or one of 
these two macros at the end of every switch?

--Oliver

On Sep 13, 2013, at 10:29 AM, Darin Adler  wrote:

> On Sep 13, 2013, at 10:28 AM, Alexey Proskuryakov  wrote:
> 
>> 13 сент. 2013 г., в 10:13, Darin Adler  написал(а):
>> 
>>> Since there’s no runtime guarantee that the enum will have a valid value, I 
>>> think there needs to be a return statement outside the switch, even if we 
>>> have ASSERT_NOT_REACHED before it.
>> 
>> Should it be a RELEASE_ASSERT? If we have a bad value in an enum, it's 
>> likely a memory smasher, so it's best to crash before it's exploited.
> 
> Sure, that’d be OK with me.
> 
> -- Darin
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

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

Re: [webkit-dev] TimerWindowWndProc and dangling page instances

2013-09-13 Thread Brent Fulgham 
Hi Vincent and Mark:

On Sep 13, 2013, at 1:06 AM, Salisbury, Mark  wrote:

> Vincent,
>  
> Maybe some tips I’ve learned could be of help to you or others:
> ·Calling DestroyWindow will cause WebView::close() to be called (when 
> WM_DESTROY is received), but it does not cause WebView’s destructor to be 
> called, that doesn’t happen until the RCW holding the last COM reference is 
> destroyed and the COM ref count goes to 0.  This happens on the GC thread 
> (.NET internals), and deleting core webkit objects from a thread besides the 
> main thread can lead to undefined behavior.  I’d see crashes from concurrent 
> javascript GCs.  I fixed this by marshaling the delete call back to the main 
> thread (in every single COM exposed class).

I’m not sure this is limited to WebKit, or .NET.  I think destroying any GDI or 
other “User Interface” content outside of the main thread causes bad things to 
happen. I’ve seen this with MFC and base WinAPI programs as well.

To be fair, Mac OS has a number of similar constraints on how UI elements are 
handled, resulting in a bunch of infrastructure to allow things to be spun off 
for later processing on the main thread.

> ·WebView’s destructor calls DestroyWindow() on a tool tip window 
> which may or may not have been destroyed (at least on WinCE).  When embedding 
> in a .NET application, there can be a decent gap between the time the 
> WebView’s window is destroyed and the destructor is called.  It’s possible 
> that in the instances when Windows destroyed the tool tip window (because it 
> is a child of the webview window) that the tool tip handle is assigned to 
> another window by the time WebView’s destructor is called.  You can guess 
> what happens then when WebView’s destructor deletes the tool tip window.  
> Windows in the system disappear – sometimes causing a crash.  The only fix I 
> could figure out what to check to see if the window is still a tool tip 
> window before deleting it.

This sounds like a bug. Could you please file one and add me to the CC list on 
it?

> I don’t know if anyone wants to see a patch land for either of these 
> problems, they’re confined to embedded WebKit on Windows under .NET…

I’d love to see the patches.  You are obviously not the only person to suffer 
from these issues, and it would be great to at least document the issue and how 
to work around it.

Thanks!

-Brent


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

Re: [webkit-dev] Announcing new port: Nix

2013-09-13 Thread Geoffrey Garen 
>> Thank you for this list. I started reading through it, but I noticed a high 
>> percentage of patches that were port-specific build fixes or port-specific 
>> features like support for legacy ARM chips. For example, “...on ARM 
>> traditional” (). Those patches are 
>> cost to core WebKit development, not benefit. 
> I don't want to mis-interpret your statement here.  Can you clarify what you 
> mean by "Those
> patches are cost to core WebKit development, not benefit.”

Consider  — a patch for legacy 
CPUs that don’t have floating point processing. That patch took three months of 
reviews, spanning three different core JavaScript hackers, to get right. And 
after that, it was still wrong, and it required three follow-up fixes.

That’s cost.

Geoff___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Can we disable "control reaches end of non-void function" warning on Qt?

2013-09-13 Thread Konstantin Tokarev 

13.09.2013, 06:54, "Ryosuke Niwa" :
> Hm... it appears that I was wrong about this.  It appears that this is the 
> intended feature in gcc:http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28236
>
> Regardless, I don't think we should have this warning enabled. We're 
> generating some unused code everywhere :(

Actually, this warning (when not false positive) is quite dangerous - program 
is likely to crash if returned value is used when return-less branch was 
executed inside called function.

-- 
Regards,
Konstantin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Changes in QtWebKit development

2013-09-13 Thread Albisser Zeno 
Hello WebKittens

As many of you have probably noticed already, we have recently been focusing on 
a project called Qt WebEngine. Our WebKit efforts have therefore been reduced 
significantly over the past weeks.
While we will keep shipping QtWebKit with Qt for the foreseeable future, we 
want to concentrate our efforts on Qt WebEngine.
Therefore we are planning some changes to our development setup. In particular 
we are planning to remove our QtWebKit/Mac and QtWebKit/Windows builds from 
WebKit trunk. We will keep maintaining these platforms in a separate branch 
through the Qt project’s gerrit infrastructure.
This essentially means our presence in trunk will be reduced to QtWebKit/Linux.

We are planning to gradually implement the required changes within the next 
month.
If this proves to bring significant issues for some development, please do let 
us know and we can sort out a way to work together on a phase-out process.

The Digia QtWebKit Team.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Announcing new port: Nix

2013-09-13 Thread Thomas Fletcher 



Geoffrey Garen wrote:

Sure. We at University of Szeged who work on WebKitNix from this year
contributed many fixes to various part of WebKit: JavaScriptCore,
WebCore, Tools, …


Thank you for this list. I started reading through it, but I noticed a high 
percentage of patches that were port-specific build fixes or port-specific features 
like support for legacy ARM chips. For example, “...on ARM traditional” 
(). Those patches are cost to core 
WebKit development, not benefit.
I don't want to mis-interpret your statement here.  Can you clarify what 
you mean by "Those

patches are cost to core WebKit development, not benefit."

Thanks,
 Thomas
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] TimerWindowWndProc and dangling page instances

2013-09-13 Thread Van Den Berghe, Vincent 
Hello Mark,

Thank you for your tips. I am painfully aware of #1 and have compensated for it 
in much the same way you have. Tip #2 doesn't really apply to my scenario.
I'm embedding the Wincairo build of WebKit to generate PDF files from web pages 
in an ASP.NET application. Webkit isn't really designed for such a scenario but 
with some careful patching, a solution can be constructed which is "reasonably 
reliable".   However, these patches touch on WebKit's fundamental design 
decisions and I'm reluctant to submit them without first some validation of 
someone who knows the code better.   Some are more hacks than patches.
So I became a member of the webkit-dev list and submitted the result of my last 
frustrating bug hunt to see what happens. And it looks like it's not totally 
worthless.  As an added bonus, I can show it to my manager to explain why I was 
doing these last few days and why I was in such a foul disposition. Yay!

If people are interested, I'll post the rest of my experiences here, with the 
solutions I came up with. My employer's needs have priority, however.


Vincent

From: Salisbury, Mark [mailto:mark.salisb...@hp.com]
Sent: Friday, September 13, 2013 10:07 AM
To: Van Den Berghe, Vincent; webkit-dev@lists.webkit.org
Subject: RE: TimerWindowWndProc and dangling page instances

Vincent,

I've also embedded WebKit in a .NET application, and I've seen similar issues - 
not exactly what you're seeing though.

Maybe some tips I've learned could be of help to you or others:

* Calling DestroyWindow will cause WebView::close() to be called (when 
WM_DESTROY is received), but it does not cause WebView's destructor to be 
called, that doesn't happen until the RCW holding the last COM reference is 
destroyed and the COM ref count goes to 0.  This happens on the GC thread (.NET 
internals), and deleting core webkit objects from a thread besides the main 
thread can lead to undefined behavior.  I'd see crashes from concurrent 
javascript GCs.  I fixed this by marshaling the delete call back to the main 
thread (in every single COM exposed class).

* WebView's destructor calls DestroyWindow() on a tool tip window which 
may or may not have been destroyed (at least on WinCE).  When embedding in a 
.NET application, there can be a decent gap between the time the WebView's 
window is destroyed and the destructor is called.  It's possible that in the 
instances when Windows destroyed the tool tip window (because it is a child of 
the webview window) that the tool tip handle is assigned to another window by 
the time WebView's destructor is called.  You can guess what happens then when 
WebView's destructor deletes the tool tip window.  Windows in the system 
disappear - sometimes causing a crash.  The only fix I could figure out what to 
check to see if the window is still a tool tip window before deleting it.

I don't know if anyone wants to see a patch land for either of these problems, 
they're confined to embedded WebKit on Windows under .NET...

Mark

From: 
webkit-dev-boun...@lists.webkit.org 
[mailto:webkit-dev-boun...@lists.webkit.org] On Behalf Of Van Den Berghe, 
Vincent
Sent: Friday, September 13, 2013 1:43 AM
To: webkit-dev@lists.webkit.org
Subject: [webkit-dev] TimerWindowWndProc and dangling page instances

Hello,

Background
---
I'm currently embedding WebKit in a .NET application, which required me to 
solve a whole set of issues that are not relevant here. However, I've stumbled 
upon a scenario which I suspect is *really* problematic (but I can be wrong). 
Before patching anything, I'd like to submit this to greater minds for 
validation. The version of WebKit to which this applies is irrelevant: any 
recent version will do.

Problem
--
When I'm finish with a WebView instance and before I'm releasing the COM 
object, I close it by doing a

DestroyWindow(m_viewWindow)

...where m_viewWindow is WebView's view window. Note that calling 
WebView::close() would work just as well.
This triggers a sequence of events that ultimately causes the destructor of the 
page to be called:

Page::~Page()

This works well, but when stress testing this will crash the WebKit.DLL with 
the following stack trace:

WebKit.dll!WebCore::setImageLoadingSettings(WebCore::Page * 
page)  Line 57 + 0x3 bytes  C++
   
WebKit.dll!WebCore::Settings::imageLoadingSettingsTimerFired(WebCore::Timer
 * __formal)  Line 363 + 0x8 bytes C++
   
WebKit.dll!WebCore::Timer::fired()
  Line 114 + 0xb bytes C++
   WebKit.dll!WebCore::ThreadTimers::sharedTimerFiredInternal()  
Line 132   C++
   WebKit.dll!WebCore::TimerWindowWndProc(HWND__ * hWnd, unsigned 
int message, unsigned int wParam, long lParam)  Line 111  C++

Depending on the managed environment (details are irrelevant for this 
discussion), the crash happens either imme

Re: [webkit-dev] TimerWindowWndProc and dangling page instances

2013-09-13 Thread Salisbury, Mark 
Vincent,

I've also embedded WebKit in a .NET application, and I've seen similar issues - 
not exactly what you're seeing though.

Maybe some tips I've learned could be of help to you or others:

*Calling DestroyWindow will cause WebView::close() to be called (when 
WM_DESTROY is received), but it does not cause WebView's destructor to be 
called, that doesn't happen until the RCW holding the last COM reference is 
destroyed and the COM ref count goes to 0.  This happens on the GC thread (.NET 
internals), and deleting core webkit objects from a thread besides the main 
thread can lead to undefined behavior.  I'd see crashes from concurrent 
javascript GCs.  I fixed this by marshaling the delete call back to the main 
thread (in every single COM exposed class).

*WebView's destructor calls DestroyWindow() on a tool tip window which 
may or may not have been destroyed (at least on WinCE).  When embedding in a 
.NET application, there can be a decent gap between the time the WebView's 
window is destroyed and the destructor is called.  It's possible that in the 
instances when Windows destroyed the tool tip window (because it is a child of 
the webview window) that the tool tip handle is assigned to another window by 
the time WebView's destructor is called.  You can guess what happens then when 
WebView's destructor deletes the tool tip window.  Windows in the system 
disappear - sometimes causing a crash.  The only fix I could figure out what to 
check to see if the window is still a tool tip window before deleting it.

I don't know if anyone wants to see a patch land for either of these problems, 
they're confined to embedded WebKit on Windows under .NET...

Mark

From: webkit-dev-boun...@lists.webkit.org 
[mailto:webkit-dev-boun...@lists.webkit.org] On Behalf Of Van Den Berghe, 
Vincent
Sent: Friday, September 13, 2013 1:43 AM
To: webkit-dev@lists.webkit.org
Subject: [webkit-dev] TimerWindowWndProc and dangling page instances

Hello,

Background
---
I'm currently embedding WebKit in a .NET application, which required me to 
solve a whole set of issues that are not relevant here. However, I've stumbled 
upon a scenario which I suspect is *really* problematic (but I can be wrong). 
Before patching anything, I'd like to submit this to greater minds for 
validation. The version of WebKit to which this applies is irrelevant: any 
recent version will do.

Problem
--
When I'm finish with a WebView instance and before I'm releasing the COM 
object, I close it by doing a

DestroyWindow(m_viewWindow)

...where m_viewWindow is WebView's view window. Note that calling 
WebView::close() would work just as well.
This triggers a sequence of events that ultimately causes the destructor of the 
page to be called:

Page::~Page()

This works well, but when stress testing this will crash the WebKit.DLL with 
the following stack trace:

WebKit.dll!WebCore::setImageLoadingSettings(WebCore::Page * 
page)  Line 57 + 0x3 bytes  C++
   
WebKit.dll!WebCore::Settings::imageLoadingSettingsTimerFired(WebCore::Timer
 * __formal)  Line 363 + 0x8 bytes C++
   
WebKit.dll!WebCore::Timer::fired()
  Line 114 + 0xb bytes C++
   WebKit.dll!WebCore::ThreadTimers::sharedTimerFiredInternal()  
Line 132   C++
   WebKit.dll!WebCore::TimerWindowWndProc(HWND__ * hWnd, unsigned 
int message, unsigned int wParam, long lParam)  Line 111  C++

Depending on the managed environment (details are irrelevant for this 
discussion), the crash happens either immediately or after a while. Because of 
the way I embed WebKit, this usually happens when the second (or third, 
forth...) instance is being created.
The visible cause of the crash is the call to

WebKit.dll!WebCore::setImageLoadingSettings(WebCore::Page * page)

... with a page instance for which its destructor has already been executed.

Primary Cause
-
I suspect the primary cause of a crash is the pending timer whose message is 
still in the message queue, that is executed just after the destruction of the 
page, but before any pending timers are killed. This causes a delayed execution 
of a function on a dangling page instance.
The problem doesn't occur when I don't call DestroyWindow or WebView::Close(), 
but this leads to unacceptable memory leaks.

Workaround
---
The minimal (but far from elegant) workaround is to add a method to 
WebCore::Settings:

void clearPage()
{
  m_page = 0;
}


And call this method as the first line of Page's destructor:

Page::~Page()
{
m_settings->clearPage();
m_mainFrame->setView(0);
...


...and finally add a if(page) guard in setImageLoadingSettings like so:

static void setImageLoadingSettings(Page* page)
{
if(page)
for (Frame* frame = &page->mainFrame(); frame; frame = 
frame->tree().traverseNext()) {

frame->document()->cachedResourceLoader()->setImagesEnabled

Re: [webkit-dev] TimerWindowWndProc and dangling page instances

2013-09-13 Thread Darin Adler 
On Sep 13, 2013, at 12:42 AM, "Van Den Berghe, Vincent" 
 wrote:

> And call this method as the first line of Page’s destructor:
>  
> Page::~Page()
> {
> m_settings->clearPage();
> m_mainFrame->setView(0);

You’ve got it exactly right. This issue is not at all specific to Windows.

Page does need to disconnect itself from Settings. Normally we’d name this 
something other than clearPage, like detachFromPage.

And we’d want to clear out m_page and also call 
m_setImageLoadingSettingsTimer.stop() in that function. We also need to check 
m_page for null in various other functions since there’s no guarantee that 
callers won’t call those other functions after the Page has gone away.

Please file a bug and contribute a patch if you like. Put me on the cc list of 
the bug, please.

-- Darin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] TimerWindowWndProc and dangling page instances

2013-09-13 Thread Van Den Berghe, Vincent 
Hello,

Background
---
I'm currently embedding WebKit in a .NET application, which required me to 
solve a whole set of issues that are not relevant here. However, I've stumbled 
upon a scenario which I suspect is *really* problematic (but I can be wrong). 
Before patching anything, I'd like to submit this to greater minds for 
validation. The version of WebKit to which this applies is irrelevant: any 
recent version will do.

Problem
--
When I'm finish with a WebView instance and before I'm releasing the COM 
object, I close it by doing a

DestroyWindow(m_viewWindow)

...where m_viewWindow is WebView's view window. Note that calling 
WebView::close() would work just as well.
This triggers a sequence of events that ultimately causes the destructor of the 
page to be called:

Page::~Page()

This works well, but when stress testing this will crash the WebKit.DLL with 
the following stack trace:

WebKit.dll!WebCore::setImageLoadingSettings(WebCore::Page * 
page)  Line 57 + 0x3 bytes  C++
   
WebKit.dll!WebCore::Settings::imageLoadingSettingsTimerFired(WebCore::Timer
 * __formal)  Line 363 + 0x8 bytes C++
   
WebKit.dll!WebCore::Timer::fired()
  Line 114 + 0xb bytes C++
   WebKit.dll!WebCore::ThreadTimers::sharedTimerFiredInternal()  
Line 132   C++
   WebKit.dll!WebCore::TimerWindowWndProc(HWND__ * hWnd, unsigned 
int message, unsigned int wParam, long lParam)  Line 111  C++

Depending on the managed environment (details are irrelevant for this 
discussion), the crash happens either immediately or after a while. Because of 
the way I embed WebKit, this usually happens when the second (or third, 
forth...) instance is being created.
The visible cause of the crash is the call to

WebKit.dll!WebCore::setImageLoadingSettings(WebCore::Page * page)

... with a page instance for which its destructor has already been executed.

Primary Cause
-
I suspect the primary cause of a crash is the pending timer whose message is 
still in the message queue, that is executed just after the destruction of the 
page, but before any pending timers are killed. This causes a delayed execution 
of a function on a dangling page instance.
The problem doesn't occur when I don't call DestroyWindow or WebView::Close(), 
but this leads to unacceptable memory leaks.

Workaround
---
The minimal (but far from elegant) workaround is to add a method to 
WebCore::Settings:

void clearPage()
{
  m_page = 0;
}


And call this method as the first line of Page's destructor:

Page::~Page()
{
m_settings->clearPage();
m_mainFrame->setView(0);
...


...and finally add a if(page) guard in setImageLoadingSettings like so:

static void setImageLoadingSettings(Page* page)
{
if(page)
for (Frame* frame = &page->mainFrame(); frame; frame = 
frame->tree().traverseNext()) {

frame->document()->cachedResourceLoader()->setImagesEnabled(page->settings().areImagesEnabled());

frame->document()->cachedResourceLoader()->setAutoLoadImages(page->settings().loadsImagesAutomatically());
}
}

This doesn't remedy the delayed execution of the timer, but solves the problem 
by setting the deleted instance to NULL and making sure it's not used in the 
delayed call.

The questions of course are:

-  Is this behavior by design?

-  If it is, is there a way to clean up WebKit instances without 
causing this crashing behavior, and if so which one?

-  If it isn't, is there a more elegant workaround than the one 
outlined here?

Thanks for any feedback,

Vincent


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