Re: [webkit-dev] Sunsetting committership and reviewership

[Dmitry Titov]

How about creating an 'emeritus reviewer' status (no r+ power) and let
people *voluntarily* move themselves to this status? I bet a lot of
'inactive reviewers' would do that, since everybody understands the issue
of getting out of sync with current code base. It may have different vibe
though than figuring some automatic time-based enforcement system...

As an added bonus, this gives such people a good way to avoid being asked
to "review a patch for a colleague" while keeping some ties with the
project...


On Mon, Apr 8, 2013 at 3:34 PM, Maciej Stachowiak  wrote:

>
> On Apr 7, 2013, at 5:53 PM, Benjamin Poulain  wrote:
>
> On Sun, Apr 7, 2013 at 5:49 PM, Timothy Hatcher  wrote:
>
>> I think 6 months is fine for deactivating SVN accounts. And a full revoke
>> of reviewer status after 2 years of no activity sounds reasonable to me. We
>> could make it easier to get reviewer status again after a 2 year sunset if
>> the person becomes active again and shows good judgment still.
>>
>
> +1 to this.
>
> I think 2 years to revoke reviewer rights is too long. All the drive-by
> reviews that have caused problems were from reviewers that were inactive
> for less than 2 years. Nevertheless, 2 years is better than the current
> situation so it is a good start.
>
>
> We sometimes get low-quality drive-by reviews even from people who are
> active at the time. I feel like that's not the right basis for the time
> cutoff. If we do have a sunset period, we should think about it in terms of
> how long it takes to be so out of touch with the current state of the
> project that there's little chance you can give a useful review.
>
> Regards,
> Maciej
>
>
>
> ___
> 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] "Magic Iframe" removal proposed

[Dmitry Titov]

On Mon, Mar 19, 2012 at 6:09 PM, Geoffrey Garen  wrote:

> Hi Dmitry.
>
> Two thoughts on this:
>
> (1) If we remove this feature, are Chromium/GMail developers going to
> re-request the other "shared document" features that this feature subsumed?
> Or are y'all now convinced that "shared document" is, in general, not a
> good idea?
>

On a contrary, 'shared application state' could be a good idea, however
this particular way to implement it unfortunately is very difficult to get
right. There are no Google applications that use this feature currently,
and there is understanding of the costs involved. There is a possibility
that some other idea can both address the potential need and be reliably
implementable at the same time. Workers, for example, are a good case of
limiting the surface that also limits design/maintenance costs. Perhaps
something similar can be proposed for shared state. However, there was a
discussion in Chromium and it appears that ongoing design and maintenance
of magic iframe is not worth the benefit the feature provides for the
applications.


>
> The reason I ask this is that, given your description, I see some problems
> with the shared iframe feature, but I still think it's much better
> than previously proposed alternatives.
>
> (2) I think you should share your data with the relevant standards bodies,
> and suggest a change to the HTML5 spec, if you haven't done so already. I
> wouldn't want to remove this feature just to add it back later for the sake
> of spec compliance.
>

Good suggestion, will do. Just wanted to give WebKit community a heads-up...


>
> Thanks,
> Geoff
>
> On Mar 19, 2012, at 5:51 PM, Dmitry Titov wrote:
>
> Hi,
>
> There is a patch posted <https://bugs.webkit.org/show_bug.cgi?id=81590>for 
> removal of the 'magic iframe' feature. This is the ability to move
> 'live' iframe from one page to another w/o unloading it.
> If you have interest or ideas about this feature, please reply.
>
> HISTORY
> This feature was added 2 years ago (bug 
> here<https://bugs.webkit.org/show_bug.cgi?id=32848>).
> It was intended as a shared app context for complex apps that span several
> pages. In case when random set of pages is closed, the surviving iframe
> could be passed between remaining pages and serve as 'app state'.
> This behavior is somewhat described in HTML5 
> spec<http://www.whatwg.org/specs/web-apps/current-work/multipage/the-iframe-element.html#the-iframe-element>:
> "Removing an iframe from a Document does not cause its browsing context to
> be discarded. Indeed, an iframe's browsing context can survive its original
> parent Document if its iframe is moved to another Document."
> All non-WebKit browsers don't have this and always unload the iframe when
> it is disconnected form the document.
>
> PROBLEMS
> We did have quite a few issues with this mechanism. The root of the
> problem seems to be that traditionally, multiple 'permissions' and 'live
> objects' are associated with a top-level page, or a top frame of some kind,
> instead of being associated with each Frame. Even HTML specifications often
> formulate the scope of things like permissions in terms of a page - for
> example, geo permissions are computed based on the origin of the page. When
> an iframe is transferred from one page to another, it may enter a different
> set of permissions while already performing operations authorized
> before. Association with the top-level page is also used to determine which
> one should show modal UI for HTTP Auth, per-origin permissions, or
> certificate issues for example.
> As a result, we had quite a few bugs popping up (and fixed).
>
> WHY REMOVE
> This is somewhat obscure feature of the platform. Only a few apps that we
> knew used the feature. Most developers, both app and webkit kind, don't
> even know about it. When new mechanisms/APIs are implemented, a lot of
> objects get associated with Page (WebView) level and they are almost
> 'automatically' broken in case of live iframe transfer because once old
> page closes, it destroys the objects with lifetimes scoped by it. This
> makes it somewhat dangerous and difficult to support. The benefits that it
> gives to the big multi-page applications do not seem to warrant the actual
> complexity of maintaining this feature.
> Other browsers never implemented the feature, siting difficult design due
> to various thorny security issues as well.
>
> This is potentially a compatibility issue for sites that use
> document.adoptNode(iframe) to ensure live transfer of an iframe from one
> page to another.
> In the future

[webkit-dev] "Magic Iframe" removal proposed

[Dmitry Titov]

Hi,

There is a patch posted  for
removal of the 'magic iframe' feature. This is the ability to move 'live'
iframe from one page to another w/o unloading it.
If you have interest or ideas about this feature, please reply.

HISTORY
This feature was added 2 years ago (bug
here).
It was intended as a shared app context for complex apps that span several
pages. In case when random set of pages is closed, the surviving iframe
could be passed between remaining pages and serve as 'app state'.
This behavior is somewhat described in HTML5
spec:
"Removing an iframe from a Document does not cause its browsing context to
be discarded. Indeed, an iframe's browsing context can survive its original
parent Document if its iframe is moved to another Document."
All non-WebKit browsers don't have this and always unload the iframe when
it is disconnected form the document.

PROBLEMS
We did have quite a few issues with this mechanism. The root of the problem
seems to be that traditionally, multiple 'permissions' and 'live objects'
are associated with a top-level page, or a top frame of some kind, instead
of being associated with each Frame. Even HTML specifications often
formulate the scope of things like permissions in terms of a page - for
example, geo permissions are computed based on the origin of the page. When
an iframe is transferred from one page to another, it may enter a different
set of permissions while already performing operations authorized
before. Association with the top-level page is also used to determine which
one should show modal UI for HTTP Auth, per-origin permissions, or
certificate issues for example.
As a result, we had quite a few bugs popping up (and fixed).

WHY REMOVE
This is somewhat obscure feature of the platform. Only a few apps that we
knew used the feature. Most developers, both app and webkit kind, don't
even know about it. When new mechanisms/APIs are implemented, a lot of
objects get associated with Page (WebView) level and they are almost
'automatically' broken in case of live iframe transfer because once old
page closes, it destroys the objects with lifetimes scoped by it. This
makes it somewhat dangerous and difficult to support. The benefits that it
gives to the big multi-page applications do not seem to warrant the actual
complexity of maintaining this feature.
Other browsers never implemented the feature, siting difficult design due
to various thorny security issues as well.

This is potentially a compatibility issue for sites that use
document.adoptNode(iframe) to ensure live transfer of an iframe from one
page to another.
In the future, if there will be sufficient need, it is possible to design a
'shared module' feature that would explicitly deal with various
security/lifetime boundaries.

Please let us know what you think.

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

Re: [webkit-dev] Git/SVN is slow

[Dmitry Titov]

over here in Seattle I am getting 5KiB/s all day, no way to get an updated
checkout today :-(

On Thu, Mar 15, 2012 at 10:54 AM, Jarred Nicholls  wrote:

> Well I was just about to follow up that from the east coast on Comcast
> bbone, I'm pulling at acceptable rates from git.webkit.org, ~700KiB/s.
>  That's about as fast as it's always been.  Same goes for
> nightly.webkit.org.
>
> There's a number of possible issues that would result in slow response
> times and slow downloads.  E.g., it could be sheer packet loss between
> carrier backbones and not necessarily tapped bandwidth.
>
>
> On Thu, Mar 15, 2012 at 1:45 PM, Ryosuke Niwa  wrote:
>
>> I don't really think checking the latency is interesting. What's killing
>> us is bandwidth. As far as I tested yesterday, the ping at my work (Google
>> SF office) gives me a reasonable time as well.
>>
>> There's something that's killing our bandwidth. Does anyone know some
>> tools to investigate this?
>>
>> - Ryosuke
>>
>>
>> On Thu, Mar 15, 2012 at 10:40 AM, Jarred Nicholls wrote:
>>
>>> Ditto, @ ae-11-70 attempting to get to ae-21-60 the trace dies.  Pings
>>> to svn.webkit.org succeed in acceptable times however, for me.  Perhaps
>>> the hops following ae-11-70 and ae-21-60 simple aren't able to reply with
>>> proper ICMP packets; no real conclusion to based on that info alone, but
>>> maybe worth passing off to the provider and/or directly to Level3.
>>>
>>> Jarred
>>>
>>>
>>> On Thu, Mar 15, 2012 at 1:22 PM, Levi Weintraub wrote:
>>>
 Likewise, I lose everything past *.car1.sanjose2.level3.net. SVN
 updates are dog slow :(

  6  pr01-xe-8-2-0.sjc07.net.google.com (72.14.218.230)  4.306 ms
  4.966 ms *
  7  xe-11-1-0.edge2.sanjose3.level3.net (4.79.40.153)  20.116 ms
  3.031 ms  3.056 ms
  8  ae-31-90.car1.sanjose2.level3.net (4.69.152.203)  4.316 ms
 ae-11-70.car1.sanjose2.level3.net (4.69.152.75)  4.239 ms
 ae-21-60.car1.sanjose2.level3.net (4.69.152.11)  4.545 ms
  9  * * *
 10  * * *
 11  * * *


 On Thu, Mar 15, 2012 at 7:31 AM, Philip Rogers  wrote:

> Bill,
>
> I'm currently pulling from svn.webkit.org at what feels like 5kbps,
> and poor http://build.webkit.org/console hits the page refresh before
> it's even able to render to the bottom :(
>
> Below is a traceroute to webkit.org:
> traceroute to svn.webkit.org (17.254.20.241), 30 hops max, 60 byte
> packets
>   1  DD-WRT (192.168.2.1)  0.233 ms  0.297 ms  0.371 ms
>  2  10.1.10.1 (10.1.10.1)  2.446 ms  2.445 ms  2.518 ms
>  3  96.176.191.1 (96.176.191.1)  24.451 ms  25.398 ms  28.688 ms
>  4  xe-11-0-0-0-sur01.a2atlanta.ga.atlanta.comcast.net (68.85.91.177)
>  14.588 ms  15.541 ms  15.733 ms
>  5  xe-2-1-3-0-ar01.b0atlanta.ga.atlanta.comcast.net (68.86.106.57)
>  16.563 ms  16.929 ms  16.946 ms
>  6  pos-3-6-0-0-cr01.atlanta.ga.ibone.comcast.net (68.86.93.201)
>  17.967 ms pos-3-5-0-0-cr01.atlanta.ga.ibone.comcast.net(68.86.93.125)  
> 14.599 ms  11.428 ms
>  7  4.28.24.77 (4.28.24.77)  15.973 ms  17.858 ms  17.307 ms
>  8  vlan51.ebr1.Atlanta2.Level3.net (4.69.150.62)  19.688 ms
> vlan52.ebr2.Atlanta2.Level3.net (4.69.150.126)  14.891 ms
> vlan51.ebr1.Atlanta2.Level3.net (4.69.150.62)  15.116 ms
>  9  ae-73-73.ebr3.Atlanta2.Level3.net (4.69.148.253)  14.651 ms
> ae-63-63.ebr3.Atlanta2.Level3.net (4.69.148.241)  13.767 ms
> ae-73-73.ebr3.Atlanta2.Level3.net (4.69.148.253)  14.955 ms
> 10  ae-7-7.ebr3.Dallas1.Level3.net (4.69.134.21)  34.004 ms  36.807
> ms  34.950 ms
> 11  ae-3-3.ebr2.LosAngeles1.Level3.net (4.69.132.77)  66.601 ms
>  65.766 ms  66.692 ms
> 12  ae-6-6.ebr2.SanJose5.Level3.net (4.69.148.202)  78.577 ms  78.007
> ms  78.175 ms
> 13  ae-1-100.ebr1.SanJose5.Level3.net (4.69.148.109)  78.594 ms
>  78.520 ms ae-5-5.ebr4.SanJose1.Level3.net (4.69.148.142)  81.371 ms
> 14  ae-34-34.ebr2.SanJose1.Level3.net (4.69.153.33)  71.989 ms
> ae-5-5.ebr1.SanJose1.Level3.net (4.69.148.138)  77.341 ms
> ae-34-34.ebr2.SanJose1.Level3.net (4.69.153.33)  77.662 ms
> 15  ae-62-62.csw1.SanJose1.Level3.net (4.69.153.18)  80.375 ms
> ae-61-61.csw1.SanJose1.Level3.net (4.69.153.2)  87.895 ms
> ae-81-81.csw3.SanJose1.Level3.net (4.69.153.10)  77.137 ms
> 16  ae-31-90.car1.SanJose2.Level3.net (4.69.152.203)  77.660 ms
> ae-41-80.car1.SanJose2.Level3.net (4.69.152.139)  78.313 ms
> ae-21-60.car1.SanJose2.Level3.net (4.69.152.11)  77.746 ms
> 17  * * *
> 18  * * *
> 19  * * *
> 20  * * *
> 21  * * *
> 22  * * *
> 23  * * *
> 24  * * *
> 25  * * *
> 26  * * *
> 27  * * *
>  28  * * *
> 29  * * *
> 30  * * *
>
> Thanks for looking into this.
> Philip
>
> On Thu, Mar 15, 2012 at 10:23 AM, William Siegrist <
> wsiegr...@apple.com> wrote:
>
>> Our network provider did not find anything wro

Re: [webkit-dev] how to create a test that can perform actions while resources are still loading?

[Dmitry Titov]

It will work, but you need to add more to it, like this:

parent.reportLoading('start')");
echo("A bunch of text in the body");
}
sleep(2);
echo("parent.reportLoading('done')");
?>

The trick is to make the text big enough for various network components to
decide to stop accumulating bytes and send them to the receiver. 'flush()'
etc may only affect part of the pipeline. The example above runs a loop and
builds up enough text in the body. That makes using 'flush()' unnecessary as
well.

Also, I believe we have a bug in TextResourceDecoder::checkForHeadCharset,
it has incorrect condition for exit from the loop. This function tries to
find 'charset' in  section or in first 1024 bytes, whatever ends last.
Unfortunately, it checks for 1024 only on tag boundaries after first
non-head tag, so if you have a huge body with just text in it, the parser
will never receive a byte before . I'll fix this soon but for now
those  tags in the loop will do the trick.

Dmitry

On Thu, Oct 7, 2010 at 5:12 PM, Jenn Braithwaite (胡慧鋒) wrote:

> I need the inline script to be in the iframe content so that the test does
> not execute until the iframe has started loading (but has not completed).  I
> tried the php below, but the script doesn't execute until after the sleep. I
> don't know php.  Is my php wrong?  Or does DRT buffer the response until the
> entire response is complete?
>
>  header("Expires: Thu, 01 Dec 2003 16:00:00 GMT");
> header("Cache-Control: no-cache, no-store, must-revalidate");
> header("Pragma: no-cache");
> header("Content-Type: text/html; charset=utf-8");
> echo("parent.opener.test();");
> ob_flush();
> flush();
> sleep(10);
> ?>
>
> Thanks,
> Jenn
>
> On Thu, Oct 7, 2010 at 8:15 AM, Ojan Vafai  wrote:
>
>> On Wed, Oct 6, 2010 at 4:42 PM, Darin Adler  wrote:
>>
>>> On Oct 6, 2010, at 4:36 PM, Jenn Braithwaite (胡慧鋒) wrote:
>>>
>>> > I've also tried making this an http test using a slow loading iframe,
>>> but the window onload handler for the page does not run until after its
>>> iframe has finished loading.
>>>
>>> This seems OK. You can put your test code somewhere other than the load
>>> handler. For example, an inline script:
>>>
>>>
>>>test();
>>>
>>>
>>> That will run right away and won’t wait for the window load event.
>>>
>>
>> I'm not 100% sure, so take this with a grain of salt, but I think there
>> are cases where iframes the load immediately (e.g. if the resource is
>> cached).
>>
>> To avoid race conditions, I think you need the frames to actually never
>> finish loading. I thought there were some HTTP tests that have resources
>> that intentionally never finish loading. I'd look in the
>> LayoutTests/http/tests for files with 'slow' in the name.
>>
>> Ojan
>>
>
>
> ___
> 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] Misplaced files

[Dmitry Titov]

Considering there are already specific WebCore subdirs for notifications,
storage, workers, svg, mathml and others, it seems having a new subdirectory
named perhaps 'blob' wouldn't be out of line. There is quite a few of those
Blob/File files already...

Dmitry

On Fri, Aug 27, 2010 at 3:55 PM, Adam Barth  wrote:

> Looking through WebCore/html I noticed the files below.  I'm not sure
> they belong in WebCore/html because they don't appear to be
> HTML-specific.  Rather, they seem like generic web platform APIs
> (e.g., they could be exposed to SVG or whatever other markup languages
> we choose to support in the future).  Should we move these to
> WebCore/page, WebCore/dom, or should we make a new location for these
> sorts of things?
>
> Adam
>
>
> == Blob-related ==
> Blob.cpp
> Blob.h
> Blob.idl
> BlobBuilder.cpp
> BlobBuilder.h
> BlobBuilder.idl
> BlobURL.cpp
> BlobURL.h
> ThreadableBlobRegistry.cpp
> ThreadableBlobRegistry.h
>
> == File-related ==
> File.cpp
> File.h
> File.idl
> FileError.h
> FileError.idl
> FileList.cpp
> FileList.h
> FileList.idl
> FileReader.cpp
> FileReader.h
> FileReader.idl
> FileStreamProxy.cpp
> FileStreamProxy.h
> FileThread.cpp
> FileThread.h
> FileThreadTask.h
> FileWriter.cpp
> FileWriter.h
> FileWriter.idl
> ___
> 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] Does any port implements Navigator.registerProtocolHandler and Navigator.registerContentHandler?

