Re: [webkit-dev] SharedWorkers alternate design
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. 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] Security Origins
On Mon, Jun 1, 2009 at 8:29 PM, Jeremy Orlow jor...@chromium.org wrote: If this is the only issue, the parsing code could work around it. There are 3 parts to the identifier: the protocol (should never have a _ in it, right?), the domain, and the port (once again, should never have a _). It seems as though the parsing code should look for the first _, the last _, and then assume everything in the middle is the domain. I don't know of any reason why a scheme can't have a _... If you'd like to change the parsing code to understand domains with a _ this way, I think that would be an improvement. Doesn't seem like a top priority, but maybe it's worth filing a low priority bug for it anyway. Although they are 2 somewhat distinct use cases and I see the possibility for misuse and bad assumptions, I'm not terribly worried about it. I think HTML 5 has notions of origin and effective script origin (or some such) that separate these two concepts. It might be worth syncing up our internal names with the spec to make these concepts more accessible to future developers. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorkers alternate design
02.06.2009, в 0:19, Drew Wilson написал(а): My design doc just reflects the current spec - I don't really intend to be the defender of said spec. As I said previously, I think this is the wrong venue for us to describe issues with the spec - we should do it on the whatwg list to include other stakeholders. Did my response to Michael Nordman's message make the nature of objections more clear? 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? I think that there is value in discussing this among WebKit developers, as we can talk about how the design corresponds to low level implementation details. This is always important, but it would create a communication barrier on other venues. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Fwd: ［GTK］Scr oll deficiency
Hi Xiong, My platform is WebKiton gtk+directfb. I am noticing that the issue is still present in the current Webkit nightly R-44111 build. I saw your sugested patch : In function ChromeClient::scroll() // gdk_window_move_region(window, moveRegion, delta.width(), delta.height()); // gdk_region_offset(moveRegion, delta.width(), delta.height()); gdk_window_move_region(window, moveRegion, moveRect.width, moveRect.height); gdk_region_offset(moveRegion, moveRect.width, moveRect.height); After applying it, I am not finding the scroll deficiency issue. I wish to know if this fix is working, why is it not landed yet. What is the plan for this bug. What is the bug number for Gtk+Directfb platform. Thanks and regards, Srinivas Rao.M http://msrinirao.blogspot.com On Wed, Apr 22, 2009 at 8:04 AM, Xiong browse...@gmail.com wrote: -- Forwarded message -- From: Xiong browse...@gmail.com Date: Wed, Apr 22, 2009 at 9:42 AM Subject: Re: [webkit-dev] ［GTK］Scroll deficiency To: Frank Thomsen f...@trifork.com Cc: Brent Fulgham bfulg...@gmail.com Hi Frank I am working on gtk+directfb and Brent working on Window+cairo, and you ? As you see, Brent and i have two separate bugs, because the workarounds he described do not help me. For now, i have resolved the problem in my platform. The reason why the screen display confusion is that GDK do not refresh the overlapping region when scrolling. So, change the codes as following: In function ChromeClient::scroll() // gdk_window_move_region(window, moveRegion, delta.width(), delta.height()); // gdk_region_offset(moveRegion, delta.width(), delta.height()); gdk_window_move_region(window, moveRegion, moveRect.width, moveRect.height); gdk_region_offset(moveRegion, moveRect.width, moveRect.height); After do that, the problem was gone, at least in my platform(Gtk+directfb). Good luck. -xiong 2009/4/17 Frank Thomsen f...@trifork.com Hi guys Yesterday I wrote that I had solved the problem - at least on my machine. Well, I was wrong. Apparently the redraw-problem only exists in release-mode. Could you please tell me what you have done to circumvent this problem? You have talked about both commenting out code and doing something with the ... background..? Whatever it is I cannot find it in the mailing list, so I would really appreciate if you could enlighten me. And do you know if this has been reported as a bug? Can't seem to find that either... Thanks in advance! Frank -Original Message- From: webkit-dev-boun...@lists.webkit.org [mailto: webkit-dev-boun...@lists.webkit.org] On Behalf Of Brent Fulgham Sent: 31. marts 2009 01:04 To: xiong Cc: webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] ［GTK］Scroll deficiency Hi Xiong, Thanks for trying these suggestions. On Sun, Mar 29, 2009 at 8:24 PM, xiong browse...@gmail.com wrote: Brent, In my platform, all the hack as you metioned are valueless. Bad news to me. Now, i only have a clue on cario for the scroll problem. I think we may have two separate (but perhaps related) bugs, because the workarounds I described do not help your problem. Furthermore, the change you suggested (comment out the if (contentChanged) test in ChromeClient::repaint ()) does not resolve my problem, while it does fix yours. Thanks, -Brent ___ 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 -- Srinivas Rao M Hamse ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Security Origins
On Mon, Jun 1, 2009 at 11:30 PM, Adam Barth aba...@webkit.org wrote: On Mon, Jun 1, 2009 at 8:29 PM, Jeremy Orlow jor...@chromium.org wrote: If this is the only issue, the parsing code could work around it. There are 3 parts to the identifier: the protocol (should never have a _ in it, right?), the domain, and the port (once again, should never have a _). It seems as though the parsing code should look for the first _, the last _, and then assume everything in the middle is the domain. I don't know of any reason why a scheme can't have a _... If you'd like to change the parsing code to understand domains with a _ this way, I think that would be an improvement. Doesn't seem like a top priority, but maybe it's worth filing a low priority bug for it anyway. Although they are 2 somewhat distinct use cases and I see the possibility for misuse and bad assumptions, I'm not terribly worried about it. I think HTML 5 has notions of origin and effective script origin (or some such) that separate these two concepts. It might be worth syncing up our internal names with the spec to make these concepts more accessible to future developers. Agreed. Most of the new features use the simpler same origin policy which compares only the protocol, port, and domain. The effective script origin and the security around cookies are the more complex parts. I believe there's a fairly clean split between the two parts in the source code. I'll file a bug tomorrow regarding this opportunity for cleanup. J ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Fwd: ［GTK］Scroll deficiency
Hi, I am happy to hear that you solve the issue. I am also sorry to say i can not search the bug report, and never submit the patch with my sloth. -Xiong 2009/6/2 Srinivas Rao M Hamse msrini...@gmail.com Hi Xiong, My platform is WebKiton gtk+directfb. I am noticing that the issue is still present in the current Webkit nightly R-44111 build. I saw your sugested patch : In function ChromeClient::scroll() // gdk_window_move_region(window, moveRegion, delta.width(), delta.height()); // gdk_region_offset(moveRegion, delta.width(), delta.height()); gdk_window_move_region(window, moveRegion, moveRect.width, moveRect.height); gdk_region_offset(moveRegion, moveRect.width, moveRect.height); After applying it, I am not finding the scroll deficiency issue. I wish to know if this fix is working, why is it not landed yet. What is the plan for this bug. What is the bug number for Gtk+Directfb platform. Thanks and regards, Srinivas Rao.M http://msrinirao.blogspot.com On Wed, Apr 22, 2009 at 8:04 AM, Xiong browse...@gmail.com wrote: -- Forwarded message -- From: Xiong browse...@gmail.com Date: Wed, Apr 22, 2009 at 9:42 AM Subject: Re: [webkit-dev] ［GTK］Scroll deficiency To: Frank Thomsen f...@trifork.com Cc: Brent Fulgham bfulg...@gmail.com Hi Frank I am working on gtk+directfb and Brent working on Window+cairo, and you ? As you see, Brent and i have two separate bugs, because the workarounds he described do not help me. For now, i have resolved the problem in my platform. The reason why the screen display confusion is that GDK do not refresh the overlapping region when scrolling. So, change the codes as following: In function ChromeClient::scroll() // gdk_window_move_region(window, moveRegion, delta.width(), delta.height()); // gdk_region_offset(moveRegion, delta.width(), delta.height()); gdk_window_move_region(window, moveRegion, moveRect.width, moveRect.height); gdk_region_offset(moveRegion, moveRect.width, moveRect.height); After do that, the problem was gone, at least in my platform(Gtk+directfb). Good luck. -xiong 2009/4/17 Frank Thomsen f...@trifork.com Hi guys Yesterday I wrote that I had solved the problem - at least on my machine. Well, I was wrong. Apparently the redraw-problem only exists in release-mode. Could you please tell me what you have done to circumvent this problem? You have talked about both commenting out code and doing something with the ... background..? Whatever it is I cannot find it in the mailing list, so I would really appreciate if you could enlighten me. And do you know if this has been reported as a bug? Can't seem to find that either... Thanks in advance! Frank -Original Message- From: webkit-dev-boun...@lists.webkit.org [mailto: webkit-dev-boun...@lists.webkit.org] On Behalf Of Brent Fulgham Sent: 31. marts 2009 01:04 To: xiong Cc: webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] ［GTK］Scroll deficiency Hi Xiong, Thanks for trying these suggestions. On Sun, Mar 29, 2009 at 8:24 PM, xiong browse...@gmail.com wrote: Brent, In my platform, all the hack as you metioned are valueless. Bad news to me. Now, i only have a clue on cario for the scroll problem. I think we may have two separate (but perhaps related) bugs, because the workarounds I described do not help your problem. Furthermore, the change you suggested (comment out the if (contentChanged) test in ChromeClient::repaint ()) does not resolve my problem, while it does fix yours. Thanks, -Brent ___ 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 -- Srinivas Rao M Hamse ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Fwd: ［GTK］Scr oll deficiency
Hi Gustavo/Xiong, Is the patch discussed in this thread is acceptable for Gtk+Directfb platform ? Its very annoying that UI goes bad when we use scroll feature. Also is there a bug already logged on this issue, Can we log a fresh bug report if its not done ? regards, Srinivas Rao. M http://msrinirao.blogspot.com On Tue, Jun 2, 2009 at 2:27 PM, Xiong browse...@gmail.com wrote: Hi, I am happy to hear that you solve the issue. I am also sorry to say i can not search the bug report, and never submit the patch with my sloth. -Xiong 2009/6/2 Srinivas Rao M Hamse msrini...@gmail.com Hi Xiong, My platform is WebKiton gtk+directfb. I am noticing that the issue is still present in the current Webkit nightly R-44111 build. I saw your sugested patch : In function ChromeClient::scroll() // gdk_window_move_region(window, moveRegion, delta.width(), delta.height()); // gdk_region_offset(moveRegion, delta.width(), delta.height()); gdk_window_move_region(window, moveRegion, moveRect.width, moveRect.height); gdk_region_offset(moveRegion, moveRect.width, moveRect.height); After applying it, I am not finding the scroll deficiency issue. I wish to know if this fix is working, why is it not landed yet. What is the plan for this bug. What is the bug number for Gtk+Directfb platform. Thanks and regards, Srinivas Rao.M http://msrinirao.blogspot.com On Wed, Apr 22, 2009 at 8:04 AM, Xiong browse...@gmail.com wrote: -- Forwarded message -- From: Xiong browse...@gmail.com Date: Wed, Apr 22, 2009 at 9:42 AM Subject: Re: [webkit-dev] ［GTK］Scroll deficiency To: Frank Thomsen f...@trifork.com Cc: Brent Fulgham bfulg...@gmail.com Hi Frank I am working on gtk+directfb and Brent working on Window+cairo, and you ? As you see, Brent and i have two separate bugs, because the workarounds he described do not help me. For now, i have resolved the problem in my platform. The reason why the screen display confusion is that GDK do not refresh the overlapping region when scrolling. So, change the codes as following: In function ChromeClient::scroll() // gdk_window_move_region(window, moveRegion, delta.width(), delta.height()); // gdk_region_offset(moveRegion, delta.width(), delta.height()); gdk_window_move_region(window, moveRegion, moveRect.width, moveRect.height); gdk_region_offset(moveRegion, moveRect.width, moveRect.height); After do that, the problem was gone, at least in my platform(Gtk+directfb). Good luck. -xiong 2009/4/17 Frank Thomsen f...@trifork.com Hi guys Yesterday I wrote that I had solved the problem - at least on my machine. Well, I was wrong. Apparently the redraw-problem only exists in release-mode. Could you please tell me what you have done to circumvent this problem? You have talked about both commenting out code and doing something with the ... background..? Whatever it is I cannot find it in the mailing list, so I would really appreciate if you could enlighten me. And do you know if this has been reported as a bug? Can't seem to find that either... Thanks in advance! Frank -Original Message- From: webkit-dev-boun...@lists.webkit.org [mailto: webkit-dev-boun...@lists.webkit.org] On Behalf Of Brent Fulgham Sent: 31. marts 2009 01:04 To: xiong Cc: webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] ［GTK］Scroll deficiency Hi Xiong, Thanks for trying these suggestions. On Sun, Mar 29, 2009 at 8:24 PM, xiong browse...@gmail.com wrote: Brent, In my platform, all the hack as you metioned are valueless. Bad news to me. Now, i only have a clue on cario for the scroll problem. I think we may have two separate (but perhaps related) bugs, because the workarounds I described do not help your problem. Furthermore, the change you suggested (comment out the if (contentChanged) test in ChromeClient::repaint ()) does not resolve my problem, while it does fix yours. Thanks, -Brent ___ 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 -- Srinivas Rao M Hamse -- Srinivas Rao M Hamse ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Fwd: ［GTK］Scroll deficiency
On Tuesday 02 June 2009 09:41:38 Srinivas Rao M Hamse wrote: I wish to know if this fix is working, why is it not landed yet. What is the plan for this bug. What is the bug number for Gtk+Directfb platform. Please see http://webkit.org/coding/contributing.html and http://webkit.org/quality/reporting.html. From what I know no bug report has been filed, and no patch has been posted for review. If you experience an issue, please file a bug report, if you have a patch, please see the contributing guidelines and post a patch, I'm happy to review it then. z. ___ 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
When a document calls a SharedWorker constructor, the worker script is loaded from the document's appcache (because all subresource loading goes through appcache, of course). If I understand correctly, that is not what the spec currently says. Dedicated workers load as you describe, but not shared workers. The algorithm to determine what resource to load for a shared worker is the same as the algorithm used to determine what resource to load for a window.open(urlToPageWithoutAManifestAttributre) call. Personally, I think we should defer adding support for the appcache scriptable API to workers for the time being. But do support the resource loading / cache selection as currently specified. This would allow shared workers can be versioned independently (despite not having a good reload worker after an update story). These are shared workers. That implies a degree of separation from the pages that are sharing them. But how is it a problem if we require SharedWorkers to implement a stable messaging API? There are other interfaces to consider. The client-server messaging interface used by the worker to talk to the mother ship. And more significantly, the localstorage schema used by the worker. Consider a newer version of a shared worker alters a local database schema. If an older version of the worker is pinned in some other appcache, that schema change is likely incompatible with the that older worker. 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. 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
02.06.2009, в 21:10, Drew Wilson написал(а): If worker global scope is actually a SharedWorkerGlobalScope object (i.e. the worker is a shared worker), and there are any relevant application caches that are identified by a manifest URL with the same origin as url and that have url as one 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? There's a vague definition of most appropriate in the spec: Multiple application caches in different application cache groups can contain the same resource, e.g. if the manifests all reference that resource. If the user agent is to select an application cache from a list of relevant application caches that contain a resource, that the user agent must use the application cache that the user most likely wants to see the resource from, taking into account the following: • which application cache was most recently updated, • which application cache was being used to display the resource from which the user decided to look at the new resource, and • which application cache the user prefers. In current implementation, most appropriate is just random, but the second test is what I think applies to SharedWorkers most closely. - 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
From Andrew's design document, I don't see how my description was inaccurate: --- Currently, all worker XHR requests are proxied to the parent page and executed on the main thread. This approach currently works for dedicated workers because there is a 1:1 mapping between dedicated workers and active pages, and the worker is shutdown when the page closes. For SharedWorkers (and for dedicated workers once we introduce nested workers) this is no longer the case - the worker can outlive the parent page. To address this, we will use the DocumentSet for the worker. Worker XHR requests will still be proxied to the main thread. This task will request the DocumentSet from the repository, and select a document from that set to use to satisfy the request. If the DocumentSet is empty, then it means that the worker is shutting down, so the XHR should return a failure response. --- From my reading of this, it appears that shared workers will use FrameLoader of the opener page, or some other page in the DocumentSet, and won't get their own loaders (that would be a feature of persistent workers, which we aren't even discussing yet). This speaks specifically about XHR, but I assumed that the same holds true for other network requests. - WBR, Alexey Proskuryakov 02.06.2009, в 21:18, Michael Nordman написал(а): When a document calls a SharedWorker constructor, the worker script is loaded from the document's appcache (because all subresource loading goes through appcache, of course). If I understand correctly, that is not what the spec currently says. Dedicated workers load as you describe, but not shared workers. The algorithm to determine what resource to load for a shared worker is the same as the algorithm used to determine what resource to load for a window.open(urlToPageWithoutAManifestAttributre) call. Personally, I think we should defer adding support for the appcache scriptable API to workers for the time being. But do support the resource loading / cache selection as currently specified. This would allow shared workers can be versioned independently (despite not having a good reload worker after an update story). These are shared workers. That implies a degree of separation from the pages that are sharing them. ___ 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/2 Alexey Proskuryakov a...@webkit.org: From Andrew's design document, I don't see how my description was inaccurate: --- Currently, all worker XHR requests are proxied to the parent page and executed on the main thread. This approach currently works for dedicated workers because there is a 1:1 mapping between dedicated workers and active pages, and the worker is shutdown when the page closes. For SharedWorkers (and for dedicated workers once we introduce nested workers) this is no longer the case - the worker can outlive the parent page. To address this, we will use the DocumentSet for the worker. Worker XHR requests will still be proxied to the main thread. This task will request the DocumentSet from the repository, and select a document from that set to use to satisfy the request. If the DocumentSet is empty, then it means that the worker is shutting down, so the XHR should return a failure response. --- From my reading of this, it appears that shared workers will use FrameLoader of the opener page, or some other page in the DocumentSet, and won't get their own loaders (that would be a feature of persistent workers, which we aren't even discussing yet). This speaks specifically about XHR, but I assumed that the same holds true for other network requests. That would be a design flaw... not a feature. All of this stuff about the DocumentSet associated with a shared worker is a hack to work around the problem of how to load resource without a frame in webkit. 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. - WBR, Alexey Proskuryakov 02.06.2009, в 21:18, Michael Nordman написал(а): When a document calls a SharedWorker constructor, the worker script is loaded from the document's appcache (because all subresource loading goes through appcache, of course). If I understand correctly, that is not what the spec currently says. Dedicated workers load as you describe, but not shared workers. The algorithm to determine what resource to load for a shared worker is the same as the algorithm used to determine what resource to load for a window.open(urlToPageWithoutAManifestAttributre) call. Personally, I think we should defer adding support for the appcache scriptable API to workers for the time being. But do support the resource loading / cache selection as currently specified. This would allow shared workers can be versioned independently (despite not having a good reload worker after an update story). These are shared workers. That implies a degree of separation from the pages that are sharing them. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Security Origins
FYI: https://bugs.webkit.org/show_bug.cgi?id=26143 On Tue, Jun 2, 2009 at 12:45 AM, Jeremy Orlow jor...@chromium.org wrote: On Mon, Jun 1, 2009 at 11:30 PM, Adam Barth aba...@webkit.org wrote: On Mon, Jun 1, 2009 at 8:29 PM, Jeremy Orlow jor...@chromium.org wrote: If this is the only issue, the parsing code could work around it. There are 3 parts to the identifier: the protocol (should never have a _ in it, right?), the domain, and the port (once again, should never have a _). It seems as though the parsing code should look for the first _, the last _, and then assume everything in the middle is the domain. I don't know of any reason why a scheme can't have a _... If you'd like to change the parsing code to understand domains with a _ this way, I think that would be an improvement. Doesn't seem like a top priority, but maybe it's worth filing a low priority bug for it anyway. Although they are 2 somewhat distinct use cases and I see the possibility for misuse and bad assumptions, I'm not terribly worried about it. I think HTML 5 has notions of origin and effective script origin (or some such) that separate these two concepts. It might be worth syncing up our internal names with the spec to make these concepts more accessible to future developers. Agreed. Most of the new features use the simpler same origin policy which compares only the protocol, port, and domain. The effective script origin and the security around cookies are the more complex parts. I believe there's a fairly clean split between the two parts in the source code. I'll file a bug tomorrow regarding this opportunity for cleanup. J ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorkers alternate design
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
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
the most appropriate app cache should be used A little off topic... the spec says that in regard to appcache selection in general, its not specific to workers. That squishiness should probably be better defined at some point. 2009/6/2 Drew Wilson atwil...@google.com: Basically, the spec says 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] stack alignment bug
I don't know how to file bug so I posted here. In privateCompileCTIMachineTrampolines() there are multiple align() to align code on 16byte margin, yet, the stack can be put on 32bit margin that causes crush. Suppose original stack is aligned to 8/16bytes, the above function frequently pop/push regT3 that makes stack mis-aligned. Then int to double conversion uses stack that will fail. rgds joe ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Does anyone know why http/tests/appcache/fallback.html is failing?
Based on this: http://build.webkit.org/waterfall?last_time=1243932987 It looks like http://trac.webkit.org/changeset/44350 caused the test to fail. On Tue, Jun 2, 2009 at 10:39 PM, Darin Adler da...@apple.com wrote: This test is failing on all the Mac buildbots. --- layout-test-results/http/tests/appcache/fallback-expected.txt 2009-06-02 20:27:35.0 -0700 +++ layout-test-results/http/tests/appcache/fallback-actual.txt 2009-06-02 20:27:35.0 -0700 @@ -2,5 +2,6 @@ Should say SUCCESS: -SUCCESS +FAIL: Loading an URL from fallback namespace when network is disabled returned unexpected response +FAILURE Does anyone know why? Can we roll out the change that caused this to start failing? Or fix 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] How to compile testbindings under WebCore/bridge?
Anyone helps? Thanks! On Mon, Jun 1, 2009 at 3:09 PM, Harry Zhang zhangha...@gmail.com wrote: Hi all, i'm looking for the methods to bridge C object into JS runtime, then i found the test cases under WebCore/bridge which seems to be a good sample for me, because i found similar codes in Qt port, so i want to try out testbindings.cpp to see whether the C bridge works. However, i cannot use make_testbindings script to compile the source code, can anybody kindly show some tips to play with it? Many thanks in advance for the helps! (Btw, i'm using the latest r44282 source package, not the svn trunk.) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
