02.06.2009, в 1:29, Michael Nordman написал(а):
What is the use case for this? It doesn't seem useful to me - to
invoke update explicitly, one
normally needs to have UI anyway, at which point it's much easier
to call update() directly from a
page.
The use case are workers that can be
On Mon, Jun 1, 2009 at 8:29 PM, Jeremy Orlow jor...@chromium.org wrote:
If this is the only issue, the parsing code could work around it. There are
3 parts to the identifier: the protocol (should never have a _ in it,
right?), the domain, and the port (once again, should never have a _). It
02.06.2009, в 0:19, Drew Wilson написал(а):
My design doc just reflects the current spec - I don't really intend
to be the defender of said spec. As I said previously, I think this
is the wrong venue for us to describe issues with the spec - we
should do it on the whatwg list to include
Hi Xiong,
My platform is WebKiton gtk+directfb. I am noticing that the issue is still
present in the current Webkit nightly R-44111 build. I saw your sugested
patch :
In function ChromeClient::scroll()
// gdk_window_move_region(window, moveRegion, delta.width(),
delta.height());
On Mon, Jun 1, 2009 at 11:30 PM, Adam Barth aba...@webkit.org wrote:
On Mon, Jun 1, 2009 at 8:29 PM, Jeremy Orlow jor...@chromium.org wrote:
If this is the only issue, the parsing code could work around it. There
are
3 parts to the identifier: the protocol (should never have a _ in it,
Hi,
I am happy to hear that you solve the issue.
I am also sorry to say i can not search the bug
report, and never submit the patch with my sloth.
-Xiong
2009/6/2 Srinivas Rao M Hamse msrini...@gmail.com
Hi Xiong,
My platform is WebKiton gtk+directfb. I am noticing that the issue is still
Hi Gustavo/Xiong,
Is the patch discussed in this thread is acceptable for Gtk+Directfb
platform ? Its very annoying that UI goes bad when we use scroll feature.
Also is there a bug already logged on this issue, Can we log a fresh bug
report if its not done ?
regards,
Srinivas Rao. M
On Tuesday 02 June 2009 09:41:38 Srinivas Rao M Hamse wrote:
I wish to know if this fix is working, why is it not landed yet. What is
the plan for this bug.
What is the bug number for Gtk+Directfb platform.
Please see http://webkit.org/coding/contributing.html and
2009/6/1 Alexey Proskuryakov a...@webkit.org
02.06.2009, в 1:29, Michael Nordman написал(а):
What is the use case for this? It doesn't seem useful to me - to invoke
update explicitly, one
normally needs to have UI anyway, at which point it's much easier to call
update() directly from a
When a document calls a SharedWorker constructor, the worker script is loaded
from the document's
appcache (because all subresource loading goes through appcache, of course).
If I understand correctly, that is not what the spec currently says.
Dedicated workers load as you describe, but not
02.06.2009, в 21:10, Drew Wilson написал(а):
If worker global scope is actually a SharedWorkerGlobalScope object
(i.e. the worker is a shared worker), and there are any relevant
application caches that are identified by a manifest URL with the
same origin as url and that have url as one
From Andrew's design document, I don't see how my description was
inaccurate:
---
Currently, all worker XHR requests are proxied to the parent page and
executed on the main thread. This approach currently works for
dedicated workers because there is a 1:1 mapping
2009/6/2 Alexey Proskuryakov a...@webkit.org:
From Andrew's design document, I don't see how my description was
inaccurate:
---
Currently, all worker XHR requests are proxied to the parent page and
executed on the main thread. This approach currently works for
FYI: https://bugs.webkit.org/show_bug.cgi?id=26143
On Tue, Jun 2, 2009 at 12:45 AM, Jeremy Orlow jor...@chromium.org wrote:
On Mon, Jun 1, 2009 at 11:30 PM, Adam Barth aba...@webkit.org wrote:
On Mon, Jun 1, 2009 at 8:29 PM, Jeremy Orlow jor...@chromium.org wrote:
If this is the only issue,
02.06.2009, в 21:59, Michael Nordman написал(а):
Per the spec, shared workers are a distinct browsing context. In
appcache terms, they have a distinct appcache host. We have to come
up with a design that accomplishes that.
OK, I was getting a feeling that we talked about different things.
Basically, the spec says the most appropriate app cache should be used
(which apparently we're free to interpret however we like), and that the
SharedWorker should have the ability to update its current app cache. I
think that the spec is fine.
As for our implementation - I don't know how
the most appropriate app cache should be used
A little off topic... the spec says that in regard to appcache
selection in general, its not specific to workers. That squishiness
should probably be better defined at some point.
2009/6/2 Drew Wilson atwil...@google.com:
Basically, the spec says
I don't know how to file bug so I posted here.
In privateCompileCTIMachineTrampolines() there are multiple align() to align
code on 16byte margin, yet, the stack can be put on 32bit margin that causes
crush.
Suppose original stack is aligned to 8/16bytes, the above function frequently
pop/push
Based on this: http://build.webkit.org/waterfall?last_time=1243932987
It looks like http://trac.webkit.org/changeset/44350 caused the test to
fail.
On Tue, Jun 2, 2009 at 10:39 PM, Darin Adler da...@apple.com wrote:
This test is failing on all the Mac buildbots.
---
Anyone helps? Thanks!
On Mon, Jun 1, 2009 at 3:09 PM, Harry Zhang zhangha...@gmail.com wrote:
Hi all, i'm looking for the methods to bridge C object into JS runtime,
then i found the test cases under WebCore/bridge which seems to be a good
sample for me, because i found similar codes in Qt
20 matches
Mail list logo