[Dmitry Titov]

Thanks to all,

the bug is here: https://bugs.webkit.org/show_bug.cgi?id=41878

I've added link to tracking Chromium bug as well.

Dmitry


On Wed, Jul 7, 2010 at 7:59 PM, Jeremy Orlow  wrote:

> That would be the standard thing to do.
>
> The sooner someone gets started on the feature, the easier it'll be to
> revert the patch that removes the code.  :-)
>
> J
>
> On Thu, Jul 8, 2010 at 10:55 AM, David Levin  wrote:
>
>>
>>
>> On Wed, Jul 7, 2010 at 5:24 PM, Peter Kasting wrote:
>>
>>> On Wed, Jul 7, 2010 at 5:00 PM, Dmitry Titov wrote:
>>>
>>>> I'd lean to the removal, unless there is a port that has work ongoing or
>>>> planned soon for those implementations.
>>>>
>>>> Does anybody vote for #ifdefs?
>>>>
>>>
>>> I vote against removal if only because Chromium has really wanted these
>>> badly for a long time and simply hasn't been able to find someone to
>>> implement them.  Perhaps I could make it worth your while to implement
>>> rather than remove the stubs?  :)
>>>
>>
>> *Even if someone to implement them for chromium, it doesn't seem to fix
>> the overall problem. *Dmitry indicated that the presences of these is
>> breaking feature detection in browsers using WebKit (-- which is something
>> being heard from web developers).
>>
>> A simple solution is to remove them. Later, any port (including chromium)
>> who gets someone to work on them could re-add these methods back properly
>> under ifdef's.
>>
>> dave
>>
>> ___
>> 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

[webkit-dev] Does any port implements Navigator.registerProtocolHandler and Navigator.registerContentHandler?

[Dmitry Titov]

Hi,

I'm looking to disable/remove the methods exposed on Navigator for
registering the protocol handler and content handler (HTML5 spec is
here
).
It was implemented a while ago, unfortunately neither Chrome nor Safari
don't actually implement these. So they are exposed to JS and do nothing
when called. There is some level of checks for parameter values but past
those checks there is no implementation for Chrome. I've tested Safari 5 and
it does not implement it. FF has the implementation since v3 I believe.

It is not optimal to expose the methods but dont't have actual
implementation (it screws up the feature detection), so I'm thinking about
either removing those altogether (until the time someone wants to implement
them for real, they are easy to add back) or adding a pair of #ifdefs around
each of those methods. I'd lean to the removal, unless there is a port that
has work ongoing or planned soon for those implementations.

Does anybody vote for #ifdefs?

Thanks,
Dmitry



These are the methods in question:

Navigator.idl


> interface [

] *Navigator* {


> 


> void *registerProtocolHandler*(in DOMString scheme, in DOMString
> url, in DOMString title)

raises(DomException);



void *registerContentHandler*(in DOMString mimeType, in DOMString
> url, in DOMString title)

raises(DomException);

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

Re: [webkit-dev] Behavior of file:// URLs when dragging

[Dmitry Titov]

On Mon, May 10, 2010 at 5:48 PM, Daniel Cheng  wrote:

> From the discussion on https://bugs.webkit.org/show_bug.cgi?id=25882, I
> believe the general consensus is that file:// URLs should not be exposed
> when dragging and dropping.
>
> Removing file:// URL population from event.dataTransfer is pretty easy;
> however, what should we do when the user drops a file in an editable area?
> Right now, it creates a link with the file URL, which (I think) defeats the
> point of removing file:// URLs from event.dataTransfer. I think the right
> behavior here is to return DragOperationNone unless the active target
> element is a file input or it's a non-editable element that handles files in
> event.dataTransfer, but I'd like to see what other people think first.
>

I think there was a suggestion in that bug to only drop the filename into
the editable area, without the full path. I'm not sure if it is better then
DragOperationNone though.


>
> On a tangent, I noticed that a lot of implementations of DragData::asURL
> try to check that a file URL points at a file that actually exists. What is
> the rationale for doing the file existence check in DragData? The loader has
> to check for existence anyway, so why not just let the loader do it? This
> should save some IO time, especially if the file is on a slow NFS share in
> another continent. Does anyone depend on asURL's undocumented behavior to
> not return file URLs that point to non-existent files? (If so, I'd be
> willing to argue that they shouldn't be doing that anyway.) If not, I'd like
> to remove that behavior.
>
> Daniel
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Crashing Workers Code?

[Dmitry Titov]

On Mon, Mar 29, 2010 at 5:26 PM, Darin Adler  wrote:

> On Mar 29, 2010, at 5:14 PM, Dmitry Titov wrote:
>
> > JSC workers are terminated by setting a 1-ms timeout. V8 workers
> terminate by throwing exception of a special kind and then checking for it
> in C++ code.
>
> There is precedent in JavaScriptCore for using a special exception to
> terminate code. InterruptedExecutionError is used for this purpose. I could
> imagine having something similar for workers. A timeout sounds like a poor
> way to do it.
>
>
Indeed. Added this info to https://bugs.webkit.org/show_bug.cgi?id=36646 and
renamed it.


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

Re: [webkit-dev] Crashing Workers Code?

[Dmitry Titov]

I believe thee is more then one underlying issue.

For example, tests that fail with "CONSOLE MESSAGE: line 3: JavaScript
execution exceeded timeout." - seems this is legit since JSC workers are
terminated by setting a 1-ms timeout. V8 workers terminate by throwing
exception of a special kind and then checking for it in C++ code. In JCS
case, we likely should disable the message once WorkerThread::stop() was
invoked.

I'm trying to catch one elusive crash for some time now. It's in Chromium
but perhaps it's the same thing. It manifests like this:

ASSERTION FAILED: !m_sharedBuffer
(/b/slave/mac/build/src/third_party/WebKit/WebCore/WebCore.gyp/../platform/text/StringImpl.cpp:59
WebCore::StringImpl::~StringImpl())

or like this:

Test: worker-cloneport.html
Chromium Helper(1774,0xb00a1000) malloc: *** error for object 0x241e260:
double free
*** set a breakpoint in malloc_error_break to debug
Chromium Helper(1774,0xb00a1000) malloc: *** error for object 0x241e280:
incorrect checksum for freed object - object was probably modified after
being freed.

There is some race going on... But not frequent enough to easily find it :-(

Dmitry

On Mon, Mar 29, 2010 at 4:54 PM, Eric Seidel  wrote:

> It seems Workers makes for a disproportionate number of crashes and
> flaky tests on the bots:
>
> https://bugs.webkit.org/show_bug.cgi?id=36646 (timeout)
> https://bugs.webkit.org/show_bug.cgi?id=36633 (crash)
> https://bugs.webkit.org/show_bug.cgi?id=36585 (timeout)
> https://bugs.webkit.org/show_bug.cgi?id=29926 (crash)
> https://bugs.webkit.org/show_bug.cgi?id=29090 (timeout)
> https://bugs.webkit.org/show_bug.cgi?id=34281 (timeout)
> https://bugs.webkit.org/show_bug.cgi?id=33653 (crash)
> https://bugs.webkit.org/show_bug.cgi?id=33437 (crash)
> https://bugs.webkit.org/show_bug.cgi?id=33008 (crash)
>
> I have not tried running a full run-webkit-tests with --guard, but I
> suspect there may be some sort of memory smasher or other corruption
> problem which has been flying under our radar for a long while.
>
> Unfortunately I don't know more than that yet...
>
> -eric
> ___
> 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] Chromium layout test expectations coming today

[Dmitry Titov]

For now, I've just used a shortest notation:
http://trac.webkit.org/changeset/56582

It's easy to change if this thread will come to a resolution. Since it's
copy/paste to browser anyways, the bug number works as well as url perhaps.

Dmitry

On Mon, Mar 22, 2010 at 2:03 PM, Dirk Pranke  wrote:

> On Fri, Mar 19, 2010 at 7:06 PM, Maciej Stachowiak  wrote:
> >
> > On Mar 19, 2010, at 5:30 PM, Ojan Vafai wrote:
> >
> > Currently we do BUG12345 for Chromium bugs. There are no WebKit bugs
> listed.
> > How about we instead use CR12345 for Chromium bugs and WK12345 for WebKit
> > bugs?
> >
> > Another possibility would be to use bug URLs.
>
> The current expectations file has lines that (barely but) usually
> clock in at under 80-characters.
>
> I am reluctant to change things that make it more effort for a user to
> type in and make it harder to read by going over 80 characters and
> wrapping. I'm not sure what real advantage would be gained by making
> it a URL to offset this. I have rarely found myself
> cutting-and-pasting or clicking on stuff from this file.
>
> So, I would vote for a shorter shortcut, like the 3-4 character
> prefixes that have been suggested.
>
> -- Dirk
> ___
> 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] FileAPI/FileWriter support

[Dmitry Titov]

I'm curious what the ByteStore object is for? While reading the document,
I've got an impression that BlobBuilder would store all content of the blob
under construction in that store, 'realizing' the parts (encoding the
strings into utf-8 and reading the files underlying Blobs). It seems to be
better to avoid 'realizing' the separate strings/blobs until the very end
(basically, until the bits are needed for actual XHR.send() or
FileWriter.write()), otherwise BlobBuilder.append() becomes a synchronous
"read whole file" operation.

Dmitry

On Wed, Mar 24, 2010 at 5:42 PM, Kinuko Yasuda  wrote:

> Hi webkit-dev folks,
>
> I'm working on FileAPI/FileWriter support and would like to start making
> changes / send patches for the work.
> Our initial target platform is chromium and many of the changes will only
> touch files under platform/chromium, but I will also change existing
> Blob/File code and will add some modules in WebCore for async file
> operations.
>
> Here's the design doc (implementation plan) for FileWriter:
>
> http://docs.google.com/View?docID=0AWoCez0NQ60KZG5jaGhkZ18xZ25rZ3RxY3A&revision=_latest&hgd=1
>
> The plan/design is not concrete yet and any feedbacks are more than
> welcome.
> To start with, I'm planning to open a new meta issue for FileWriter (will
> also update webkit.org/b/32624) and start submitting changes in small
> pieces whenever possible.
>
> Thanks!
> Kinuko
>
>
> ___
> 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] Question regarding build flags for the features

