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
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
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=81590for
removal of the 'magic iframe' feature
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 jar...@webkit.org wrote:
Well I was just about to follow up that from the east coast on Comcast
bbone, I'm pulling at acceptable rates from
It will work, but you need to add more to it, like this:
?php
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(scriptparent.reportLoading('start')/script);
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,
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 le...@chromium.org wrote:
On Wed, Jul 7, 2010 at 5:24 PM, Peter Kasting pkast...@google.comwrote:
On Wed, Jul 7, 2010 at 5:00 PM, Dmitry Titov dim...@chromium.orgwrote
On Mon, May 10, 2010 at 5:48 PM, Daniel Cheng dch...@chromium.org 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
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
On Mon, Mar 29, 2010 at 5:26 PM, Darin Adler da...@apple.com 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
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
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
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
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
On Tue, Mar 9, 2010 at 11:13 AM, Alexey Proskuryakov a...@webkit.org 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
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
On Mon, Mar 8, 2010 at 11:38 AM, Alexey Proskuryakov a...@webkit.org 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
, Mar 8, 2010 at 1:24 PM, Dmitry Titov dim...@chromium.org wrote:
On Mon, Mar 8, 2010 at 11:38 AM, Alexey Proskuryakov a...@webkit.orgwrote:
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
types?
-atw
On Mon, Mar 8, 2010 at 2:08 PM, Dmitry Titov dim...@chromium.org 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
On Thu, Feb 25, 2010 at 9:48 AM, Jochen Eisinger joc...@chromium.orgwrote:
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
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
+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
On Tue, Dec 15, 2009 at 12:06 PM, Maciej Stachowiak m...@apple.com wrote:
On Dec 15, 2009, at 11:09 AM, Michael Nordman wrote:
On Mon, Dec 14, 2009 at 9:16 PM, Darin Fisher da...@chromium.org wrote:
I think that use case has been de-emphasized. However, if we wanted to
support it, we'd
Thanks for sharing your thoughts!
On Fri, Dec 11, 2009 at 2:44 AM, Jeremy Orlow jor...@chromium.org wrote:
On Thu, Dec 10, 2009 at 6:48 PM, Dmitry Titov dim...@chromium.org wrote:
Hi webkit-dev!
Trying to add ASSERTS to RefCounted objects (
https://bugs.webkit.org/show_bug.cgi?id=31639
On Thu, Dec 10, 2009 at 11:09 AM, Eric Uhrhane er...@chromium.org wrote:
On Wed, Dec 9, 2009 at 6:55 PM, Dmitry Titov dim...@chromium.org wrote:
Thanks for the link to the prototype code!
If I understand it right and the DatabaseManager can not have any other
relationship
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)
{
On Wed, Dec 9, 2009 at 12:58 PM, Eric Uhrhane er...@chromium.org 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
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 er...@chromium.org wrote:
On Wed, Dec 9, 2009 at 4:11 PM, Dmitry Titov dim...@chromium.org wrote
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
On Mon, Nov 30, 2009 at 10:24 PM, Oliver Hunt oli...@apple.com 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,
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
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
On Mon, Nov 30, 2009 at 5:21 PM, Maciej Stachowiak m...@apple.com 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
:
On Wed, Nov 25, 2009 at 9:41 PM, Dmitry Titov dim...@chromium.org 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.
-Sam
On Thu, Nov 19, 2009 at 10:35 PM, Dmitry Titov dim...@chromium.org 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
Hi webkit!
I'm starting to work on actual implementation of GlobalScript experimental
API http://docs.google.com/View?id=dxv3cth_2rnj9wffz and started to post
patches (hopefully in reviewable portions). There is an
uber-bughttps://bugs.webkit.org/show_bug.cgi?id=31317which has plan
of
On Thu, Oct 29, 2009 at 3:10 PM, Anton Muhin ant...@chromium.org 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.
On Mon, Oct 5, 2009 at 9:48 PM, Sam Weinig sam.wei...@gmail.com 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
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
This actually displays one of the issues i have with global script as a
concept, you are basically just doingiframe src=.../..
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
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
pkast...@google.com wrote:
On Mon, Aug 31, 2009 at 6:09 PM, Dmitry Titov dim...@chromium.org 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
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
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
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
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
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
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
Good point. The double as used in SystemTime.h looks right indeed.
On Tue, Dec 30, 2008 at 10:31 PM, Darin Adler da...@apple.com 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
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
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
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
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
53 matches
Mail list logo
