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
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 Documen
I would like to control JavaScript execution in my app remotely using the V8
debugger protocol. Does anyone know if there exists code that implements and
the V8 debugger protocol for JavaScriptCore?
My main goal is remotely debug JavaScript, so I am also wondering what other
technologies exist
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 a
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
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
This is not surprising to me at all. The problem is even more complicated
when you consider window.showModalDialog.
I recently changed Chromium to suppress WebKit's shared timer during calls
to alert, confirm, prompt, and the beforeunload prompt. That may be why you
aren't seeing the problem wit
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 e
This is not surprising to me at all. The problem is even more complicated
when you consider window.showModalDialog.
I recently changed Chromium to suppress WebKit's shared timer during calls
to alert, confirm, prompt, and the beforeunload prompt. That may be why you
aren't seeing the problem wit
I saw a very similar bug recently regarding modal dialogs and focus/blur
events: https://bugs.webkit.org/show_bug.cgi?id=33962. I think you will see
the crash from that stacktrace with or without r55593 in place. For
example, currently some mouse event handlers can fire underneath a
window.alert
Hi all,
This weekend I spent some time trying to track down a regression caused by
r55593. In particular:
http://trac.webkit.org/changeset/55593/trunk/WebCore/dom/Document.cpp
This was a change to Document.postTask() to always use callOnMainThread()
(previously, calls to postTask() on the main t
11 matches
Mail list logo