[Dmitry Titov]

If we had a single flag for all those (ENABLE_FILE_API ?) then a port would
have to implement all features at once to be able to enable it. It might
be inconvenient. If the code is not shared and those flags can be enabled in
any combination, why not keep them separate?

On a related note, it'd be nice to have a page (on a wiki?) with a list of
those flags with some sort of a status/owner, and possibly some info on what
a port should implement to be able to enable a feature.

On Tue, Mar 23, 2010 at 10:11 AM, Jian Li  wrote:

> Hi,
>
> I've introduced a build flag ENABLE(BLOB_SLICE) for the Blob.slice feature.
> To continue implementing other File API features, we probably need a couple
> more build flags, like ENABLE(FILE_URN) and ENABLE(FILE_READER). When the
> embedder implements the necessary support, these flags can be turned on
> respectively. Do we want to use multiple flags to control File API features
> or simply use one flag? For the latter, all the features will only
> be available after the embedder hooks up all the supporting logics.
>
> Thanks,
>
> Jian
>
> ___
> 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] Compile failures on Leopard build bot

[Dmitry Titov]

Hi!

One of 2 slaves (apple-xserve-1 <../../../buildslaves/apple-xserve-1>) on
that bot fails Release compile:
http://build.webkit.org/builders/Leopard%20Intel%20Release%20(Build)/builds/12151

It seems like because of incremental build after
http://trac.webkit.org/changeset/54411, it now has DOMBlob.h file in both
WebKitBuild/Release/WebKit.framework/Headers and PrivateHeaders.

Could someone with access to this machine take a look (or just
clobber/delete the file?)

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

Re: [webkit-dev] WTF::callOnMainThread() and re-entrancy

[Dmitry Titov]

I've tried to post a timer if the scheduleDispatchFunctionsFromMainThread
comes on main thread - this fixes the test and it is a minimal change.

Drew, let me know if you want to dig deeper in CFRunLoopObserver, otherwise
I could whip up a patch (post a timer from main thread + postTask change
from Dumi's patch).

Dmitry

On Tue, Mar 9, 2010 at 12:37 PM, Drew Wilson  wrote:

> That's a great idea:
>
>
> http://developer.apple.com/Mac/library/documentation/CoreFoundation/Reference/CFRunLoopObserverRef/Reference/reference.html#//apple_ref/c/tdef/CFRunLoopActivity
>
>
> This
> gives us lots of places to hook. scheduleDispatchFunctionsFromMainThread()
> could be a no-op on the mac, if we just always invoke
> dispatchFunctionsFromMainThread() at a specified point in the loop (e.g.
> kCFRunLoopBeforeWaiting
> ).
>
> The only downside is that I'm not sure how to implement the "yield for UI
> events" behavior in dispatchFunctionsFromMainThread() if we're calling this
> from an observer - we actually need to have some kind of event generated to
> make sure we wake up. Maybe we could use
> scheduleDispatchFunctionsFromMainThread() to fire an event to make sure we
> have something to process, but actually do the processing from within the
> observer.
>
> -atw
>
> On Tue, Mar 9, 2010 at 11:55 AM, Alexey Proskuryakov wrote:
>
>>
>> On 09.03.2010, at 11:51, Drew Wilson wrote:
>>
>>  That actually is an interesting idea - perhaps we could implement
>>> scheduleDispatchFunctionsFromMainThread() using a 0-delay timer in the case
>>> where it's called from the main thread...
>>>
>>
>> As an unsubstantiated idea, we could also consider using a run loop
>> observer. These can be set to fire at well defined points of run loop
>> execution.
>>
>> - WBR, Alexey Proskuryakov
>>
>>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] WTF::callOnMainThread() and re-entrancy

[Dmitry Titov]

On Tue, Mar 9, 2010 at 11:13 AM, Alexey Proskuryakov  wrote:

>
> On 09.03.2010, at 9:45, Drew Wilson wrote:
>
>  Yeah, it's a race condition - it seems to all depend on whether the worker
>> resource gets loaded before the postMessage loop starts. Failure rate is
>> around 30-50% on my machine.
>>
>
> It would help to have a more detailed description of the problem. I've been
> following the discussion in bugs and in this thread, but I'm still unsure
> about some aspects of it.
>
> Seems that there are two issues at hand:
>
> 1) We feel the need to change how Document::postTask() behaves, because
> otherwise, the patch for 
> doesn't work. We feel the need because it makes little sense for it to have
> drastically different behavior depending on what thread it's called from.
>
> It feels like a good change to make indeed, but I'm surprised that it
> apparently went through review unmentioned and unquestioned. The questions
> to ask are why exactly it was needed, and whether there are other ways to
> fix bug 34726.
>
> 2) if we make that change, the worker-cloneport.html test starts to fail.
>
> I didn't attempt to debug this myself, and I don't quite understand the
> problem description. I see only one postMessage loop in the test, and it's
> in worker code. How can it be executed before the worker resource gets
> loaded?


There is a MessageChannel which sets the same onmessage handler for both
ports, and that handler 'reflects' the received message to the sender
through the channel. Then the test starts this ping-pong by sending a single
message through. As a result, there is always a message in transit - they
are delivered via Document::postTask. So at every moment there is at least
one task in the postTask's queue, and executing that task immediately adds a
new task (since the onmessage handler posts the next message through the
MessageChannel). All this ping-pong happens on main thread, while worker
gets loaded.

That means we always exit the loop processing the tasks in
dispatchFunctionsFromMainThread() via timeout, and there are always
a performSelectorOnMainThread in the RunLoop queue.

The interesting thing I don't yet understand is why one-shot timer
(implemented via CFRunLoopAddTimer), when used for queueing in
Docuemnt::postTask works fine and performSelectorOnMainThread causes hang of
the test.


>
>
>  It looks like events have priority in Cocoa, and I'm guessing that
>> performSelectorOnMainThread() creates events with a higher priority than
>> those generated by URLConnection, which can lead to starvation. I'm not
>> certain what the right fix is, other than to maybe use a different method of
>> dispatching events other than performSelectorOnMainThread that lets us set a
>> lower priority?
>>
>
> These main thread calls do not use events for processing. CF/NSRunLoop has
> a concept of run loop sources, which can generate events or perform other
> actions, see <
> http://developer.apple.com/mac/library/documentation/CoreFoundation/Reference/CFRunLoopRef/Reference/reference.html>
> and <
> http://developer.apple.com/Mac/library/documentation/CoreFoundation/Reference/CFRunLoopSourceRef/Reference/reference.html
> >.
>
> - WBR, Alexey Proskuryakov
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] WTF::callOnMainThread() and re-entrancy

[Dmitry Titov]

At least user input is dispatched even if there are outstanding
performSelectorOnMainThread calls:
https://bugs.webkit.org/show_bug.cgi?id=23705

With the change in postTask, the cloneport test does not always hang - on my
machine it's 50-50. There is some racing condition somewhere perhaps...

On Mon, Mar 8, 2010 at 5:29 PM, Drew Wilson  wrote:

> Following up with a related note - does anyone have any insight into how
> the Cocoa event loop dispatches events from different sources? In
> particular, I have a test (worker-cloneport.html) which posts a port back
> and forth between two endpoints (both on the main thread).
>
> With the change to Document.postTask() I described earlier in this thread,
> this test results in there always being a pending event (posted via
> performSelectorOnMainThread) when we re-enter the cocoa runloop. It appears
> that the run loop *always* dispatches this event before dispatching events
> from NSURLConnection - the result is that any pending resource loads never
> complete.
>
> Is there some kind of prioritization within the cocoa run loop so that
> certain types of events (like NSURLConnection events) if there are no
> pending events of other types?
>
> -atw
>
>
> On Mon, Mar 8, 2010 at 2:08 PM, Dmitry Titov  wrote:
>
>> Many tasks are just fine to execute while modal UI is present. For
>> example, XHR in a Worker probably should not be frozen by an alert on the
>> parent page. That posts tasks to main thread for loader.
>> Also, it's unclear if a task can be simply delayed or in fact some other
>> action should be performed at resume point - for example, timers
>> re-calculate the next fire time.
>>
>> Maybe there can be a generic mechanism for tasks to participate in
>> suspend/resume... It'd require a better definition of the events - for
>> example, is there a difference between "suspense on modal UI" and "suspense
>> on going into BF cache"? Probably there is.
>>
>> Dmitrty
>>
>>
>> On Mon, Mar 8, 2010 at 1:45 PM, Drew Wilson  wrote:
>>
>>> So the implication is that every single place that uses tasks has to have
>>> an associated activeDOMObject() or other hooks in ScriptExecutionContext so
>>> it can get suspend/resume calls and try to queue up the tasks for later?
>>> That seems a) hard (since not everything that uses tasks necessarily has an
>>> activeDOMObject), and b) fragile because we'll undoubtedly miss cases --
>>> there's something like 70 calls to callOnMainThread()/postTask() in the
>>> WebCore code.
>>>
>>> Is there no way to do something at a lower level? callOnMainThread()
>>> already keeps a queue of pending callbacks, so it seems like just not
>>> dispatching those callbacks might be better? It's tricky because you don't
>>> necessarily know which ScriptExecutionContext a task is destined for at that
>>> low level.
>>>
>>> -atw
>>>
>>>
>>> On Mon, Mar 8, 2010 at 1:24 PM, Dmitry Titov wrote:
>>>
>>>> On Mon, Mar 8, 2010 at 11:38 AM, Alexey Proskuryakov 
>>>> wrote:
>>>>
>>>>>
>>>>> On 08.03.2010, at 11:21, Drew Wilson wrote:
>>>>>
>>>>>  So, my question is: does it surprise anyone that tasks posted via
>>>>>> callOnMainThread() are getting executed even though there's a modal 
>>>>>> dialog
>>>>>> shown? And is there anything I should be doing in my task handler to make
>>>>>> sure we aren't re-entering JS execution inappropriately in these cases? 
>>>>>> I'm
>>>>>> just concerned that the way we're posting tasks from worker threads to 
>>>>>> the
>>>>>> main thread may cause reentrancy problems.
>>>>>>
>>>>>
>>>>> It is not correct to deliver messages from worker threads when an alert
>>>>> or a modal window is displayed. It may be ok for modal dialogs that are
>>>>> triggered asynchronously (such as credentials dialog).
>>>>>
>>>>> We have a manual test regression for a related issue,
>>>>> WebCore/manual-tests/js-timers-beneath-modal-dialog.html. You can compare
>>>>> how timers work, and how worker messages are delivered to find out how to
>>>>> fix the problem.
>>>>>
>>>>
>>>> Timers are suspended by
>>>> ScriptExecutionContext::suspendActiveDOMObjects/resumeActiveDOMObjects from
>>>> PageGroupLoadDeferrer. So the context (Document) knows when it is suspended
>>>> and when it gets resumed.
>>>> It seems the task to process accumulated port messages can be postponed
>>>> until resume.
>>>>
>>>>
>>>>
>>>>> - WBR, Alexey Proskuryakov
>>>>>
>>>>>
>>>>> ___
>>>>> 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] WTF::callOnMainThread() and re-entrancy

