Re: [webkit-dev] Trouble with updating Chromium' slayout test expectations
Yeah, it's weird. I rebaselined those tests, but the chromium canaries still showed them as red. Now, however, the canaries are showing many of them passing. I was planning to remove the lines from test_expectations today to see if they stay green. -atw On Tue, Feb 22, 2011 at 6:46 AM, Mihai Parparita mih...@chromium.orgwrote: It looks like Drew checked in baselines with http://trac.webkit.org/changeset/79034 (which may be why rebaseline-chromium-webkit-tests isn't doing anything, since it already has correct pixel baselines), but given http://trac.webkit.org/changeset/79088 it didn't seem to work. Drew, any ideas why? Mihai On Tue, Feb 22, 2011 at 2:07 AM, Hajime Morita morr...@google.com wrote: Hi Chromium WebKit folks, I'm looking for a help to retrieve the latest expectation files for Chromium Mac LayoutTest. At the weekend there was a change that triggers massive amount of pixel test failures that requires rebaselining. (https://bugs.webkit.org/b/54736) But the buildbot doesn't have the latest result for part of them, that means * rebaseline-chromium-webkit-tests doesn't update pixel results * [layout test results] links on buildbot dashboard are broken. Then now around 100 tests for Mac Chromium are left marked as failed (BUGWK54736 lines), waiting for their fresh expectations. Unfortunately I have no idea what's happening but missing 100 tests will possibly hurt us. How could I update these expectations? Any suggestions and/or helps are appreciated. Regards. -- morrita ___ 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] Trouble with updating Chromium' slayout test expectations
That's an interesting thread. I had always assumed that either the testers always synced to the same rev as the builders, or at least that they pulled the layout test files/expectations from the builders along with the executables. Not doing this just seems inherently broken, but I understand why we do it. BTW, I'm figuring that most of webkit-dev can't access that group - here's the summary, pulled from the public chromium documentation: *Breaks Canary bots.* Canary test bots pick the latest WebKit revision available. Because test bots start later than build bots, test bots tend to pick later revisions. i.e. when a build bot picks a revision X, the corresponding test bot will pick a revision X+delta where delta = 0. This implies that any new tests added or rebaselines done in the interval (X, X+delta] will result in test failures because the build didn't contain necessary changes. To detect failure caused by this, compare gclient update's stdout on build bots and test bots. On that note, I suspect this topic is of little interest to webkit-dev at large, so we may want to move this to chrome-webkit-gardening for future discussion. -atw On Tue, Feb 22, 2011 at 10:43 AM, Mikhail Naganov mnaga...@chromium.orgwrote: Ah, true. The code changes were long ago. On Tue, Feb 22, 2011 at 21:40, Mihai Parparita mih...@chromium.org wrote: But these were rebaselines, which don't depend on any code changes. Mihai On Tue, Feb 22, 2011 at 10:35 AM, Mikhail Naganov mnaga...@chromium.org wrote: I have a suspicion that the cause of canaries failures is described here: https://groups.google.com/a/google.com/group/chrome-webkit-gardening/browse_thread/thread/d3b3a4fc647e804d In short, bots can run tests prematurely, emitting false failures. I observed this during my gardening, and I think you should check which revisions of WebKit and Chromium bots used while running tests. On Tue, Feb 22, 2011 at 20:16, Drew Wilson atwil...@google.com wrote: Yeah, it's weird. I rebaselined those tests, but the chromium canaries still showed them as red. Now, however, the canaries are showing many of them passing. I was planning to remove the lines from test_expectations today to see if they stay green. -atw On Tue, Feb 22, 2011 at 6:46 AM, Mihai Parparita mih...@chromium.org wrote: It looks like Drew checked in baselines with http://trac.webkit.org/changeset/79034 (which may be why rebaseline-chromium-webkit-tests isn't doing anything, since it already has correct pixel baselines), but given http://trac.webkit.org/changeset/79088 it didn't seem to work. Drew, any ideas why? Mihai On Tue, Feb 22, 2011 at 2:07 AM, Hajime Morita morr...@google.com wrote: Hi Chromium WebKit folks, I'm looking for a help to retrieve the latest expectation files for Chromium Mac LayoutTest. At the weekend there was a change that triggers massive amount of pixel test failures that requires rebaselining. (https://bugs.webkit.org/b/54736) But the buildbot doesn't have the latest result for part of them, that means * rebaseline-chromium-webkit-tests doesn't update pixel results * [layout test results] links on buildbot dashboard are broken. Then now around 100 tests for Mac Chromium are left marked as failed (BUGWK54736 lines), waiting for their fresh expectations. Unfortunately I have no idea what's happening but missing 100 tests will possibly hurt us. How could I update these expectations? Any suggestions and/or helps are appreciated. Regards. -- morrita ___ 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] Implementing HTML5 context menus
Has anyone done any work/investigation towards implementing the context menu support in HTML5 (the contextmenu attribute and menu elements with type=contextMenu) as described here: http://www.w3.org/TR/html5/interactive-elements.html#context-menus ? I didn't see anything from a quick browse through the source code, and also haven't seen much traffic on webkit-dev on the subject. The spec itself seems to be at Last call for comments so it seems like it should be stable enough to start implementation. One of the members of my team has expressed some interest in working on this if there's no implementation already underway. -atw ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Implementing HTML5 context menus
OK, we'll start looking into this and float out an implementation proposal/design doc once we understand what needs to be done. Thanks, -atw On Wed, Apr 21, 2010 at 5:46 PM, Maciej Stachowiak m...@apple.com wrote: On Apr 21, 2010, at 5:06 PM, Drew Wilson wrote: Has anyone done any work/investigation towards implementing the context menu support in HTML5 (the contextmenu attribute and menu elements with type=contextMenu) as described here: http://www.w3.org/TR/html5/interactive-elements.html#context-menus ? I didn't see anything from a quick browse through the source code, and also haven't seen much traffic on webkit-dev on the subject. The spec itself seems to be at Last call for comments so it seems like it should be stable enough to start implementation. One of the members of my team has expressed some interest in working on this if there's no implementation already underway. No one has started on this yet. This part of the spec has never been implemented by anyone, so I suspect that if WebKit does the first implementation, we will likely need to give input to the relevant standards groups, and I suspect that we'll probably run into issues that require changes to the spec. That's not to say we shouldn't do it, but rather, whoever is working on this should be prepared to communicate with the standards groups on this feature. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Crashing Workers Code?
I'll also note that a disproportionate number of those bugs are happening on the Qt build. This either means that the Qt build is awesome at reproducing this race condition, or that there's some other flakiness on that build that is exposed with workers. -atw 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 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. -- 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] Crashing Workers Code?
Agreed, we (worker folks) should go investigate this further - it sounds like we may be getting lucky and we have a platform that can repro the crash more frequently. I just wanted to mention that the main thing in the system that exercises the platform-specific thread/locking infrastructure is workers. If there are any synchronization bugs on a platform (or in a specific part of WebKit) they'll primarily show up as failures in Worker tests. I don't think that's what is happening here, but it's something to keep in mind. -atw On Mon, Mar 29, 2010 at 6:10 PM, Eric Seidel e...@webkit.org wrote: From my experience watching the bots, I would say the Qt build is relatively stable, so I suspect it's just good at reproducing this crasher. The Qt build is nice that it produces stack traces for every crash. Sadly their useless until https://bugs.webkit.org/show_bug.cgi?id=33654 is fixed. On Mon, Mar 29, 2010 at 5:47 PM, Drew Wilson atwil...@google.com wrote: I'll also note that a disproportionate number of those bugs are happening on the Qt build. This either means that the Qt build is awesome at reproducing this race condition, or that there's some other flakiness on that build that is exposed with workers. -atw 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 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. -- 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 ___ 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
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 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? -atw On Mon, Mar 8, 2010 at 7:24 PM, Dmitry Titov dim...@chromium.org wrote: 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 atwil...@google.com 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 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, 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 atwil...@google.com 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 dim...@chromium.orgwrote: 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 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
Re: [webkit-dev] WTF::callOnMainThread() and re-entrancy
Another alternative is for us to add a flag to
scheduleDispatchFunctionsOnMainThread() which is passed as true in the case
where we are calling it from dispatchFunctionsOnMainThread():
// If we are running accumulated functions for too long so UI may
become unresponsive, we need to
// yield so the user input can be processed. Otherwise user may not
be able to even close the window.
// This code has effect only in case the
scheduleDispatchFunctionsOnMainThread() is implemented in a way that
// allows input events to be processed before we are back here.
if (currentTime() - startTime maxRunLoopSuspensionTime) {
scheduleDispatchFunctionsOnMainThread(true); // delay = true
break;
}
}
That way, in the case where we are in some kind of tight loop and we want to
yield anyway to let UI events happen, we could instead yield for (say) 10ms
to make sure lower priority events have a chance to be dispatched.
Alexey, what do you think? My preference would be to use a lower priority
event instead of a delay, but I don't know enough about Cocoa programming to
know whether that's possible.
-atw
On Tue, Mar 9, 2010 at 9:45 AM, Drew Wilson atwil...@google.com 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 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?
-atw
On Mon, Mar 8, 2010 at 7:24 PM, Dmitry Titov dim...@chromium.org wrote:
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 atwil...@google.com 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 dim...@chromium.orgwrote:
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 atwil...@google.comwrote:
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 dim...@chromium.orgwrote:
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
Re: [webkit-dev] WTF::callOnMainThread() and re-entrancy
On Tue, Mar 9, 2010 at 11:34 AM, Dmitry Titov dim...@chromium.org wrote: On Tue, Mar 9, 2010 at 11:13 AM, Alexey Proskuryakov a...@webkit.orgwrote: 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 https://bugs.webkit.org/show_bug.cgi?id=34726 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. I'm guessing that timers aren't implemented as a CFRunLoopSource, so have different behavior (they won't starve CFRunLoopSources and won't be starved by them). Whereas performSelectorOnMainThread can starve other CFRunLoopSources. 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... -atw 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 . Got it. Doesn't seem like we can affect the order of the CFRunLoopSource used by performSelectorOnMainThread(). - 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
That's a great idea: http://developer.apple.com/Mac/library/documentation/CoreFoundation/Reference/CFRunLoopObserverRef/Reference/reference.html#//apple_ref/c/tdef/CFRunLoopActivity http://developer.apple.com/Mac/library/documentation/CoreFoundation/Reference/CFRunLoopObserverRef/Reference/reference.html#//apple_ref/c/tdef/CFRunLoopActivityThis 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. kCFRunLoopBeforeWaitingreference.html#//apple_ref/doc/c_ref/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 a...@webkit.org 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
Yeah, that seems to be the least invasive. And we're already confident that creating a zero-delay timer won't cause event source starvation, since that's how postTask() used to work. -atw On Tue, Mar 9, 2010 at 12:53 PM, Dmitry Titov dim...@chromium.org wrote: 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 atwil...@google.com wrote: That's a great idea: http://developer.apple.com/Mac/library/documentation/CoreFoundation/Reference/CFRunLoopObserverRef/Reference/reference.html#//apple_ref/c/tdef/CFRunLoopActivity http://developer.apple.com/Mac/library/documentation/CoreFoundation/Reference/CFRunLoopObserverRef/Reference/reference.html#//apple_ref/c/tdef/CFRunLoopActivityThis 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. kCFRunLoopBeforeWaitinghttp://reference.html#//apple_ref/doc/c_ref/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 a...@webkit.orgwrote: 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
[webkit-dev] WTF::callOnMainThread() and re-entrancy
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 thread were using one-shot
timers).
We've since reverted r55593, but I've been playing around locally with that
same change to Document.postTask(), and I noticed that it *appeared* that
tasks posted via callOnMainThread() were still being executed even though
the main thread was displaying a javascript alert. The end result is that if
a worker thread was sending messages to the main thread via a message port,
the event handlers for incoming messages would still be invoked (so we'd run
javascript even though the javascript execution context should be blocked on
the alert()). In my test, I ended up trying to display nested alert()
dialogs, which resulted in a failed assertion.
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.
Here's the stack from my nested call to alert():
#0 0x03ff073d in WebCore::DOMTimer::suspend (this=0x15c8a5b0) at
/Volumes/source/chrome.git/src/third_party/WebKit/WebCore/page/DOMTimer.cpp:181
#1 0x046b2945 in WebCore::ScriptExecutionContext::suspendActiveDOMObjects
(this=0x81d8434) at
/Volumes/source/chrome.git/src/third_party/WebKit/WebCore/dom/ScriptExecutionContext.cpp:206
#2 0x04538ae5 in WebCore::PageGroupLoadDeferrer::PageGroupLoadDeferrer
(this=0xbfffc6bc, page=0xc97940, deferSelf=true) at
/Volumes/source/chrome.git/src/third_party/WebKit/WebCore/page/PageGroupLoadDeferrer.cpp:47
#3 0x03e0d977 in WebCore::Chrome::runJavaScriptAlert (this=0xc8ddb0,
frame=0x805a600, messa...@0xbfffc790) at
/Volumes/source/chrome.git/src/third_party/WebKit/WebCore/page/Chrome.cpp:264
#4 0x03ff6c2c in WebCore::DOMWindow::alert (this=0x147e23f0,
messa...@0xbfffc790) at
/Volumes/source/chrome.git/src/third_party/WebKit/WebCore/page/DOMWindow.cpp:795
#5 0x04266617 in WebCore::jsDOMWindowPrototypeFunctionAlert
(exec=0x14f0c1b0, thisValue={u = {asEncodedJSValue = -8455721472, asDouble =
-nan(0xe07ffee00), asBits = {payload = 134213120, tag = -2}}},
ar...@0xbfffc7bc) at
/Volumes/source/chrome.git/src/third_party/WebKit/WebKitBuild/Debug/DerivedSources/WebCore/JSDOMWindow.cpp:8320
#6 0x00d8b166 in ?? ()
#7 0x0070bd6b in JSC::JITCode::execute (this=0x147a7690,
registerFile=0x1473a7fc, callFrame=0x14f0c150, globalData=0x818e800,
exception=0x818f60c) at JITCode.h:77
#8 0x006f542f in JSC::Interpreter::execute (this=0x1473a7f0,
functionExecutable=0x147a7680, callFrame=0x81ed664, function=0x7fd5400,
thisObj=0x7fd5200, ar...@0xbfffca64, scopeChain=0x147a8920,
exception=0x818f60c) at
/Volumes/source/chrome.git/src/third_party/WebKit/JavaScriptCore/interpreter/Interpreter.cpp:687
#9 0x0074d767 in JSC::JSFunction::call (this=0x7fd5400, exec=0x81ed664,
thisValue={u = {asEncodedJSValue = -8455892480, asDouble =
-nan(0xe07fd5200), asBits = {payload = 134042112, tag = -2}}},
ar...@0xbfffca64) at
/Volumes/source/chrome.git/src/third_party/WebKit/JavaScriptCore/runtime/JSFunction.cpp:122
#10 0x0069d481 in JSC::call (exec=0x81ed664, functionObject={u =
{asEncodedJSValue = -8455891968, asDouble = -nan(0xe07fd5400), asBits =
{payload = 134042624, tag = -2}}}, callType=JSC::CallTypeJS,
callda...@0xbfffca34, thisValue={u = {asEncodedJSValue = -8455892480,
asDouble = -nan(0xe07fd5200), asBits = {payload = 134042112, tag =
-2}}}, ar...@0xbfffca64) at
/Volumes/source/chrome.git/src/third_party/WebKit/JavaScriptCore/runtime/CallData.cpp:39
#11 0x0429f5bb in WebCore::JSEventListener::handleEvent (this=0x15c31ef0,
scriptExecutionContext=0x81d8434, event=0xc34d40) at
/Volumes/source/chrome.git/src/third_party/WebKit/WebCore/bindings/js/JSEventListener.cpp:115
#12 0x04037da0 in WebCore::EventTarget::fireEventListeners (this=0x15c9c400,
event=0xc34d40) at
/Volumes/source/chrome.git/src/third_party/WebKit/WebCore/dom/EventTarget.cpp:297
#13 0x04037e88 in WebCore::EventTarget::dispatchEvent (this=0x15c9c400,
eve...@0xbfffcbac) at
/Volumes/source/chrome.git/src/third_party/WebKit/WebCore/dom/EventTarget.cpp:262
#14 0x0403769a in WebCore::EventTarget::dispatchEvent (this=0x15c9c400,
eve...@0xbfffcc2c, e...@0xbfffcbfc) at
/Volumes/source/chrome.git/src/third_party/WebKit/WebCore/dom/EventTarget.cpp:254
#15 0x044eeaa8 in WebCore::MessagePort::dispatchMessages (this=0x15c9c400)
at
/Volumes/source/chrome.git/src/third_party/WebKit/WebCore/dom/MessagePort.cpp:177
#16 0x046b3173 in WebCore::ScriptExecutionContext::dispatchMessagePortEvents
(this=0x81d8434) at
Re: [webkit-dev] WTF::callOnMainThread() and re-entrancy
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 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 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
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 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, 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 atwil...@google.com 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 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 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
[webkit-dev] Issues with WebWorkers that may block Safari support
Hi all, There have been various side discussions regarding the stability/viability of Workers and SharedWorkers, and I wanted to make sure we understand all of the concerns, since as far as I know there isn't any one person who has been privy to all of the conversations (or maybe it's just me that's been out of the loop :). So I'll enumerate the issues I'm aware of below, and people can chime in on any that I've missed that may impact the ability to ship these features, and we can figure out how to get them addressed ASAP. 1) worker-lifecycle.html fails intermittently ( https://bugs.webkit.org/show_bug.cgi?id=29344) The original report doesn't seem to be a true worker failure, but rather an artifact of the way GC works in JSC. Since JSC uses conservative GC, it's quite possible for the VM to think that there's a dangling reference to a Worker even though there isn't actually one, and that seems to be what's happening here (workers would get shutdown when the parent document closes regardless, so there's no actual leak). Unless someone has some idea of how to make this GC more deterministic, my recommendation would be to just disable this test and close this bug, since seemingly it's the test itself that is not reliable, not the underlying worker code. That said, there's a sporadic worker crash that seems to have started happening in the last week or so which I believe is a different issue - eseidel has glommed that crash onto the same bug, and I think we should move that to its own issue and see if we can collect more information about it. 2) SharedWorkers proxy their network access to a parent document (no bug for this currently) The result of this is the application can get a network error if the user has multiple windows open that are using the same SharedWorker, then closes the parent document that is acting as a network proxy while a network request is in progress. While this is something that would need to change eventually in order to properly support exposing the appcache APIs to SharedWorker context, it doesn't seem like this would be any kind of ship blocker. Any robust application would need to deal with sporadic network hiccups anyway by retrying, and in practice this situation will almost never be encountered in the field. Perhaps people have other concerns that make this a ship blocker? 3) Potential race conditions with Document.postTask() ( https://bugs.webkit.org/show_bug.cgi?id=31633) I've suggested a simple solution to the potential race condition with SharedWorkers in the bug. I'd be interested in hearing whether people think it's a good approach or not - if so, I'm happy to submit a patch for review in short order. There's still the question as to whether dispatching tasks on a detached Document is OK or not, but I'm assuming it is (since that's what Dedicated workers have always done). Are there other issues we should be addressing as a high priority? -atw ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Issues with WebWorkers that may block Safari support
On Fri, Dec 4, 2009 at 2:00 PM, Maciej Stachowiak m...@apple.com wrote: On Dec 4, 2009, at 1:40 PM, Drew Wilson wrote: Hi all, There have been various side discussions regarding the stability/viability of Workers and SharedWorkers, and I wanted to make sure we understand all of the concerns, since as far as I know there isn't any one person who has been privy to all of the conversations (or maybe it's just me that's been out of the loop :). So I'll enumerate the issues I'm aware of below, and people can chime in on any that I've missed that may impact the ability to ship these features, and we can figure out how to get them addressed ASAP. 1) worker-lifecycle.html fails intermittently ( https://bugs.webkit.org/show_bug.cgi?id=29344) The original report doesn't seem to be a true worker failure, but rather an artifact of the way GC works in JSC. Since JSC uses conservative GC, it's quite possible for the VM to think that there's a dangling reference to a Worker even though there isn't actually one, and that seems to be what's happening here (workers would get shutdown when the parent document closes regardless, so there's no actual leak). Unless someone has some idea of how to make this GC more deterministic, my recommendation would be to just disable this test and close this bug, since seemingly it's the test itself that is not reliable, not the underlying worker code. That said, there's a sporadic worker crash that seems to have started happening in the last week or so which I believe is a different issue - eseidel has glommed that crash onto the same bug, and I think we should move that to its own issue and see if we can collect more information about it. For what it's worth, we'd likely consider a resolution to this bug a blocker to shipping the next Safari release, but we would not consider disabling dedicated Workers as a solution, since we have shipped them already. If this bug could be shown to be an error in the test and inappropriate dependence on GC, that would be a satisfactory resolution. However, the sporadic failure here is a at least sometimes a crash. A crash definitely indicates a bug in WebKit, not in the test, even if the test itself is also flawed. Therefore, I would not consider disabling the test a solution until we have at least addressed the crash. That makes sense to me - we should try to address the crash, and if keeping this test enabled is the only way to do that, that's fine. I would recommend changing the test, however, so the test itself always passes so it's not making the bots red while we're waiting to reproduce the crash. Regarding Geoff's comments - I'm as convinced as I can be (based on my own and ap's efforts stepping through the GC code - see ap's comments in the bug) that the original failures were a conservative GC issue. I'm honestly stumped as to how to move forward on that. 2) SharedWorkers proxy their network access to a parent document (no bug for this currently) The result of this is the application can get a network error if the user has multiple windows open that are using the same SharedWorker, then closes the parent document that is acting as a network proxy while a network request is in progress. While this is something that would need to change eventually in order to properly support exposing the appcache APIs to SharedWorker context, it doesn't seem like this would be any kind of ship blocker. Any robust application would need to deal with sporadic network hiccups anyway by retrying, and in practice this situation will almost never be encountered in the field. Perhaps people have other concerns that make this a ship blocker? I don't believe we consider this a ship blocker. Though we did discuss it at the same time as the other two items on the list. 3) Potential race conditions with Document.postTask() ( https://bugs.webkit.org/show_bug.cgi?id=31633) I've suggested a simple solution to the potential race condition with SharedWorkers in the bug. I'd be interested in hearing whether people think it's a good approach or not - if so, I'm happy to submit a patch for review in short order. There's still the question as to whether dispatching tasks on a detached Document is OK or not, but I'm assuming it is (since that's what Dedicated workers have always done). Are there other issues we should be addressing as a high priority? This one would probably be a ship blocker. We would consider disabling SharedWorkers to ship if that addressed the issue. Any objections to the solution I proposed? Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] GlobalScript in WebKit
On Tue, Dec 1, 2009 at 9:15 AM, Michael Davidson m...@google.com wrote: A third improvement: When we adopt the HTML5 notification API for showing users new mail or incoming chat notifications we will only show one notification regardless of the number of Gmail tabs that are open. Today each window would have to show a notification. That one just occurred to me, I'm sure we can come up with others. Michael FWIW, we've been pushing developers to use SharedWorkers to manage their notifications for exactly this reason. It's fairly trivial to do so, since notifications are fundamentally an async API anyway. But agreed that SharedScript would also work for this. -atw - Maciej I sense that there's some pushback due to a Google property requesting a feature that Google engineers are trying to get into the browser, but I think that Gmail is emblematic of all large web apps. Shared workers have their place, but that place is not sharing the UI code for large apps. I saw a comment that forcing multiple windows of one application into the same process is undesirable. I disagree. Gmail is not a CPU-bound application. We believe that the savings of having one JS heap, one request queue, one data store, etc. would outweigh the benefits of process isolation. 3) Should SharedScript be added to WebKit? I'm not a WebKit developer, so I'm not as qualified to comment. However, I believe that SharedScript is a feature that many apps would use. We tried to come up with a representative set of examples in the spec. We're happy to come up with more. I don't believe that SharedWorkers will solve those scenarios. I doubt that developers inside or outside of Google will move to a totally async programming model. Sorry that this initial mail is also a little scattered. I'll try to stay on top of the conversation as it progresses, and will hopefully be able to provide a perspective from the trenches of web development. Michael On Mon, Nov 30, 2009 at 6:16 PM, Drew Wilson atwil...@google.com wrote: Following up, I think this highlights the distinct set of use cases that shared workers and shared script address: SharedWorkers are a great platform for when you have a single database that is shared across multiple instances of your web app, and you want to coordinate updates to that database. I can imagine sharing a single connection to the server, etc via SharedWorkers. SharedScripts are a good platform for when you want to share data/code (for example, the immense body of Javascript used to implement the Gmail UI) across multiple windows. I can't speak to whether passing a hidden iframe between windows as was suggested in the other thread would address this use case sufficiently. -atw On Mon, Nov 30, 2009 at 6:11 PM, Drew Wilson atwil...@google.comwrote: I believe that the offline gmail team uses the Gears flavor of shared workers and is planning to migrate to the HTML5 version once DB access is supported from within worker context in shipping browsers. So I guess that Gmail would be a candidate app that has asked for both. -atw On Mon, Nov 30, 2009 at 6:08 PM, Maciej Stachowiak m...@apple.comwrote: On Nov 30, 2009, at 3:43 PM, Dmitry Titov wrote: 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. Are there any Web apps at Google or elsewhere currently using SharedWorker? Would any of them still use it if they could switch to SharedScript? Has any app team specifically requested support for *both* SharedWorker *and* SharedScript? (Serious questions, since the justification for SharedScript is largely based on Web developer feedback.) Note: if SharedScript was really globally shared it could be used to implement shared workers - simply have the SharedScript manage the per-app Workers. Regards, Maciej ___ 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] GlobalScript in WebKit
As an aside (that doesn't necessarily detract from your point) I'd say that the WebWorker spec is fairly clear in intent: that there will be a single sharedworker per domain/name within a given UserAgent. You'd have to parse the idea of a user agent fairly finely (i.e. treat separate Chrome processes as different user agents) to conclude that cross-process sharing is an implementation detail and not mandated by the specification. -atw On Mon, Nov 30, 2009 at 3:43 PM, Dmitry Titov dim...@chromium.org wrote: 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 issueshttp://www.chromium.org/developers/design-documents/process-modelsare 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 gga...@apple.com 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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] GlobalScript in WebKit
On Mon, Nov 30, 2009 at 4:15 PM, Ian Hickson i...@hixie.ch wrote: The pushback on SharedWorkers at Google is because Google teams don't want to rewrite their apps to work with workers -- SharedScript lets them handle some of the cases SharedWorkers would get them, without having to rewrite as much code. I have to step in and disagree here - the problem is not that Google teams don't want to rewrite their apps to work with workers - the problem is that there are fundamentally things that you *must* do synchronously within the execution context of a page and SharedWorkers doesn't let you do that. If you have a mouse click handler and you want to take some sort of synchronous action (invoke preventDefault(), disable UI, display other UI, etc), SharedWorkers doesn't help you there. Javascript code that displays and manipulates DOM elements can't live in a shared worker. I think that SharedWorkers are a really important tool, and they solve a bunch of problems, but we should be realists and admit that they don't solve all of them, and should not characterize the proponents of SharedScript as somehow just being unwilling to cowboy up and rewrite their apps. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ___ 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
I believe that the offline gmail team uses the Gears flavor of shared workers and is planning to migrate to the HTML5 version once DB access is supported from within worker context in shipping browsers. So I guess that Gmail would be a candidate app that has asked for both. -atw On Mon, Nov 30, 2009 at 6:08 PM, Maciej Stachowiak m...@apple.com wrote: On Nov 30, 2009, at 3:43 PM, Dmitry Titov wrote: 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. Are there any Web apps at Google or elsewhere currently using SharedWorker? Would any of them still use it if they could switch to SharedScript? Has any app team specifically requested support for *both* SharedWorker *and* SharedScript? (Serious questions, since the justification for SharedScript is largely based on Web developer feedback.) Note: if SharedScript was really globally shared it could be used to implement shared workers - simply have the SharedScript manage the per-app Workers. Regards, Maciej ___ 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
Following up, I think this highlights the distinct set of use cases that shared workers and shared script address: SharedWorkers are a great platform for when you have a single database that is shared across multiple instances of your web app, and you want to coordinate updates to that database. I can imagine sharing a single connection to the server, etc via SharedWorkers. SharedScripts are a good platform for when you want to share data/code (for example, the immense body of Javascript used to implement the Gmail UI) across multiple windows. I can't speak to whether passing a hidden iframe between windows as was suggested in the other thread would address this use case sufficiently. -atw On Mon, Nov 30, 2009 at 6:11 PM, Drew Wilson atwil...@google.com wrote: I believe that the offline gmail team uses the Gears flavor of shared workers and is planning to migrate to the HTML5 version once DB access is supported from within worker context in shipping browsers. So I guess that Gmail would be a candidate app that has asked for both. -atw On Mon, Nov 30, 2009 at 6:08 PM, Maciej Stachowiak m...@apple.com wrote: On Nov 30, 2009, at 3:43 PM, Dmitry Titov wrote: 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. Are there any Web apps at Google or elsewhere currently using SharedWorker? Would any of them still use it if they could switch to SharedScript? Has any app team specifically requested support for *both* SharedWorker *and* SharedScript? (Serious questions, since the justification for SharedScript is largely based on Web developer feedback.) Note: if SharedScript was really globally shared it could be used to implement shared workers - simply have the SharedScript manage the per-app Workers. Regards, Maciej ___ 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] Why are PassRefPtrs used as function parameters?
In this case, HTMLCollection() keeps a reference to the object, so you can't
safely pass in just a raw pointer. Since HTMLCollection keeps it around,
you'd have to do the ref anyway.
-atw
On Tue, Oct 27, 2009 at 10:55 AM, Jens Alfke s...@chromium.org wrote:
Looking at how refcounting is implemented in WebCore, I was surprised to
find that there are a lot of functions/methods that take PassRefPtrs as
parameters instead of regular pointers to those objects. I can't see any
benefit to this, and it adds the overhead of a ref() and deref() at every
call-site.
For example in HTMLNameCollection.h:
HTMLNameCollection(PassRefPtrDocument, CollectionType, const String
name);
Why shouldn't this be
HTMLNameCollection(Document*, CollectionType, const String name);
?
The use of PassRefPtr instead of RefPtr here also seems prone to trouble,
since inside the implementation of the method it could end up unexpectedly
clearing the parameter:
HTMLNameCollection::HTMLNameCollection(Document* doc, {
RefDocument otherDoc = doc; // This sets doc to NULL!
doc-something(); // CRASH
}
I ran across this while trying to track down a reference leak of a Document
object. As one of my last resorts I set a watchpoint on the object's
m_refcount to see who refs/derefs it; but I had to give up because so many
method calls, including the one above, keep constantly twiddling the
refcount while passing the Document as a parameter.
—Jens
___
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] Why are PassRefPtrs used as function parameters?
Aside from the ref-counter munging, it still seems like there's value in
using PassRefPtr as a signifier that a given API takes ownership of a
pointer.
So I'm not certain (in the case of HTMLNameCollection) that it'd be a better
solution to change it not to take an ordinary pointer - yes, it would
eliminate some ref churn, but at the cost of losing that connotation.
A better solution (since the constructor is private) would be to make the
constructor explicitly take a CollectionCache* parameter, thereby allowing
us to directly pass the document straight through to the base class.
-atw
On Thu, Oct 29, 2009 at 3:31 PM, Maciej Stachowiak m...@apple.com wrote:
On Oct 29, 2009, at 12:56 PM, Darin Adler wrote:
On Oct 27, 2009, at 10:55 AM, Jens Alfke wrote:
Looking at how refcounting is implemented in WebCore, I was surprised to
find that there are a lot of functions/methods that take PassRefPtrs as
parameters instead of regular pointers to those objects. I can't see any
benefit to this, and it adds the overhead of a ref() and deref() at every
call-site.
Have you read the RefPtr document? It is at
http://webkit.org/coding/RefPtr.html.
Only functions that take ownership of the passed-in objects should take
PassRefPtr. This makes it so we can optimally handle the case where that
object was just created and lets us hand off the reference instead of having
to do a round of reference count thrash. If the function is going to be
storing the value in a RefPtr, then the PassRefPtr does not introduce any
reference count thrash even if the passed in object was not just created.
It’s wrong for the HTMLNameCollection constructor to take a PassRefPtr for
its document argument because it doesn’t take ownership of the document. So
that one is definitely a mistake.
However, its base class HTMLCollection can take ownership. The
HTMLNameCollection constructor misses out on the optimization though:
HTMLNameCollection::HTMLNameCollection(PassRefPtrDocument document,
CollectionType type, const String name)
: HTMLCollection(document.get(), type,
document-nameCollectionInfo(type, name))
, m_name(name)
{
}
Note that it passes document.get(), but also uses document after that so it
couldn't just pass document. Thus, it probably shouldn't take a PassRefPtr
(unless there is a clever way to fix it that I'm not seeing).
- Maciej
It is true that PassRefPtr arguments can be tricky as you mentioned and
the RefPtr document also mentions.
-- 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
___
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
Circling back on this - I have a patch together for the V8 side of this issue (code generation changes and associated infrastructure). I'm just waiting for someone to R+ it for me: https://bugs.webkit.org/show_bug.cgi?id=30240 -- if someone can take a look at this, I can get this in the tree, and we can start working on the second half of the fix: Currently many of these runtime enabled flags are sitting in WebCore::Settings. This is a fairly inappropriate place for them, for a few reasons - 1) We need to have access to these Settings *before* the window object is initialized (as part of initializing the V8 bindings), and this is difficult/impossible the way the bindings are currently generated. 2) The Settings objects aren't available from worker context, so some runtime features (like notifications) can't be disabled from worker context. So the second half of this fix is to move things like experimentalWebSocketEnabled out of WebCore::Settings and into some other kind of static object that's threadsafe and universally accessible. I'm not certain if this needs to be part of WebCore proper, or if all we care about is disabling V8 bindings, this is a static singleton class that can live in the V8 bindings themselves. Anyhow, I don't have strong opinions about the right way to go here, but I *would* like to get my codegen changes checked in so I can unblock SharedWorkers :) -atw On Mon, Oct 5, 2009 at 10:00 PM, Darin Fisher da...@chromium.org wrote: On Mon, Oct 5, 2009 at 9:56 PM, Jeremy Orlow jor...@chromium.org wrote: On Mon, Oct 5, 2009 at 9:54 PM, Mark Rowe mr...@apple.com wrote: On 2009-10-05, at 21:48, Darin Fisher wrote: It is a matter of our process that we do not change the configuration when promoting builds. The bits that passed the test get promoted. I'm happy to absorb this cost in the V8 bindings. I don't think it is important to solve this problem for the JSC bindings since there is not a consumer that yet needs the same. The present state of Web Sockets is that they're compiled in on Mac OS X but disabled via the runtime setting. This leads to them being detectable in the manner Sam mentioned. Either the compile-time setting needs to be fixed for Mac OS X or the runtime code fixed so that the feature is not detectable when disabled. I assume that we want regression testing of the feature so disabling it at compile time does not seem like the best idea. I guess it comes down to whether or not it's in good enough shape to be useful to web sites at this time. I don't believe that anyone is shipping a working implementation of WebSockets yet (or is Firefox's working now?), in which case it shouldn't matter to have it on by default. It matters for feature detection in the future. Once there are real implementations in the wild, those will be detected in the same way that the current implementation is detected. If the implementations aren't compatible (because one is very incomplete), then it makes the detection less reliable, and one must then resort to UA sniffing hacks. -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] Runtime setting for incomplete features
So, two weeks ago I sent an email on this thread stating exactly what I was planning to do, To whit: I do think that we ought to be returning undefined instead of null in those cases, though, just to catch people who are accidentally using isUndefined() utility functions from common libraries. It would not be hard to define some kind of [mapNullToUndefined] custom attribute for the code generator. Maciej and AP both chimed in saying that disabling enumeration (i.e. SharedWorker in window) would be prohibitively hard, and giving a tacit OK to my approach (my emphasis below): It would be pretty complicated to do that [disabling [LocalStorage in window] based on a runtime setting. You would need a custom getter for any object that has properties which may appear or disappear based on settings. This is *probably too complicated to be worth it*. Or at least, if we added that level of code complexity I would begin to doubt the merits of supporting runtime enabling of Web platform features. I'm surprised to see these objections coming up now, weeks after the original discussion, and only after my patch has landed in the tree. That said, I agree that in an ideal world, we'd hide window.audio, shared workers, notifications, local storage, databases, session storage and any other runtime/platform-disabled API from enumerations - I just agree with Maciej that this isn't a hugely important issue, since these features are only runtime-disabled while under development and so not widely available anyway. Regardless, I don't think we should rush out to roll all of those features out of the tree, and I certainly don't think we should be singling out SharedWorkers or WebSockets - if we feel strongly that this needs to be addressed, we can update all of those features accordingly. If people with knowledge of the internals of V8 and JSC can chime in, we can discuss how best to approach this. -atw On Mon, Oct 5, 2009 at 5:04 PM, Sam Weinig sam.wei...@gmail.com wrote: Hi Folks, I am not happy with the way these runtime settings have been implemented so far as they break runtime detection using the technique we evangelize to developers, specifically, using the (property in window) method. A feature that is turned off at runtime should not be detectable at all, using any method (including Object.keys(), object.hasOwnProperty(), object.propertyIsEnumerable(), for-in enumeration, etc). I filed https://bugs.webkit.org/show_bug.cgi?id=29896 when the WebSocket runtime switching code went in and was disappointed to see similarly buggy code go in for SharedWorkers with out this being fixed. Leaving this in the tree is likely to introduce compatibility issues so I would recommend that we roll out these changes if they cannot be fixed in a timely manner. -Sam On Tue, Sep 8, 2009 at 11:47 PM, Darin Fisher da...@chromium.org wrote: As is described in https://bugs.webkit.org/show_bug.cgi?id=28941, for the Chromium project, we like to make incomplete features available behind a command line flag to help facilitate testing. I understand that the norm for WebKit is to only have compile time options for new / incomplete features. In some cases, runtime settings are defined, but these generally correspond to end user preferences or the needs of specific embedders. At any rate, I just wanted to make sure that folks were aware that some settings may only exist to help facilitate Chromium's goal of shipping incomplete features, disabled by default. Alexey asked if there are any guidelines for when these settings may be removed. I think the main thing is that the feature has to be reasonably complete and enabled by default by embedders (e.g., Chromium) that are compiling the feature. Regards, -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 ___ 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
BTW, I modeled my SharedWorker disabling after the code in JSDOMWindowCustom::audio() that disables the audio constructor on platforms that don't have MediaPlayer support. I think the runtime behavior of window.audio and window.SharedWorker should be identical in practice. Sam, it looks like you wrote JSDOMWindowCustom::audio() - do you see its behavior as unacceptable as well, or do you have some other code to prevent enumeration of window.audio that I can generalize for use for SharedWorkers too? -atw On Mon, Oct 5, 2009 at 5:46 PM, Drew Wilson atwil...@google.com wrote: So, two weeks ago I sent an email on this thread stating exactly what I was planning to do, To whit: I do think that we ought to be returning undefined instead of null in those cases, though, just to catch people who are accidentally using isUndefined() utility functions from common libraries. It would not be hard to define some kind of [mapNullToUndefined] custom attribute for the code generator. Maciej and AP both chimed in saying that disabling enumeration (i.e. SharedWorker in window) would be prohibitively hard, and giving a tacit OK to my approach (my emphasis below): It would be pretty complicated to do that [disabling [LocalStorage in window] based on a runtime setting. You would need a custom getter for any object that has properties which may appear or disappear based on settings. This is *probably too complicated to be worth it*. Or at least, if we added that level of code complexity I would begin to doubt the merits of supporting runtime enabling of Web platform features. I'm surprised to see these objections coming up now, weeks after the original discussion, and only after my patch has landed in the tree. That said, I agree that in an ideal world, we'd hide window.audio, shared workers, notifications, local storage, databases, session storage and any other runtime/platform-disabled API from enumerations - I just agree with Maciej that this isn't a hugely important issue, since these features are only runtime-disabled while under development and so not widely available anyway. Regardless, I don't think we should rush out to roll all of those features out of the tree, and I certainly don't think we should be singling out SharedWorkers or WebSockets - if we feel strongly that this needs to be addressed, we can update all of those features accordingly. If people with knowledge of the internals of V8 and JSC can chime in, we can discuss how best to approach this. -atw On Mon, Oct 5, 2009 at 5:04 PM, Sam Weinig sam.wei...@gmail.com wrote: Hi Folks, I am not happy with the way these runtime settings have been implemented so far as they break runtime detection using the technique we evangelize to developers, specifically, using the (property in window) method. A feature that is turned off at runtime should not be detectable at all, using any method (including Object.keys(), object.hasOwnProperty(), object.propertyIsEnumerable(), for-in enumeration, etc). I filed https://bugs.webkit.org/show_bug.cgi?id=29896 when the WebSocket runtime switching code went in and was disappointed to see similarly buggy code go in for SharedWorkers with out this being fixed. Leaving this in the tree is likely to introduce compatibility issues so I would recommend that we roll out these changes if they cannot be fixed in a timely manner. -Sam On Tue, Sep 8, 2009 at 11:47 PM, Darin Fisher da...@chromium.org wrote: As is described in https://bugs.webkit.org/show_bug.cgi?id=28941, for the Chromium project, we like to make incomplete features available behind a command line flag to help facilitate testing. I understand that the norm for WebKit is to only have compile time options for new / incomplete features. In some cases, runtime settings are defined, but these generally correspond to end user preferences or the needs of specific embedders. At any rate, I just wanted to make sure that folks were aware that some settings may only exist to help facilitate Chromium's goal of shipping incomplete features, disabled by default. Alexey asked if there are any guidelines for when these settings may be removed. I think the main thing is that the feature has to be reasonably complete and enabled by default by embedders (e.g., Chromium) that are compiling the feature. Regards, -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 ___ 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
On Mon, Oct 5, 2009 at 6:20 PM, Sam Weinig sam.wei...@gmail.com wrote: On Mon, Oct 5, 2009 at 5:46 PM, Drew Wilson atwil...@google.com wrote: I'm surprised to see these objections coming up now, weeks after the original discussion, and only after my patch has landed in the tree. Sorry, I seemed to have missed that thread. I did however file a bug as soon as the first runtime switch went in. That said, I agree that in an ideal world, we'd hide window.audio, shared workers, notifications, local storage, databases, session storage and any other runtime/platform-disabled API from enumerations - I just agree with Maciej that this isn't a hugely important issue, since these features are only runtime-disabled while under development and so not widely available anyway. I obviously disagree with Maciej on this. I think it is bad to break developers expectations for feature detection. OK, it's good to get consensus, even if it comes after I already thought we had achieved it :) From a purist's perspective, I see where you're coming from. Pragmatically, though, these runtime flags are only available on the Chrome dev channel (and go away before the features are ever shipped to the beta/stable channels) so the compatibility issues are somewhat moot. We've discussed removing these feature flags (and the ability to disable the features at runtime) once the features become stable - I don't know if that's a good idea or not, but that might impact this discussion as well. Regardless, I don't think we should rush out to roll all of those features out of the tree, and I certainly don't think we should be singling out SharedWorkers or WebSockets I don't mean to single out SharedWorkers or WebSockets, but I don't see any others using the same technique (barring window.Audio, which I don't think is the same thing, but should non-the less be fixed). But, as we have many developers using the nightlies, I think this should be handled with some speed. Take a look at DOMWindow.cpp - there's quite a bit of code that does something like look at settings to see if feature is enabled, return null if not (DOMWindow::openDatabase(), for an example). We discussed changing this code to return undefined instead of null, which was the genesis of this thread, before we realized that the issues ran deeper than that. -Sam ___ 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
Ooops, meant to reply to all. On Mon, Oct 5, 2009 at 7:49 PM, Drew Wilson atwil...@google.com wrote: On Mon, Oct 5, 2009 at 6:40 PM, Sam Weinig sam.wei...@gmail.com wrote: That is not true, they are also available in nightly builds at http://nightly.webkit.org/. I'm not sure what you mean, exactly - the nightly webkit builds all have SharedWorkers turned on, with no way to turn them off short of editing the source code and recompiling (since the only existing implementation of SharedWorkerRepository.isAvailable() returns true). I suspect I'm missing something obvious, though - can you elaborate? My expectation was that only when I write the Chromium implementation of SharedWorkerRepository will isAvailable() ever return false - so this only affects Chromium deployments. Regardless, I don't think we should rush out to roll all of those features out of the tree, and I certainly don't think we should be singling out SharedWorkers or WebSockets I don't mean to single out SharedWorkers or WebSockets, but I don't see any others using the same technique (barring window.Audio, which I don't think is the same thing, but should non-the less be fixed). But, as we have many developers using the nightlies, I think this should be handled with some speed. Take a look at DOMWindow.cpp - there's quite a bit of code that does something like look at settings to see if feature is enabled, return null if not (DOMWindow::openDatabase(), for an example). This is indeed unfortunate, but also is a step removed, since it does not really effect feature detection, it is also not a shipping configuration. Why doesn't it affect feature detection? Someone can do if localStorage in window, yet have their code fail when window.localStorage is null? -Sam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Skipping Flakey Tests
I wanted to re-open this discussion with some real-world feedback. In this case, there was a failure in one of the layout tests on the windows platform, so following the advice below, aroben correctly checked in an update to the test expectations instead of skipping the tests. Downstream, this busted the Chromium tests, because that failure was not happening in Chromium, and now our correct test output doesn't match the incorrect test output that's been codified in the test expecations. We can certainly manage this downstream by rebaselining the test and managing a custom chromium test expectation, but that's a pain and is somewhat fragile as it requires maintenance every time someone adds a new test case to the test. I'd really like to suggest that we skip broken tests rather than codify their breakages in the expectations file. Perhaps we'd make exceptions to this rule for tests that have a bunch of working test cases (in which case there's value in running the other test cases instead of skipping the entire test). But in general it's less work for everyone just to skip broken tests. I don't have an opinion about flakey tests, but flat-out-busted tests should get skipped. Any thoughts/objections? -atw On Fri, Sep 25, 2009 at 1:59 PM, Darin Adler da...@apple.com wrote: Green buildbots have a lot of value. I think it’s worthwhile finding a way to have them even when there are test failures. For predictable failures, the best approach is to land the expected failure as an expected result, and use a bug to track the fact that it’s wrong. To me this does seem a bit like “sweeping something under the rug”, a bug report is much easier to overlook than a red buildbot. We don’t have a great system for keeping track of the most important bugs. For tests that give intermittent and inconsistent results, the best we can currently do is to skip the test. I think it would make sense to instead allow multiple expected results. I gather that one of the tools used in the Chromium project has this concept and I think there’s no real reason not to add the concept to run-webkit-tests as long as we are conscientious about not using it when it’s not needed. And use a bug to track the fact that the test gives insufficient results. This has the same downsides as landing the expected failure results. For tests that have an adverse effect on other tests, the best we can currently do is to skip the test. I think we are overusing the Skipped machinery at the moment for platform differences. I think in many cases it would be better to instead land an expected failure result. On the other hand, one really great thing about the Skipped file is that there’s a complete list in the file, allowing everyone to see the list. It makes a good to do list, probably better than just a list of bugs. This made Darin Fisher’s recent “why are so many tests skipped, lets fix it” message possible. -- 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] Skipping Flakey Tests
OK, I agree as well - skipping is not a good solution here; I don't think the status quo is perfect, yet probably not imperfect enough to do anything about :) I guess there's just a process wrinkle we need to address on the Chromium side. It's easy to rebaseline a test in Chromium, but less easy to figure out when it's safe to un-rebaseline it. -atw On Thu, Oct 1, 2009 at 11:57 AM, Eric Seidel esei...@google.com wrote: I agree with Darin. I don't think that this is a good example of where skipping would be useful. I think more you're identifying that there is a test hierarchy problem here. Chromium really wants to base its tests off of some base win implementation, and then win-apple, win-chromium, win-cairo results could derive from that, similar to how mac and mac-leopard, mac-tiger, mac-snowleopard work. I think we should skip only tests that endanger the testing strategy because they are super-slow, crash, or adversely affect other tests in some way. Back to the original topic: I do however see flakey tests as endangering our testing strategy because they provide false negatives, and greatly reduce the value of the layout tests and things which run the layout tests, like the buildbots or the commit-bot. I also agree with Darin's earlier comment that WebKit needs something like Chromium's multiple-expected results support so that we can continue to run flakey tests, even if they're flakey instead of having to resort to skipping them. But for now, skipping is the best we have, and I still encourage us to use it when necessary instead of leaving layout tests flakey. :) -eric ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Issues with Workers
There is this: https://bugs.webkit.org/show_bug.cgi?id=22878 The issue extends beyond workers - it's anything that supports the postMessage() API (window objects, MessagePorts). As was pointed out previously, there have been some design discussions in this area, but I haven't seen any patches yet (and since serialization is closely tied to the JS VM on each platform, we will undoubtedly need to have two implementations - one for JSC and one for V8). -atw On Mon, Sep 28, 2009 at 1:15 PM, Mark Rowe mr...@apple.com wrote: On 2009-09-28, at 10:23, Chris Campbell wrote: Hi Tali, Regarding event.data, there is a chromium issue filed for this here: http://crbug.com/21299 Given that this would seem to be an issue at the WebKit level, is there a bug in WebKit bug about this issue? - Mark ___ 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] Runtime setting for incomplete features
Following up on this, because I missed Maciej's response. On Mon, Sep 21, 2009 at 1:22 PM, Maciej Stachowiak m...@apple.com wrote: Fair enough. But I would be against user-level preferences that add or remove entire APIs. Rather, the preference should affect the behavior of the API (possibly making it do nothing). So far the only actual user-level preference I'm aware of that effectively disables APIs is private browsing. And I think the way it works (in both Safari and Chrome, even though it is different) is better than it would be to make storage-related APIs disappear completely. Maciej, are you saying that if I were to add a flag to disable SharedWorkers, you'd want it to leave the constructor intact (i.e. not remove the API) but just not create the actual thread? That seems bad, as it means web apps can't do capability checking. It seems better to remove the API. I'm about to add a flag for SharedWorkers (possibly just within Chromium if I can), so I definitely want to resolve this. Which is a shame, because if (localStorage in window) is a generally a better way to feature test than if (window.localStorage). The latter idiom is problematic for attributes where a possible valid value is something that evaluates to false, or where computing the value can be expensive. For example, if (document.body.outerHTML) would be an awful way to test whether outerHTML is available. Agreed. In practice, I can't think of anything we'd disable in run time like that, but it's obviously more difficult for the web developer to know this. Even though this style of feature test is better, it's tragically much less common than if (window.fooBar), so it's likely not a problem in practice. Even if we can't make the property not show up, would you agree that returning undefined is better than returning null? Slightly better. The only real difference it would make is if someone tests using a === comparison to undefined (as opposed to == or just a plain boolean test). Regards, Maciej ___ 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] Runtime setting for incomplete features
I think shooting for perfect compatibility might be nice, but is probably not required. I do think that we ought to be returning undefined instead of null in those cases, though, just to catch people who are accidentally using isUndefined() utility functions from common libraries. It would not be hard to define some kind of [mapNullToUndefined] custom attribute for the code generator. I'll probably be adding a flag for Chromium shared workers in the near future, and I could tackle this at that time if people think this is a reasonable solution. Jeremy, do you do anything to turn off the Storage constructor (i.e. window['Storage']) if storage is disabled? -atw On Fri, Sep 18, 2009 at 1:30 PM, Jeremy Orlow jor...@chromium.org wrote: On Fri, Sep 18, 2009 at 12:59 PM, Alexey Proskuryakov a...@webkit.orgwrote: 18.09.2009, в 12:24, Jeremy Orlow написал(а): I'm not sure if we've hit any compatibility issues with this yet, but it seems quite plausible that someone would compare window.localStorage (or sessionStorage or database) to undefined and, since it's null (vs. undefined), their script would assume it's available. Note that they can also do 'localStorage in window', which we can't easily prevent from returning true. That's true. And unfortunate. What would be involved in making it not return true? ___ 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] Commit Queue Status
So awesome - thanks for doing this, Eric. It says it's blocked because the builders are red - is it just looking for compile status across all platforms, or does it actually wait for all unit tests to be green, or just some subsets of the Mac unit tests, or what? -atw On Fri, Sep 18, 2009 at 2:47 PM, Eric Seidel e...@webkit.org wrote: In case you're wondering why your commit-queue+'d patch has not landed yet... http://webkit-commit-queue.appspot.com/ will now tell you. It needs work, but it's better than nothing. The code will soon be in SVN and patches are most welcome: https://bugs.webkit.org/show_bug.cgi?id=29307 -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] Passing data structures through postMessage()
Note that ImageData is cloned/copied when sent via postMessage(). So you end
up with a copy of the ImageData, obviating the need for locks.
I think (per my private mail to Darin which I'm restating here) that the use
case is doing some kind of raytracing or something in a Worker, posting the
result to a page, then blitting the result back to the canvas via
putImageData().
-atw
On Fri, Sep 11, 2009 at 10:54 AM, Darin Fisher da...@google.com wrote:
On Thu, Sep 10, 2009 at 5:21 PM, Maciej Stachowiak m...@apple.com wrote:
On Sep 10, 2009, at 3:12 PM, Chris Campbell wrote:
Hi All,
I had it in mind to implement support for passing data structures
through postMessage() using the structured clone algorithm laid out
in the HTML5 spec:
http://dev.w3.org/html5/spec/Overview.html#posting-messages
http://dev.w3.org/html5/spec/Overview.html#safe-passing-of-structured-data
I've had some brief discussion with Dave Levin and Drew Wilson on
#chromium IRC about this, and have an approach in mind that follows
and elaborates on their suggestions, but there are still some holes in
it and I'd very much like input from people familiar with this area.
Currently, there are several postMessage() handlers (in
MessagePort.idl, DOMWindow.idl, DedicatedWorkerContext.idl, and
Worker.idl), and they all take a DOMString for the message parameter.
The general idea is to change that message parameter from a DOMString
to a new AttributeIterator type that allows walking of any sort of JS
structure/type. AttributeIterator would essentially be an adapter to
translate native V8 or JSC JavaScript objects to an agnostic interface
suitable for walking the structure and serializing it. I'm thinking
it would look something like this:
interface AttributeIterator {
bool isUndefined();
bool isNull();
bool isFalse();
bool isTrue();
bool isNumber();
String getNumber();
bool isString();
// ... cover the other types including Date, RegExp, ImageData,
// File, FileData, and FileList ...
// Retrieve the key for the next property (for Objects and Arrays)
String nextEnumerableProperty();
AttributeIterator getPropertyValue(key);
}
Some thoughts off the cuff:
I think it would be better to write custom code for doing the cloning for
each JS engine. For one thing, turning everything into a string is not
necessarily the most efficient way to do things. It might be possible to
clone the object graph more directly in a threadsafe way. Also, things like
File and ImageData fundamentally can't be turned into a string (well
ImageData can)
What does it mean to send a File along? Isn't that just a reference to a
file? A handle of sorts. It seems like that is something that can be
passed between threads easily enough.
What is the use case for sending ImageData? It seems like it could be to
allow a worker to modify the pixels of a canvas or it could be to share a
separate copy of the data (copy-on-write). It may be undesirable to make
the canvas have to support having its data be modified by a background
thread / background process.
-Darin
Second, to be really agnostic about it, postMessage should take a generic
Message object that has some methods that can be used to do the cross-thread
clone without building in the assumption that it serializes to a string in
the middle.
Third, using a stateful iterator for this instead of an interface
representing a value is not a great design. Iterators are not good when what
you are traversing is in general a graph.
Fourth, this doesn't give a way to detect if an object graph is not in
fact legal to clone.
It's kind of a shame that we have the baggage of multiple JavaScript
engines to contend with. Trying to do things in a generic way will make this
task needlessly more difficult.
You may also want to get input on this from Oliver Hunt, who wrote the JSC
JSON parse/stringify code; from past discussions I know has opinions on how
cross-thread cloning should work.
I'm also thinking that depending on compile-time flags, the
contstructor for AttributeIterator would either take a
v8::Handlev8::Value or JSC::JSvalue value.
Then in each implementation of postMessage() the AttributeIterator
instance could be passed to the structured clone serializer, which
would return a string. Thereafter, no changes would be required to
WebCore internals since they already pass strings around... until on
the receiving end we get to MessageEvent.data where we would do the
deserialization in a custom getter.
Open questions:
(1) Is passing an AttributeIterator type into postMessage() really the
best way to go? Drew mentioned that this might incur a bunch of ObjC
binding work on the JSC side...
(2) Where should AttributeIterator live in the source tree?
(3) Where should the serialization and deserialization routines live
in the source tree?
(3) I haven't addressed the specifics of the serialized string
Re: [webkit-dev] Passing data structures through postMessage()
The other approach we discussed was leaving the postMessage() APIs in
WebCore as they are (taking a DOMString parameter) and doing the
serialization/de-serialization in the JS bindings instead.
My one concern about building the serialization into the WebCore postMessage
impls is I didn't quite understand how that would map to ObjC (although for
ObjC we could just continue exposing only postMessage(DOMString) and have
the ObjC bindings wrap the string in an attributeIterator).
My main concern with any approach is that we find a way to share
serialization code between V8 and JSC.
-atw
On Thu, Sep 10, 2009 at 3:12 PM, Chris Campbell campb...@flock.com wrote:
Hi All,
I had it in mind to implement support for passing data structures
through postMessage() using the structured clone algorithm laid out
in the HTML5 spec:
http://dev.w3.org/html5/spec/Overview.html#posting-messages
http://dev.w3.org/html5/spec/Overview.html#safe-passing-of-structured-data
I've had some brief discussion with Dave Levin and Drew Wilson on
#chromium IRC about this, and have an approach in mind that follows
and elaborates on their suggestions, but there are still some holes in
it and I'd very much like input from people familiar with this area.
Currently, there are several postMessage() handlers (in
MessagePort.idl, DOMWindow.idl, DedicatedWorkerContext.idl, and
Worker.idl), and they all take a DOMString for the message parameter.
The general idea is to change that message parameter from a DOMString
to a new AttributeIterator type that allows walking of any sort of JS
structure/type. AttributeIterator would essentially be an adapter to
translate native V8 or JSC JavaScript objects to an agnostic interface
suitable for walking the structure and serializing it. I'm thinking
it would look something like this:
interface AttributeIterator {
bool isUndefined();
bool isNull();
bool isFalse();
bool isTrue();
bool isNumber();
String getNumber();
bool isString();
// ... cover the other types including Date, RegExp, ImageData,
// File, FileData, and FileList ...
// Retrieve the key for the next property (for Objects and Arrays)
String nextEnumerableProperty();
AttributeIterator getPropertyValue(key);
}
I'm also thinking that depending on compile-time flags, the
contstructor for AttributeIterator would either take a
v8::Handlev8::Value or JSC::JSvalue value.
Then in each implementation of postMessage() the AttributeIterator
instance could be passed to the structured clone serializer, which
would return a string. Thereafter, no changes would be required to
WebCore internals since they already pass strings around... until on
the receiving end we get to MessageEvent.data where we would do the
deserialization in a custom getter.
Open questions:
(1) Is passing an AttributeIterator type into postMessage() really the
best way to go? Drew mentioned that this might incur a bunch of ObjC
binding work on the JSC side...
(2) Where should AttributeIterator live in the source tree?
(3) Where should the serialization and deserialization routines live
in the source tree?
(3) I haven't addressed the specifics of the serialized string format.
Plain JSON is not quite sufficient since it doesn't retain type
information for Date, RegExp, etc.. However, I'm not too worried
about coming up with a suitable format for this.
Comments, advice, admonitions welcome! :)
Regards,
--Chris
___
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] Passing data structures through postMessage()
On Thu, Sep 10, 2009 at 5:29 PM, Oliver Hunt oli...@apple.com wrote: This is incorrect, from the bindings point of view the type here should be any, which in the JS bindings means ScriptValue. The actual serialisation is by definition bindings dependent, be that JSC or ObjC. Certainly, from a WebIDL standpoint this is correct. I'm not certain that our current code generator will accept this (the JS bindings are quite flexible especially if we are talking about custom attributes, but my experience with the ObjC generated bindings are that you need to specify concrete classes in the .idl files or else you end up with type errors at compile time - this could obviously be changed). --Oliver ___ 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] Passing data structures through postMessage()
I'm not sure that it is actually more restrictive now than it was 6 months ago. I assume you're looking at this: http://www.w3.org/TR/2009/WD-html5-20090212/infrastructure.html#safe-passing-of-structured-data where it seems to say that all host objects (DOM objects, etc) are cloned as null. Sounds like you looked into it in much more detail than I did, so undoubtedly there are ambiguities that aren't obvious at first glance. Anyhow, from April up until two weeks ago, ImageData was the only serialized host object: http://www.w3.org/TR/2009/WD-html5-20090423/infrastructure.html#safe-passing-of-structured-data ...so I'm not totally crazy :) It's a moot point now - while I could (and did :) imagine a reasonably compact one-off serialization for something like ImageData, the addition of the File types on 8/25 (and who knows what else in the future) makes it clear that serialization is not the way to go. -atw On Thu, Sep 10, 2009 at 5:38 PM, Oliver Hunt oli...@apple.com wrote: No, it is more restrictive now than it was 6 months ago -- I was attempting to implement this back then and the ambiguity in handling the more excitingly complex objects (now simply return null) made it substantially more complex, that is the only reason the implementation is not currently matching the object clone semantic. JSON was never sufficient for the purpose of postMessage, and is also relatively trivially breakable. --Oliver On Sep 10, 2009, at 5:29 PM, Drew Wilson wrote: Good point - re-reviewing the Structured Clone spec, I see all kinds of crazy stuff is cloneable now, so string/JSON may not be a particularly good basis. It seems that we'll need to support File access from Workers, since you can clone/send those objects over from page context. I had expected that having a common serialization format would be useful, but I agree - it probably is better to just send opaque objects around, which might enable WebKit to send actual cloned object instances without requiring any serialization, while chromium can do the serialization itself when sending the data cross-process. -atw ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] How to handle Array types in IDL files?
I'm trying to update MessageEvent to match the current HTML5 spec. Currently, MessageEvent has two references to MessagePort: readonly attribute *MessagePort messagePort*; void initMessageEvent(in DOMString typeArg, in boolean canBubbleArg, in boolean cancelableArg, in DOMString dataArg, in DOMString originArg, in DOMString lastEventIdArg, in DOMWindow sourceArg, *in MessagePort messagePort*); MessageEvent now needs to support an array of MessagePorts. I had planned to provide a custom getter for the messagePort attribute and change initMessageEvent to be custom as well, resulting in this: readonly attribute [CustomGetter] *Array ports*; [Custom] void initMessageEvent(in DOMString typeArg, in boolean canBubbleArg, in boolean cancelableArg, in DOMString dataArg, in DOMString originArg, in DOMString lastEventIdArg, in DOMWindow sourceArg, *in Array messagePorts*); My custom JS handlers could map between JSArray and the native WebCore collection used by the impl class. I'm not certain whether this is the right approach for the objc bindings, however - in fact, the generated code for DOMMessageEvent.mm contains #import Array.h and #import DOMArrayInternal.h, neither of which exist. What do people suggest here? I'm not certain how this should be exposed for ObjC. Other classes (like Clipboard.idl) that use Array don't seem to have objc bindings, but I don't think that's an option for MessageEvent. -atw ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] How to handle Array types in IDL files?
To be more precise, the HTML5 IDL defines the following: typedef sequenceMessagePort MessagePortArray; The types above are all MessagePortArray in the spec, not Array. So it seems like the intent is that they should indeed get mapped to a vanilla JS Array. I could make these attributes JS-only - that shouldn't be a huge issue since MessagePorts are currently only enabled for JS anyway (MessagePort is an empty interface for ObjC). Is that acceptable? Sam? -atw On Wed, Aug 26, 2009 at 12:34 AM, Cameron McCormack c...@mcc.id.au wrote: Maciej Stachowiak: We probably need special support for Web IDL array types in the bindings generator. Sam can probably comment n more detail. As a stopgap, we could make the relevant IDL attributes be JS only. I would check out what Web IDL says about Array - I don't think it's supposed to be reflected as just a vanilla JS Array. Currently Web IDL says that when getting an attribute of type sequenceT, a new JS Array object is returned. For array types, T[], a host object with particular [[Get]] and [[Put]] behaviour is meant to be used, which makes it similar to a native Array. Both of these things are pretty speculative, and could do with review. -- Cameron McCormack ≝ http://mcc.id.au/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Leaks in layout tests
I'm seeing a bunch of leaks when running even simple layout tests (i.e. run-webkit-tests --debug --leaks fast/js/typeof-syntax.html). This ring any bells for anyone?: start main dumpRenderTree(int, char const**) runTestingServerLoop() runTest(std::basic_stringchar, std::char_traitschar, std::allocatorchar const) -[NSRunLoop(NSRunLoop) runMode:beforeDate:] CFRunLoopRunInMode CFRunLoopRunSpecific MultiplexerSource::perform() URLConnectionClient::processEvents() URLConnectionClient::ClientConnectionEventQueue::processAllEventsAndConsumePayload(XConnectionEventInfoXClientEvent, XClientEventParams*, long) URLConnectionClient::_clientDidFinishLoading(URLConnectionClient::ClientConnectionEventQueue*) _NSURLConnectionDidFinishLoading -[NSURLConnection(NSURLConnectionReallyInternal) sendDidFinishLoading] -[WebCoreResourceHandleAsDelegate connectionDidFinishLoading:] WebCore::ResourceLoader::didFinishLoading(WebCore::ResourceHandle*) WebCore::SubresourceLoader::didFinishLoading() WebCore::Loader::Host::didFinishLoading(WebCore::SubresourceLoader*) WebCore::CachedCSSStyleSheet::data(WTF::PassRefPtrWebCore::SharedBuffer, bool) WebCore::CachedCSSStyleSheet::checkNotify() WebCore::HTMLLinkElement::setCSSStyleSheet(WebCore::String const, WebCore::String const, WebCore::CachedCSSStyleSheet const*) WebCore::CSSStyleSheet::checkLoaded() WebCore::HTMLLinkElement::sheetLoaded() WebCore::Document::removePendingSheet() WebCore::HTMLTokenizer::executeScriptsWaitingForStylesheets() WebCore::HTMLTokenizer::notifyFinished(WebCore::CachedResource*) WebCore::HTMLTokenizer::scriptExecution(WebCore::ScriptSourceCode const, WebCore::HTMLTokenizer::State) WebCore::FrameLoader::executeScript(WebCore::ScriptSourceCode const) WebCore::ScriptController::evaluate(WebCore::ScriptSourceCode const) JSC::evaluate(JSC::ExecState*, JSC::ScopeChain, JSC::SourceCode const, JSC::JSValue) WTF::PassRefPtrJSC::ProgramNode JSC::Parser::parseJSC::ProgramNode(JSC::ExecState*, JSC::Debugger*, JSC::SourceCode const, int*, JSC::UString*) JSC::Parser::parse(JSC::JSGlobalData*, int*, JSC::UString*) jscyyparse(void*) JSC::ParserArenaDeletable::operator new(unsigned long) WTF::fastMalloc(unsigned long) malloc malloc_zone_malloc ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Loading from shared workers (shadow documents?)
Hi all, I'm about to work on adding network access support to shared workers. To refresh your memory, shared workers can outlive any specific document object - they exit when the last referring document exits. Current dedicated workers just proxy all network operations over to their associated Document object. If the Document is closed prematurely, then the network operation is aborted and an error is returned to the worker, which is fine because the Worker is exiting anyway. For shared workers we can't just proxy network operations over to an arbitrary parent document, because the user may choose to close that document in mid-load yielding an inappropriate error response to the user. We have a few options: 1) If a document closes mid-load, just return an error to the worker. So treat this case like Just Another Network Hiccup. 2) If a document closes mid-load, just retry the network access on another parent document. I'm not certain that this is acceptable from a spec-compliance standpoint (the server might end up seeing multiple network requests even though from the client stand point only one was issued). 3) Don't let documents fully go away while there's outstanding worker network access. For a long-lived hanging get, this seems like it might keep a document around (in hidden state) for a long time, and I'm not sure what the ramifications are of that. Also, there's the issue of how to deal with things like HTTP auth from hidden documents (although HTTP auth is problematic for shared workers in general as it's kind of arbitrary which window the auth UI appears under). 4) Create a new shadow document for the worker that it uses to satisfy all of its loading requests. This is what Chromium does for all its worker network access currently. This is the most robust solution, although I'm still not certain how HTTP auth would be handled in this case). I'm leaning towards #1 in the short-term, but I'd like to get feedback about what our long-term approach should be. -atw ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Reporting exceptions from worker context to users
Hi all, Currently, unhandled exceptions are sent from worker context over to the parent page where they are logged to the console. This works fine for dedicated workers, but not for shared workers which can have multiple active windows. The immediate solution that springs to mind is to broadcast the exception to every window associated with a shared worker, and have each window log the unhandled exception to its console. Is there another option that might be better (is there the concept of an inspector/console that is not associated with a specific window, for example)? -atw ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Reporting exceptions from worker context to users
OK, I really wanted to gloss over this, but now Jeremy's going to make me elaborate :) There are a few things I think we will eventually need to support worker development: 1) Some way to print out the values of things in a worker's global scope. 2) Similar debugging support for workers that we have for page script (breakpoints, etc). 3) When the user is selecting a worker for #1/#2, it might be useful to indicate what the parent(s) of the worker are to help developers select the right worker (in case there are nested workers). Or maybe it's not very useful - perhaps just having the URL of the worker base script is sufficient. We don't know yet. None of these issues have anything to do specifically with SharedWorkers. Nor do I think that we should block development on arbitrary features like nested workers because we think we need better tools. A better solution would be to roll out a just barely good enough solution, get developer feedback on real use cases, and improve the tools over time to reflect that feedback, just as we do for every other feature in WebKit. -atw On Sat, Aug 1, 2009 at 1:06 PM, Jeremy Orlow jor...@chromium.org wrote: I think logging to all connected pages' console is fine for now, but I think Michael's suggestion (or something similar) should be implemented in the not too distant future. Definitely before shared workers are allowed to communicate with each other. J On Sat, Aug 1, 2009 at 12:45 PM, Michael Nordman micha...@google.comwrote: it sounds like we have one vote for just log them to the console for every connected document sgtm On Sat, Aug 1, 2009 at 12:39 PM, Drew Wilsonatwil...@google.com wrote: Yes, SharedWorkers will eventually be able to communicate with one another, as will DedicatedWorkers. So at some point we'll have a big connected graph of workers that potentially might be interesting for people to traverse and inspect their global contexts (I'm not sure - I don't think we know yet what debugging tools will be useful for developers). Further agreed, the HTML5 spec states that exceptions from shared workers are *not* propagated to parent pages for application execution - this would be solely for logging purposes. In the meantime while we work towards our glorious future, I'd still like to log exceptions somewhere :) It sounds like we have one vote for just log them to the console for every connected document. -atw On Sat, Aug 1, 2009 at 10:35 AM, Michael Nordman micha...@google.com wrote: Shared workers can also communicate directly with one another, is that right? And its possible to have a shared worker whose only client is another shared worker, is that right? Feels like we should be working towards inspecting shared workers directly. Where a page inspector would show which shared workers it was connected to, and you could open a separate inspector to see what is going on within each shared worker (including which shared workers it was connected to). Broadcasting exceptions within a worker to its clients for inspection purposes may be useful even with separate inspectors per shared worker. The client's 'shared worker' tab (or console) could log unhandled exceptions occurring in each, as you described, encouraging the developer to look into it... open the shared worker inspector and poke around. About broadcasting unhandled shared worker exceptions in general... It makes sense to have unhandled exceptions in a dedicated process propagated to the parent page's context (which may presumably handle the exception in some way). But I'm not sure that model applies to unhandled exceptions in shared workers. The possibility of multiple connected pages, which should handle it? Seems good for logging/debugging purposes to have them show up in the client's inspector, but doesn't sound like a good fit for application execution purposes. On Sat, Aug 1, 2009 at 9:31 AM, Drew Wilsonatwil...@google.com wrote: Hi all, Currently, unhandled exceptions are sent from worker context over to the parent page where they are logged to the console. This works fine for dedicated workers, but not for shared workers which can have multiple active windows. The immediate solution that springs to mind is to broadcast the exception to every window associated with a shared worker, and have each window log the unhandled exception to its console. Is there another option that might be better (is there the concept of an inspector/console that is not associated with a specific window, for example)? -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
Re: [webkit-dev] Setting event handlers on the global context
Ran a quick test on Opera and IE along these lines:
htmlbodyscript function onload() { alert(onload); }
/script/body/html
Only firefox displayed the alert dialog when loading this page -
IE/Opera/WebKit do not. So if this behavior is incorrect, at least we have
lots of company.
-atw
On Sun, Jul 19, 2009 at 4:28 PM, Maciej Stachowiak m...@apple.com wrote:
On Jul 19, 2009, at 11:10 AM, Adam Barth wrote:
I think we should do what Firefox does in the window.onload case. :)
I'm not familiar with the history through. Is there some particular
reason we have our current behavior?
The current behavior is an accident of implementation, but I think the
relevant applicable spec is somewhat ambiguous. A function declaration
creates a new var-like binding which shadows the underlying onmessage
setter.
The relevant spec here is ECMAScript, not HTML5. In ECMA-262, section
10.1.3 is what would apply, I haven't checked the proper reference for the
fifth edition draft. Regarding the declaration of a function with the same
name as an existing property, it says: If the variable object already has a
property with this name, replace its value and attributes. So a vanilla
property should get replaced with a DontDelete property, but in the case of
a setter it's not clear whether it should be replaced or shadowed.
It would probably be good to match other browsers. I am curious what IE and
Opera do here. I would also be curious if ECMAScript 5 is more clear about
what to do when a function declaration has the same name as a setter
property, since it supports getters and setters in the spec.
his would be slightly, but not insanely tricky to fix. The relevant code
is all in BytecodeGenerator::BytecodeGenerator(ProgramNode*
programNode), since this only affects global scope. The change could
have far-reaching consequences so we'd have to be on the lookout for Web
compatibility regressions if we change this.
Regards,
Maciej
Adam
On Sun, Jul 19, 2009 at 10:56 AM, Drew Wilsonatwil...@google.com wrote:
Yes, it happens with window.onload() too (I didn't mean to imply that it
was
a worker-only issue).
This seems like precisely the type of inoperability that the HTML5 spec
should address, but I figured I should get some input here before
bringing
it up there.
-atw
On Sun, Jul 19, 2009 at 10:31 AM, Adam Barth aba...@webkit.org wrote:
You should test the same thing with window.onload. If I recall
correctly, you'll see similar inoperability.
Adam
On Sun, Jul 19, 2009 at 9:29 AM, Drew Wilsonatwil...@google.com
wrote:
I was writing a new worker unit test and I noticed that all of our unit
tests set event handlers in worker global context like so:
onmessage = function(event) { ... do something ... };
I note that Firefox also allows setting event handlers like this:
function onmessage(event) { ... do something ... };
In WebKit, the latter form creates a function at global scope named
onmessage but does not set it as an event handler.
I'm trying to figure out what the correct behavior should be - I've
asked
IanH, and his response was that he dimly recalls that both forms should
be
valid (through a convoluted argument that I forget right now, but
which
should be examined carefully by whoever implements this, and which
requires
careful examination of at least the ECMAScript spec and maybe also the
WebIDL and HTML5 specs) - basically, he wasn't entirely certain and
thought
I should check here and with the Mozilla devs to get your opinions.
Anyone familiar enough with the various specs to make a definitive
argument
one way or the other?
-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] Setting event handlers on the global context
Yes, it happens with window.onload() too (I didn't mean to imply that it was
a worker-only issue).
This seems like precisely the type of inoperability that the HTML5 spec
should address, but I figured I should get some input here before bringing
it up there.
-atw
On Sun, Jul 19, 2009 at 10:31 AM, Adam Barth aba...@webkit.org wrote:
You should test the same thing with window.onload. If I recall
correctly, you'll see similar inoperability.
Adam
On Sun, Jul 19, 2009 at 9:29 AM, Drew Wilsonatwil...@google.com wrote:
I was writing a new worker unit test and I noticed that all of our unit
tests set event handlers in worker global context like so:
onmessage = function(event) { ... do something ... };
I note that Firefox also allows setting event handlers like this:
function onmessage(event) { ... do something ... };
In WebKit, the latter form creates a function at global scope named
onmessage but does not set it as an event handler.
I'm trying to figure out what the correct behavior should be - I've asked
IanH, and his response was that he dimly recalls that both forms should
be
valid (through a convoluted argument that I forget right now, but which
should be examined carefully by whoever implements this, and which
requires
careful examination of at least the ECMAScript spec and maybe also the
WebIDL and HTML5 specs) - basically, he wasn't entirely certain and
thought
I should check here and with the Mozilla devs to get your opinions.
Anyone familiar enough with the various specs to make a definitive
argument
one way or the other?
-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] Documentation for attributes in IDL files
Hi all, Over the last couple of weeks I've run into some snags with my refactoring of the Worker code, most of them caused by a lack of understanding of how the various interface attributes in the IDL files worked. For example, the innocuous-sounding NoStaticTables attribute really means If you omit this on a class visible to Worker code, then only the first Worker ever created will be able to lookup properties on this class. On the bright side, I have a much better idea of how JSC prototype lookups work now that I've stepped through the code to debug this :) Anyhow, I've added a page to the wiki which attempts to document a (currently very small) subset of our supported IDL attributes: https://trac.webkit.org/wiki/IdlAttributes Feel free to correct any misinformation on that page, or to add documentation for the many attributes I've omitted. Hopefully this will save other people some time getting up to speed in the future. -atw ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Build File Maintenance (was Re: Please welcome GYP to the our dysfunctional build family)
Having used both Chromium's .gyp solution and WebKit's .update-a-bunch-of-random-files solution, I'd like to add a huge +1 to anyone interested in doing this for their own port. Especially since the lack of trybots for webkit means that it's prohibitively difficult for people to actually test their build changes cross-platform currently. Although maybe I'm just extra-sensitive to this since dimich and I spent a chunk of time last night diagnosing and fixing some gtk test bustage due to missing files from the build config. -atw On Fri, Jul 10, 2009 at 11:37 AM, Dimitri Glazkov dglaz...@chromium.orgwrote: To add to this, GYP also only generates files for _your_ platform on checkout. Even to the degree that on Windows, it would generate VS2008 projects if you had it installed, and VS2005 otherwise. To be precise, the selection is not automatic (you need an env variable) to avoid dual-VS installs ambiguity. :DG On Fri, Jul 10, 2009 at 11:32 AM, Mike Pinkertonpinker...@chromium.org wrote: On Fri, Jul 10, 2009 at 2:20 PM, Dimitri Glazkovdglaz...@chromium.org wrote: If you hand-edit Xcode project files enough times you start to understand them, but you also may go insane in the process. I don't know that you have to write a full parser for it, but there is some non-trivial, minimal structure you have to understand to update the file properly. GYP generates very nice XCode projects -- they are always properly sorted, logically structured, and clean. I think the difference worth highlighting here is that GYP doesn't *edit* Xcode projects. That is explicitly a non-goal. It generates new ones from scatch every time (but is smart enough not to touch anything if nothing would change). As a result, it doesn't need to know about all the various ways a project file could change from state A to state B. In Chromium, we don't have any Xcode files checked in, they're generated (again, from scratch, replacing whatever was there before) on every checkout. If you want to make local changes during the course of your development, that's fine (and helpful to test small tweaks), but the only canonical representation of the Xcode project file is in GYP. -- Mike Pinkerton Mac Weenie pinker...@google.com ___ 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 about Constructors in WebKit JS Bindings
OK, coming back around to this - I'm looking at the automatically generated
constructors. As an example, let's look at something simple like
EventException.
JSEventExceptionConstructor(ExecState* exec)
:
DOMObject(JSEventExceptionConstructor::createStructure(exec-lexicalGlobalObject()-objectPrototype()))
{
putDirect(exec-propertyNames().prototype,
JSEventExceptionPrototype::self(exec, *exec-lexicalGlobalObject()*), None);
}
It looks like this uses the current lexicalGlobalObject when constructing
the event exceptions prototype chain. Furthermore,
JSDOMGlobalObject::getDOMConstructor() and JSDOMBinding.cpp both use the
lexical global object to cache constructors.
So in the case the Maciej describes below, it *looks* like for
auto-generated constructors, the window you grab the constructor from is
immaterial - it always looks up/caches the constructor object in lexical
global scope (i.e. referencing window.EventExecutor returns the same value
for a given lexical scope, no matter what window refers to) so his bug
won't actually happen for his case.
I guess this behavior might be a bug, given this bugzilla entry:
https://bugs.webkit.org/show_bug.cgi?id=21138, but I'm somewhat uncertain
about that conclusion as it would mean that 95% of our constructors are
buggy. Anyone want to confirm this?
The other place where problems happen are for custom constructors that are
passed a reference to a JSDOMGlobalObject - in these situations we cache the
constructor on the passed-in JSDOMGlobalObject itself rather than on the
lexicalGlobalObject. So it seems incorrect to do this:
JSMessageChannelConstructor::JSMessageChannelConstructor(ExecState* exec,
JSDOMGlobalObject* globalObject)
: DOMObject(JSMessageChannelConstructor::createStructure(*
exec-lexicalGlobalObject()*-objectPrototype()))
, m_globalObject(globalObject)
{
putDirect(exec-propertyNames().prototype,
JSMessageChannelPrototype::self(exec, *exec-lexicalGlobalObject()*), None);
}
Note that the constructor prototype is being generated using
lexicalGlobalObject, but then the result is being cached in the passed-in
globalObject, leaving you with a reference in globalObject to a
constructor with a prototype chain that might be from a foreign context
(maciej's bug he described previously).
So it seems like we should never reference lexicalGlobalObject in our
constructor/prototype creation code at all. if I invoke new
otherWindow.MessageChannel(), I should get a MessageChannel object whose
prototype chain == otherWindow.MessageChannel.prototype. So the constructor
should look like this instead:
JSMessageChannelConstructor::JSMessageChannelConstructor(ExecState* exec,
JSDOMGlobalObject* globalObject)
: DOMObject(JSMessageChannelConstructor::createStructure(*globalObject*
-objectPrototype()))
, m_globalObject(globalObject)
{
putDirect(exec-propertyNames().prototype,
JSMessageChannelPrototype::self(exec, *globalObject*), None);
}
Sorry to belabor the point, but I want to make sure I don't propagate
invalid behavior in new code I'm writing, but I'm having trouble finding
*any* constructors that are doing the right thing currently, so I figure I
must be missing something :)
-atw
On Tue, Jun 23, 2009 at 5:14 PM, Adam Barth aba...@webkit.org wrote:
[+sam]
On Tue, Jun 23, 2009 at 5:11 PM, Drew Wilsonatwil...@google.com wrote:
On Tue, Jun 23, 2009 at 4:53 PM, Maciej Stachowiak m...@apple.com
wrote:
Also, there might be a subtle bug in the above code: what if
window.Worker
is first accessed from a different frame? Then the prototype of the
Worker
constructor itself will use the other frame's Object prototype as its
prototype. I'm not sure if that is right. I think maybe
JSWorkerConstructor
should be passed the global object from which it is retrieved as a
property,
instead of using the lexical global object.
Good catch. This bug seems to be in all our custom generated
constructors.
Yes. This has caused us headaches (e.g., security bugs) in the past.
Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Question about Constructors in WebKit JS Bindings
On Tue, Jul 7, 2009 at 5:25 PM, Adam Barth aba...@webkit.org wrote:
I'd have to look at the code a bit more to know whether this is
correct. Where does |globalObject| come from?
It comes from the JSDOMWindow object where that constructor is exposed. Case
in point:
#if ENABLE(CHANNEL_MESSAGING)
JSValue JSDOMWindow::messageChannel(ExecState* exec) const
{
return getDOMConstructorJSMessageChannelConstructor(exec, *this*);
}
#endif
So, when you first access someWindow.MessageChannel it should create a
JSMessageChannelConstructor whose prototype property is derived from
someWindow, then cache it in someWindow.
I'll run some tests as you suggest.
For an added bonus, you should test what happens if you transplant the
constructor from one window to another. The constructor should keep
its original prototype chain.
Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Question about Constructors in WebKit JS Bindings
Interesting - I ran some tests on both current WebKit and Firefox.
Firefox has a couple of interesting properties. For example this code:
Worker.prototype.foo = 3;
log(Worker.prototype.foo = + Worker.prototype.foo);
var worker = new Worker(foobar.js);
log(worker.foo = + worker.foo);
yields:
Worker.prototype.foo = 3
worker.foo = undefined
in Firefox, while in Safari it yields worker.foo = 3 as expected.
Along those same lines:
new Worker().__proto__ == Worker.prototype
yields true on Safari, but false on Firefox, which seems broken to me.
This is all within the same page (no frames). I've also verified that new
parent.window.Worker().__proto__ yields a different object than invoking new
window.Worker().__proto__ from the parent page context. So they don't seem
to be doing the right thing wrt prototype chains either.
As expected, WebKit is clearly broken with frames, as parent.window.Worker
does not even yield the same host object that invoking window.Worker
yields from the parent page context (not surprising, since we're looking at
lexicalGlobalObject() when we shouldn't be).
-atw
On Tue, Jul 7, 2009 at 5:33 PM, Drew Wilson atwil...@google.com wrote:
On Tue, Jul 7, 2009 at 5:25 PM, Adam Barth aba...@webkit.org wrote:
I'd have to look at the code a bit more to know whether this is
correct. Where does |globalObject| come from?
It comes from the JSDOMWindow object where that constructor is exposed.
Case in point:
#if ENABLE(CHANNEL_MESSAGING)
JSValue JSDOMWindow::messageChannel(ExecState* exec) const
{
return getDOMConstructorJSMessageChannelConstructor(exec, *this*);
}
#endif
So, when you first access someWindow.MessageChannel it should create a
JSMessageChannelConstructor whose prototype property is derived from
someWindow, then cache it in someWindow.
I'll run some tests as you suggest.
For an added bonus, you should test what happens if you transplant the
constructor from one window to another. The constructor should keep
its original prototype chain.
Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Inheritance in IDL files/JS bindings
BTW, I noticed that the CustomToJS IDL attribute in HTMLCollection.idl is not implemented - instead, there's just a big hard-coded list of classes in CodeGeneratorJS.pm::UsesManualToJSImplementation() that corresponds to that functionality. Any reason not to get rid of UsesManualToJSImplementation() in favor of an explicit CustomToJS attribute? I'm happy to put together a patach for this. -atw On Sat, Jul 4, 2009 at 3:02 PM, Maciej Stachowiak m...@apple.com wrote: On Jul 4, 2009, at 11:52 AM, Drew Wilson wrote: 1) I don't ever actually want a raw JSAbstractWorker to be created - is there a way to disable the toJS() generation? It looks like maybe CustomToJS might've let me do this, but it still defines toJS() in the AbstractWorker.h file. I'd rather have this generate a compile error than have incorrect behavior at runtime. I think the right way to handle this is to make a custom toJS function that does a runtime check of the actual type, and makes the right kind of wrapper object. That's because any time you deal with an AbstractWorker pointer, you want toJS on it to return the canonical wrapper of the right concrete class. The toJS function for Node is a fairly elaborate example of this. 2) What does GenerateNativeConverter do? I note that both Node and Element.idl define GenerateToJS, but none of their derived classes (HTMLElement.idl, HTMLOptionElement.idl) define GenerateToJS, which makes me think that just defining GenerateToJS on derived classes is not the correct fix. Correct - see above. toJS needs to do a dynamic check based on the runtime type, not a static check based on the declared type. We don't ever want to vend an Element wrapper for something that actually should be an HTMLDivElement, even if it got returned from a context that deals with generic elements. I don't know how useful the diff would be, but I uploaded one here - it's not ready for review yet as it has lots of odd debugging flotsam in it: https://bugs.webkit.org/attachment.cgi?id=32257action=review It sounds like you're on the right track to figuring this out. I believe writing a custom toJS for AbstractWorker which checks what kind of object it actually has will fix your problem. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Inheritance in IDL files/JS bindings
OK - I've uploaded a patch here if anyone has a chance to look at it - it's only about 11 changed lines, so it's pretty small. https://bugs.webkit.org/show_bug.cgi?id=27010 -atw On Mon, Jul 6, 2009 at 3:00 PM, Darin Adler da...@apple.com wrote: On Jul 6, 2009, at 2:52 PM, Drew Wilson wrote: BTW, I noticed that the CustomToJS IDL attribute in HTMLCollection.idl is not implemented - instead, there's just a big hard-coded list of classes in CodeGeneratorJS.pm::UsesManualToJSImplementation() that corresponds to that functionality. Any reason not to get rid of UsesManualToJSImplementation() in favor of an explicit CustomToJS attribute? I'm happy to put together a patch for this. No reason I can think of. That would be fine to do. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Inheritance in IDL files/JS bindings
Thanks for the insights.
I stepped through the worker constructor code. The problem was at the very
last line, where we create a JS wrapper object around the core
WebCore::Worker object:
return asObject(toJS(exec, worker.release()));
Before I changed Worker.idl to have Worker derive from the AbstractWorker
interface, the generator was creating a toJS() function in JSWorker. Once I
changed Worker to derive from AbstractWorker, the generator stopped putting
toJS() in JSWorker, so the code was falling through to call the base-class
code and returning an AbstractWorker object. I guess by default the
generator only creates toJS() functions for base classes?
In this case, adding GenerateToJS to Worker.idl fixed the problem by telling
the generator to create a toJS() function for JSWorker as well. Is that the
right fix?
I still have a couple of questions:
1) I don't ever actually want a raw JSAbstractWorker to be created - is
there a way to disable the toJS() generation? It looks like maybe CustomToJS
might've let me do this, but it still defines toJS() in the AbstractWorker.h
file. I'd rather have this generate a compile error than have incorrect
behavior at runtime.
2) What does GenerateNativeConverter do? I note that both Node and
Element.idl define GenerateToJS, but none of their derived classes
(HTMLElement.idl, HTMLOptionElement.idl) define GenerateToJS, which makes me
think that just defining GenerateToJS on derived classes is not the correct
fix.
I don't know how useful the diff would be, but I uploaded one here - it's
not ready for review yet as it has lots of odd debugging flotsam in it:
https://bugs.webkit.org/attachment.cgi?id=32257action=review
-atw
On Fri, Jul 3, 2009 at 3:23 PM, Sam Weinig sam.wei...@gmail.com wrote:
On Fri, Jul 3, 2009 at 2:42 PM, Drew Wilson atwil...@google.com wrote:
I'm working on refactoring some code out of WebCore::Worker into a common
base class to be shared between SharedWorker and Worker.
So I've defined a new AbstractWorker.idl and its associated JS bindings.
AbstractWorker is not intended to be instantiable, so I don't have a
constructor generated for it.
interface [CustomMarkFunction, Conditional=WORKERS] AbstractWorker {
...
}
GenerateConstructor is a slight misnomer unfortunately. Event
non-instatiatable interfaces should have one so that they can be exposed on
the global object for use with instanceof and accessing the prototype.
I then changed Worker.idl to make the Worker interface derive from the
base AbstractWorker interface, like so:
interface [CustomMarkFunction, Conditional=WORKERS] Worker :
AbstractWorker {
...
}
Everything compiles just fine, except that at runtime when I instantiate a
Worker object from Javascript, I seem to get an instance of AbstractWorker
instead, and referencing things that should be defined on the Worker
prototype (like Worker::postMessage) yields undefined. I thought at first
that perhaps I was doing something wrong with the prototype (setup in
JSWorkerConstructor.cpp) so I wrote some JS tests, which produced the
expected results:
log(Worker.toString()); = [object WorkerConstructor]
log(Worker.prototype.toString());= [object WorkerPrototype]
log(Worker.prototype.postMessage.toString()); = function
postMessage() { [native code] }
And yet when I actually instantiate a Worker object:
var worker = new Worker(resources/worker-common.js);
log (worker.toString());= [object *AbstractWorker*]
log (typeof worker.postMessage);= *undefined*
Is there anything special I need to do when implementing inheritance in
IDL files and JS bindings? I *think* I'm correctly following the example of
other places where we use inheritance (example HTMLElement - Element -
Node), although there are some options defined in the .idl file like
GenerateNativeConverter and GenerateToJS that might be relevant but
which I couldn't find any documentation for.
Anyhow, I'm digging into this further, but I figured people might be able
to shed some light on possible causes of this behavior.
It is hard to say without a full diff. Nothing you have described seems
too far off.
-Sam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Inheritance in IDL files/JS bindings
I'm working on refactoring some code out of WebCore::Worker into a common
base class to be shared between SharedWorker and Worker.
So I've defined a new AbstractWorker.idl and its associated JS bindings.
AbstractWorker is not intended to be instantiable, so I don't have a
constructor generated for it.
interface [CustomMarkFunction, Conditional=WORKERS] AbstractWorker {
...
}
I then changed Worker.idl to make the Worker interface derive from the base
AbstractWorker interface, like so:
interface [CustomMarkFunction, Conditional=WORKERS] Worker :
AbstractWorker {
...
}
Everything compiles just fine, except that at runtime when I instantiate a
Worker object from Javascript, I seem to get an instance of AbstractWorker
instead, and referencing things that should be defined on the Worker
prototype (like Worker::postMessage) yields undefined. I thought at first
that perhaps I was doing something wrong with the prototype (setup in
JSWorkerConstructor.cpp) so I wrote some JS tests, which produced the
expected results:
log(Worker.toString()); = [object WorkerConstructor]
log(Worker.prototype.toString());= [object WorkerPrototype]
log(Worker.prototype.postMessage.toString()); = function
postMessage() { [native code] }
And yet when I actually instantiate a Worker object:
var worker = new Worker(resources/worker-common.js);
log (worker.toString());= [object *AbstractWorker*]
log (typeof worker.postMessage);= *undefined*
Is there anything special I need to do when implementing inheritance in IDL
files and JS bindings? I *think* I'm correctly following the example of
other places where we use inheritance (example HTMLElement - Element -
Node), although there are some options defined in the .idl file like
GenerateNativeConverter and GenerateToJS that might be relevant but
which I couldn't find any documentation for.
Anyhow, I'm digging into this further, but I figured people might be able to
shed some light on possible causes of this behavior.
-atw
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Question about Constructors in WebKit JS Bindings
I had another question - I'm looking at JSWorkerConstructor code, but this
pattern exists elsewhere as well:
JSWorkerConstructor::JSWorkerConstructor(ExecState* exec)
:
DOMObject(JSWorkerConstructor::createStructure(exec-lexicalGlobalObject()-objectPrototype()))
{
putDirect(exec-propertyNames().prototype, JSWorkerPrototype::self(exec,
exec-lexicalGlobalObject()), None);
*putDirect(exec-propertyNames().length, jsNumber(exec, 1),
ReadOnly|DontDelete|DontEnum);*
}
What is the purpose of the second putDirect() call? I don't see this in
other constructors like JSXMLHttpRequestConstructor, but I do see it in
things like JSOptionConstructor and JSAudioConstructor.
At first I thought it was just some kind of copy/paste error, but now I'm
not so sure given how many files it's found in.
-atw
On Tue, Jun 23, 2009 at 5:14 PM, Adam Barth aba...@webkit.org wrote:
[+sam]
On Tue, Jun 23, 2009 at 5:11 PM, Drew Wilsonatwil...@google.com wrote:
On Tue, Jun 23, 2009 at 4:53 PM, Maciej Stachowiak m...@apple.com
wrote:
Also, there might be a subtle bug in the above code: what if
window.Worker
is first accessed from a different frame? Then the prototype of the
Worker
constructor itself will use the other frame's Object prototype as its
prototype. I'm not sure if that is right. I think maybe
JSWorkerConstructor
should be passed the global object from which it is retrieved as a
property,
instead of using the lexical global object.
Good catch. This bug seems to be in all our custom generated
constructors.
Yes. This has caused us headaches (e.g., security bugs) in the past.
Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] What is WebCore.order used for?
Thanks for the help, guys. I'll steer clear of the mysterious .order file and take a look at my build file additions instead. Cheers, -atw On Sun, Jun 28, 2009 at 4:14 PM, Maciej Stachowiak m...@apple.com wrote: On Jun 28, 2009, at 3:26 PM, Drew Wilson wrote: I'm adding the initial APIs for SharedWorkers, which require me to add a couple of .idl files, as well as implementations in WebCore/workers and JS bindings in bindings/js. I'm getting a bunch of weird link errors which I haven't figured out: __ZN7WebCore23JSSharedWorkerPrototype4selfEPN3JSC9ExecStateEPNS1_14JSGlobalObjectE, referenced from: __ZN7WebCore25JSSharedWorkerConstructorC1EPN3JSC9ExecStateEPNS_17JSDOMGlobalObjectE in JSSharedWorkerConstructor.o __ZN7WebCore25JSSharedWorkerConstructorC2EPN3JSC9ExecStateEPNS_17JSDOMGlobalObjectE in JSSharedWorkerConstructor.o I note that there are a number of Worker symbols in WebCore.order, and I'm wondering if I might need to add SharedWorker symbols in there as well - is there any documentation for what WebCore.order is used for, and when/how to update it? Others have explained that these errors are likely not from the .order file. I don't think they relate to exports either. Exports would only be relevant if an external module linking to WebCore was failing to resolve the symbol, or if the .exp file was cited as referencing a missing symbol. It seems like the cited symbol is simply missing at link time, either because a file is missing from the build or because the code generator failed to produce the required definition. Specifically, it's complaining that this function is missing: WebCore::JSSharedWorkerPrototype::self(JSC::ExecState*, JSC::JSGlobalObject*) And it's called from this function: WebCore::JSSharedWorkerConstructor::JSSharedWorkerConstructor(JSC::ExecState*, WebCore::JSDOMGlobalObject*) I found this out using c++filt. My guess is you may have forgotten to add the autogenerated bindings files to the build, so the handwritten parts of the bindings find the headers but can't resolve the symbols at link time. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Testing worker lifecycle
(resending to a wider audience - apologies to those of you who receive this twice) Hi all, The HTML5 worker spec has changed significantly from its earlier incarnations, in that it's no longer externally visible whether a given worker thread has shut down or not (there are no more close events surfaced on the Worker). This means that there's not currently a good way to write tests to verify that workers are actually shutting down when they are unreachable/idle. Do you guys have any ideas about how to address this? One idea I had would be to expose a WorkerController for layout tests, similar to GCController - the WorkerController could expose a numWorkers attribute which is incremented/decremented as worker threads startup/exit. I haven't started looking into how this would be done, but I figured I'd ask you guys if this was a good approach or if there's a cleaner way to test these cases. -atw ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Testing worker lifecycle
On Thu, Jun 25, 2009 at 2:33 PM, Maciej Stachowiak m...@apple.com wrote: On Jun 25, 2009, at 2:27 PM, Drew Wilson wrote: (resending to a wider audience - apologies to those of you who receive this twice) Hi all, The HTML5 worker spec has changed significantly from its earlier incarnations, in that it's no longer externally visible whether a given worker thread has shut down or not (there are no more close events surfaced on the Worker). What's the motivation for this particular change? Primarily to avoid requiring specific GC behavior in the HTML5 spec. If you expose when a worker has shut down, then for compatibility reasons you need to try to make all user agents behave identically wrt garbage collection and reachability, which puts an unnecessary burden on implementors. We've also removed things like MessagePort.active as well as throwing exceptions if you try to post a MessagePort that's been closed, for similar reasons. All of this is motivated by the fact that it's prohibitively difficult to determine cross-thread/cross-process reachability. This means that there's not currently a good way to write tests to verify that workers are actually shutting down when they are unreachable/idle. Do you guys have any ideas about how to address this? One obvious way would be to add a nonstandard equivalent to the close event (webkitClose). The downside is that this would be exposed to Web content. Exactly, which I'd like to avoid for the reasons mentioned above. One idea I had would be to expose a WorkerController for layout tests, similar to GCController - the WorkerController could expose a numWorkers attribute which is incremented/decremented as worker threads startup/exit. I haven't started looking into how this would be done, but I figured I'd ask you guys if this was a good approach or if there's a cleaner way to test these cases. That's also possible, the downside of this approach would be that the tests wouldn't work in a normal browser that doesn't have the special DumpRenderTree APIs. Indeed. That feels kind of lame, but the current alternative (no tests at all) seems bad too. - Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Question about Constructors in WebKit JS Bindings
On Tue, Jun 23, 2009 at 11:49 AM, Adam Barth aba...@webkit.org wrote: I am not even sure all of these should have the same behavior, however. For instance, as I read the Web Workers spec, the lexical global object may be correct thing to use for the Worker constructor. I looked at the spec briefly. What leads you to think that? It's probably a bug in the spec. Section 4.5 of the web workers spec reads: Given a script's global scope o when creating or obtaining a worker, the list of relevant Document objects to add depends on the type of o. If o is a WorkerGlobalScope object (i.e. if we are creating a nested worker), then the relevant Documents are the Documents that are in o's own list of the worker's Documents. Otherwise, o is a Window object, and the relevant Document is just the Document that is the active document of the Window object o. So it seems to imply that parent document for a worker is derived from the currently executing script's global scope. I'll ping IanH about this - it may not be what he intended. -atw ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Question about Constructors in WebKit JS Bindings
Following up after an IRC chat with Ian - for Workers it is his intention to always grab the context from the currently executing script, not from the window the constructor originated from. So for Workers, using the more succinct implementation is actually correct - in his words all Worker constructors are created equal. -atw On Tue, Jun 23, 2009 at 2:20 PM, Drew Wilson atwil...@google.com wrote: On Tue, Jun 23, 2009 at 11:49 AM, Adam Barth aba...@webkit.org wrote: I am not even sure all of these should have the same behavior, however. For instance, as I read the Web Workers spec, the lexical global object may be correct thing to use for the Worker constructor. I looked at the spec briefly. What leads you to think that? It's probably a bug in the spec. Section 4.5 of the web workers spec reads: Given a script's global scope o when creating or obtaining a worker, the list of relevant Document objects to add depends on the type of o. If o is a WorkerGlobalScope object (i.e. if we are creating a nested worker), then the relevant Documents are the Documents that are in o's own list of the worker's Documents. Otherwise, o is a Window object, and the relevant Document is just the Document that is the active document of the Window object o. So it seems to imply that parent document for a worker is derived from the currently executing script's global scope. I'll ping IanH about this - it may not be what he intended. -atw ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Question about Constructors in WebKit JS Bindings
Not sure. There's language in the WebIDL spec around prototype objects of interface objects, but I'm not sure how window.Worker.prototype is intended to relate to new Worker().prototype (if at all), based on my 10 minutes of scanning specs. -atw On Tue, Jun 23, 2009 at 3:26 PM, Adam Barth aba...@webkit.org wrote: 2009/6/23 Drew Wilson atwil...@google.com: On Tue, Jun 23, 2009 at 11:49 AM, Adam Barth aba...@webkit.org wrote: I am not even sure all of these should have the same behavior, however. For instance, as I read the Web Workers spec, the lexical global object may be correct thing to use for the Worker constructor. I looked at the spec briefly. What leads you to think that? It's probably a bug in the spec. Section 4.5 of the web workers spec reads: Given a script's global scope o when creating or obtaining a worker, the list of relevant Document objects to add depends on the type of o. If o is a WorkerGlobalScope object (i.e. if we are creating a nested worker), then the relevant Documents are the Documents that are in o's own list of the worker's Documents. Otherwise, o is a Window object, and the relevant Document is just the Document that is the active document of the Window object o. So it seems to imply that parent document for a worker is derived from the currently executing script's global scope. I'll ping IanH about this - it may not be what he intended. There's another question, which is where does the prototype chain of the JS object you get out of the worker constructor point? It might not have anything to do with this Document calculation. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Question about Constructors in WebKit JS Bindings
BTW, Adam - can you elaborate your specific concerns? On Tue, Jun 23, 2009 at 3:37 PM, Drew Wilson atwil...@google.com wrote: Not sure. There's language in the WebIDL spec around prototype objects of interface objects, but I'm not sure how window.Worker.prototype is intended to relate to new Worker().prototype (if at all), based on my 10 minutes of scanning specs. -atw On Tue, Jun 23, 2009 at 3:26 PM, Adam Barth aba...@webkit.org wrote: 2009/6/23 Drew Wilson atwil...@google.com: On Tue, Jun 23, 2009 at 11:49 AM, Adam Barth aba...@webkit.org wrote: I am not even sure all of these should have the same behavior, however. For instance, as I read the Web Workers spec, the lexical global object may be correct thing to use for the Worker constructor. I looked at the spec briefly. What leads you to think that? It's probably a bug in the spec. Section 4.5 of the web workers spec reads: Given a script's global scope o when creating or obtaining a worker, the list of relevant Document objects to add depends on the type of o. If o is a WorkerGlobalScope object (i.e. if we are creating a nested worker), then the relevant Documents are the Documents that are in o's own list of the worker's Documents. Otherwise, o is a Window object, and the relevant Document is just the Document that is the active document of the Window object o. So it seems to imply that parent document for a worker is derived from the currently executing script's global scope. I'll ping IanH about this - it may not be what he intended. There's another question, which is where does the prototype chain of the JS object you get out of the worker constructor point? It might not have anything to do with this Document calculation. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Question about Constructors in WebKit JS Bindings
On Tue, Jun 23, 2009 at 4:53 PM, Maciej Stachowiak m...@apple.com wrote: The code above means that Worker.prototype is set at the time the Worker constructor itself is created, which is good. In the line you bolded, a fresh prototype object is created, and under the covers it will get cached. However, it looks to me like the Worker wrapper will use the prototype from the Window where the reference is created, rather than the one that the Worker constructor came from. So everything I said may be wrong. Short version: this all needs tests. Agreed, tests would be good. BTW, I don't see where the code is using the prototype from the Window where the reference is created. I do see where the current ScriptExecutionContext is passed in to the Worker() constructor, but that's just the WebCore class and shouldn't affect the JSWorker prototype? Also, there might be a subtle bug in the above code: what if window.Worker is first accessed from a different frame? Then the prototype of the Worker constructor itself will use the other frame's Object prototype as its prototype. I'm not sure if that is right. I think maybe JSWorkerConstructor should be passed the global object from which it is retrieved as a property, instead of using the lexical global object. Good catch. This bug seems to be in all our custom generated constructors. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Fwd: Review queue needs love
I note that this bug fix: https://bugs.webkit.org/show_bug.cgi?id=23721 ...was not on the list below, and has been waiting for some reviewer love for a couple of weeks now. Is it falling through the cracks somehow? -atw On Fri, Jun 19, 2009 at 4:18 AM, Andrei Popescu andr...@google.com wrote: Hi, On Fri, Jun 19, 2009 at 3:03 AM, Eric Seidele...@webkit.org wrote: The other 24 remaining patches consist of 6 Gtk patches, 3 Chromium patches, and a bunch of huge new feature patches. No quite. The following two are rather small patches to common code (appcache and database): https://bugs.webkit.org/show_bug.cgi?id=22700 https://bugs.webkit.org/show_bug.cgi?id=25711 I think Alexey promised to look at them. Thanks, Andrei ___ 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] Fwd: Review queue needs love
I absolutely understand that there are ways to proactively find reviewers, and I'm *not* complaining about the time being taken (I understand the constraints that most of the webkit reviewers have been under the last few weeks with WWDC, etc). As you say, we can always ping people on IRC to find reviewers for bugfixes. I was more specifically wondering if there was something about this patch that made it not show up on the list Eric provided below. My concern is because the bugfix came from a google.com address, it might have been getting lumped in with the oh, must be Yet Another Chromium Patch so I won't worry about it list, which if true has troubling implications given that there are an increasing number of Googlers that are making contributions to WebKit that have nothing to do with Chromium. -atw On Fri, Jun 19, 2009 at 10:51 AM, David Levin le...@google.com wrote: Drew, if you go to http://nightly.webkit.org/start/, then click *Patches awaiting Review http://webkit.org/pending-review.* * That is the list folks work off of, but it doesn't hurt to figure out the appropriate person to review the patch (find out who has changed the file a lot) and ping them in irc to see if they can get to it. Dave * On Fri, Jun 19, 2009 at 10:21 AM, Drew Wilson atwil...@google.com wrote: I note that this bug fix: https://bugs.webkit.org/show_bug.cgi?id=23721 ...was not on the list below, and has been waiting for some reviewer love for a couple of weeks now. Is it falling through the cracks somehow? -atw On Fri, Jun 19, 2009 at 4:18 AM, Andrei Popescu andr...@google.comwrote: Hi, On Fri, Jun 19, 2009 at 3:03 AM, Eric Seidele...@webkit.org wrote: The other 24 remaining patches consist of 6 Gtk patches, 3 Chromium patches, and a bunch of huge new feature patches. No quite. The following two are rather small patches to common code (appcache and database): https://bugs.webkit.org/show_bug.cgi?id=22700 https://bugs.webkit.org/show_bug.cgi?id=25711 I think Alexey promised to look at them. Thanks, Andrei ___ 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] Fwd: Review queue needs love
Great, thanks for the responses, all - I feel much better knowing that we're one big WebKit family :) I agree that it's a good practice to tag platform-specific bugs, but I wasn't aware how to do this - I'll make sure I add the appropriate annotations on any future chrome-specific bugs I submit. Cheers, -atw On Fri, Jun 19, 2009 at 11:54 AM, Maciej Stachowiak m...@apple.com wrote: On Jun 19, 2009, at 11:46 AM, Maciej Stachowiak wrote: On Jun 19, 2009, at 11:05 AM, Drew Wilson wrote: I absolutely understand that there are ways to proactively find reviewers, and I'm *not* complaining about the time being taken (I understand the constraints that most of the webkit reviewers have been under the last few weeks with WWDC, etc). As you say, we can always ping people on IRC to find reviewers for bugfixes. I was more specifically wondering if there was something about this patch that made it not show up on the list Eric provided below. My concern is because the bugfix came from a google.com address, it might have been getting lumped in with the oh, must be Yet Another Chromium Patch so I won't worry about it list, which if true has troubling implications given that there are an increasing number of Googlers that are making contributions to WebKit that have nothing to do with Chromium. I try to tag Chromium-specific bugs with [Chromium] in the bug title when I go through the review queue, and I know others do as well, so from the fact that this bug is not so tagged you can assume we are aware it is a cross-platform fix. I should also note, in case this helps assuage your concerns, that many cross-platform patches submitted by Google contributors have been reviewed by non-Google reviewers, probably the majority of such patches. We definitely don't want every company to become an island of review, in fact I'd love it if more patches from Apple contributors were reviewed by non-Apple reviewers. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorkers alternate design
For SharedWorkers, the fallback is to select a document from the document set. It's slightly uglier, though, as I'd need to deal with the case where the user closes the document while we're trying to load via it. Having a dedicated shadow frame would be much simpler. -atw On Wed, Jun 17, 2009 at 7:03 PM, Dmitry Titov dim...@google.com wrote: 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. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorkers alternate design
Following up again on this - now that my cross-thread MessagePort patch is getting close to landing, I am moving forward on the SharedWorker design described earlier in this thread. I think there is still little clarity around the appcache behavior (dimich: are you bring over your shadow frame concept to webkit?). It doesn't seem like it should block the rest of SharedWorker development while we work out the details - I will not expose the appcache APIs for SharedWorkers until we have consensus about how they should work. Let me know if you have any concerns with my approach. I'll add an ENABLE_SHARED_WORKERS flag to control access to these APIs while development proceeds. -atw On Tue, Jun 2, 2009 at 11:43 AM, Michael Nordman micha...@google.comwrote: As for our implementation - I don't know how appcache is integrated with the loader code. We're still working out the details sans workers. But if it's a requirement to be able to a have an distinct appache host per shared worker, then so be it. If not, we either need to add this support, or delay exposing appcache APIs to SharedWorkers until we add the ability to load data from worker context without going through a document object (probably required for persistent workers). I'm for deferring appcache + worker integration until we have appcach - worker integration in place (including in place for chrome). Exposing the scriptable APIs to workers don't necessarily have to go in lock step with and appcache selection and resource loading on behalf of workers. There may be some overlap with work being done to support resource loading for dedicated workers in chrome. In chrome resource loads don't go thru the renderer process at all (so no Document/Frame instances). I think Dmitry was talking about introducing a FakeFrame (maybe not the best name) for this purpose. ___ 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()
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 atwil...@google.com 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
Re: [webkit-dev] SharedWorkers alternate design
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 page. The use case are workers that can be considered faceless applications. They are versioned independently of user interfaces that make use of them thru a stable message based API. Is it really possible for a SharedWorker to be versioned independently from UI? 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). So, its source always matches the UI version. Even if there is a newer version of appcache already loaded, the document's one will be used for loading subresources. I don't think that's the intent of the spec: If worker global scope is actually a SharedWorkerGlobalScope#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 of their entries, *not* excluding entries marked as foreign, then associate the worker global scope with themost appropriate application cache of those that match. I'm not at all certain what most appropriate application cache means, but I *think* it means most up-to-date cache, not cache associated with the constructing document. I think that's the point that this discussion hinges upon. Michael, do you know what that phrase means? I don't understand our AppCache implementation well enough to know how hard it will be to implement this behavior, given that we are proxying our loads to a parent document. -atw When a worker's script is referenced from several appcaches, this becomes somewhat trickier. As Andrew correctly mentioned, the version used will depend on which application was the first to construct the SharedWorker. But how is it a problem if we require SharedWorkers to implement a stable messaging API? Given that SharedWorkers are versioned together with UI, and that loading a new main resource in UI always invokes update process, I'm not sure if there are any use cases that require workers to call update() on their own. This is quite similar to how faceless helpers in large native application suites work - I don't think that they ever check for updates, it's only done at application startup. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorkers alternate design
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 appcache is integrated with the loader code. Can I proxy a load to a given document, but still specify which version of the app cache I want to use? If so, then we don't need to change the design. If not, we either need to add this support, or delay exposing appcache APIs to SharedWorkers until we add the ability to load data from worker context without going through a document object (probably required for persistent workers). -atw 2009/6/2 Alexey Proskuryakov a...@webkit.org 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. Andrew, do you agree that a different design is needed, or is this something we should push into the spec instead? - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorkers alternate design
We should probably discuss this point on the whatwg list, but I'll give you my understanding of why this is desirable: 1) Since SharedWorkers aren't explicitly tied to a specific Document, it doesn't make sense to have them possibly get loaded from an out-of-date version of the app cache. If you have two separate documents running from different caches, it's weird (and indeterminate) if the version of the cache used to load the SharedWorker script is dependent on which one happens to call new SharedWorker() first. 2) Since SharedWorkers may outlive a given document, it makes sense to allow them to manage their own appcache state, especially once we start supporting PersistentWorkers (which may run for days, weeks, or years). 3) SharedWorkers may have a different criteria determining when it wants to update its app cache. As for what happens to a SharedWorker whose cache was updated? My presumption is that all future resource loads would use that cache. At that point, the SharedWorker has a few different things it could do: - Reload all of its scripts again using importScripts(). This implies that its script loading is idempotent, but that's not too hard to do. - Send messages to all of its client documents letting it know that it is shutting down, then invoke close() to shut itself down. The client documents can re-create the SharedWorker the next time they want one. This is inherently race-y, though, since you can't easily coordinate the shutdown of the worker with instantiations of new ones. - Do nothing at all -atw 2009/6/1 Alexey Proskuryakov a...@webkit.org 22.05.2009, в 3:20, Drew Wilson написал(а): - SharedWorkers have explicit access to the ApplicationCache APIs, while dedicated Workers merely inherit the ApplicationCache from their parent window. 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. A tangentially related question: what will happen to a SharedWorker whose cache got updated? Will the repository use a new source for new instances, while the old ones will continue to run? Looks like there is a significant potential for mistakes here, as scripts won't normally expect several instances of the same SharedWorker to be active. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorkers alternate design
2009/6/1 Alexey Proskuryakov a...@webkit.org 01.06.2009, в 22:37, Drew Wilson написал(а): 1) Since SharedWorkers aren't explicitly tied to a specific Document, it doesn't make sense to have them possibly get loaded from an out-of-date version of the app cache. If you have two separate documents running from different caches, it's weird (and indeterminate) if the version of the cache used to load the SharedWorker script is dependent on which one happens to call new SharedWorker() first. I don't see how exposing DOMApplicationCache methods to workers can help this - a worker will only be able to call DOMApplicationCache.update() after it has started, which is too late. Not sure why that is too late? Can you clarify? Besides, won't the document using an old version of cache break if a newer SharedWorker is suddenly returned to it? The main idea of appcache is that all application resources are versioned, so if we see SharedWorkers as part of application, they should use the same cache version. And if they are independent entities with a stable API, using an out of date version for a while cannot hurt. Why would a document using an old version of cache break if a newer SharedWorker is returned? Why is that any more of a problem than a document using a new version of cache breaking if an older SharedWorker is returned, which is what would happen if SharedWorkers inherited appcache from the first document that instantiated them? It seems like there are several easy options available to apps: 1) Change the name of the shared worker if a non-backward-compatible change needs to be made to the worker script (so new documents don't share the same worker instance as old documents) 2) When updates are available, coordinate updates with all documents so everyone updates at once, possibly exiting the SharedWorker. As for what happens to a SharedWorker whose cache was updated? My presumption is that all future resource loads would use that cache. At that point, the SharedWorker has a few different things it could do: - Reload all of its scripts again using importScripts(). This implies that its script loading is idempotent, but that's not too hard to do. - Send messages to all of its client documents letting it know that it is shutting down, then invoke close() to shut itself down. The client documents can re-create the SharedWorker the next time they want one. This is inherently race-y, though, since you can't easily coordinate the shutdown of the worker with instantiations of new ones. - Do nothing at all All of these options seem quite dangerous - it may be difficult for JS authors to write applications that won't break at update time. It might be tricky, although any application that does dynamic JS loading has to deal with versioning issues already. This is not particularly different. A document can reload itself after updating, but SharedWorkers do not have a way to reload themselves. As you mentioned, they can reload imported scripts (but the main script will remain the same, which would be inconsistent). Why can't they reload the main script? Again, there's a need to be idempotent if you need to maintain some cached state, but it's not totally impossible. Or they can shut down and ask a document to re-create themselves - at which point, we can as well say that the document can update the cache. I'm not arguing against this, I just don't see how it works when you have multiple documents each of which are running from different versions of the app cache, where the shared worker itself is attached to some arbitrary instance. Interaction of SharedWorkers and appcache, explicit or not, sounds like a major issue to me. It can significantly affect the design (or even make SharedWorkers not worth being added, if no acceptable solution is found). 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 other stakeholders. I'd be happy to start that conversation on the whatwg list, but to be honest I don't think I'm quite understanding what your objections to the current spec are. Would you mind kicking off that discussion with whatwg, outlining your concerns? -atw ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorkers alternate design
One more thing I'd follow up with is if we were to have a SharedWorker just inherit an applicationcache from the first document that creates it, what happens after that document closes? How can the SharedWorker update its application cache if an update becomes available, since the only document associated with that cache is now closed? -atw 2009/6/1 Michael Nordman micha...@google.com How workers and appcaches interact has been discussed on the WHATWG list. Ian's Worker feedback message on 3/27/09 tried to tie things up for the time being. I think where he left things was a reasonable stepping stone, although the answers to the questions being asked here about updates were not entirely resolved. 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 considered faceless applications. They are versioned independently of user interfaces that make use of them thru a stable message based API. A tangentially related question: what will happen to a SharedWorker whose cache got updated? Will the repository use a new source for new instances, while the old ones will continue to run? I think the intent of the current spec is that a new instance would not be created provided there is an existing instance already running. How to reload an existing worker to utilize new resources in an updated cache was left as an exercise to the reader. At least that's my understanding of the current spec. 2009/6/1 Drew Wilson atwil...@google.com: 2009/6/1 Alexey Proskuryakov a...@webkit.org 01.06.2009, в 22:37, Drew Wilson написал(а): 1) Since SharedWorkers aren't explicitly tied to a specific Document, it doesn't make sense to have them possibly get loaded from an out-of-date version of the app cache. If you have two separate documents running from different caches, it's weird (and indeterminate) if the version of the cache used to load the SharedWorker script is dependent on which one happens to call new SharedWorker() first. I don't see how exposing DOMApplicationCache methods to workers can help this - a worker will only be able to call DOMApplicationCache.update() after it has started, which is too late. Not sure why that is too late? Can you clarify? Besides, won't the document using an old version of cache break if a newer SharedWorker is suddenly returned to it? The main idea of appcache is that all application resources are versioned, so if we see SharedWorkers as part of application, they should use the same cache version. And if they are independent entities with a stable API, using an out of date version for a while cannot hurt. Why would a document using an old version of cache break if a newer SharedWorker is returned? Why is that any more of a problem than a document using a new version of cache breaking if an older SharedWorker is returned, which is what would happen if SharedWorkers inherited appcache from the first document that instantiated them? It seems like there are several easy options available to apps: 1) Change the name of the shared worker if a non-backward-compatible change needs to be made to the worker script (so new documents don't share the same worker instance as old documents) 2) When updates are available, coordinate updates with all documents so everyone updates at once, possibly exiting the SharedWorker. As for what happens to a SharedWorker whose cache was updated? My presumption is that all future resource loads would use that cache. At that point, the SharedWorker has a few different things it could do: Reload all of its scripts again using importScripts(). This implies that its script loading is idempotent, but that's not too hard to do. Send messages to all of its client documents letting it know that it is shutting down, then invoke close() to shut itself down. The client documents can re-create the SharedWorker the next time they want one. This is inherently race-y, though, since you can't easily coordinate the shutdown of the worker with instantiations of new ones. Do nothing at all All of these options seem quite dangerous - it may be difficult for JS authors to write applications that won't break at update time. It might be tricky, although any application that does dynamic JS loading has to deal with versioning issues already. This is not particularly different. A document can reload itself after updating, but SharedWorkers do not have a way to reload themselves. As you mentioned, they can reload imported scripts (but the main script will remain the same, which would be inconsistent). Why can't they reload the main script? Again, there's a need to be idempotent if you need to maintain some cached state, but it's
Re: [webkit-dev] Notifications API
The problem I have with defining permissions on top of anything other than origin, is that every other aspect of HTML security seems to hang on the venerable same-origin policy. Allowing an application under foobar.com/trusted to have different permissions from an application under foobar.com/untrusted seems dangerous, given that pages under foobar.com/untrusted can: 1) Share storage, cookies, and workers with foobar.com/trusted 2) Load foobar.com/trusted in an iframe and call into its javascript, inject its own script, etc. I agree that it has implications for things like geocities where pages from different authors share the same domain, but that seems inherent to the general model of the web - you can't, in general, do anything interesting on the client if you don't trust all of the content served from your origin. -atw On Thu, May 28, 2009 at 12:03 PM, Michael Nordman micha...@google.comwrote: Its a comfortable notion that an origin == application, but the reality is that a single site can host multiple applications, and that an individual application can span multiple origins. We can probably do better than imposing the origin == application model on everybody. The only organizing principles we have for web permission granting are at the page level or at the origin level. Neither of these is particularly satisfying. I think end users would like to see things in terms of applications. The web provides no means of identifying which pages/origins should be considered part of an application. If there was a sense of application'ness, we could apply permissions to them... which is a desirable goal i think. So how to establish a sense of application'ness? html application = urlToAppIdentifyingFile If a page that doesn't identify itself start requesting permissions... fallback on the origin = application model. ___ 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] Notifications API
Sam, I think you are right here. I'm convinced that applications should be specific about what permissions they are asking for. I also believe that from a UX standpoint, we will probably want to provide the user with a single dialog that enumerates the permissions being granted, although a given user-agent may want to do this differently. We certainly want to enable both models. So I'd like to propose an API like the following (cribbed from the Android permissions manifest): int getTrusted(permissionName) - returns 0 if the application is blocked/unsupported (user said no or user-agent does not support it), 1 if it is untrusted (no permissions grant yet), 2 if it is trusted void requestTrust(permissionArray, callback) This provides a couple of important things: 1) granularity, so an application can specify exactly what permissions it wants 2) flexibility for the user agent - the application asks for a block of permissions at once (for example, a given feature like background notifications may require two permissions: persistent workers and notifications). The user agent has the flexibility to decide whether to display this as one dialog enumerating permissions, two separate dialogs, a dialog which allows the user to pick and choose which permissions it wants to grant, etc. What do you think? -atw On Tue, May 26, 2009 at 9:49 PM, Sam Weinig sam.wei...@gmail.com wrote: On Tue, May 26, 2009 at 9:18 PM, David Levin le...@chromium.org wrote: On Tue, May 26, 2009 at 8:57 PM, Sam Weinig sam.wei...@gmail.com wrote: On Tue, May 26, 2009 at 5:04 PM, Drew Wilson atwil...@google.comwrote: On Tue, May 26, 2009 at 4:43 PM, Sam Weinig sam.wei...@gmail.comwrote: On Tue, May 26, 2009 at 4:20 PM, Drew Wilson atwil...@google.comwrote: To give the list some insight into the discussions we've had with the Chrome UX folks: 1) We want to associate some set of enhanced permissions with a given origin (e.g. https://mail.yahoo.com), and we want the user to be presented with a single do you want to grant permissions to https://mail.yahoo.com; dialog, rather peppering the user with a bunch of individual permission dialogs for each feature (Yes, please allow mail.yahoo.com to use 100MB of local storage, Yes, allow mail.yahoo.com to display notifications, Yes, allow mail.yahoo.comto run in the background). It seems like a bad idea to give all or nothing trust, and not along the lines of how APIs have managed choices in the past (quotas are increased when the limit is hit). I am not even sure how a UA would present such a choice to a user in a meaningful manner. I think a workflow such as the one quoted above by Maciej is a good direction, that gives a user a better chance of understanding the choice they are making. I thought that maciej suggested the same thing we suggested - an explicit javascript API to request permissions. In our case, we want to ask for permissions in bulk up front, rather than peppering the user with permissions on an ad-hoc basis - in your example (prompting for more quota when the quota is hit) will break things like background sync in persistent workers, as the user may not be around when that background sync occurs. It is similar, but I am concerned with how to present a dialog to a user that states that by clicking grant they are completely trusting you. 2) We want the timing of the permission grant UI to be under application control (as part of some kind of application user flow). So just visiting mail.yahoo.com would not suddenly popup an unexpected dialog - instead the application would have some UI along the lines of Turn on desktop notifications which would drive some app-specific UI flow, a part of which would involve the permission grant. Can you please elaborate on this, perhaps with a concrete example. One example of a similar flow is Gmail Offline feature, where the user clicks on a Offline link, which drives the user through some app-controlled UI, culminating in a Gears permission-grant dialog. Here's another example: Remember The Milk rolls out a new feature: desktop reminder notifications. This is implemented by having a persistent worker which tracks changes on the server, determines when it's appropriate to display a reminder for a task, and displays a desktop notification. When a user logs into Remember The Milk, he sees a link: New feature: desktop reminders!. He clicks on this link, and is taken to an HTML page in Remember The Milk which describes what the feature is and asks the user if he wants to turn on these reminders. The application invokes getTrusted() to see if the domain is already trusted - if it isn't, then the UI may include some language to prepare the user for the upcoming permission grant dialog by telling him what to expect. When the user clicks yes, turn on this feature, the application calls requestTrust() - this brings up the UserAgent-specific permission
Re: [webkit-dev] SharedWorkers alternate design
OK, I've got two strong votes for the interface + static factory approach. Any objections from the rest of the WebKit team? If I don't hear any counter proposals, I'll do that. -atw On Mon, May 25, 2009 at 10:41 PM, John Abd-El-Malek j...@google.com wrote: On Fri, May 22, 2009 at 2:50 PM, Jeremy Orlow jor...@chromium.org wrote: On Fri, May 22, 2009 at 2:25 PM, Drew Wilson atwil...@google.com wrote: Following up on this, I had a question about the best way to enable the implementation of SharedWorkerRepository to vary for different platforms. I'd like to provide a default WebKit implementation, but on Chromium we'll want to provide an implementation that proxies shared worker operations to the browser process - it is unlikely that the two implementations will share very much (any?) code. The current design just defines SharedWorkerRepository as an interface, then has a platform-specific static factory which returns an instance of this class - the idea is that I'd provide a default WebKit implementation (called SharedWorkerProxyImpl.cpp?), then Chromium (or other platforms that want their own implementation) can provide their own factory method and implementation (for an example of this, see WorkerContextProxy::create() in WebCore/worker/WorkerMessagingProxy.cpp. Is this an acceptable approach? Other approaches I've seen either scatter ifdefs around in header files (see KURL.h for an example) which seems non-ideal for our case which won't have any shared code, or to have separate platform-specific subdirectories, but I'm not certain what the naming convention is for a directory that contains implementation for everything but chromium. I think the interface + static factory approach is the cleanest, This is the gist of what I'm planning for LocalStorage and I believe what Michael's planning for AppCache. At least in my case, I think I'll be able to share a substantial amount of code by running the backend of the code in the chromium browser process. I also agree this is the cleanest approach. Especially for these kind of objects (workers, storage) that aren't created or called that frequently, the memory and performance overhead is negligible. One other benefit is that it allows platforms to both define their own implementations and to use the default WebKit implementation. but I've gotten the impression that the use of virtual functions to vary implementations per-platform is frowned upon in WebKit. Any advice for me? -atw On Fri, May 22, 2009 at 1:20 PM, Kenneth Christiansen kenneth.christian...@openbossa.org wrote: I believe Qt uses instance() in this situation. Sadly we have not yet found a good verb for the common get or create idiom. Cheers. Kenneth ___ 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] SharedWorkers alternate design
Thanks for the explanation, Maciej. I actually looked at ResourceRequest prior to sending my mail, but I wasn't clear what makefile magic was being used to load the correct version of ResourceRequest.h for a given platform. For example, if I look at WebCore/WebCore.vcproj/WebCore.vcproj, I see only two references to ResourceRequest.h: platform/network/curl and platform/network/cf, but clearly we might want to use the chromium/ or win/ versions as well. Can someone give me a quick explanation of how the platform-specific version is selected at compile time? Do we have a naming convention for the default implementation? I'm expecting there to be two versions of SharedWorkerRepository - the chromium version, and the everything else version. -atw On Tue, May 26, 2009 at 10:36 AM, Maciej Stachowiak m...@apple.com wrote: On May 26, 2009, at 10:21 AM, Darin Adler wrote: On May 26, 2009, at 10:16 AM, Drew Wilson wrote: OK, I've got two strong votes for the interface + static factory approach. Any objections from the rest of the WebKit team? If I don't hear any counter proposals, I'll do that. I think it's unpleasant to pay run-time cost for a compile-time choice. Sure, sometimes the extra cost is no big deal, but sometimes it can be a big deal and I see no reason to choose idioms that use virtual functions if there are equally good or better ones that don't. Are there really no better techniques than abstract base classes and virtual functions for this sort of compile-time switch? How about the technique used for ResourceRequest and ResourceResponse? Maybe Darin Fisher can explain that one. I agree with Darin's comments here. We've tried hard to avoid using runtime polymorphism for compile-time choices. Here it's probably not performance-critical, but it can be avoided. The ResourceRequestBase / ResourceRequest model (due to Darin Fisher) seems pretty clean to me. I would like to see more of our classes with port-specific implementation details move to this style. I think it could work for SharedWorkerRepository. The basic idea is this. Let's say you have a class FooBar. - You define a FooBarBase class that has the cross-platform interface and data members. But not all the methods are actually implemented in the cross-platform code. All of its constructors are protected so the class cannot be instantiated directly. - Each port subclasses FooBarBase to define FooBar, adding constructors, platform-specific data members, and any needed platform-specific private helpers or type conversions. - Each port implements the methods of FooBarBase that are platform-specific, freely downcasting to FooBar when needed since we have guaranteed that every instance of FooBarBase is actually a FooBar. - Cross-platform code using the class just uses FooBar. The Base class is an implementation detail. (Darin F., please correct me if I have not done justice to this technique.) Note that this method has no runtime cost - there's no need to use virtual methods or other forms of runtime indirection. And there's no need to #ifdef any headers, everything is controlled purely by including the right platform specific FooBar.h so it can be handled by include paths. It's a little subtle at first but I think it results in nice, understandable code. I think we should document this technique as the preferred way to make classes with port-specific implementation details and convert more of WebCore/platform/ to this technique, as well as using it for new classes. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Notifications API
Has John sufficiently addressed people's concerns about this issue? Perhaps some of the people who previously expressed concerns in the bug could chime in here saying whether or not they are bought in now. We'd like to move forward on getting a reviewer on this change, but we're not certain what the next steps would be - we have a patch and we've done our best to address concerns about our proposal. John's patch itself doesn't provide any problematic behavior - it just enables individual user agents to provide notification behavior on top of WebKit should they so choose. So, what's the best way to move forward on this? -atw On Thu, May 21, 2009 at 11:17 PM, John Gregg john...@google.com wrote: I circulated a proposal several weeks ago which specified a notifications API for workers (desktop toasts), and the feedback was that (a) persistent workers are still far away, (b) is a notifications api necessary given it's basically a new window?, and (c) have we thought through the security issues? (https://bugs.webkit.org/show_bug.cgi?id=25463) I've tried to answer these questions but some points have remained sticky, so I'm reaching out again in search of consensus. As far as workers go, I've modified the proposal (and patch) to attach the notifications object to DOMWindow as well as WorkerContext, so that both regular pages can access it as well and this is not worker-specific. On the security question, a substantial amount of thought has gone into how to prevent unwanted popups (and in general how to control access to HTML5 application features). We think user opt-in on an origin-basis is the best policy and it's what we plan to do in Chromium; the WebKit interfaces are structured so that the policy is up to the user agent via a NotificationProvider interface. The API use case question seems to be the big one remaining open. On the use case front, there are several Google products interested in using it (Calendar reminders, Gmail alerts, etc.) We also see Mozilla Jetpack demoing an API very similar to the one I've proposed in their recent release. So I think there is plenty of reason to believe this feature would be used to greatly enhance applications. Last, if the feature is included should the interface be * window.notifications.create*() -- my proposal (also Jetpack's API) -- or * window.open*(style=notification), the alternate suggestion? Here are my thoughts supporting the former: - Notifications will evolve: the first generation is text+icon only, the second generation is small HTML bubbles, maybe something else later. While small HTML bubbles might align well with window.open, text+icon toasts don't. For some platforms we can get both, for some only the simple form. Logically what an app developer will do is check what notification options are available on the platform, then use the most full-featured option available. This check should be easy to do, and the result shouldn't send them to different existing APIs to find the closest match, if we can help it. I think providing a notifications object to encapsulate the feature makes more sense. - Opening a new window for an HTML notification is only one possible implementation. In the future (or now) a user agent may want to toast up the HTML block on the taskbar, or in a corner of an existing tab, or append it to a stream in a dedicated notification panel. Semantically the service provided to the app developer is alert the user using the HTML at this URL, and defining the interface to match gives us the most flexibility to implement in the future without being tied to a particular existing notion. Other thoughts? Thanks, -John ___ 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] Notifications API
To give the list some insight into the discussions we've had with the Chrome UX folks: 1) We want to associate some set of enhanced permissions with a given origin (e.g. https://mail.yahoo.com), and we want the user to be presented with a single do you want to grant permissions to https://mail.yahoo.com; dialog, rather peppering the user with a bunch of individual permission dialogs for each feature (Yes, please allow mail.yahoo.com to use 100MB of local storage, Yes, allow mail.yahoo.com to display notifications, Yes, allow mail.yahoo.com to run in the background). 2) We want the timing of the permission grant UI to be under application control (as part of some kind of application user flow). So just visiting mail.yahoo.com would not suddenly popup an unexpected dialog - instead the application would have some UI along the lines of Turn on desktop notifications which would drive some app-specific UI flow, a part of which would involve the permission grant. 3) To prevent applications from spamming the user with unwanted permission dialogs, the user agent could only display permission grants in response to user input (similar to how popup blocking works). The intent is to drive application authors to build UI flow around the permission grant, and to prevent things like third-party ad domains from doing drive-by permission grants. 4) Once the user has denied the permission grant, we would not display them again. The user agent can provide its own UI for managing domains with permission grants, similar to how some applications have a popup blocking whitelist/blacklist. 5) Long term, we probably want the application to specify what permissions it wants and display those permissions as part of the permissions grant. Some folks have even requested that users have the ability to pick-and-choose which permissions they want to grant, but it's not clear that this is feasible (giving an origin the ability to run in the background, but then not giving it the ability to store data locally may not make sense). We weren't positive what the correct way to specify the desired permissions would be - array of identifier strings? Javascript object/hash of configuration params? URL to some kind of application manifest? 6) From an application standpoint, they need the ability to test whether they have permission (granted, ungranted, blocked) and the ability to request permissions (throws an exception if the current permission state == blocked). This patch is already fairly large, which is why we were planning to drive the permissions API in a follow-on patch. Our current thinking was to have a simple API as John describes (getTrusted() and requestTrust()). Since there's not really any consensus around how to specify individual permissions, the API would not take any parameters so it would reflect a blanket elevated trust level for the application, with the intent of evolving this API based on feedback from whatwg and internal developers. -atw On Tue, May 26, 2009 at 2:32 PM, John Gregg john...@google.com wrote: On Tue, May 26, 2009 at 2:20 PM, Maciej Stachowiak m...@apple.com wrote: On May 22, 2009, at 10:19 AM, John Gregg wrote: Sure. We have the following plan for how to handle opt-in: - Use of the feature by script, if permission isn't granted to the origin, should throw an exception, not present permissions UI. So your insistent porn site would have no effect on the user. - A dialog box asking for permission should only appear in response to a user gesture like a click. So in the normal case, an application will present a user with a link New: Desktop Calendar Notifications available! Click here to setup. And that link will present a prompt from the user-agent Do you trust calendar.com? The site wants to display notifications on your desktop. [Yes/No] If the user says yes, script running under that origin will have permission to show desktop notifications. To expose this flow, wouldn't you need a method in the API exposed to JavaScript that requests permission for notifications, rather than actually posting a notification? I don't see such a method in the submitted patch. It would not make sense for a link labeled New: Desktop Calendar Notifications available! Click here to setup to actually display a notification itself, I wouldn't think. Having a JavaScript API to request permissions, along with plumbing through the WebKit layer to allow a WebKit embedder to suitably prompt the user, would address most of my concerns. Yes, this would be necessary. It's actually part of the spec API I originally proposed at http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-March/019113.html(readonly bool trusted attribute and void requestTrust() method), and I was planning to submit in a follow-up patch. But if you prefer it come in at the same time as the rest of the code, it can be done all at once. Do you have any particular proposal for how to accomplish the plumbing?
Re: [webkit-dev] SharedWorkers alternate design
Thanks - I hadn't realized that about WebKit style. I've updated the interfaces to use different verbs (like createWorkerProxy()) or omit the verb entirely where appropriate. -atw On Fri, May 22, 2009 at 12:30 PM, Darin Adler da...@apple.com wrote: No substantive comment, but a small style comment. On May 21, 2009, at 4:20 PM, Drew Wilson wrote: // Static factory method for getting the correct repository implementation for a given browser static public SharedWorkerRepository* getRepository(); Generally WebKit does not use the verb get to name functions that simply return something. Instead for those we simply use a noun. If there is some real action involved, then we would want to use a verb, but not get. For example, if the function always creates something we can use the word create. Sadly we have not yet found a good verb for the common get or create idiom. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorkers alternate design
Following up on this, I had a question about the best way to enable the implementation of SharedWorkerRepository to vary for different platforms. I'd like to provide a default WebKit implementation, but on Chromium we'll want to provide an implementation that proxies shared worker operations to the browser process - it is unlikely that the two implementations will share very much (any?) code. The current design just defines SharedWorkerRepository as an interface, then has a platform-specific static factory which returns an instance of this class - the idea is that I'd provide a default WebKit implementation (called SharedWorkerProxyImpl.cpp?), then Chromium (or other platforms that want their own implementation) can provide their own factory method and implementation (for an example of this, see WorkerContextProxy::create() in WebCore/worker/WorkerMessagingProxy.cpp. Is this an acceptable approach? Other approaches I've seen either scatter ifdefs around in header files (see KURL.h for an example) which seems non-ideal for our case which won't have any shared code, or to have separate platform-specific subdirectories, but I'm not certain what the naming convention is for a directory that contains implementation for everything but chromium. I think the interface + static factory approach is the cleanest, but I've gotten the impression that the use of virtual functions to vary implementations per-platform is frowned upon in WebKit. Any advice for me? -atw On Fri, May 22, 2009 at 1:20 PM, Kenneth Christiansen kenneth.christian...@openbossa.org wrote: I believe Qt uses instance() in this situation. Sadly we have not yet found a good verb for the common get or create idiom. Cheers. Kenneth ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] MessagePorts and garbage collection
BTW, it looks like the current Worker implementation doesn't notify the Worker object when timers/network activity are finished, so an unreferenced Worker thread won't be terminated in that case. When I get done with this design mess, I'll log a bug with some tests. -atw On Thu, May 7, 2009 at 11:54 AM, Alexey Proskuryakov a...@webkit.org wrote: on 07.05.2009 22:25, Maciej Stachowiak at m...@apple.com wrote: The best way I can think of to handle this is to have a special phase after normal marking where objects with an external/cross-thread reference get marked in a distinctive way. Then each MessagePort would know if it was marked solely due to its opposite endpoint being live. I don't recall if there is a way for an unreachable MessagePort to become reachable - I think yes, because the message event listener can stuff the MessagePort in a global variable. But I think an unerachable port can only become reachable by receiving a message. Thus, you need a core data structure for the MessageChannel which detects the case that there are no messages pending in either direct and both endpoints are alive only due to the other endpoint. Something like that. This is a very rough design sketch, Alexey can probably explain in more detail or I can study the code. This design with a separate stage between marking and sweeping is something that I started implementing, and had in ToT for a while last year. As I recall, the big problem with it is the need to detect when there are no messages pending in either direction, which is not possible without temporarily freezing the other thread/process AFAICT. That's something I'd like to avoid (yes, we do have a lock in MessageQueue, but it's not strictly necessary long-term, and there are already reports that it seriously affects performance). My impression is that Workers use a similar scheme with a special additional marking phase, or once did, but Alexey will recall better than I. You are probably thinking about my attempts to implement cross-thread MessagePort here. Worker GC makes use of the ActiveDOMObject concept - for as long as there is an unanswered message, or if it is known that the worker thread has timers (or network requests) running in it, the Worker object in main thread is deemed uncollectable. So, dedicated workers did not require any changes to JavaScriptCore GC behavior. - WBR, Alexey Proskuryakov. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] MessagePorts and garbage collection
Hi all,
I'm fixing some race conditions in the MessagePort code, and I want to make
sure I understand how garbage collection works for things like MessagePorts
that are access across multiple threads.
Some quick background: HTML5 MessagePorts are essentially two ends of a
message channel - messages posted to one MessagePort are raised as events on
the corresponding paired (entangled) MessagePort. They are used for
window-worker messaging, so each MessagePort may be run by a different
thread.
I'm simplifying the situation a bit, but in general as long as there is a
reference to one of the MessagePorts, both port objects should be treated as
reachable for the purposes of garbage collection. There is code in
bindings/js/JSMessagePortCustom.cpp to handle this, by invoking mark() on
the entangled port.
void JSMessagePort::mark()
{
DOMObject::mark();
...
if (MessagePortProxy* entangledPort = m_impl-entangledPort()) {
DOMObject* wrapper =
getCachedDOMObjectWrapper(*Heap::heap(this)-globalData(), entangledPort);
if (wrapper !wrapper-marked())
*wrapper-mark();*
}
...
}
There's one wrinkle, however - it's possible (via MessagePort::clone()) to
change the linkage between the two MessagePorts ; essentially one object is
swapped out for the other which requires updating the linkage on both ends.
If this were to happen in the middle of a GC operation, that would be bad.
It looks like the JSC collection code relies on JSLock to lock the heap -
I'm guessing that I'll need to explicitly grab the JSLock whenever I'm
manipulating the linkage between the two ports, is that correct? Or is there
a different/better way to handle situations like this?
-atw
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] MessagePorts and garbage collection
OK, that's good to know (it only supports document contexts) - clearly some work has been done to prepare for multi-thread usage (for example, the core data structure is a thread-safe MessageQueue). I'm quite happy to drive this design (in fact, I'm in the middle of this now) but I would like to make sure I understand in general what the correct approach is for managing GC-able objects that are accessed cross-thread - I haven't been able to find any documentation (outside of the code itself). Is the right approach to use JSLock when manipulating cross-thread linkage? I'll write up a quick document to describe the approach I'm taking, but I'd like to understand your concerns about deadlocks. So long as we have only a single shared per-channel mutex, and we never grab any other locks (like JSLock) after grabbing that mutex, we should be OK. Are there other locks that may be grabbed behind the scenes that I should be aware of? -atw 2009/5/6 Alexey Proskuryakov a...@webkit.org 06.05.2009, в 21:38, Drew Wilson написал(а): It looks like the JSC collection code relies on JSLock to lock the heap - I'm guessing that I'll need to explicitly grab the JSLock whenever I'm manipulating the linkage between the two ports, is that correct? Or is there a different/better way to handle situations like this? The JavaScriptCore implementation of MessagePorts only supports document contexts (i.e., it only works on main thread). As mentioned earlier, the first thing needed to implement MessagePorts in workers is a design of how they can be passed around without breaking GC. It is likely that taking a lock whenever atomicity is desired will cause deadlocks. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] MessagePorts and garbage collection
Thanks, this puts me on the right track. I've had a bunch of discussions with the Chrome folks on how we'd track MessagePort reachability in Chrome, but I'd hoped that the problem might be simpler in WebKit since we had direct access to the data structures cross-thread. The existence of separate GC heaps means it's not particularly simpler after all. -atw 2009/5/6 Maciej Stachowiak m...@apple.com On May 6, 2009, at 1:53 PM, Drew Wilson wrote: OK, that's good to know (it only supports document contexts) - clearly some work has been done to prepare for multi-thread usage (for example, the core data structure is a thread-safe MessageQueue). I'm quite happy to drive this design (in fact, I'm in the middle of this now) but I would like to make sure I understand in general what the correct approach is for managing GC-able objects that are accessed cross-thread - I haven't been able to find any documentation (outside of the code itself). Is the right approach to use JSLock when manipulating cross-thread linkage? I'll write up a quick document to describe the approach I'm taking, but I'd like to understand your concerns about deadlocks. So long as we have only a single shared per-channel mutex, and we never grab any other locks (like JSLock) after grabbing that mutex, we should be OK. Are there other locks that may be grabbed behind the scenes that I should be aware of? JSLock is not the right approach. Workers have their own completely separate GC heap. JSLock only locks the current context group's heap. It will not prevent collection in other heaps. I don't know exactly what the right approach is. Ultimately it's a distributed GC problem, both for our split-heap multithreading and for an approach that used processes for workers. And distributed GC is hard. However, Worker itself has a similar issue, since it can be kept alive either from the inside or the outside reference. You could look at how that problem was solved. - Maciej -atw 2009/5/6 Alexey Proskuryakov a...@webkit.org 06.05.2009, в 21:38, Drew Wilson написал(а): It looks like the JSC collection code relies on JSLock to lock the heap - I'm guessing that I'll need to explicitly grab the JSLock whenever I'm manipulating the linkage between the two ports, is that correct? Or is there a different/better way to handle situations like this? The JavaScriptCore implementation of MessagePorts only supports document contexts (i.e., it only works on main thread). As mentioned earlier, the first thing needed to implement MessagePorts in workers is a design of how they can be passed around without breaking GC. It is likely that taking a lock whenever atomicity is desired will cause deadlocks. - 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] MessagePorts and garbage collection
Following up. I think I have my head around how Worker GC is happening (I may start another thread about that, as it looks like there's some cases where the thread won't be shut down, but the general design is sound). MessagePort GC is a little trickier, because we need to detect when both sides have no external references, based on this part of the HTML5 spec: [...] a message port can be received, given an event listener, and then forgotten, and so long as that event listener could receive a message, the channel will be maintained. Of course, if this was to occur on both sides of the channel, then both ports would be garbage collected, since they would not be reachable from live code, despite having a strong reference to each other. From looking at the code in bindings/js, it looks like I've got two tools to manage object reachability: 1) I can tell when my object is reachable (during a GC) because mark() will be invoked on it. 2) I can force my object to stay active (as long as the owning context is active) by making it an ActiveDOMObject and returning true from hasPendingActivity() (which seems like it does nothing but invoke mark() on the object). So, #2 lets me keep an object alive, but to implement the spec, I need to be able to detect when my object has no more references, without actually having it get garbage collected. If I can do that, then I can build my own distributed state mechanism to allow me to determine when it's safe to GC the objects. I'm looking through the JSC::Collector code, and I didn't see anything that did exactly what I want, but there are probably some things that we could do with protect() to enable this. Has anyone else had to do anything like what I describe above? It's not exactly even a multi-thread issue, as it seems like this problem would occur even with just a single thread. -atw 2009/5/6 Drew Wilson atwil...@google.com Thanks, this puts me on the right track. I've had a bunch of discussions with the Chrome folks on how we'd track MessagePort reachability in Chrome, but I'd hoped that the problem might be simpler in WebKit since we had direct access to the data structures cross-thread. The existence of separate GC heaps means it's not particularly simpler after all. -atw 2009/5/6 Maciej Stachowiak m...@apple.com On May 6, 2009, at 1:53 PM, Drew Wilson wrote: OK, that's good to know (it only supports document contexts) - clearly some work has been done to prepare for multi-thread usage (for example, the core data structure is a thread-safe MessageQueue). I'm quite happy to drive this design (in fact, I'm in the middle of this now) but I would like to make sure I understand in general what the correct approach is for managing GC-able objects that are accessed cross-thread - I haven't been able to find any documentation (outside of the code itself). Is the right approach to use JSLock when manipulating cross-thread linkage? I'll write up a quick document to describe the approach I'm taking, but I'd like to understand your concerns about deadlocks. So long as we have only a single shared per-channel mutex, and we never grab any other locks (like JSLock) after grabbing that mutex, we should be OK. Are there other locks that may be grabbed behind the scenes that I should be aware of? JSLock is not the right approach. Workers have their own completely separate GC heap. JSLock only locks the current context group's heap. It will not prevent collection in other heaps. I don't know exactly what the right approach is. Ultimately it's a distributed GC problem, both for our split-heap multithreading and for an approach that used processes for workers. And distributed GC is hard. However, Worker itself has a similar issue, since it can be kept alive either from the inside or the outside reference. You could look at how that problem was solved. - Maciej -atw 2009/5/6 Alexey Proskuryakov a...@webkit.org 06.05.2009, в 21:38, Drew Wilson написал(а): It looks like the JSC collection code relies on JSLock to lock the heap - I'm guessing that I'll need to explicitly grab the JSLock whenever I'm manipulating the linkage between the two ports, is that correct? Or is there a different/better way to handle situations like this? The JavaScriptCore implementation of MessagePorts only supports document contexts (i.e., it only works on main thread). As mentioned earlier, the first thing needed to implement MessagePorts in workers is a design of how they can be passed around without breaking GC. It is likely that taking a lock whenever atomicity is desired will cause deadlocks. - 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
Re: [webkit-dev] Notifications API for workers
Thanks for the thoughtful response. We're also concerned about many of the same issues you've brought up below, and we've engaged in a number of discussions with the Chrome UX team and our internal Security folks to determine how we can best expose this functionality to the user and prevent misuse. The specification linked by the bug only describes the security/UX aspects at a high level - this is not because the issues aren't important, but rather because it's expected that different user agents may have varying policies/implementations so the specifics of a given implementation are outside the bounds of the spec. Our goal is to produce an implementation in Chrome which can be used to inform other user agent implementations (more on this below). More replies are inline below - John can provide more specifics, but I'll try to give you a general idea of how we're planning to protect this feature from misuse. We'd appreciate any feedback you have on our approach. On Sat, May 2, 2009 at 4:07 PM, Maciej Stachowiak m...@apple.com wrote: I'm pretty concerned about the security/spamming implications of notifications from Workers. A lot of thought has been put into how to make them a good feature for thoughtful, competent Web developers like those at Google. But it seems to me that not as much thought has been put into making the feature resistant to abuse. A few specific concerns: 1) Notifications may appear to the user to come from the Web page they are currently looking at, even if the Worker issuing them was created by a different originating page. Our intent is to make it clear from within the notification what the origin of the notification is (essentially, each notification has a mini address bar and can include similar cues to highlight verified sites). John, perhaps you can send out a screenshot of an example notification to give an idea of what we mean? One other idea we're considering is preventing keyboard input into these notifications to prevent phishing attempts. 2) In the case of a SharedWorker, there may not even be an originating page with which to assiciate the notification, and it may not be clear to the user how to make notifications stop. 3) It appears that Notifications can be used for unwelcome advertising spam, much as pop-up windows before the advent of browser pop-up blocking. We're hoping to address the popup spam issue through two methods: 1) User opt-in - users have to opt-in before a domain is allowed to use notifications. This prevents some random site or ad provider from suddenly throwing notifications up. This is similar to the Gears install flow, where a domain needs to get explicit user permission before it is allowed to access enhanced APIs. 2) User opt-out - users will have opt-out UI within the notification itself, allowing them to easily undo mistaken permission grants. On Apr 30, 2009, at 2:05 PM, John Gregg wrote: Hi WebKit, I'm working on a Notifications API for Web Workers, with the idea that a user agent could receive these from script and route them in a platform-appropriate user-configurable way (desktop HTML toasts, Growl calls, status bar on mobile browsers, etc.). Permission controls would be similar to popups. I don't see how that's possible. The default policy used by many WebKit clients (including Safari) is that popups are only allowed in response to explicit user actions, such as clicking a link. But no code running in a Worker is in response to a user action. In addition, as I understand it, the whole point of Notifications is that they are in response to background events, *not* in response to user actions. John can clarify what he meant to say here, but I believe he intended to convey that permission controls would be similar to the whitelists maintained by some popup blockers (e.g. Always allow popups from www.popupspam.com?). Agreed that we can't whitelist notifications based on user action, so it's not completely analogous to popups. I have a prototype working in Chromium but I need some advice as to how I might get the JS API checked in. I opened a bugzilla item here: https://bugs.webkit.org/show_bug.cgi?id=25463, which links to the design doc I'm using and has a rough draft of the patch I'm proposing. I got some feedback there already, so I thought I would reach out for more advice. Basically it amounts to adding to WorkerContext.idl an attribute WorkerContext.notifications, which notifications object contains methods like createNotification(URL or text+icon). Because of the proposed idea of dynamic routing, I'm inclined not to roll it in to window.open() until we get more experience building apps on it and decide that makes sense. Since this is experimental, it's already behind a compile time flag, but I would be happy to do more to make it further protected (like calling it WorkerContext.chromiumNotifications to indicate it's currently a Chromium experiment). Any other
Re: [webkit-dev] SharedWorker design doc
That's an excellent point about HTTP auth. I'm not sure that the let's just go find an open frame associated with this worker solution will work - the reason is that with the ability to create/pass around message ports, you can end up with the worker associated with a frame from a different domain (window A creates worker B, then passes worker B's MessagePort to window C which is running under a different domain - once window A closes, worker B can't load through window C because it's a different domain). Clearly being able to pass MessagePorts around is a bad idea :) -atw 2009/4/21 Alexey Proskuryakov a...@webkit.org 22.04.2009, в 2:31, Drew Wilson написал(а): David's take is that long term we'll need to change the loader code so it is not dependent on a specific frame - his upcoming refactoring may facilitate this, but there will still be a significant amount of work to achieve this in WebKit. Over the short term, he suggested that we might be able to suspend the parent frame, such that it still exists for the purposes of allowing associated workers to perform network loads, but it itself no longer has an open window and its active DOM objects are shutdown. When the last child worker exits, the parent frame can be completely discarded. A problem with this approach is communicating to the user - e.g. asking for HTTP authentication credentials. Without an open window, it won't be possible to display a sheet, and if we were to display a dialog window instead, the user wouldn't know which site needs the credentials. We do need to make loading work for frameless documents (e.g. to support XSLT document() function), but in other cases I'm aware of, we can rely on a parent window being visible. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorker design doc
Following up on this - is using a dialog for HTTP auth for worker requests really such a bad thing? What if we only do this as a fallback, in the case that the initiating window is closed? It seems more like a UX issue that the application itself could manage (if you want to use HTTP Auth from your workers, then be sure to force the auth to happen before your window closes). -atw 2009/4/22 Drew Wilson atwil...@google.com That's an excellent point about HTTP auth. I'm not sure that the let's just go find an open frame associated with this worker solution will work - the reason is that with the ability to create/pass around message ports, you can end up with the worker associated with a frame from a different domain (window A creates worker B, then passes worker B's MessagePort to window C which is running under a different domain - once window A closes, worker B can't load through window C because it's a different domain). Clearly being able to pass MessagePorts around is a bad idea :) -atw 2009/4/21 Alexey Proskuryakov a...@webkit.org 22.04.2009, в 2:31, Drew Wilson написал(а): David's take is that long term we'll need to change the loader code so it is not dependent on a specific frame - his upcoming refactoring may facilitate this, but there will still be a significant amount of work to achieve this in WebKit. Over the short term, he suggested that we might be able to suspend the parent frame, such that it still exists for the purposes of allowing associated workers to perform network loads, but it itself no longer has an open window and its active DOM objects are shutdown. When the last child worker exits, the parent frame can be completely discarded. A problem with this approach is communicating to the user - e.g. asking for HTTP authentication credentials. Without an open window, it won't be possible to display a sheet, and if we were to display a dialog window instead, the user wouldn't know which site needs the credentials. We do need to make loading work for frameless documents (e.g. to support XSLT document() function), but in other cases I'm aware of, we can rely on a parent window being visible. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorker design doc
That's also a reasonable option - so we'd just return a 401 error to the caller if the initiating window is unable to gather credentials. -atw 2009/4/22 Maciej Stachowiak m...@apple.com On Apr 22, 2009, at 11:54 AM, Drew Wilson wrote: Following up on this - is using a dialog for HTTP auth for worker requests really such a bad thing? What if we only do this as a fallback, in the case that the initiating window is closed? It seems more like a UX issue that the application itself could manage (if you want to use HTTP Auth from your workers, then be sure to force the auth to happen before your window closes). It's not only a problem for the Web application but also a problem for the browser: 1) We don't want the UI to be confusing even if a Web application is written without sufficient caution. 2) We don't want to create a phishing risk via SharedWorkers throwing up auth dialogs that appear to belong to another window. One possible solution is that if the frame that created the SharedWorker originally is now gone, then any network request that would lead to an authentication prompt or other kind of prompt fails. That allows the solution you propose for Web apps, but prevents confusion and abuse in the case of malicious or poorly written Web apps. Regards, Maciej -atw 2009/4/22 Drew Wilson atwil...@google.com That's an excellent point about HTTP auth. I'm not sure that the let's just go find an open frame associated with this worker solution will work - the reason is that with the ability to create/pass around message ports, you can end up with the worker associated with a frame from a different domain (window A creates worker B, then passes worker B's MessagePort to window C which is running under a different domain - once window A closes, worker B can't load through window C because it's a different domain). Clearly being able to pass MessagePorts around is a bad idea :) -atw 2009/4/21 Alexey Proskuryakov a...@webkit.org 22.04.2009, в 2:31, Drew Wilson написал(а): David's take is that long term we'll need to change the loader code so it is not dependent on a specific frame - his upcoming refactoring may facilitate this, but there will still be a significant amount of work to achieve this in WebKit. Over the short term, he suggested that we might be able to suspend the parent frame, such that it still exists for the purposes of allowing associated workers to perform network loads, but it itself no longer has an open window and its active DOM objects are shutdown. When the last child worker exits, the parent frame can be completely discarded. A problem with this approach is communicating to the user - e.g. asking for HTTP authentication credentials. Without an open window, it won't be possible to display a sheet, and if we were to display a dialog window instead, the user wouldn't know which site needs the credentials. We do need to make loading work for frameless documents (e.g. to support XSLT document() function), but in other cases I'm aware of, we can rely on a parent window being visible. - 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] SharedWorker design doc
I followed up with David Levin, who has been working on some chrome-internal refactoring of the loader code necessitated by the fact that workers in Chrome run in a different process from the loading frame. David's take is that long term we'll need to change the loader code so it is not dependent on a specific frame - his upcoming refactoring may facilitate this, but there will still be a significant amount of work to achieve this in WebKit. Over the short term, he suggested that we might be able to suspend the parent frame, such that it still exists for the purposes of allowing associated workers to perform network loads, but it itself no longer has an open window and its active DOM objects are shutdown. When the last child worker exits, the parent frame can be completely discarded. I'll need to dig further into this, but I wanted to see whether you thought this was a reasonable approach and what obstacles there might be to implementing this. -atw 2009/4/18 Alexey Proskuryakov a...@webkit.org Hi Drew, Thanks for the detailed proposal, it's great to have one. Prior to diving into threading details, I'd like to clarify a background assumption that doesn't seem to be mentioned in the proposal. How does a SharedWorker relate to the browsing context that created it? Specifically, we probably don't want a SharedWorker to be a top browsing context, because that would be an easy way to subvert same origin cookie policy. And since loading in WebCore can only happen when there is a Frame, what will happen to a SharedWorker whose original frame goes away? 18.04.2009, в 8:55, Drew Wilson написал(а): Any feedback would be appreciated, especially for some of the cross-threading and worker lifecycle issues. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorker design doc
Those are good questions - I've been primarily concentrating on the mechanisms around worker lifecycle management so I'm not entirely up to speed on the loadng mechanisms. The resource loading issues for dedicated Workers are the same as for SharedWorkers, since dedicated Workers can outlive their parent window closes once we support passing MessagePorts through Worker.postMessage(). I know that David Levin has been doing work on enabling loading within workers - I've CC'd him in hopes he might have some insights here. -atw 2009/4/18 Alexey Proskuryakov a...@webkit.org Hi Drew, Thanks for the detailed proposal, it's great to have one. Prior to diving into threading details, I'd like to clarify a background assumption that doesn't seem to be mentioned in the proposal. How does a SharedWorker relate to the browsing context that created it? Specifically, we probably don't want a SharedWorker to be a top browsing context, because that would be an easy way to subvert same origin cookie policy. And since loading in WebCore can only happen when there is a Frame, what will happen to a SharedWorker whose original frame goes away? 18.04.2009, в 8:55, Drew Wilson написал(а): Any feedback would be appreciated, especially for some of the cross-threading and worker lifecycle issues. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
