Re: [webkit-dev] Top Crasher: Shadow DOM and Editing Collide Again

[Ryosuke Niwa]

After reading Dimitri's analysis and talking to him on IRC, I'm convinced
that we don't have to call setInnerTextValue in updateFromElement.  I've
uploaded a work-in-progress patch to the bug
66241 that
realizes this idea.

- Ryosuke

On Mon, Aug 29, 2011 at 2:34 PM, Ryosuke Niwa  wrote:

> On Mon, Aug 29, 2011 at 1:46 PM, Dimitri Glazkov wrote:
>>
>> I just realized what's going on here. The lifetime of the shadow DOM
>> _used_ to be tied to the HTMLTextAreaElement's RenderObjects. Kent-san
>> changed that and now the shadow DOM's lifecycle matches that of the
>> rest of the DOM.
>
>
> Yes!
>
>
>> However, the update cycle still assumes that the
>> shadow DOM lives on the RenderObjects, and does this really freaky
>> thing with shuttling updated value via an extra style recalc (see
>>
>> http://codesearch.google.com/codesearch#OAMlx_jo-ck/src/third_party/WebKit/Source/WebCore/html/HTMLTextAreaElement.cpp&l=349
>> ).
>> We should just fix that and move updating code out of
>> updateFromElement.
>>
>
> Right.  I think making updateFromElement not call setInnerTextValue will
> fix this bug for good.
>
> - Ryosuke
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] lots of red in the tree.

[David Levin]

On Tue, Aug 30, 2011 at 10:55 AM, Jarred Nicholls  wrote:

> On Tue, Aug 30, 2011 at 1:52 PM, David Levin  wrote:
>
>> It means that I'm much more likely to cause regressions because I miss new
>> test failures caused by my changes among the 12 to 62 failures
>> already occurring on the OS X bots.1
>>
>
> Yeah it was wigging me out this morning.
>
>
>>
>> I think there are a few solutions to the current situation:
>>
>> 1. Live with it. All of the red and green reminds us of the festive winter
>> holidays.
>>
>
> presents!
>
>
>> Downside: More regressions get in as nobody notices them much even if
>> they try to be careful.
>> Upside: Requires no more extra work, so it is quick to do!
>>
>> 2. Get folks working on every red test.
>>
>
> Was thinkin' about diving head first into this.
>
>
>> Downside: May not be able to get folks to drop what they are doing and
>> work on them.
>> Upside: More stable code, easier to work with, etc.
>>
>> 3. Add them to skipped and file bugs.
>>
>
> Good first step.  Some of the tests are flaky though - I'll get different
> results on subsequent runs.
>

I'm ok with letting flaky ones run for now as they are re-run by the harness
and won't hide new failures. I would like to take care of those that are
always failing.

I'm in favor of this one -- Adding them to skipped and filing bugs.

dave



>
>
>> Downside: Not having the tree red may lower the urgency and having
>> them in skipped list may mean that folks just ignore them.
>> Upside: We'll catch regressions more quickly and perhaps stop the
>> current decent which it seems like we've been proceeding on.
>>
>> 4. Your idea!
>>
>> What do other folks think?
>>
>> Dave
>>
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>>
>
>
> --
> 
>
> *Sencha*
> Jarred Nicholls, Senior Software Architect
> @jarrednicholls
> 
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] WTF StackBounds not compatible with Windows fiber threads & custom fiber or thread stack size

[Gavin Barraclough]

I had a partially working solution to this using the deallocation stack member 
of the Win32 Thread Information Block, see 
https://bugs.webkit.org/show_bug.cgi?id=26276 & 
http://en.wikipedia.org/wiki/Win32_Thread_Information_Block – but I didn't 
manage to get this working consistently.  Perhaps a Windows expert may be able 
to build on this.

Bug #26276 would be a great place to be having this discussion, so that 
anything useful is recorded.

cheers,
G.


On Aug 29, 2011, at 9:08 PM, Jacques Quidu wrote:

> Hello,
> 
> WTF current implementation of StackBounds is not quite compatible with 
> Windows fiber threads and/or custom stack sizes:
> we have successfully implemented support for Windows fiber threads in 
> StackBounds & fixed some 64 issues but we are still stuck on how to determine 
> thread or fiber allocated stack size...
> 
> From the fiber or thread context, i can only get the stack base & stack 
> current pointer but not the allocated stack size: any idea on how to get it 
> assuming that i cannot get stack size from the executable stack size because 
> our main app might use cooperative fiber threads with variable stack size, 
> along with preemptive threads created from WebKit ?
> 
> For now the only workaround i think about is to pass the fiber stack size as 
> fiber data while creating the fiber in our main app & get it in StackBounds 
> with GetFiberData() using a custom define to filter with our app impl: but it 
> means adding code specific to our app in JavacriptCore/WTF which i would like 
> to avoid if it is possible.
> 
> Kind regards, 
> 
> Jacques Quidu
> Graphics Software Engineer
> E-Mail: jqu...@hotmail.fr
> 
> ___
> 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] lots of red in the tree.

[Jarred Nicholls]

On Tue, Aug 30, 2011 at 1:52 PM, David Levin  wrote:

> It means that I'm much more likely to cause regressions because I miss new
> test failures caused by my changes among the 12 to 62 failures
> already occurring on the OS X bots.1
>

Yeah it was wigging me out this morning.


>
> I think there are a few solutions to the current situation:
>
> 1. Live with it. All of the red and green reminds us of the festive winter
> holidays.
>

presents!


> Downside: More regressions get in as nobody notices them much even if
> they try to be careful.
> Upside: Requires no more extra work, so it is quick to do!
>
> 2. Get folks working on every red test.
>

Was thinkin' about diving head first into this.


> Downside: May not be able to get folks to drop what they are doing and
> work on them.
> Upside: More stable code, easier to work with, etc.
>
> 3. Add them to skipped and file bugs.
>

Good first step.  Some of the tests are flaky though - I'll get different
results on subsequent runs.


> Downside: Not having the tree red may lower the urgency and having them
> in skipped list may mean that folks just ignore them.
> Upside: We'll catch regressions more quickly and perhaps stop the
> current decent which it seems like we've been proceeding on.
>
> 4. Your idea!
>
> What do other folks think?
>
> Dave
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>


-- 


*Sencha*
Jarred Nicholls, Senior Software Architect
@jarrednicholls

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

[webkit-dev] lots of red in the tree.

[David Levin]

It means that I'm much more likely to cause regressions because I miss new
test failures caused by my changes among the 12 to 62 failures
already occurring on the OS X bots.

I think there are a few solutions to the current situation:

1. Live with it. All of the red and green reminds us of the festive winter
holidays.
Downside: More regressions get in as nobody notices them much even if
they try to be careful.
Upside: Requires no more extra work, so it is quick to do!

2. Get folks working on every red test.
Downside: May not be able to get folks to drop what they are doing and
work on them.
Upside: More stable code, easier to work with, etc.

3. Add them to skipped and file bugs.
Downside: Not having the tree red may lower the urgency and having them
in skipped list may mean that folks just ignore them.
Upside: We'll catch regressions more quickly and perhaps stop the
current decent which it seems like we've been proceeding on.

4. Your idea!

What do other folks think?

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

Re: [webkit-dev] WTF StackBounds not compatible with Windows fiber threads & custom fiber or thread stack size

[Darin Adler]

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

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