[Dmitry Titov]

Many tasks are just fine to execute while modal UI is present. For example,
XHR in a Worker probably should not be frozen by an alert on the parent
page. That posts tasks to main thread for loader.
Also, it's unclear if a task can be simply delayed or in fact some other
action should be performed at resume point - for example, timers
re-calculate the next fire time.

Maybe there can be a generic mechanism for tasks to participate in
suspend/resume... It'd require a better definition of the events - for
example, is there a difference between "suspense on modal UI" and "suspense
on going into BF cache"? Probably there is.

Dmitrty

On Mon, Mar 8, 2010 at 1:45 PM, Drew Wilson  wrote:

> So the implication is that every single place that uses tasks has to have
> an associated activeDOMObject() or other hooks in ScriptExecutionContext so
> it can get suspend/resume calls and try to queue up the tasks for later?
> That seems a) hard (since not everything that uses tasks necessarily has an
> activeDOMObject), and b) fragile because we'll undoubtedly miss cases --
> there's something like 70 calls to callOnMainThread()/postTask() in the
> WebCore code.
>
> Is there no way to do something at a lower level? callOnMainThread()
> already keeps a queue of pending callbacks, so it seems like just not
> dispatching those callbacks might be better? It's tricky because you don't
> necessarily know which ScriptExecutionContext a task is destined for at that
> low level.
>
> -atw
>
>
> On Mon, Mar 8, 2010 at 1:24 PM, Dmitry Titov  wrote:
>
>> On Mon, Mar 8, 2010 at 11:38 AM, Alexey Proskuryakov wrote:
>>
>>>
>>> On 08.03.2010, at 11:21, Drew Wilson wrote:
>>>
>>>  So, my question is: does it surprise anyone that tasks posted via
>>>> callOnMainThread() are getting executed even though there's a modal dialog
>>>> shown? And is there anything I should be doing in my task handler to make
>>>> sure we aren't re-entering JS execution inappropriately in these cases? I'm
>>>> just concerned that the way we're posting tasks from worker threads to the
>>>> main thread may cause reentrancy problems.
>>>>
>>>
>>> It is not correct to deliver messages from worker threads when an alert
>>> or a modal window is displayed. It may be ok for modal dialogs that are
>>> triggered asynchronously (such as credentials dialog).
>>>
>>> We have a manual test regression for a related issue,
>>> WebCore/manual-tests/js-timers-beneath-modal-dialog.html. You can compare
>>> how timers work, and how worker messages are delivered to find out how to
>>> fix the problem.
>>>
>>
>> Timers are suspended by
>> ScriptExecutionContext::suspendActiveDOMObjects/resumeActiveDOMObjects from
>> PageGroupLoadDeferrer. So the context (Document) knows when it is suspended
>> and when it gets resumed.
>> It seems the task to process accumulated port messages can be postponed
>> until resume.
>>
>>
>>
>>> - WBR, Alexey Proskuryakov
>>>
>>>
>>> ___
>>> 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] WTF::callOnMainThread() and re-entrancy

[Dmitry Titov]

On Mon, Mar 8, 2010 at 11:38 AM, Alexey Proskuryakov  wrote:

>
> On 08.03.2010, at 11:21, Drew Wilson wrote:
>
>  So, my question is: does it surprise anyone that tasks posted via
>> callOnMainThread() are getting executed even though there's a modal dialog
>> shown? And is there anything I should be doing in my task handler to make
>> sure we aren't re-entering JS execution inappropriately in these cases? I'm
>> just concerned that the way we're posting tasks from worker threads to the
>> main thread may cause reentrancy problems.
>>
>
> It is not correct to deliver messages from worker threads when an alert or
> a modal window is displayed. It may be ok for modal dialogs that are
> triggered asynchronously (such as credentials dialog).
>
> We have a manual test regression for a related issue,
> WebCore/manual-tests/js-timers-beneath-modal-dialog.html. You can compare
> how timers work, and how worker messages are delivered to find out how to
> fix the problem.
>

Timers are suspended by
ScriptExecutionContext::suspendActiveDOMObjects/resumeActiveDOMObjects from
PageGroupLoadDeferrer. So the context (Document) knows when it is suspended
and when it gets resumed.
It seems the task to process accumulated port messages can be postponed
until resume.



> - WBR, Alexey Proskuryakov
>
>
> ___
> 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] [webkit-changes] [55234] trunk/JavaScriptCore

[Dmitry Titov]

On Thu, Feb 25, 2010 at 9:48 AM, Jochen Eisinger wrote:

> Here's a bit of context. When a database is opened, right now you
> don't have any context from where it is opened. The problem is that
> the actual calls that open a database go through the sqlite3 vfs
> layer, so there's no easy way to pass this function down to to
> platform/sql/chromium/SQLFileSystemChromium*.cpp
>
> This patch will allow you to get from anywhere within webkit a pointer
> to the Thread object that actually created the thread you're currently
> on


Would TLS mechanism provide the same thing?


> (in case of the database, this can be either a thread forked of
> from the main thread or from a worker thread), and query the object
> for context information.
>
> I hope this explains this.
>
> best
> -jochen
>
> On Thu, Feb 25, 2010 at 6:31 PM, Alexey Proskuryakov 
> wrote:
> >
> > There is not a single word explaining this change - neither in ChangeLog,
> > nor in the bug. Such a patch shouldn't have been accepted. Is there any
> > reason not to roll it out?
> > - WBR, Alexey Proskuryakov
> > On 25.02.2010, at 6:49, e...@webkit.org wrote:
> >
> > revision55234authore...@webkit.orgdate2010-02-25 06:49:12 -0800 (Thu, 25
> Feb
> > 2010)
> >
> > Log Message
> >
> > 2010-02-25  Jochen Eisinger  
> >
> > Reviewed by Jeremy Orlow.
> >
> > Make the context that was passed to the ThreadFunction
> accessible.
> > https://bugs.webkit.org/show_bug.cgi?id=35379
> >
> > * wtf/Threading.h:
> > * wtf/ThreadingNone.cpp:
> > (WTF::threadContext):
> > * wtf/ThreadingPthreads.cpp:
> > (WTF::):
> > (WTF::identifierByPthreadHandle):
> > (WTF::establishIdentifierForPthreadHandle):
> > (WTF::pthreadHandleForIdentifier):
> > (WTF::contextForIdentifier):
> > (WTF::createThreadInternal):
> > (WTF::currentThread):
> > (WTF::threadContext):
> > * wtf/ThreadingWin.cpp:
> > (WTF::):
> > (WTF::threadMap):
> > (WTF::storeThreadHandleByIdentifier):
> > (WTF::threadHandleForIdentifier):
> > (WTF::contextForIdentifier):
> > (WTF::createThreadInternal):
> > (WTF::threadContext):
> >
> >
> ___
> 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] The tree is on fire

[Dmitry Titov]

Ok, I believe r53727 and r53738 are going to fix Leopard and SnowLeopard
(and improve Windows) test runs.

Keeping an eye on it...
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Database in Worker context

[Dmitry Titov]

+1 to small patches.

I've reviewed a couple of iterations of the patch in
https://bugs.webkit.org/show_bug.cgi?id=22725 and it was so far manageable,
although it could be split in 2 at least (inheritance change and
WorkerThread termination change). For future patches, definitely lets split
into smaller ones, 60kb is on a biggish side.

There is no DatabaseManager class anymore since the database-supporting
methods are being moved to ScriptExecutionContext from which both Document
and WorkerContext are derived from. Having a 'Context' to own another
'Manager' seemed like too much layers.

I lean to r+ the first patch after latest set of notes is addressed, more
eyes are always welcome though :-)

Dmitry

On Thu, Jan 14, 2010 at 3:06 PM, Darin Adler  wrote:

> On Jan 14, 2010, at 2:35 PM, Eric Uhrhane wrote:
>
> > I think it would have been hard to break this chunk any smaller.
>
> Any time you have a chunk and you’re wondering how it could be broken up
> smaller, please feel free to ask that question after cc'ing me on a bug.
> Maciej and I, in particular, have a lot of experience with this, much of
> dating from the first year of the Safari project. I made changes that were
> too large and learned “no apologies” strategies to break them up into much
> smaller pieces that were easier to get right and to read and review.
>
>-- Darin
>
> ___
> 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] SharedScript: next steps and result of offline discussion.

[Dmitry Titov]

On Tue, Dec 15, 2009 at 12:06 PM, Maciej Stachowiak  wrote:

>
> On Dec 15, 2009, at 11:09 AM, Michael Nordman wrote:
>
>
>
> On Mon, Dec 14, 2009 at 9:16 PM, Darin Fisher  wrote:
>
>> I think that use case has been de-emphasized.  However, if we wanted to
>> support it, we'd probably have to say that removeChild of an IFRAME element
>> doesn't cause the unload event to be dispatched.  (I'm a bit concerned that
>> that may cause incompatibilities with existing pages.)  Then, you'd have to
>> store a reference to the IFRAME element in a global variable, so that you
>> could find it again when the next document is loaded.
>
>
> I hope this use-case can be accommodated, I think this is ultimately the
> more generally applicable use-case. Btw, concern for incompatibilities with
> existing pages was one reason we came up with a new construct for this
> capability (instead of overloading  or 

Re: [webkit-dev] WTF::currentThread() and non-WTF threads

[Dmitry Titov]

Thanks for sharing your thoughts!

On Fri, Dec 11, 2009 at 2:44 AM, Jeremy Orlow  wrote:

> On Thu, Dec 10, 2009 at 6:48 PM, Dmitry Titov  wrote:
>
>> Hi webkit-dev!
>>
>> Trying to add ASSERTS to RefCounted objects (
>> https://bugs.webkit.org/show_bug.cgi?id=31639) I've added some more calls
>> to WTF::currentThread() and started to get a lot of assertions here:
>>
>> static ThreadIdentifier establishIdentifierForPthreadHandle(pthread_t&
>> pthreadHandle)
>> {
>> ASSERT(!identifierByPthreadHandle(pthreadHandle));
>>
>> Here is what happens: A thread that is not created by WTF::CreateThread is
>> calling currentThread() in hope to get a ThreadIdentifier. It doesn't have
>> it so we create it and put into ThreadMap. Normally, WTF threads call
>> WTF::detachThread() that removes the ThreadIdentifier from the map. The
>> 'other' threads do not do so - so the TheradIdentifier remains in the map.
>>
>> On OSX, pthreads reuse system handles when one thread terminates and
>> another starts... That easily leads to threads that run sequentially to have
>> the same handle, and the same ThreadIdentifier - since it is still in the
>> threadMap, which makes currentThread() kind of useless since it returns the
>> same id for different threads, the very thing the threadMap is tryign to
>> avoid.
>>
>> I'm thinking about changing the implementation to stop "auto-register"
>> non-WTF threads.
>>
>
> Wouldn't this break binary compatibility?
>

If you mean nightly builds, OSX Safari runs fine with this. On Windows it's
going to be ok because we use OS-supplied ThreadIdentifiers there.


> Does pthreads have any facility to register a callback that's called on
> thread shutdown?  Could we use some sort of thread local storage to keep
> track of whether that thread has been auto-registered yet?
>

I think I see what you mean. I tried to figure out if it is possible. There
is a callback invoked on destruction of a thread-specific slot... Perhaps it
can be used to un-register the thread if we add a thread-specific slot to
all incoming threads. The problem with those is that they are called in
unspecified order so another thread-specific destructor could re-register a
thread again, by calling currentThread(). Perhaps there is a way to do this
cleanly, it escapes me at the moment...


> Maybe all non-registered threads could just use a default thread identifier
> and some sort of warning message could be logged the first time this
> happens?
>

Most usages of currentThread() are like this:
ASSERT(m_myThreadId == currentThread());
Basically, they verify that the object is called on the same thread as
created... Returning same identifier for different threads satisfies this
check even if the treads are different. If currentThread() returned the
different identifier each time in case of un-registered thread, it would
force the developer to either use WTF::createThread or WTF::registerThread.


>
>
>> Instead, lets add a new function, WTF::registerThread() that would
>> establish the ThreadIdentifier for a thread not created by WTF::createThread
>> - and assert in currentThread() if the current thread is unknown to WTF.
>> This way, we could find all the cases of such threads and equip them with
>> registerThread()/detachThread() pair that will keep the thread map in a good
>> state.
>>
>> The currentThread() would look like this:
>>
>> ThreadIdentifier currentThread()
>> {
>> pthread_t currentThread = pthread_self();
>> if (ThreadIdentifier id = identifierByPthreadHandle(currentThread))
>> return id;
>>
>> ASSERT_NOT_REACHED();
>>
>> // Either the thread is not created by WTF::CreateThread() or
>> registered by WTF::registerThread(), or we are getting
>> // a call from thread-specific destructor after WTF::detachThread()
>> was called and ThreadIdentifier removed.
>> // Neither scenario permits reliable thread id tracking, so we can not
>> return a meaningful ThreadIdentifier here.
>> // Normally ThreadIdentifiers are compared so lets generate a fake
>> one-time ThreadIdentifier to fail comparison, if
>> // it is in fact done.
>> static ThreadIdentifier fakeId = minFakeIdentifierCount;
>>
>> if (fakeId == maxFakeIdentifierCount)
>> fakeId = minFakeIdentifierCount;
>>
>> return fakeId++;
>> }
>>
>> What would you say? Any bad feelings about that?
>>
>> Dmitry
>>
>> ___
>> 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] WTF::currentThread() and non-WTF threads

[Dmitry Titov]

Hi webkit-dev!

Trying to add ASSERTS to RefCounted objects (
https://bugs.webkit.org/show_bug.cgi?id=31639) I've added some more calls to
WTF::currentThread() and started to get a lot of assertions here:

static ThreadIdentifier establishIdentifierForPthreadHandle(pthread_t&
pthreadHandle)
{
ASSERT(!identifierByPthreadHandle(pthreadHandle));

Here is what happens: A thread that is not created by WTF::CreateThread is
calling currentThread() in hope to get a ThreadIdentifier. It doesn't have
it so we create it and put into ThreadMap. Normally, WTF threads call
WTF::detachThread() that removes the ThreadIdentifier from the map. The
'other' threads do not do so - so the TheradIdentifier remains in the map.

On OSX, pthreads reuse system handles when one thread terminates and another
starts... That easily leads to threads that run sequentially to have the
same handle, and the same ThreadIdentifier - since it is still in the
threadMap, which makes currentThread() kind of useless since it returns the
same id for different threads, the very thing the threadMap is tryign to
avoid.

I'm thinking about changing the implementation to stop "auto-register"
non-WTF threads. Instead, lets add a new function, WTF::registerThread()
that would establish the ThreadIdentifier for a thread not created by
WTF::createThread - and assert in currentThread() if the current thread is
unknown to WTF. This way, we could find all the cases of such threads and
equip them with registerThread()/detachThread() pair that will keep the
thread map in a good state.

The currentThread() would look like this:

ThreadIdentifier currentThread()
{
pthread_t currentThread = pthread_self();
if (ThreadIdentifier id = identifierByPthreadHandle(currentThread))
return id;

ASSERT_NOT_REACHED();

// Either the thread is not created by WTF::CreateThread() or registered
by WTF::registerThread(), or we are getting
// a call from thread-specific destructor after WTF::detachThread() was
called and ThreadIdentifier removed.
// Neither scenario permits reliable thread id tracking, so we can not
return a meaningful ThreadIdentifier here.
// Normally ThreadIdentifiers are compared so lets generate a fake
one-time ThreadIdentifier to fail comparison, if
// it is in fact done.
static ThreadIdentifier fakeId = minFakeIdentifierCount;

if (fakeId == maxFakeIdentifierCount)
fakeId = minFakeIdentifierCount;

return fakeId++;
}

What would you say? Any bad feelings about that?

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

Re: [webkit-dev] Database in Worker context

[Dmitry Titov]

On Thu, Dec 10, 2009 at 11:09 AM, Eric Uhrhane  wrote:

> On Wed, Dec 9, 2009 at 6:55 PM, Dmitry Titov  wrote:
> > Thanks for the link to the prototype code!
> > If I understand it right and the DatabaseManager can not have any other
> > relationship with ScriptExecutionContext but 1-1 and their lifetime is
> the
> > same then it's not clear to me what benefit could be had by effectively
> > splitting a class in two. The fact that DatabaseManager is RefCounted
> also
> > hints that some other object could take ownership of it as well outside
> of
> > lifetime of ScriptExecutionContext, but is this true?
>
> That's there because the DatabaseThread [and therefore the Database]
> can stick around for a bit after the ScriptExecutionContext is deleted
> if I make it non-refcounted.  If I move the DatabaseManager parts into
> the ScriptExecutionContext, then I have to make sure that the SEC
> sticks around until after the Database and DatabaseThread have gone
> away.
>

It feels that there is a new class that does not have a specific lifetime or
relationship to other existing classes, as it is a mechanical part of some
other class rather...

I look at how m_document is used by current Database and it feels that if
SEC had a databaseThread() accessor,  then all other methods like
addOpenDatabase etc could be part of DatabaseThread instead, with Database
keeping a pointer to its DatabaseThread. What do you think about this?

> ScriptExecutionContext collects functionality common for Workers and
> > Documents, and as such is a home for a few 'groups' of methods, like a
> few
> > methods to deal with MessagePorts. MessagePort, in turn, has a raw
> pointer
> > back to ScriptExecutionContext - so it's clear that MessagePorts do not
> > outlive the SEC. Same pattern could be used for
> > ScriptExecutionContext/Database, for consistency. It also simplifies
> design
> > a bit - no need for a special refcounted manager class, and things
> > like callOnJavaScriptThread could be replaced by SEC::postTask() which is
> > already implemented.
>
> The point of CallOnJavascriptThread is that the JS thread is the Main
> Thread in the Document context, but [in Chromium's implementation] NOT
> in the Worker context.  I needed a virtual method to distinguish
> between the two cases, since the Database code previously treated
> isMainThread as synonymous with isJavascriptThread.  But of course
> that virtual method can be moved to Document and SEC instead of DDM
> and WDM.


I understand the reason for callOnJavascriptThread... This is exactly as
SEC::postTask is defined - it posts a task from any thread to the one which
executes JavaScript code for a given SEC. So for Document it is the main
thread, for Workers - the thread associated with WorkerThread. I think they
are the same thing - you can just use postTask in place of
callOnJavascriptThread.

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

Re: [webkit-dev] Database in Worker context

[Dmitry Titov]

Thanks for the link to the prototype code!

If I understand it right and the DatabaseManager can not have any other
relationship with ScriptExecutionContext but 1-1 and their lifetime is the
same then it's not clear to me what benefit could be had by effectively
splitting a class in two. The fact that DatabaseManager is RefCounted also
hints that some other object could take ownership of it as well outside of
lifetime of ScriptExecutionContext, but is this true?

ScriptExecutionContext collects functionality common for Workers and
Documents, and as such is a home for a few 'groups' of methods, like a few
methods to deal with MessagePorts. MessagePort, in turn, has a raw pointer
back to ScriptExecutionContext - so it's clear that MessagePorts do not
outlive the SEC. Same pattern could be used for
ScriptExecutionContext/Database, for consistency. It also simplifies design
a bit - no need for a special refcounted manager class, and things
like callOnJavaScriptThread
could be replaced by SEC::postTask() which is already implemented.

Dmitry

On Wed, Dec 9, 2009 at 5:21 PM, Eric Uhrhane  wrote:

> On Wed, Dec 9, 2009 at 4:11 PM, Dmitry Titov  wrote:
> > On Wed, Dec 9, 2009 at 12:58 PM, Eric Uhrhane 
> wrote:
> >>
> >>  I've pulled the database-related members out of Document and made a
> >> new class for them, DatabaseManager.  An instance of that is owned by
> >> each ScriptExecutionContext.  There are two flavors,
> >> DocumentDatabaseManager and WorkerDatabaseManager.  They're not very
> >> different, but in a few cases it was necessary to distinguish between
> >> them
> >
> > I don't see your code, just generic thought: If those classes are small,
> > then perhaps ScriptExecutionContext could absorb a couple of methods to
> deal
> > with that? Some of them could be virtual and implemented differently on
> > Document and WorkerContext.
> > Dmitry
>
> You don't see the code because I sent this as an early
> warning--there's nothing checked in yet.
> The classes aren't huge, and in fact most of the code was in Document
> before, but given that it's all to do with a separable concept [the
> Database], I thought it nicer to pull it out.  Let's
> see...DatabaseManger.cpp is 172 lines [including copyright headers,
> etc.] and the header is 107.  Seems like a lot to sprinkle through
> ScriptExecutionContext, Database, and WorkerContext.  You can take a
> look at my current code [where I'm backing it up--this won't actually
> be sent for review from this repository] at
> http://codereview.chromium.org/401016/show [mostly storage + v8
> bindings] and http://codereview.chromium.org/464018/show [mostly
> Chrome browser process stuff] and see what you think.
>
> Thanks,
>
> Eric
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Database in Worker context

[Dmitry Titov]

On Wed, Dec 9, 2009 at 12:58 PM, Eric Uhrhane  wrote:

>
>  I've pulled the database-related members out of Document and made a
> new class for them, DatabaseManager.  An instance of that is owned by
> each ScriptExecutionContext.  There are two flavors,
> DocumentDatabaseManager and WorkerDatabaseManager.  They're not very
> different, but in a few cases it was necessary to distinguish between
> them


I don't see your code, just generic thought: If those classes are small,
then perhaps ScriptExecutionContext could absorb a couple of methods to deal
with that? Some of them could be virtual and implemented differently on
Document and WorkerContext.

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

[webkit-dev] SharedScript: next steps and result of offline discussion.

[Dmitry Titov]

Hi WebKit,

The recent discussion indicated there is a feeling that SharedScript
functionality can be achieved by other means that do not require adding new
big APIs: changing iframe a bit (so it's internals survive reparenting into
another document) and adding single getWindowByName() API.

Ian Hickson proposed this idea noting that nothing in the spec prevents
iframe from staying alive over the reparenting.  Some folks from Google met
with folks from Apple to discuss and it appears there is a consensus that we
shall remove initial code for SharedScript and instead implement changes for
iframe and getWindowByFrame(). This will not cause new API and hopefully
won't cause compatibility issues since the only scenario that will behave
differently is reparenting of the iframe between documents that is hopefully
a rare thing. Perhaps more discussion will be needed to nail details on
those.

Separately (or related?), we discussed SharedWorkers and the way XHR works
in them. It seems a good idea to investigate a "shadow document' solution
(as Chrome does for worker processes) when a dummy document is created and
used to load resources on behalf of the worker. Also we'll try to fix couple
of bugs that prevent Workers to be reliable enough.

Thanks a lot to all who chimed in and helped to arrive to a good solution to
the same issues that SharedScript was trying to solve! :-)

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

Re: [webkit-dev] SharableScriptContext [was: GlobalScript in WebKit]

[Dmitry Titov]

On Mon, Nov 30, 2009 at 10:24 PM, Oliver Hunt  wrote:

>
> All that said, Darin, Maciej and I were discussing this on IRC earlier and
> it would seem that simply adding getWindowByName (or some such) would gain a
> very large amount of the behaviour desired in the {Shared,
> Global}Script[Context] concept.
>

Got to the colloquy transcript of this. I think the proposal there is to
implement getWindowByName() and not to have SharedScriptContext object at
all, rather emulate it by passing around a JS object which would be used to
share things. The argument was made that this will reduce the API explosion
and be less work in WebKit.

However, I'd need to understand how the following would work:

- it's not clear how to load script (the code that is supposed to be
shared). The apps today don't just load the whole code in a single 

Re: [webkit-dev] GlobalScript in WebKit

[Dmitry Titov]

On Mon, Nov 30, 2009 at 5:21 PM, Maciej Stachowiak  wrote:


> By the way, we could enable the SharedScript programming model at much
> lower WebKit-level implementation cost and with much less API surface as
> follows:
>
> - Allow Window to be passed via the structured clone algorithm over a
> MessageChannel, but it throws on all access if the recipient is not
> same-origin, in the same thread, and eligible for synchronous calls (i.e. in
> the same process).
>
> I believe this would allow SharedScript to be implemented in JavaScript.
> Essentially you'd use a SharedWorker to coordinate and elect a leader Window
> within each same-process group, which could then create a JavaScript object
> which it vends to all other Windows. The object does not get GC'd until all
> the referencing windows go away.


Yep, a variants of this were proposed... One difficulty with this is that
while JS object is kept alive, the interesting objects like timers, XHR,
WebSockets die once leader Window is closed. Plus, the leader [re]election
algorithm should be implemented. It is not impossible to keep track of
enough things to fix up the context, but it is way too difficult and
error-prone.

It sounds like by making it easier with SharedScript we'd remove the burden
of those implementations from many web developers. Just connect to it and it
provides stable JS context for things to run in.

If we go with this, I believe we'll need to follow up with things like
making XHR work even if page created it was closed... It might end up being
essentially the same as SharedScript itself.

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

Re: [webkit-dev] GlobalScript in WebKit

[Dmitry Titov]

I don't think it's correct to say that SharedWorkers are not useful and "we
need a SharedScript instead". They are different things and can address
different use cases. For example, SharedWorker is great to make sure there
is only one 'app instance' running - exactly because it is shared
inter-process, it can be used as a "inter-process synchronization primitive"
to control how many app instances are opened. SharedScript is a container
for data and code shared between pages that comprise a "web application" and
normally run in the same process. As in native apps, whether or not multiple
instances of the app can run at the same time depends on the author of the
app, and can be done either way.

Multi-process browsers are bringing more complexity (and benefits).
Not all technical
issues are
completely resolved in Chrome's implementation, and we might need (or
not) some mechanism of saying that a bunch of pages form "an application"
and should share a process. Right now, it's unclear if such mechanism even
needed though.

I agreed with you to remove the implementation details from the doc because
indeed they do not belong there. Not that they are not existing. For
example, the fact that in Chrome SharedWorkers are indeed inter-process
theoretically could be different. WebWorkers spec does not specify where and
how to look for instances of SharedWorkers, although it implies some useful
degree of sharing. The fact that in Chrome they are shared across all
processes is a detail of Chrome implementation.

Dmitry

On Mon, Nov 30, 2009 at 3:08 PM, Geoffrey Garen  wrote:

> > Just a note:
> >
> > In Chrome, a SharedWorker is reachable from any WebKit process, whereas a
> SharedScript would only be reachable within a WebKit process.  This is an
> interesting distinction, and I can imagine some use cases for SharedWorker
> that SharedScript could not address.  (This distinction arises because we
> did not want to build a script proxy between WebKit processes as that would
> be quite costly.)
> >
> > For example, suppose you wanted to have only one instance of a web app
> responsible for manipulating a database or communicating with a server.
>  There's no guarantee that multiple instances of a web app would all run in
> the same WebKit process.
>
> Actually, I objected to that distinction, and it has been removed from the
> specification.
>
> You can find the discussion here:
> https://bugs.webkit.org/show_bug.cgi?id=31317.
>
> And the specification here:
> http://docs.google.com/View?id=dxv3cth_4gvggh3gh.
>
> I'm concerned that a lot of Chrome engineers are speaking for "Google", but
> they don't really have their stories straight. First, a group of Chrome
> engineers said that "Google" needed SharedWorker, so it was implemented in
> WebKit. Now, a group of Chrome engineers says "Google" can't use
> SharedWorker, and needs SharedScript instead. So, we're gearing up to
> implement that. Meanwhile, not all Chrome engineers agree about what
> SharedWorker is or why it is that way, and we can reasonably assume that the
> actual Google engineers who have asked for these technologies disagree even
> more.
>
> It's OK to disagree and hash out ideas. But it's a little weird to try to
> dictate the direction of WebKit in the name of "Google" and "several major
> apps with millions of users", when that standard seems to blow whichever way
> the wind goes.
>
> Geoff
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] GlobalScript in WebKit

[Dmitry Titov]

We could name a couple of big ones (GMail was already mentioned before),
they already have designs ready to go into test as soon as they get
SharedScript in a dev build. If there was no desire from actual app
developer teams for SharedScript, we would not have the reason to continue
with it long time ago.

That also pretty much means if we won't do SharedScript, we'll need to
explore other opportunities toward efficient sharing of code and data which
does not make people to write a multithreaded UI as SharedWorker solution
would do. We have practically zero positive response to SharedWorkers being
used this way. Granted, this is "just one company" but the limited
unscientific poll kind of shows the direction...

On Mon, Nov 30, 2009 at 1:58 PM, Jeremy Orlow  wrote:

> On Mon, Nov 30, 2009 at 1:54 PM, Geoffrey Garen  wrote:
>
>> > There are a lot of people inside Google that have a lot of experience
>> with web standards, browsers, and web apps that seem to think this is useful
>> and worth the effort to experiment with it.
>>
>> Who exactly inside Google is waiting to build a new service, feature, or
>> experiment using SharedScript?
>>
>
> I don't think we can or should have to say specifically, but several major
> apps with millions of users.
>
> ___
> 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] GlobalScript in WebKit

[Dmitry Titov]

What I meant was it would be nice, for the sake of discussion, to share the
experience of real life applications that used SharedWorkers or inter-window
communications for sharing of significant portions of code and data. Google
apps may be a partial example but it is a real life example of concrete
issues with proposed solution that sounds pretty generic and useful for
other web apps. It is only prudent to take their feedback rather then
replace it with our own theories about future of the web. No doubt this is a
new mechanism and it's good to question it, since it has costs even as
experimental API. Gut feelings vary, some app devs say they need it to solve
real issues, we dont hear from other app devs who were facing similar issues
and solved it differently. Seems there is no strong argument to kill it nor
bless it. Why don't make it experimental and see? If it was possible to
implement it in extension or plugin, we would run it as another Gears-like
experiment, but it can not be done in a plugin... I believe there could be
good arguments that simply didn't surface yet, and hope to hear them.
Dmitry.

On Wed, Nov 25, 2009 at 10:16 PM, Peter Kasting  wrote:

> On Wed, Nov 25, 2009 at 9:41 PM, Dmitry Titov  wrote:
>
>> BTW, could you tell what's the 'course' that would be reverted?
>
>
> Meaning, "before we decide that SharedWorkers and inter-window
> communication are insufficient, and a further proposal should be entertained
> by the standards community".
>
> PK
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] GlobalScript in WebKit

[Dmitry Titov]

Hi Sam!

Thanks a lot for sharing your perspective! I really wish your reply
had, in addition to the statement of the opinion, an argument or just
more explanation of why you think so. I think we covered SharedWorkers
and inter-window communication in the previous discussions and in the
design doc.

BTW, could you tell what's the 'course' that would be reverted?

Dmitry


On Wed, Nov 25, 2009 at 8:30 PM, Sam Weinig  wrote:
> Hi Dmitry,
> As I have noted to others on the Chrome team, I do not think this is good
> idea and I don't think we should have it in WebKit.  It adds extra
> complexity to WebKit and gives little beyond what is possible using
> inter-window communication and SharedWorkers. I think we need to give more
> time for large applications to adopt designs around workers before we
> reverse course, at which point, we should again discuss this in the
> standards community.
> -Sam
>
> On Thu, Nov 19, 2009 at 10:35 PM, Dmitry Titov  wrote:
>>
>> Hi webkit!
>> I'm starting to work on actual implementation of GlobalScript experimental
>> API and started to post patches (hopefully in reviewable portions). There is
>> an uber-bug which has plan of implementation.
>> The current plan is to get it in under ENABLE_GLOBAL_SCRIPT, with both JSC
>> and v8 bindings (first with JSC because at the moment JSC bindings are
>> easier to work with and I'd wish WebKit not to have 1-engine-only features
>> ever).
>> I'd be glad to know if there are suggestions, ideas or concerns of any
>> kind... For example, if there is no interest in JSC bindings, it can be hard
>> to get them reviewed by someone who knows them well. It'd be better to know
>> that earlier.
>> Thanks!
>> Dmitry
>> ___
>> 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] GlobalScript in WebKit

[Dmitry Titov]

Hi webkit!

I'm starting to work on actual implementation of GlobalScript experimental
API  and started to post
patches (hopefully in reviewable portions). There is an
uber-bugwhich has plan
of implementation.

The current plan is to get it in under ENABLE_GLOBAL_SCRIPT, with both JSC
and v8 bindings (first with JSC because at the moment JSC bindings are
easier to work with and I'd wish WebKit not to have 1-engine-only features
ever).

I'd be glad to know if there are suggestions, ideas or concerns of any
kind... For example, if there is no interest in JSC bindings, it can be hard
to get them reviewed by someone who knows them well. It'd be better to know
that earlier.

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

Re: [webkit-dev] ThreadIdentifier abstraction is inefficient

[Dmitry Titov]

On Thu, Oct 29, 2009 at 3:10 PM, Anton Muhin  wrote:

> ens,
>
> Somewhat aside from ThreadIdentifier.
>
> Actually, at least for now, there should be no invocations of
> WTF::currentThread() at least for the renderer---everything should run
> in the same thread.


That sounds right. Same for Chromium Worker processes. Some time ago we
tried to run workers in the same process as renderer, or several workers in
the Worker process using v8 locking. It didn't work well so we abandoned the
idea. Seems like some good cleanup could help, nothing is as fast as not
running the code! :-)

As for previous attempt to fix the issue, there were 2 main concerns (to
recap):

- pthread_t is reused by some OSes between threads so comparing thread ids
may give false matches in case we just use pthread_t as TheradIdentifier.

- Safari apparently uses WTF directly from JSC and changing binary interface
and especially subtle protocol details will likely break nightly builds.
Optimally, someone with visibility into both codebases could fix this with
more confidence. Alternatively, perhaps such services as threading could be
provided by the embedder via WebKit API rather then implemented in WTF -
since embedders need access to the same time/thread services as the rest of
WebKit.

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

Re: [webkit-dev] Runtime setting for incomplete features

[Dmitry Titov]

On Mon, Oct 5, 2009 at 9:48 PM, Sam Weinig  wrote:

I would still very much like a good solution to runtime enabling/disabling
> features in the bindings as I think this would be a useful addition to the
> webkit arsenal and I am curious why it is thought that doing it right will
> be prohibitively expensive (it may very well be, I just don't know why that
> is).
>

This is a good question, I don't see also why it will be very difficult...
It seems most of the features we are talking about are exposed off window
object that already has custom getters. Also, if it can be assumed that the
flags don't change during lifetime of the browser process (which is true for
Chromium-like command-line flags) then it is not needed to reset script
state and caches on change. It might be not a very complex change...

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

[webkit-dev] window.open issues in DRT?

[Dmitry Titov]

One (quite old) change - http://trac.webkit.org/changeset/25793 - has
changed tests using window.open to use iframes instead, apparently because
of some difficulty in DRT with closing windows...
I'm finding myself creating tests using window.open(). Can anybody remember
if those difficulties were fixed or what they are? The change does not
explain what was the issue...

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

Re: [webkit-dev] GlobalScript API.

[Dmitry Titov]

>
> This actually displays one of the issues i have with global script as a
>> concept, you are basically just doing
>>
>> And that gives you a context that achieves almost everything the global
>> script concept gives you.
>>
>
> People keep saying that this is no better than a new window or an iframe
> because you can script those synchronously across pages, but that totally
> misses the point. The the frame/script/window survives when it's parent page
> is closed if there's another page pointing to it and, in some versions of
> this proposal, it survives same-origin page navigations. That isn't true of
> iframes or windows and is exactly what makes these useful.
>

This is exactly right, the most interesting aspect is its lifetime that
makes it a nice place to call 'the application'. It can keep the app state
while pages navigate between each other, making browser history and page
cache just work.  And it can make windows independent of each other without
loading the whole app in each of them...

There was an interesting
presentationfrom
Facebook folks at O'Reilly Velocity conference (pdf
slides here )
where they describe 'quicklings' - the elaborate way to avoid full page
loads. Also they try to cache as much as possible in the 'live' form in
memory - so they can keep those fast caches up to date. This is similar to
what many applications are doing today - trying to keep a single 'main' page
alive and inventing their incarnations of navigation and history. Global
Script could be useful there as a replacement for those ad-hoc mechanisms.

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

Re: [webkit-dev] GlobalScript API.

[Dmitry Titov]

On Tue, Sep 1, 2009 at 8:07 PM, Maciej Stachowiak  wrote:

>
> instead of
> var globalScript = new webkitGlobalScript(name, url, loadHandler,
> errorHandler);
>
> to have this:
>  onerror=...>
>
> The first tag with a specific name that provides a src or inline script or
> injected with innerText would effectively supply 'initial script'. The
> later-encountered tags withthe same name would have their initial script
> ignored and simply connected to the same one. The tag's DOM element would be
> EventTarget (for load and error) and have a 'context' property to pull the
> global scope object of the script.
>
>
> Why is a tag better for this than a constructor or function?
>

I'm not saying it's better. The tag idea was brought more then once before
so I think it is worth considered.I think the motivation behind it is to be
able to hook up event handlers before loading ends to be notified when the
context is ready. Constructor with callbacks can do the similar thing, imo.

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

Re: [webkit-dev] GlobalScript API.

[Dmitry Titov]

Thanks a lot Maciej!
As a note to the API described in this thread: there was a proposal in
private thread to replace the JS constructor with 4 parameters with a tag:

instead of
var globalScript = new webkitGlobalScript(name, url, loadHandler,
errorHandler);

to have this:


The first tag with a specific name that provides a src or inline script or
injected with innerText would effectively supply 'initial script'. The
later-encountered tags withthe same name would have their initial script
ignored and simply connected to the same one. The tag's DOM element would be
EventTarget (for load and error) and have a 'context' property to pull the
global scope object of the script.

Dmitry

On Mon, Aug 31, 2009 at 7:18 PM, Maciej Stachowiak  wrote:

>
> On Aug 31, 2009, at 6:09 PM, Dmitry Titov wrote:
>
> Hi WebKit-dev,
>
> I'm hoping to get your advice on Global Script proposal and how to start
> implementing it as an 'experimental API' since it's not standardized yet.
>
> As part of work on Workers in WebKit and Chromium, we discussed them with
> our web application folks (mostly gmail). We came to the idea that in
> addition to workers, they need a shared script context which runs on the
> same UI thread and directly scriptable.
>
> Our previous take (with an invisible window running all the time in the
> background) was not that fruitful but it indicated the way to go. We are
> thankful to the members of the whatwg community for the detailed threat
> analysis of 'permanently running invisible pages', it helped very much. Not
> right away but it was absorbed :-) Current proposal reflects realization
> that there is a less-powerful way to achieve the same benefits.
>
> I'm looking for a way to implement it as an experimental API in WebKit and
> Chromium. I'm thinking it can go the similar way as webkitNotifications -
> surrounded by ENABLE(GLOBAL_SCRIPT) and prefixed with 'webkit' to keep the
> difference.
>
>
> Here's what I think we should take a look at:
>
> 1) Does this proposal have a potential standards-track future? Relevant
> specific issues would be interest from other browser vendors and standards
> folks, interest from content producers, and our own degree of confidence
> that this is the right approach. Note: in some cases a prototype can be the
> best way to address concerns, however. In some cases we're willing to add
> proprietary extensions that have little hope of ever becoming a standard,
> but almost always we do this for the sake of non-browser use.
>
> 2) Do we have some agreement in the WebKit community that this is a good
> approach? It would be good for us to do some of our own design review, if
> this isn't going to be a standard in the foreseeable future.
>
> If we are optimistic about the future, then an ENABLE macro and a WebKit
> prefix would be a good way to handle things.
>
> I will do some detailed design review soon.
>
> Regards,
> Maciej
>
>
> I'd appreciate much your advice on the whole API and on the way to bring it
> into WebKit.
>
> Here is a link to the whatwg thread, with the proposal and use cases:
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/022113.html
>
> Here is an actual API:
> ---
> Page-level API
>
> var globalScript = new webkitGlobalScript(name, url, loadHandler,
> errorHandler);
>
> This returns a global scope object for the named Global Script.
> If one does not exist yet, creates a new one. The globalScript is
> sharing same process and same thread as the page running the constructor
> and is operational right away. No synchronization is necessary.
> Parameters:
> name - string identifying the global script. Scoped to the orogin.
> url  - the JS resource to load, if it was not yet loaded. If the Global
> Script is already loaded but from a different url - the error is raised.
> laodHandler - a function called asynchronously when the script is loaded
> (or if it was already loaded by another page)
> errorHandler - handler for loading errors, like violation of same-origin
> policy or network error
>
> The GlobalScript would create its own ScriptExecutionContext-derived
> context if it was not yet created, and start to load the script into it.
> Once the script is loaded, it is evaluated in the global scope of the Global
> Script and loadHandlers are executed. Other pages that create a Global
> Script with the same name in the same origin would get the same object back.
>
> The globalScript object returned from the constructor can be immediately
> used to set/retrieve properties and event handlers on it.
>
> API exposed to Global Script (on its global scope object)
> -

Re: [webkit-dev] GlobalScript API.

[Dmitry Titov]

Ian also said (and I agree with him) that experimental implementation is
needed. In fact if he added it to HTML5 already I'd be very surprised. For
example, the notifications were removed from HTML5 because it was not clear
to the point of writing the spec that they are even needed (as Ian said
also). A lot of HTML5 is there because there were Gears with real-life
experience. It's hard to see if any web mechanism will prove it viability
purely theoretically. So all we are trying to do is take the feedback from
app developers, produce a proposal, discuss it in the community to refine
it, produce implementation and see how it goes so it can be included into
HTML x at some point. It might not stand the test of time and not be
standardized at the end, or it might influence some other idea - who knows?
Nobody is 'pushing ahead' :-)
Dmitry

On Mon, Aug 31, 2009 at 6:18 PM, Peter Kasting  wrote:

> On Mon, Aug 31, 2009 at 6:09 PM, Dmitry Titov  wrote:
>
>> I'm hoping to get your advice on Global Script proposal and how to start
>> implementing it as an 'experimental API' since it's not standardized yet.
>>
>
> That sounds a little optimistic when so far the feedback from Hixie is "I
> haven't added the Global Script Object proposal to HTML5. ... I really don't
> think it is the direction we should be taking the platform in."  I realize
> that there have been subsequent comments objecting to that viewpoint, I'm
> just saying that pushing boldly ahead seems... early.
>
> PK
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] GlobalScript API.

[Dmitry Titov]

Hi WebKit-dev,

I'm hoping to get your advice on Global Script proposal and how to start
implementing it as an 'experimental API' since it's not standardized yet.

As part of work on Workers in WebKit and Chromium, we discussed them with
our web application folks (mostly gmail). We came to the idea that in
addition to workers, they need a shared script context which runs on the
same UI thread and directly scriptable.

Our previous take (with an invisible window running all the time in the
background) was not that fruitful but it indicated the way to go. We are
thankful to the members of the whatwg community for the detailed threat
analysis of 'permanently running invisible pages', it helped very much. Not
right away but it was absorbed :-) Current proposal reflects realization
that there is a less-powerful way to achieve the same benefits.

I'm looking for a way to implement it as an experimental API in WebKit and
Chromium. I'm thinking it can go the similar way as webkitNotifications -
surrounded by ENABLE(GLOBAL_SCRIPT) and prefixed with 'webkit' to keep the
difference.

I'd appreciate much your advice on the whole API and on the way to bring it
into WebKit.

Here is a link to the whatwg thread, with the proposal and use cases:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/022113.html

Here is an actual API:
---
Page-level API

var globalScript = new webkitGlobalScript(name, url, loadHandler,
errorHandler);

This returns a global scope object for the named Global Script.
If one does not exist yet, creates a new one. The globalScript is
sharing same process and same thread as the page running the constructor
and is operational right away. No synchronization is necessary.
Parameters:
name - string identifying the global script. Scoped to the orogin.
url  - the JS resource to load, if it was not yet loaded. If the Global
Script is already loaded but from a different url - the error is raised.
laodHandler - a function called asynchronously when the script is loaded (or
if it was already loaded by another page)
errorHandler - handler for loading errors, like violation of same-origin
policy or network error

The GlobalScript would create its own ScriptExecutionContext-derived context
if it was not yet created, and start to load the script into it. Once the
script is loaded, it is evaluated in the global scope of the Global Script
and loadHandlers are executed. Other pages that create a Global Script with
the same name in the same origin would get the same object back.

The globalScript object returned from the constructor can be immediately
used to set/retrieve properties and event handlers on it.

API exposed to Global Script (on its global scope object)
- Timers
- XHR
- Navigator
- localStorage
- Database
- Workers
-

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

Re: [webkit-dev] I *HATE* CHANGELOGS!!!

[Dmitry Titov]

Arguably a text file is the simplest and most reliable way to keep a log
over time and across tools and platforms. Things happen to databases
(bugzilla!) more often then to plain text files. It seems there are ways to
reduce the merging hassle using better tools/process.

+1 to having a single ChangeLog though! Also, this can be done independently
from other improvements.

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

Re: [webkit-dev] SharedWorkers alternate design

[Dmitry Titov]

>
> I think there is still little clarity around the appcache behavior (dimich:
>> are you bring over your "shadow frame" concept to webkit?).
>>
>
> I'm wondering about bringing the 'shadow frame' technique to webcore too?
>

If needs be :-)

Just to explain what is meant by 'shadow frame' (I'm not sure it was
discussed in webkit-dev beore): to provide access to FrameLoader in Chrome's
Worker process (which loads WebKit but doesn't load any html, just creates a
worker out of JS string), we create a WebView and load it from a (url,
encoding, mimtype, data) source with empty data and the worker's url. This
creates a frame with a an empty document but with a right origin and
encoding. This makes it possible to create a ThreadableLoader (and
underlying DocumentThreadableLoader) w/o aceess to the original worker's
parent. This loader is used to implement XHR and importScripts in Chrome
workers. Oriinally a Darin Fisher's idea, it was implemented as alternative
to rollign out a new frame-less loader.

Shared workers can use the same approach since they can not forever hold the
ref to the 'creating' document.

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

Re: [webkit-dev] Expected behavior of Mutex.lock()

[Dmitry Titov]

Then perhaps all implementations could ASSERT in debug on mutex reentrancy
to help discover where differences in behavior are accidentally 'used' (a
stuck thread may sometimes mask some other issues).

It's not good to have this kind of differences in 'cross-platform' code,
sooner or later it'll cause very cryptic bugs, especially since developers
with Windows background take reentrancy of critical section for granted.

Dmitry

On Tue, Jun 9, 2009 at 11:34 AM, Jeremy Orlow  wrote:

> I actually had exact the same question (but never got around to asking it).
>
> Given that pthreads' implementation is more strict, it'd seem like mutexes
> are not supposed to be reentrant.  Maybe the windows version should ASSERT
> on reentrancy when in debug mode?
>
>
> On Tue, Jun 9, 2009 at 11:09 AM, Drew Wilson  wrote:
>
>> Any insights here? I'd be happy to add some documentation to Mutex if
>> someone can verify what the intended behavior is...
>> -atw "sending emails to webkit-dev during WWDC is probably futile, I know
>> :)"
>>
>>
>> On Sat, Jun 6, 2009 at 8:57 AM, Drew Wilson  wrote:
>>
>>> I can't seem to find any documentation as to what the expected behavior
>>> of Mutex.lock() is with regard to calling lock() recursively on the same
>>> thread.
>>> Looking at the pthreads implementation, it appears that when we create
>>> the mutex we pass null as the attributes, which gives us the default
>>> behavior (not re-entrant).
>>>
>>> The Windows implementation uses EnterCriticalSection which *is*
>>> re-entrant.
>>>
>>> I'm assuming that the pthreads implementation is the correct one (calling
>>> Mutex.lock() twice on the same mutex on a single thread should deadlock the
>>> thread) but I wanted to verify this since the implementations seem to vary.
>>>
>>> -atw
>>>
>>
>>
>> ___
>> 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] Multithread issue

[Dmitry Titov]

WebKit uses thread-specific data in quite a few cases so objects in general
expect to be created, used and destroyed on the same thread. One of such
examples are timers, frequently used as deferred tasks. Creating a view and
loading a url into it likely creates one or more of such timers whihc are
stored in thread-specific list. So the code verifies that we are still
accessing the thread-specific list on the same thread on which we were
creating the timer.

Can you create view on the same thread where gtk_main is called?

Dmitry


On Wed, May 27, 2009 at 5:17 AM, Matt Bockt  wrote:

> Hi everybody,
>
> I'm new to WebKit and I'm developing a C++ application that uses the WebKit
> browser.
>
> It runs on Fedora10, kernel 2.6.27.5-117.fc10.i686.
> The WebKit version I'm using is the r44111.
>
> Here is my problem : I'm creating a new web view in the main thread, say,
> thread A.
> The webview is then attached to a gtk_window as it's made in the
> GtkLauncher exemple.
>
> Then webkit_web_view_load_uri() is called, always in thread A.
>
> Finally, the gtk_main() function is called in another thread, say thread B.
>
> And it crashes  with the following trace  :
>
> ASSERTION FAILED: m_thread == currentThread()
> (WebCore/platform/Timer.cpp:206 bool WebCore::TimerBase::isActive() const)
>
> I experience this problem with the webkit r44111 and r43808, but not with
> r38297.
>
> I noticed that there must have been a modification in the thread management
> between the builds r38297 and r43808 since g_threads must be initialized.
> But I can't figure out why it doesn't work.
>
> Any suggestions or specific rules to follow about multi-threading, gtk and
> webkit ?
>
> Thank you for your help.
>
> --
> matt
>
> ___
> 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 to create a test for a "missing layout update" bug?

[Dmitry Titov]

Hi WebKit,
I hope you can help me with ideas on how to create a test for the bug where
layout update does not happen (https://bugs.webkit.org/show_bug.cgi?id=24453
).

The bug is caused by timeout code using Document::updateRendering() instead
of Document::updateDocumentsRendering() so it can miss the actually changed
document. However, many things trigger layout so any attempt to dump the
render tree, use layoutTestController::display() etc do not 'catch' the
buggy behavior since all of them trigger layout. I have a test that is based
on extending layoutTestController to expose FrameView::needsLayout() but it
does not feel right to me to expose internals.

Perhaps anybody had a need to write a test for missing layout update
before.. I would appreciate all possible ideas about it!

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

Re: [webkit-dev] Using LGPL-derived source in one of the wtf files.

[Dmitry Titov]

As far as I understand it, it is indeed covered:
1. The file contains BSD license at the top for the whole file.
2. It also includes the original LGPL license of the code that was used to
derive a portion of the implementation.

I'm not a lawyer, but it seems to be all right.

Dmitry

On Mon, Jan 19, 2009 at 12:26 PM, Darin Adler  wrote:

> On Jan 19, 2009, at 12:12 PM, Dmitry Titov wrote:
>
>  In the proposed patch the ThreadingWin.cpp would contain 2 licenses -
>> standard WebKit one and a copy of Pthread-win32 license (LGPL). The latter
>> is there because the code for ThreadCondition is derived from the sources of
>> that library (removing the need to pull in the whole library for 50 lines of
>> code).
>>
>> Does this idea look acceptable? Can we use LGPL'ed source this way and how
>> should we go about the license if we can?
>>
>
> The WebKit contribution terms are on the attachment creation page in
> bugs.webkit.org:
>
>1) If you are sending in a patch to existing WebKit code, you agree
> by clicking below that your changes are licensed under the existing license
> terms of the file you are modifying (i.e., BSD license or GNU Lesser General
> Public License v.2.1, LGPL v. 2.1). Please also add your copyright (name and
> year) to the relevant files for changes that are more than 10 lines of code.
>2) If you are sending in a new file for inclusion in WebKit (no code
> copied from another source), the preferred license is BSD, but LGPL 2.1 is
> an option as well. Please include your copyright (name and year) and license
> preference (BSD or LGPL 2.1). By clicking below you agree that your file is
> licensed under either the BSD license or LGPL 2.1, as indicated in your
> file.
>3) If you aren't the author of the patch, you agree to include the
> original copyright notices and licensing terms with it, to the extent that
> they exist. If there wasn't a copyright notice or license, please make a
> note of it. Generally we can only take in patches that are BSD- or
> LGPL-licensed in order to maintain license compatibility within the project.
>
> Is there something in this case that isn't covered by those terms?
>
>-- Darin
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] Using LGPL-derived source in one of the wtf files.

[Dmitry Titov]

Hi,
There was an IRC discussion about
https://bugs.webkit.org/show_bug.cgi?id=23373, and there was no clear
solution..

In the proposed patch the ThreadingWin.cpp would contain 2 licenses -
standard WebKit one and a copy of Pthread-win32 license (LGPL). The latter
is there because the code for ThreadCondition is derived from the sources of
that library (removing the need to pull in the whole library for 50 lines of
code).

Does this idea look acceptable? Can we use LGPL'ed source this way and how
should we go about the license if we can?

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

Re: [webkit-dev] Change WTF::ThreadCondition::timedWait to use absolute time?

[Dmitry Titov]

Good point. The double as used in SystemTime.h looks right indeed.
On Tue, Dec 30, 2008 at 10:31 PM, Darin Adler  wrote:

> On Dec 30, 2008, at 6:21 PM, Dmitry Titov wrote:
>
>  bool ThreadCondition::timedWait(Mutex& mutex, const struct timespec
>> *timeoutTime)
>>
>
> It seems OK, roughly speaking, but I don't think that will achieve the
> platform independence goals of the Threading.h header. The type timespec is
> not necessarily a suitable one for use on all the different platforms we
> support. So even if it's an absolute time, we might want to use a double
> rather than a timespec. But we'd probably need to move currentTime from
> WebCore/platform/SystemTime.h to somewhere in JavaScriptCore/wtf to serve as
> a timebase.
>
>-- Darin
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] Change WTF::ThreadCondition::timedWait to use absolute time?

[Dmitry Titov]

For worker implementation of "run loop", I am looking to implement
MessageQueue::waitForMessageWithTimeout(), where timeout would be computed
from the the JS timer with nearest expiration. I am looking at using
WTF::ThreadCondition::timedWait for implementation but it seems it is not
implemented right... Before trying to send a patch, I'd like to ask here to
validate the idea.

It is defined with 'secondsToWait':


bool ThreadCondition::timedWait(Mutex& mutex, double secondsToWait)

while a corresponding pthread function takes absolute time:


int  pthread_cond_timedwait(pthread_cond_t *, pthread_mutex_t *, const
struct timespec *);

 The reason pthread function takes abs time is because pthread's function
can return 'spuriously'. I think the reason is that most implementation lack
the atomic "wake up and re-acquire the mutex" operation, so the conditions
can change between waking up and re-acquiring the mutex - and the wait can
return while in fact it should have not. Here is a piece of pthread doc (
https://computing.llnl.gov/tutorials/pthreads/man/pthread_cond_timedwait.txt
):

  When using condition variables there  is  always  a  Boolean
predicate  involving
   shared  variables  associated  with each condition wait that is
true if the thread
   should  proceed.   Spurious   wakeups   from   the
pthread_cond_timedwait()   or
   pthread_cond_wait() functions may occur. Since the return from
pthread_cond_timed-
   wait() or pthread_cond_wait() does not imply anything  about
the  value  of  this
   predicate, the predicate should be re-evaluated upon such return.

That means the waiting should always be done in a loop, checking if
the thread can actually proceed and if not, call wait function again,
like here:

bool MessageQueue::waitForMessage()

{

MutexLocker lock(m_mutex);

while (m_queue.isEmpty())

m_condition.wait(m_mutex);

.. consume message ...

}

 In case of timed wait it means the absolute time should be computed
before such loop, and it explains why pthreads have timed wait
function with absolute time as a parameter. That means WTF timedWait
method should change prototype to take absolute time:

bool ThreadCondition::timedWait(Mutex& mutex, const struct timespec
*timeoutTime)

Then it's possible to implement blocking
MessageQueue::waitForMessageWithTimeout() to return exactly after
specified timeout or with a message.

Ok to change?

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

Re: [webkit-dev] Timer callback and 'this' object

[Dmitry Titov]

Thanks Sam,
I've sent a patch with a test.

Dmitry

On Mon, Dec 1, 2008 at 7:23 PM, Sam Weinig <[EMAIL PROTECTED]> wrote:

> Hi Dmitry,
> The first example using a closure executes in the parent scope because
> functions execute in lexical scope regardless of where they are called from,
> capturing variables as required.  The string version is simply executed as a
> program by the caller and has no knowledge of the scope in which it was
> declared.  This is a bit strange, but follows the conventions of the
> language.  As for the test, tests are always welcomed, especially for odd
> edges like this.
>
> -Sam
>
> On Mon, Dec 1, 2008 at 8:08 PM, Dmitry Titov <[EMAIL PROTECTED]> wrote:
>
>> Hi webkit-dev,
>>
>> I'm looking at JS timeout code and found a callback behavior that seems
>> strange. Not sure if it is intentional.
>> If timeout is set on a 'window' object from another frame and timeout
>> callback is specified as a JS string, it is executed "inside the frame"...
>> So the context of execution is different depending how the callback is
>> specified.
>>
>> Here is html (also attached) that loads an empty IFRAME and sets 2
>> timeouts on that iframe's window - as a JS closure and as JS string. In
>> former case, the callback runs in the main page (expected, since the JS
>> closure 'captures' the context in which it is defined), in the latter-
>> inside iframe (a bit weird?). So the text goes in both "body" elements.
>>
>> Is there a reason why JS string is evaluated in the inner context of the
>> iframe? Would a test verifying this behavior be a good thing? Curiously, IE
>> and FF behave the same way.
>>
>> 
>> 
>> function test() {
>>   // Get the iframe's window.
>>   var iframeWindow = window.frames["testIframe"];
>>
>>   // setTimeout with a closure as callback.
>>   iframeWindow.setTimeout(
>> function() {
>>   if (!document.body)
>> document.write('<body></body>');
>>   document.body.appendChild(document.createTextNode('Timer 1
>> fired.'));}, 1);
>>
>>   // setTimeout with a JS string containing similar code.
>>   iframeWindow.setTimeout(
>>  "if (!document.body)" +
>>  "  document.write('<body></body>');" +
>>  "document.body.appendChild(document.createTextNode('Timer 2
>> fired.'));", 1);
>> }
>> 
>> 
>> 
>> 
>> 
>>
>>
>> Thanks,
>> Dmitry
>>
>> ___
>> 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] Timer callback and 'this' object

[Dmitry Titov]

Hi webkit-dev,

I'm looking at JS timeout code and found a callback behavior that seems
strange. Not sure if it is intentional.
If timeout is set on a 'window' object from another frame and timeout
callback is specified as a JS string, it is executed "inside the frame"...
So the context of execution is different depending how the callback is
specified.

Here is html (also attached) that loads an empty IFRAME and sets 2 timeouts
on that iframe's window - as a JS closure and as JS string. In former case,
the callback runs in the main page (expected, since the JS closure
'captures' the context in which it is defined), in the latter- inside iframe
(a bit weird?). So the text goes in both "body" elements.

Is there a reason why JS string is evaluated in the inner context of the
iframe? Would a test verifying this behavior be a good thing? Curiously, IE
and FF behave the same way.



function test() {
  // Get the iframe's window.
  var iframeWindow = window.frames["testIframe"];

  // setTimeout with a closure as callback.
  iframeWindow.setTimeout(
function() {
  if (!document.body)
document.write('');
  document.body.appendChild(document.createTextNode('Timer 1
fired.'));}, 1);

  // setTimeout with a JS string containing similar code.
  iframeWindow.setTimeout(
 "if (!document.body)" +
 "  document.write('');" +
 "document.body.appendChild(document.createTextNode('Timer 2
fired.'));", 1);
}







Thanks,
Dmitry





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

Re: [webkit-dev] Proposed Timer API

[Dmitry Titov]

Since our systems are not real-time, saying 'hi-res timer' and 'event
dispatching' together may need some clarification.
Lets say we set delay=0.001 - but not every system can guarantee that the
timer event will fire at precise 1 ms interval. So it can "skip a bit" or
fire at longer delay, then continue at 1 and so on. Some systems may skip
more then a bit :-) That's why popular way to implement animations is to
request high frequency callback and query hi-res timer from the handler for
actual advance calculation...
The spec could explicitly point that out ('delay' -> 'delayAtLeast' ?), and
perhaps recommend to use Date() in the event handler to see what is the
actual time of firing, or have an 'eventTime' property on an Event object.

On a separate note, it almost feels that just adding
invokeAsSoonAsPossible(handler) that is equivalent to unclamped
setTimeout(..., 0) could be all that's needed.

Dmitry

On Wed, Oct 1, 2008 at 9:59 AM, Justin Haygood <[EMAIL PROTECTED]> wrote:

>
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Maciej
> Stachowiak
> Sent: Wednesday, October 01, 2008 1:02 PM
> To: Darin Adler
> Cc: WebKit Development
> Subject: Re: [webkit-dev] Proposed Timer API
>
>
> On Oct 1, 2008, at 9:58 AM, Darin Adler wrote:
>
> > On Oct 1, 2008, at 9:16 AM, Mike Belshe wrote:
> >
> >> If you're going to propose a new API designed for hi-res timers, it
> >> ought to use units of microseconds instead of milliseconds.
> >
> > Or units of seconds, perhaps? Since JavaScript numbers are already
> > floating point.
>
> That's what I would propose. Then browsers can offer greater precision
> in the future without having to redesign the API.
>
> ---
>
> Updating now. Units of seconds. Precisision is browser defined, but will be
> higher precision (or same precision) as setInterval/setTimeout.
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>



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