From karthick.j at gmail.com Sun Nov 1 16:23:45 2009 From: karthick.j at gmail.com (Karthick Jayaraman) Date: Sun, 1 Nov 2009 19:23:45 -0500 Subject: [webkit-dev] DOM building process Message-ID: <1dc0beae0911011623q838914dt6803afdcd2c6b73c@mail.gmail.com> Hello Everybody, Can someone explain to me the DOM building process with some pointers to the portions in the source code, please. I understand how the Tokenizer interacts with the Parser and creates HTML elements corresponding to tags. However, I am not able to pin down the portions in the source code that add attributes to the HTML element. I set breakpoint to the Element::setAttribute functions, but I dont see the parser calling it. I appreciate your help. -- Cheers!, Karthick Jayaraman You must do the things you think you cannot do. Eleanor Roosevelt http://web.syr.edu/~kjayaram From darin at apple.com Sun Nov 1 16:29:06 2009 From: darin at apple.com (Darin Adler) Date: Sun, 01 Nov 2009 16:29:06 -0800 Subject: [webkit-dev] DOM building process In-Reply-To: <1dc0beae0911011623q838914dt6803afdcd2c6b73c@mail.gmail.com> References: <1dc0beae0911011623q838914dt6803afdcd2c6b73c@mail.gmail.com> Message-ID: On Nov 1, 2009, at 4:23 PM, Karthick Jayaraman wrote: > I am not able to pin down the portions in the source code that add > attributes to the HTML element. I set breakpoint to the > Element::setAttribute functions, but I dont see the parser calling it. I?m not sure this query belongs in the webkit-dev list. I can?t tell if you are working on development of WebKit or not. The HTML parser uses the setAttributeMap function to set the attributes of an element. This is done in the parseToken function. -- Darin From braganzasam.roberts at gmail.com Mon Nov 2 05:05:54 2009 From: braganzasam.roberts at gmail.com (Braganza Roberts) Date: Mon, 2 Nov 2009 18:35:54 +0530 Subject: [webkit-dev] Query on RSS feeds Message-ID: <1312b8490911020505k3e7b72b5q8966b97b150e540a@mail.gmail.com> Hi, For Rss Feeds the default MimeType is application/rss+xml I have seen that certain websites misconfigure the MimeType and extensions for the RSS Feeds (say as XML) but still the IE/FireFox identifies it as RSS Feeds. Can someone help me where can i find this implementation in Webkit? Thanks & Regards, Sam. -------------- next part -------------- An HTML attachment was scrubbed... URL: From darin at apple.com Mon Nov 2 07:17:19 2009 From: darin at apple.com (Darin Adler) Date: Mon, 02 Nov 2009 07:17:19 -0800 Subject: [webkit-dev] Query on RSS feeds In-Reply-To: <1312b8490911020505k3e7b72b5q8966b97b150e540a@mail.gmail.com> References: <1312b8490911020505k3e7b72b5q8966b97b150e540a@mail.gmail.com> Message-ID: <76C03A9F-6F46-49AB-B346-B79C3FBC7AB4@apple.com> WebKit doesn?t have any code for this. RSS-feed-related features are part of individual WebKit-based browsers, not WebKit itself. -- Darin From yong.li.webkit at gmail.com Mon Nov 2 13:56:31 2009 From: yong.li.webkit at gmail.com (Yong Li) Date: Mon, 2 Nov 2009 16:56:31 -0500 Subject: [webkit-dev] MutationEvent Message-ID: <774ecda50911021356p6a55d1f2jfaea1d30457a3a23@mail.gmail.com> Hi, All, Why there are #if 0 here? First, I'm told "#if 0" is not webkit style. Second, the disabled code seems useful. void Element::dispatchAttrRemovalEvent(Attribute*) { ASSERT(!eventDispatchForbidden()); #if 0 if (!document()->hasListenerType(Document::DOMATTRMODIFIED_LISTENER)) return; ExceptionCode ec = 0; dispatchEvent(new MutationEvent(DOMAttrModifiedEvent, true, false, attr, attr->value(), attr->value(), document()->attrName(attr->id()), MutationEvent::REMOVAL), ec); #endif } void Element::dispatchAttrAdditionEvent(Attribute*) { ASSERT(!eventDispatchForbidden()); #if 0 if (!document()->hasListenerType(Document::DOMATTRMODIFIED_LISTENER)) return; ExceptionCode ec = 0; dispatchEvent(new MutationEvent(DOMAttrModifiedEvent, true, false, attr, attr->value(), attr->value(), document()->attrName(attr->id()), MutationEvent::ADDITION), ec); #endif } Best regards, -Yong -------------- next part -------------- An HTML attachment was scrubbed... URL: From jorlow at chromium.org Mon Nov 2 14:46:34 2009 From: jorlow at chromium.org (Jeremy Orlow) Date: Mon, 2 Nov 2009 15:46:34 -0700 Subject: [webkit-dev] MutationEvent In-Reply-To: <774ecda50911021356p6a55d1f2jfaea1d30457a3a23@mail.gmail.com> References: <774ecda50911021356p6a55d1f2jfaea1d30457a3a23@mail.gmail.com> Message-ID: <5dd9e5c50911021446y11416d69vb0ea1ade093af708@mail.gmail.com> Did try svn blaming it and looking at the corresponding changelog entry? On Mon, Nov 2, 2009 at 2:56 PM, Yong Li wrote: > Hi, All, > > Why there are #if 0 here? First, I'm told "#if 0" is not webkit style. > Second, the disabled code seems useful. > > void Element::dispatchAttrRemovalEvent(Attribute*) > { > ASSERT(!eventDispatchForbidden()); > #if 0 > if (!document()->hasListenerType(Document::DOMATTRMODIFIED_LISTENER)) > return; > ExceptionCode ec = 0; > dispatchEvent(new MutationEvent(DOMAttrModifiedEvent, true, false, > attr, attr->value(), > attr->value(), document()->attrName(attr->id()), > MutationEvent::REMOVAL), ec); > #endif > } > void Element::dispatchAttrAdditionEvent(Attribute*) > { > ASSERT(!eventDispatchForbidden()); > #if 0 > if (!document()->hasListenerType(Document::DOMATTRMODIFIED_LISTENER)) > return; > ExceptionCode ec = 0; > dispatchEvent(new MutationEvent(DOMAttrModifiedEvent, true, false, > attr, attr->value(), > attr->value(), document()->attrName(attr->id()), > MutationEvent::ADDITION), ec); > #endif > } > > Best regards, > -Yong > > _______________________________________________ > webkit-dev mailing list > webkit-dev at lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From darin at apple.com Mon Nov 2 16:04:16 2009 From: darin at apple.com (Darin Adler) Date: Mon, 02 Nov 2009 16:04:16 -0800 Subject: [webkit-dev] DOMAttrModified event In-Reply-To: <774ecda50911021356p6a55d1f2jfaea1d30457a3a23@mail.gmail.com> References: <774ecda50911021356p6a55d1f2jfaea1d30457a3a23@mail.gmail.com> Message-ID: <4A49061A-B72D-4D6E-A251-9C85F90D2615@apple.com> On Nov 2, 2009, at 1:56 PM, Yong Li wrote: > Why there are #if 0 here? First, I'm told "#if 0" is not webkit style. This code predates that rule. > Second, the disabled code seems useful. Someone who wants to get the DOMAttrModified event working in WebKit might start by enabling that code, but we would also need testing to make sure the code works properly in a way that matches other browsers and doesn?t create a dramatic slowdown for existing web pages. -- Darin From JasonR at bsquare.com Tue Nov 3 11:06:50 2009 From: JasonR at bsquare.com (Jason Rukman) Date: Tue, 3 Nov 2009 11:06:50 -0800 Subject: [webkit-dev] Frameloader parsing isn't cancelling for our port. Message-ID: As part of our port I'm occasionally hitting the following assert in FrameLoad::addData; but do not have a reproducible case yet. I think this is most likely happening for failures from the network stack occurring and then a new request being issued (I'm using ResourceHandleWin in our build). ??? ASSERT(m_frame->document()->parsing()); This is happening during cancel(ling) any pending loading phase during a new request.? Is there something that I need to add to the client to cancel any outstanding requests?? I'm just using the my own version of the winlauncher code to make the requests which doesn't have any logic for cancelling existing ones. The stack trace during this assert shows that it's from a check to stop loading previous requests and somehow I get into a state that the FrameLoader believes it is still parsing data and triggers the assert during the cancel operation. How does the FrameLoader parsing state normally reset? ---- stack trace --- WEBKIT!WebCore::FrameLoader::addData(const char * 0x00000000, int 0)? line 1439 + 72 bytes WEBKIT!WebFrameLoaderClient::receivedData(const char * 0x00000000, int 9082496, const WebCore::String & {...})? line 484 WEBKIT!WebFrameLoaderClient::committedLoad(WebCore::DocumentLoader * 0x008a6f20, const char * 0x00000000, int 0)? line 455 WEBKIT!WebFrameLoaderClient::finishedLoading(WebCore::DocumentLoader * 0x008a6f20)? line 493 WEBKIT!WebCore::FrameLoader::finishedLoadingDocument(WebCore::DocumentLoader * 0x0000ab5f)? line 2735 WEBKIT!WebCore::DocumentLoader::finishedLoading()? line 330 WEBKIT!WebCore::FrameLoader::finishedLoading()? line 2675 WEBKIT!WebCore::MainResourceLoader::didFinishLoading()? line 394 WEBKIT!WebCore::ResourceLoader::didFinishLoading(WebCore::ResourceHandle * 0x008ac460)? line 408 WEBKIT!WebCore::ResourceHandle::finish()? line 466 WEBKIT!WebCore::ResourceHandle::cancel(const WebCore::ResourceHandleClient * 0x00000000)? line 1063 WEBKIT!WebCore::ResourceLoader::didCancel(const WebCore::ResourceError & {...})? line 334 WEBKIT!WebCore::MainResourceLoader::didCancel(const WebCore::ResourceError & {...})? line 103 WEBKIT!WebCore::ResourceLoader::cancel(const WebCore::ResourceError & {...})? line 354 + 56 bytes WEBKIT!WebCore::ResourceLoader::cancel()? line 344 + 52 bytes WEBKIT!WebCore::DocumentLoader::stopLoading(WebCore::DatabasePolicy DatabasePolicyContinue)? line 294 + 24 bytes WEBKIT!WebCore::FrameLoader::stopAllLoaders(WebCore::DatabasePolicy DatabasePolicyStop)? line 2234 WEBKIT!WebCore::FrameLoader::continueLoadAfterNavigationPolicy(const WebCore::ResourceRequest & {...}, WTF::PassRefPtr * 0x43c0d244, bool true)? line 3428 WEBKIT!WebCore::FrameLoader::callContinueLoadAfterNavigationPolicy(void * 0x004b1a50, const WebCore::ResourceRequest & {...}, WTF::PassRefPtr * 0x0011e3a4, bool true)? line 3382 WEBKIT!WebCore::PolicyCallback::call(bool true)? line 102 WEBKIT!WebCore::PolicyChecker::continueAfterNavigationPolicy(WebCore::PolicyAction 9463168)? line 161 WEBKIT!WebFrame::receivedPolicyDecision(WebCore::PolicyAction PolicyUse)? line 1535 WEBKIT!WebFramePolicyListener::receivedPolicyDecision(WebCore::PolicyAction PolicyUse)? line 129 WEBKIT!WebFramePolicyListener::use()? line 100 WEBKIT!DefaultPolicyDelegate::decidePolicyForNavigationAction(IWebView * 0x00000005, IPropertyBag * 0x00900003, IWebURLRequest * 0x00908c20, IWebFrame * 0x00000005, IWebPolicyDecisionListener * 0x00000000)? line 120 + 28 bytes WEBKIT!WebFrame::dispatchDecidePolicyForNavigationAction(void (WebCore::PolicyAction)* 0x00908c20, const WebCore::NavigationAction & {...}, const WebCore::ResourceRequest & {...}, WTF::PassRefPtr * 0x0089c7a0)? line 1584 + 168 bytes WEBKIT!WebCore::PolicyChecker::checkNavigationPolicy(const WebCore::ResourceRequest & {...}, WebCore::DocumentLoader * 0x0011e7df, WTF::PassRefPtr * 0x00000004, void (void *, const WebCore::ResourceRequest &, WTF::PassRefPtr, bool)* 0x00000007, void * 0x00000007)? line 89 WEBKIT!WebCore::FrameLoader::loadWithDocumentLoader(WebCore::DocumentLoader * 0x004b1a50, WebCore::FrameLoadType 5128704, WTF::PassRefPtr * 0x009076a8)? line 2018 WEBKIT!WebCore::FrameLoader::load(WebCore::DocumentLoader * 0x00907460)? line 1971 WEBKIT!WebCore::FrameLoader::load(const WebCore::ResourceRequest & {...}, const WebCore::SubstituteData & {...}, bool true)? line 1912 WEBKIT!WebCore::FrameLoader::load(const WebCore::ResourceRequest & {...}, bool false)? line 1898 + 40 bytes WEBKIT!WebFrame::loadRequest(IWebURLRequest * 0x009062c0)? line 504 LAUNCHER!loadURL(wchar_t * 0x00906288)? line 491 + 32 bytes From erikkay at chromium.org Wed Nov 4 15:48:44 2009 From: erikkay at chromium.org (Erik Kay) Date: Wed, 4 Nov 2009 15:48:44 -0800 Subject: [webkit-dev] layout intrinsic height Message-ID: This is from (https://bugs.webkit.org/show_bug.cgi?id=31036). Sorry for duplicating here, but I was hoping to get some feedback. I'm happy to carry on the conversation in the bug. Also, in case it isn't clear in the bug, I'm happy to make the change myself if that makes sense. For Chrome's extension system, we let the extension create a popup widget using HTML. This popup widget's size is (mostly) unconstrained externally. The idea is to let the developer take advantage of some dynamic layout so that they don't have to worry as much about issues like system font sizes and localization. Obviously, the developer needs to put some constraints in (whitespace: nowrap,  , an explicit width or height on an element, etc.). I can get pretty close to my goal by using RenderBox::minPrefWidth() (on RenderView) and using contentHeight() for the height and resizing the RenderView to match. Unfortunately, with this technique, the height will never shrink. There doesn't seem to be a way to ask for the "intrinsic height" of the view at its current width. I'm assuming this must be known somewhere in order to calculate the overflow if any, but it looks like this value isn't saved or exposed. thanks, Erik From hyatt at apple.com Wed Nov 4 17:57:07 2009 From: hyatt at apple.com (David Hyatt) Date: Wed, 04 Nov 2009 19:57:07 -0600 Subject: [webkit-dev] layout intrinsic height In-Reply-To: References: Message-ID: <9200C51F-A93A-4EDF-BAC0-839605D3EC78@apple.com> I responded in the bug. Basically lowestPosition works, but it will always at a minimum return the viewport height. If you size the view to 0 first, you can get an accurate answer out of it. dave On Nov 4, 2009, at 5:48 PM, Erik Kay wrote: > This is from (https://bugs.webkit.org/show_bug.cgi?id=31036). Sorry > for duplicating here, but I was hoping to get some feedback. I'm > happy to carry on the conversation in the bug. Also, in case it isn't > clear in the bug, I'm happy to make the change myself if that makes > sense. > > For Chrome's extension system, we let the extension create a popup > widget using > HTML. This popup widget's size is (mostly) unconstrained > externally. The idea > is to let the developer take advantage of some dynamic layout so > that they > don't have to worry as much about issues like system font sizes and > localization. > Obviously, the developer needs to put some constraints in > (whitespace: nowrap, >  , an explicit width or height on an element, etc.). > > I can get pretty close to my goal by using RenderBox::minPrefWidth() > (on > RenderView) and using contentHeight() for the height and resizing the > RenderView to match. Unfortunately, with this technique, the height > will never > shrink. There doesn't seem to be a way to ask for the "intrinsic > height" of > the view at its current width. I'm assuming this must be known > somewhere in > order to calculate the overflow if any, but it looks like this value > isn't > saved or exposed. > > thanks, > Erik > _______________________________________________ > webkit-dev mailing list > webkit-dev at lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev From n179911 at gmail.com Wed Nov 4 21:57:51 2009 From: n179911 at gmail.com (n179911) Date: Wed, 4 Nov 2009 21:57:51 -0800 Subject: [webkit-dev] Need help in getting webkit code using git Message-ID: <3b9893450911042157j1150e1c6haee5386b2a309946@mail.gmail.com> I am trying to get Webkit source using git. But I get error saying "possible repository corruption on the remote side". Does anyone know how to fix this problem? I have tried using a newer version of git (1.6.5.4), but the error is the same. Thank you. ~/Webkit $ git clone git://git.webkit.org/WebKit.git . Initialized empty Git repository in /Users/samuel/Webkit/.git/ remote: error: failed to unpack compressed delta at offset 486539223 from ./objects/pack/pack-c7fcbbd90f8a0e469e7e218ffcef0bb43aa4114d.pack remote: error: failed to read object 23c5a57a8a0c94e1b895d432e8799dbf5533dc18 at offset 486539219 from ./objects/pack/pack-c7fcbbd90f8a0e469e7e218ffcef0bb43aa4114d.pack remote: fatal: object 23c5a57a8a0c94e1b895d432e8799dbf5533dc18 is corrupted remote: aborting due to possible repository corruption on the remote side. fatal: early EOF fatal: index-pack failed ~/Webkit $ git --version git version 1.6.3.3 From mrowe at apple.com Wed Nov 4 23:57:48 2009 From: mrowe at apple.com (Mark Rowe) Date: Wed, 04 Nov 2009 23:57:48 -0800 Subject: [webkit-dev] Need help in getting webkit code using git In-Reply-To: <3b9893450911042157j1150e1c6haee5386b2a309946@mail.gmail.com> References: <3b9893450911042157j1150e1c6haee5386b2a309946@mail.gmail.com> Message-ID: <2942F696-BAF8-481B-9BD8-6FFF8C4946FD@apple.com> On 2009-11-04, at 21:57, n179911 wrote: > I am trying to get Webkit source using git. But I get error saying "possible repository corruption on the remote side". Does anyone know how to fix this problem? This is a problem on the server side. I'm looking in to it. - Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3166 bytes Desc: not available URL: From darin at chromium.org Thu Nov 5 00:02:25 2009 From: darin at chromium.org (Darin Fisher) Date: Thu, 5 Nov 2009 00:02:25 -0800 Subject: [webkit-dev] The Chromium WebKit API Message-ID: *Please ignore this if you are not interested in the Chromium WebKit API...* I'm writing to announce that we have finished decoupling the Chromium WebKit API from the rest of the Chromium repository, and so we are now ready to move it to svn.webkit.org. The plan is for it to live under WebKit/WebKit/chromium/ . *Some background:* Chromium began life using WebCore directly. A layer (named webkit/glue) was added to the Chromium repository to help insulate most of the Chromium repository from the fast moving WebCore codebase. However, that layer grew to have many dependencies on lower layers in the Chromium repository (base, net, etc.), and it was also coded using Google C++ style. For much of the past year (since Feb!), we have been working furiously to eliminate those dependencies and convert to WebKit C++ style so that this glue layer could live in the WebKit repository and thereby provide a clean and stable API to WebCore for consumption by Chromium. The result is something we have been calling our WebKit API. Over the past year, we also upstreamed all of our modifications to WebCore. However, without the corresponding WebKit layer in plain sight, it is often hard to understand some of the PLATFORM(CHROMIUM) code that lives in WebCore. It is long overdue that we contribute our WebKit API layer into svn.webkit.org. *Next steps:* Within the coming days, we plan to commit the Chromium WebKit API into WebKit/WebKit/chromium, and then throw all the requisite switches in the Chromium repository to point the Chromium build at this code. Dimitri Glazkov and Eric Seidel are going to be driving this effort. Thanks guys!! *Future steps:* After the dust has settled with this move, we will still have some chores left to do. There remain a number of WebCore dependencies in the Chromium repository that we plan to eliminate. These will be eliminated by introducing additional interfaces in the Chromium WebKit API. (We did not want to delay the initial commit of the Chromium WebKit API waiting on these changes.) It will now be possible to port DumpRenderTree to the Chromium WebKit API, and this is a task we will undertake in the following months. It'll be great for the Chromium project to move to the same testing infrastructure for layout tests as the rest of the WebKit community! Regards, -Darin -------------- next part -------------- An HTML attachment was scrubbed... URL: From mjs at apple.com Thu Nov 5 00:41:30 2009 From: mjs at apple.com (Maciej Stachowiak) Date: Thu, 05 Nov 2009 00:41:30 -0800 Subject: [webkit-dev] The Chromium WebKit API In-Reply-To: References: Message-ID: <3DC5725C-A9B9-46B4-AB3B-39EA380910A0@apple.com> Sounds like a good move. Congratulations on getting to this point. - Maciej On Nov 5, 2009, at 12:02 AM, Darin Fisher wrote: > Please ignore this if you are not interested in the Chromium WebKit > API... > > > I'm writing to announce that we have finished decoupling the > Chromium WebKit API from the rest of the Chromium repository, and so > we are now ready to move it to svn.webkit.org. The plan is for it > to live under WebKit/WebKit/chromium/. > > > Some background: > > Chromium began life using WebCore directly. A layer (named webkit/ > glue) was added to the Chromium repository to help insulate most of > the Chromium repository from the fast moving WebCore codebase. > However, that layer grew to have many dependencies on lower layers > in the Chromium repository (base, net, etc.), and it was also coded > using Google C++ style. > > For much of the past year (since Feb!), we have been working > furiously to eliminate those dependencies and convert to WebKit C++ > style so that this glue layer could live in the WebKit repository > and thereby provide a clean and stable API to WebCore for > consumption by Chromium. The result is something we have been > calling our WebKit API. > > Over the past year, we also upstreamed all of our modifications to > WebCore. However, without the corresponding WebKit layer in plain > sight, it is often hard to understand some of the PLATFORM(CHROMIUM) > code that lives in WebCore. It is long overdue that we contribute > our WebKit API layer into svn.webkit.org. > > > Next steps: > > Within the coming days, we plan to commit the Chromium WebKit API > into WebKit/WebKit/chromium, and then throw all the requisite > switches in the Chromium repository to point the Chromium build at > this code. Dimitri Glazkov and Eric Seidel are going to be driving > this effort. Thanks guys!! > > > Future steps: > > After the dust has settled with this move, we will still have some > chores left to do. > > There remain a number of WebCore dependencies in the Chromium > repository that we plan to eliminate. These will be eliminated by > introducing additional interfaces in the Chromium WebKit API. (We > did not want to delay the initial commit of the Chromium WebKit API > waiting on these changes.) > > It will now be possible to port DumpRenderTree to the Chromium > WebKit API, and this is a task we will undertake in the following > months. It'll be great for the Chromium project to move to the same > testing infrastructure for layout tests as the rest of the WebKit > community! > > > Regards, > -Darin > _______________________________________________ > webkit-dev mailing list > webkit-dev at lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From mrowe at apple.com Thu Nov 5 03:06:49 2009 From: mrowe at apple.com (Mark Rowe) Date: Thu, 05 Nov 2009 03:06:49 -0800 Subject: [webkit-dev] Need help in getting webkit code using git In-Reply-To: <2942F696-BAF8-481B-9BD8-6FFF8C4946FD@apple.com> References: <3b9893450911042157j1150e1c6haee5386b2a309946@mail.gmail.com> <2942F696-BAF8-481B-9BD8-6FFF8C4946FD@apple.com> Message-ID: <183324D5-2E60-4A0A-8B50-F1FF6FC3DD23@apple.com> On 2009-11-04, at 23:57, Mark Rowe wrote: > > On 2009-11-04, at 21:57, n179911 wrote: > >> I am trying to get Webkit source using git. But I get error saying "possible repository corruption on the remote side". Does anyone know how to fix this problem? > > This is a problem on the server side. I'm looking in to it. Things should be working again now. Sorry for the inconvenience! - Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3166 bytes Desc: not available URL: From eric at webkit.org Thu Nov 5 11:30:04 2009 From: eric at webkit.org (Eric Seidel) Date: Thu, 5 Nov 2009 11:30:04 -0800 Subject: [webkit-dev] A new JS pretty-printer Message-ID: <1448d9f30911051130vaccd51crcf0f3630b87e69f7@mail.gmail.com> The Closure Compiler was just released by Google: http://googlecode.blogspot.com/2009/11/introducing-closure-tools.html Most exciting for WebKit is we have a new JS pretty-printer: http://closure-compiler.appspot.com/home Dump piles of awful JS in there, and click "whitespace only" and "pretty print" and voila! -eric From ukai at chromium.org Thu Nov 5 20:32:10 2009 From: ukai at chromium.org (=?UTF-8?B?RnVtaXRvc2hpIFVrYWkgKOm1nOmjvOaWh+aVjyk=?=) Date: Fri, 6 Nov 2009 13:32:10 +0900 Subject: [webkit-dev] git.webkit.org/WebKit.git out of sync from svn repository? Message-ID: I think svn has r50586 (accodring to trac.webkit.org), but git only pulls r50565now. Even I clone git repository from git://git.webkit.org/WebKit.git again, it only has r50565. Is it out of sync? % TZ=UTC date Fri Nov 6 04:29:15 UTC 2009 % git remote show origin * remote origin Fetch URL: git://git.webkit.org/WebKit.git Push URL: git://git.webkit.org/WebKit.git HEAD branch: master Remote branches: Safari-3-1-branch tracked Safari-3-2-branch tracked Safari-3-branch tracked master tracked safari-4-branch tracked Local branch configured for 'git pull': master merges with remote master Local ref configured for 'git push': master pushes to master (up to date) % git pull Already up-to-date. % git log -1 HEAD commit 968141f94cc10ea755eebcdf08882a4253a2cd2d Author: aroben at apple.com Date: Thu Nov 5 16:42:45 2009 +0000 Remove bogus else clause in bugzilla-tool Fixes REGRESSION (r47121): bugzilla-tool create-bug raises exception after entering bug description Reviewed by David Kilzer. * Scripts/bugzilla-tool: (CreateBug): else clauses are only hit if no exception is raised, so it makes no sense to try to re-raise the exception in an else clause. The exception will automatically be re-raised if it doesn't match any of the except clauses, so we don't have to do anything special here at all to get the desired behavior. git-svn-id: http://svn.webkit.org/repository/webkit/trunk at 50565268f45cc-cd0 9-0410-ab3c-d52691b4dbfc -------------- next part -------------- An HTML attachment was scrubbed... URL: From tonikitoo at gmail.com Fri Nov 6 10:49:53 2009 From: tonikitoo at gmail.com (tonikitoo (Antonio Gomes)) Date: Fri, 6 Nov 2009 14:49:53 -0400 Subject: [webkit-dev] Error handling support in DRT. Message-ID: <7eb9ad710911061049y42508555o151764d058a88da1@mail.gmail.com> Hi guys, I have a question about DRT and its current support to handling error pages. For a layout test I am working for a bug fix (see bug 30573), it would be great if the DumpRenderTree supports a way to handle "error pages". For example, in the end of the hypotactic test execution below (JS snippet), the error page html source would be dumped instead: (...) if (window.layoutTestController) { layoutTestController.dumpAsText(); layoutTestController.overridePreference("WebKitUsesPageCachePreferenceKey", 1); layoutTestController.setHandleErrorPage(); <--- this does not exist current. } function onPageLoad(evt) { layoutTestController.queueLoad("./non-existent.html"); } window.onload = onPageLoad; (...) In my case specifically, I'd like to have this kind of support in DRT, since I am testing BackForward list content/state after a couple of back's and forward's involving a non-successful load (qtwebkit does give support to handle error pages). Any plans to do so ? -- --Antonio Gomes From wsiegrist at apple.com Fri Nov 6 13:10:47 2009 From: wsiegrist at apple.com (William Siegrist) Date: Fri, 6 Nov 2009 13:10:47 -0800 Subject: [webkit-dev] git.webkit.org/WebKit.git out of sync from svn repository? In-Reply-To: References: Message-ID: On Nov 5, 2009, at 8:32 PM, Fumitoshi Ukai (????) wrote: > I think svn has r50586 (accodring to trac.webkit.org), but git only pulls r50565now. > Even I clone git repository from git://git.webkit.org/WebKit.git again, it only has r50565. > Is it out of sync? We had syncing issues yesterday, but they look fixed now. Can you retry? -Bill From mrowe at apple.com Fri Nov 6 13:18:30 2009 From: mrowe at apple.com (Mark Rowe) Date: Fri, 06 Nov 2009 13:18:30 -0800 Subject: [webkit-dev] git.webkit.org/WebKit.git out of sync from svn repository? In-Reply-To: References: Message-ID: <572FED7B-B315-4ACF-ABAC-C5142A63E994@apple.com> On 2009-11-05, at 20:32, Fumitoshi Ukai (????) wrote: > I think svn has r50586 (accodring to trac.webkit.org), but git only pulls r50565now. > Even I clone git repository from git://git.webkit.org/WebKit.git again, it only has r50565. > Is it out of sync? It seems fine to me. mrowe at angara:~$ git clone git://git.webkit.org/WebKit.git WebKit Initialized empty Git repository in /Volumes/Data/Users/mrowe/WebKit/.git/ remote: Counting objects: 593853, done. remote: Compressing objects: 100% (101931/101931), done. remote: Total 593853 (delta 468182), reused 593646 (delta 468045) Receiving objects: 100% (593853/593853), 655.06 MiB | 33.53 MiB/s, done. Resolving deltas: 100% (468182/468182), done. Checking out files: 100% (55327/55327), done. mrowe at angara:~$ cd WebKit/ mrowe at angara:~/WebKit$ git log -n1 master commit 588e7c8cc95b6f070fa6e0a860b86f783a0ecaef Author: eric at webkit.org Date: Fri Nov 6 20:01:14 2009 +0000 2009-11-06 Steve Block Reviewed by Eric Seidel. V8DOMWindowCustom.cpp is missing WEB_SOCKETS guard on include. https://bugs.webkit.org/show_bug.cgi?id=31209 Build fix only. No new tests possible. * bindings/v8/custom/V8DOMWindowCustom.cpp: Modified. Added WEB_SOCKETS guard on inclue of WebSockets.h. git-svn-id: http://svn.webkit.org/repository/webkit/trunk at 50603 268f45cc-cd09-0410-ab3c-d52691b4dbfc mrowe at angara:~/WebKit$ > % git pull > Already up-to-date. > % git log -1 HEAD > commit 968141f94cc10ea755eebcdf08882a4253a2cd2d > Author: aroben at apple.com > > Date: Thu Nov 5 16:42:45 2009 +0000 > > git-svn-id: http://svn.webkit.org/repository/webkit/trunk at 50565 268f45cc-cd0 > 9-0410-ab3c-d52691b4dbfc Your looking at the most recent revision on your current branch, but there's nothing in this output that shows what branch you currently have checked out. Does "git fetch origin && git log -n1 origin/master" display a different revision? - Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3166 bytes Desc: not available URL: From darin at apple.com Fri Nov 6 14:59:20 2009 From: darin at apple.com (Darin Adler) Date: Fri, 06 Nov 2009 14:59:20 -0800 Subject: [webkit-dev] Error handling support in DRT. In-Reply-To: <7eb9ad710911061049y42508555o151764d058a88da1@mail.gmail.com> References: <7eb9ad710911061049y42508555o151764d058a88da1@mail.gmail.com> Message-ID: On Nov 6, 2009, at 10:49 AM, tonikitoo (Antonio Gomes) wrote: > Hi guys, I have a question about DRT and its current support to handling error pages. > > For a layout test I am working for a bug fix (see bug 30573), it would be great if the DumpRenderTree supports a way to handle "error pages". > > For example, in the end of the hypotactic test execution below (JS snippet), the error page html source would be dumped instead: WebKit itself does not have error pages. This is a feature of specific browsers: Recent versions of Safari do this, although earlier versions used sheets and alerts instead. I think it?s reasonable to have a way in DumpRenderTree to indicate somehow in its output if a page load fails and what error code is involved. But I would not recommend using "error pages" as the way to do this. And we?d have to be careful to make this something easy to use cross-platform. Specific error codes are also likely to be platform-specific. There may be some way to accomplish this in some cases using "onerror" and frames. We?ve welcomed patches many times in the past that add things to DumpRenderTree that help us test previously untested aspects of the engine. -- Darin From ukai at chromium.org Sun Nov 8 17:11:51 2009 From: ukai at chromium.org (=?UTF-8?B?RnVtaXRvc2hpIFVrYWkgKOm1nOmjvOaWh+aVjyk=?=) Date: Mon, 9 Nov 2009 10:11:51 +0900 Subject: [webkit-dev] git.webkit.org/WebKit.git out of sync from svn repository? In-Reply-To: References: Message-ID: On Sat, Nov 7, 2009 at 6:10 AM, William Siegrist wrote: > On Nov 5, 2009, at 8:32 PM, Fumitoshi Ukai (????) wrote: > > > I think svn has r50586 (accodring to trac.webkit.org), but git only > pulls r50565now. > > Even I clone git repository from git://git.webkit.org/WebKit.git again, > it only has r50565. > > Is it out of sync? > > > We had syncing issues yesterday, but they look fixed now. Can you retry? > It seems working now. Thanks! ukai > > -Bill > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tonikitoo at gmail.com Mon Nov 9 18:35:16 2009 From: tonikitoo at gmail.com (tonikitoo (Antonio Gomes)) Date: Mon, 9 Nov 2009 22:35:16 -0400 Subject: [webkit-dev] Error handling support in DRT. In-Reply-To: References: <7eb9ad710911061049y42508555o151764d058a88da1@mail.gmail.com> Message-ID: <7eb9ad710911091835l12130624m76a7c813ef0c4ef6@mail.gmail.com> Thanks for replying, Darin. Comments below ... > WebKit itself does not have error pages. This is a feature of specific browsers: Recent versions of Safari do this, although earlier versions used sheets and alerts instead. I agree that supporting "error pages" is a browser-specific feature. The point is that WebCore::FrameLoader gives FrameLoaderClient the right hook to load error pages and even has special treatment for when it happens: If you look close at snippet FrameLoader code in http://pastebin.com/f176c3bf5, it is obvious that "m_delegateIsHandlingProvisionalLoadError" , for example, is preventing that method body to get executed if an "error page" is being handled: (...) > m_delegateIsHandlingProvisionalLoadError = true; > m_client->dispatchDidFailProvisionalLoad(error); > m_delegateIsHandlingProvisionalLoadError = false; (...) In the sequence: (...) // Finish resetting the load state, but only if another load hasn't // been started by the delegate callback. if (pdl == m_provisionalDocumentLoadeer) clearProvisionalLoad(); else if (m_provisionalDocumentLoader) { <---- THIS IS THE PROBLEM KURL unreachableURL = m_provisionalDocumentLoader->unreachableURL(); if (!unreachableURL.isEmpty() && unreachableURL == pdl->request().url()) shouldReset = false; } Just checking for "m_provisionalDocumentLoader" (the 'else' block) is not enough to ensure if a load error has been loaded or not. in my opnion, it should be "activeDocumentLoader()". As is, shouldReset keeps as "true" and back/forward status gets broken. I have patched it and even made a layout test and qt unittests [1], but w/o DRT to support error pages my test is invalid. [1] https://bug-30573-attachments.webkit.org/attachment.cgi?id=42829 > I think it?s reasonable to have a way in DumpRenderTree to indicate somehow in its output if a page load fails and what error code is involved. But I would not recommend using "error pages" as the way to do this. And we?d have to be careful to make this something easy to use cross-platform. Specific error codes are also likely to be platform-specific. The error page I made for QT is simple "data:html/test,", just in order to let something to get rendered. So I am not caring much about the type of error here for now ... > There may be some way to accomplish this in some cases using "onerror" and frames. As far as I could see "onError" are to catch runtime JS execution exception, which from the problem description above it can not be enough (?). -- --Antonio Gomes From oliver at apple.com Tue Nov 10 11:53:04 2009 From: oliver at apple.com (Oliver Hunt) Date: Tue, 10 Nov 2009 11:53:04 -0800 Subject: [webkit-dev] Layering weirdness in chrome tree Message-ID: <3A398CD2-D563-4457-8D01-21273B7169F0@apple.com> I just noticed that there are a bunch of WebCore platform implementations being landed in Chrome's WebKit API rather than in WebCore/platform. This seems incorrect to me as there is no other place where this sort of mis-layering occurred, the obvious files that stand out are: ApplicationCacheHost.cpp GraphicsContext3D.cpp MediaPlayerPrivateChromium.cpp PlatformMessagePortChannel.* ResoureHandle.cpp DOMUtilitiesPrivate.* I see no obvious reason for these being placed in WebKit -- as far as I can tell these represent a layering violation: it's not possible to build the WebCore directory into it's own library due to the hard dependency on the chrome webkit 'api'. --Oliver From abarth at webkit.org Tue Nov 10 12:02:49 2009 From: abarth at webkit.org (Adam Barth) Date: Tue, 10 Nov 2009 12:02:49 -0800 Subject: [webkit-dev] Layering weirdness in chrome tree In-Reply-To: <3A398CD2-D563-4457-8D01-21273B7169F0@apple.com> References: <3A398CD2-D563-4457-8D01-21273B7169F0@apple.com> Message-ID: <7789133a0911101202o7632f04bs2161c4e21432188f@mail.gmail.com> That sounds like a bug to me. Historically the chromium port hasn't had a strong distinction between WebKit and WebCore/platform, but I think it's a worthwhile distinction to make. Adam On Tue, Nov 10, 2009 at 11:53 AM, Oliver Hunt wrote: > I just noticed that there are a bunch of WebCore platform implementations > being landed in Chrome's WebKit API rather than in WebCore/platform. ?This > seems incorrect to me as there is no other place where this sort of > mis-layering occurred, the obvious files that stand out are: > > ApplicationCacheHost.cpp > GraphicsContext3D.cpp > MediaPlayerPrivateChromium.cpp > PlatformMessagePortChannel.* > ResoureHandle.cpp > DOMUtilitiesPrivate.* > > I see no obvious reason for these being placed in WebKit -- as far as I can > tell these represent a layering violation: it's not possible to build the > WebCore directory into it's own library due to the hard dependency on the > chrome webkit 'api'. > > --Oliver > > _______________________________________________ > webkit-dev mailing list > webkit-dev at lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > From yaar at chromium.org Tue Nov 10 13:58:15 2009 From: yaar at chromium.org (Yaar Schnitman) Date: Tue, 10 Nov 2009 13:58:15 -0800 Subject: [webkit-dev] git.webkit.org/WebKit.git out of sync from svn repository? In-Reply-To: References: Message-ID: Hi all, I think we have this problem again. Webkit svn is on r50761, but I can only git pull up to r50738. -Yaar On Sun, Nov 8, 2009 at 5:11 PM, Fumitoshi Ukai (????) wrote: > On Sat, Nov 7, 2009 at 6:10 AM, William Siegrist wrote: > >> On Nov 5, 2009, at 8:32 PM, Fumitoshi Ukai (????) wrote: >> >> > I think svn has r50586 (accodring to trac.webkit.org), but git only >> pulls r50565now. >> > Even I clone git repository from git://git.webkit.org/WebKit.git again, >> it only has r50565. >> > Is it out of sync? >> >> >> We had syncing issues yesterday, but they look fixed now. Can you retry? >> > > It seems working now. > Thanks! > ukai > > >> >> -Bill >> >> >> > > _______________________________________________ > webkit-dev mailing list > webkit-dev at lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mrowe at apple.com Tue Nov 10 14:09:58 2009 From: mrowe at apple.com (Mark Rowe) Date: Tue, 10 Nov 2009 14:09:58 -0800 Subject: [webkit-dev] git.webkit.org/WebKit.git out of sync from svn repository? In-Reply-To: References: Message-ID: On 2009-11-10, at 13:58, Yaar Schnitman wrote: > Hi all, > > I think we have this problem again. Webkit svn is on r50761, but I can only git pull up to r50738. This is fixed. - Mark > On Sun, Nov 8, 2009 at 5:11 PM, Fumitoshi Ukai (????) wrote: > On Sat, Nov 7, 2009 at 6:10 AM, William Siegrist wrote: > On Nov 5, 2009, at 8:32 PM, Fumitoshi Ukai (????) wrote: > > > I think svn has r50586 (accodring to trac.webkit.org), but git only pulls r50565now. > > Even I clone git repository from git://git.webkit.org/WebKit.git again, it only has r50565. > > Is it out of sync? > > > We had syncing issues yesterday, but they look fixed now. Can you retry? > > It seems working now. > Thanks! > ukai > > > -Bill > > > > > _______________________________________________ > webkit-dev mailing list > webkit-dev at lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > > _______________________________________________ > webkit-dev mailing list > webkit-dev at lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3166 bytes Desc: not available URL: From clifford.meece at me.com Mon Nov 2 09:30:25 2009 From: clifford.meece at me.com (Clifford Meece) Date: Mon, 02 Nov 2009 11:30:25 -0600 Subject: [webkit-dev] access webkit-fake-url data? Message-ID: <23F4FF73-3257-4B1B-A59A-9A9481A02DBC@me.com> When you paste image content into an editable content region, webkit produces URL's similar to the following: webkit-fake-url://DCAC99B9-BA40-4BA7-A419-9C60AAB081DA/image.png Is there anyway to access that data? In particular I'm trying to get at the data from a tinyMCE instance running in safari 4. My goal would be to programmatically scour the HTML input, look for the webkit- fake-url tags, access the original image, upload it to the destination blog, and then rewrite the image links. I realize that their may be significant sandbox rules preventing me from doing this, but it would be nice to know where the original data is stored and any ways to access it. Clifford Meece Professional IT Services T: (312) 607-5189 F: (773) 292-6372 E: clifford.meece at me.com http://cliffordmeece.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From cevans at chromium.org Mon Nov 2 23:19:46 2009 From: cevans at chromium.org (Chris Evans) Date: Mon, 2 Nov 2009 23:19:46 -0800 Subject: [webkit-dev] Question on standards mode vs. site compatibility Message-ID: Hi, Whilst mining a large list of URLs, I came across some sites that render incorrectly in WebKit but fine in IE. It turns out there exist some sites which declare themselves standards complaint in their HTML via their DTD. These sites then proceed to try and load CSS resources with the incorrect MIME type. This promptly fails due to standards mode. e.g. http://web.pcc.gov.tw/ uses application/x-pointplus http://www.emart.co.kr/index.jsp uses application/css http://www.fotocolombo.it/shop/index.php uses text-css (note the hyphen in place of a slash) application/octet stream also appears to be a favourite. I saw this code in HTMLLinkElement::setCSSStyleSheet // Check to see if we should enforce the MIME type of the CSS resource in strict mode. // Running in iWeb 2 is one example of where we don't want to - if (enforceMIMEType && document()->page() && !document()->page()->settings()->enforceCSSMIMETypeInStrictMode()) enforceMIMEType = false; What is "enforceCSSMIMETypeInStrictMode()"? Is it a global setting or is there some per-page metadata somewhere? We can relax the MIME type list we enforce for "strict mode" without breaking ACID3, although I'm not even sure that's desirable? Is it worth me worrying about this at all or is the correct solution that these sites are just broken and need to fix themselves at some stage? (Pragmatically, I worry that these sites will never fix themselves so users of WebKit-based browsers are SOL). Cheers Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr at google.com Tue Nov 3 12:35:01 2009 From: kbr at google.com (Kenneth Russell) Date: Tue, 3 Nov 2009 12:35:01 -0800 Subject: [webkit-dev] Running WebGL layout tests Message-ID: <921bb10911031235q224f17a3y2d8b81521f0546f6@mail.gmail.com> Hi, Trying to run the WebGL layout tests in LayoutTests/fast/canvas/webgl. Here's the command line I'm using: run-webkit-tests --debug LayoutTests/fast/canvas/webgl/[test name.html] (I built WebKit --debug.) All of the tests fail while attempting to fetch the 3D context. (TypeError: Result of expression 'context' [undefined] is not an object.) The same tests run fine when run under "run-safari --debug". Do I need to do some other "defaults write" or other setup to allow the layout test harness to run with WebGL enabled? Thanks, -Ken From ishanahuja at gmail.com Tue Nov 3 23:30:27 2009 From: ishanahuja at gmail.com (Ishan Ahuja) Date: Wed, 4 Nov 2009 02:30:27 -0500 Subject: [webkit-dev] InkML Message-ID: Hi, I was wondering if there are any plans of implementing InkML (http://www.w3.org/2002/mmi/ink ) rendering in webkit - or would you rather have it as a plug-in. Thanks, Ishan From clifford.meece at me.com Wed Nov 4 09:32:02 2009 From: clifford.meece at me.com (Clifford Meece) Date: Wed, 4 Nov 2009 09:32:02 -0800 (PST) Subject: [webkit-dev] access webkit-fake-url data Message-ID: <26200961.post@talk.nabble.com> When an image (for example) is pasted from the clipboard into a webkit editable content region, the source code looks like this: webkit-fake-url://DCAC99B9-BA40-4BA7-A419-9C60AAB081DA/image.png Where is the actual data stored in this instance? -- View this message in context: http://old.nabble.com/access-webkit-fake-url-data-tp26200961p26200961.html Sent from the Webkit mailing list archive at Nabble.com. From chris.jerdonek at gmail.com Sun Nov 8 00:21:47 2009 From: chris.jerdonek at gmail.com (Chris Jerdonek) Date: Sun, 8 Nov 2009 00:21:47 -0800 Subject: [webkit-dev] WTFNoncopyable namespace and ADL Message-ID: I have a question regarding JSC's WTFNoncopyable::Noncopyable class and argument-dependent lookup (ADL). It seems like an old decision may have been unintentionally undone in changeset 46933 (first attempted in 46877). The Noncopyable class (currently JavaScriptCore/wtf/Noncopyable.h) was originally added in Feb 2006 with the following comment: // We don't want argument-dependent lookup to pull in everything // from the KXMLCore [now WTF] namespace when you use Noncopyable, // so put it in its own namespace. namespace KXMLCoreNoncopyable { class Noncopyable { ( http://trac.webkit.org/changeset/12523/trunk/JavaScriptCore/kxmlcore/Noncopyable.h ) Then, in changeset 46933 (August 2009), the class declaration was changed to-- namespace WTFNoncopyable { - class Noncopyable { + class Noncopyable : public FastAllocBase { ( http://trac.webkit.org/changeset/46933/trunk/JavaScriptCore/wtf/Noncopyable.h ) But FastAllocBase is in the WTF namespace, defeating the aim of the commenter. It seems like either the WTFNoncopyable namespace should be changed to WTF and the comment removed, or else FastAllocBase should be put into its own namespace as well (or something equivalent). I'm not sure how important it is to preserve the original ADL behavior. --Chris From becsi.andras at stud.u-szeged.hu Mon Nov 9 04:19:18 2009 From: becsi.andras at stud.u-szeged.hu (Andras Becsi) Date: Mon, 09 Nov 2009 13:19:18 +0100 Subject: [webkit-dev] ruby annotation layout tests Message-ID: <4AF808C6.6050302@stud.u-szeged.hu> Hello, I have a question about the following HTML5 ruby annotation (http://www.w3.org/TR/ruby/) layout tests: fast/ruby/ruby-empty-rt.html fast/ruby/ruby-length.html fast/ruby/ruby-run-break.html fast/ruby/ruby-runs-spans.html fast/ruby/ruby-runs.html fast/ruby/ruby-simple-rp.html fast/ruby/ruby-simple.html fast/ruby/ruby-trailing.html fast/ruby/rubyDOM-insert-rt.html fast/ruby/rubyDOM-insert-text1.html fast/ruby/rubyDOM-insert-text2.html fast/ruby/rubyDOM-insert-text3.html fast/ruby/rubyDOM-remove-rt1.html fast/ruby/rubyDOM-remove-rt2.html fast/ruby/rubyDOM-remove-text1.html fast/ruby/rubyDOM-remove-text2.html Is there an explicit need that the texts in these tests need to be japanese? Could they be changed to have english texts in them and add some tests that test if japanese fonts are supported correctly? Thanks in advance! Andras (bbandix) From rick at alpinenetworking.com Tue Nov 10 14:29:16 2009 From: rick at alpinenetworking.com (Rick Gigger) Date: Tue, 10 Nov 2009 15:29:16 -0700 Subject: [webkit-dev] caching of static files Message-ID: Please let me know if this is not the right place to post this question. I am new to this list. I have noticed that Safari and Firefox seem to use different strategies for caching static files. It seems that when I have the expiration headers set properly that Firefox does not request them at all until they are expired but Safari requests them gut gets back 304 "not modified" responses. Is on of those right or wrong? Does the http spec allow for either behavior? Thanks, Rick From chris.jerdonek at gmail.com Tue Nov 10 19:41:45 2009 From: chris.jerdonek at gmail.com (Chris Jerdonek) Date: Tue, 10 Nov 2009 19:41:45 -0800 Subject: [webkit-dev] "using namespace" style guideline Message-ID: Hi, I have a question about the last of the WebKit Coding Style Guidelines: http://webkit.org/coding/coding-style.html It's the second of these two: 1. Any "using namespace" statements for a nested namespace whose parent namespace is also defined in a file must be declared within that namespace definition. 2. Any other "using namespace" statements must be declared before the first namespace definition in the file. Unlike most or all of the other rules, this one can affect compilation. So I was wondering what the rule is for. For example, say I want to write the following in an existing header file to avoid having to fully qualify several identifiers in the WTF namespace: namespace MyNewNameSpace { using namespace WTF; // code } Following rule 2 and putting the using statement outside the namespace can cause compilation errors elsewhere in the project (due to ambiguous overloads for bringing the WTF namespace into files already including the above). This actually happened to me while doing some minor refactoring. If I want to keep the "using namespace" statement, it seems like the style guideline would require me to do an unknown amount of refactoring outside the file. Let me know your thoughts. Thanks, --Chris From darin at apple.com Tue Nov 10 20:30:14 2009 From: darin at apple.com (Darin Adler) Date: Tue, 10 Nov 2009 20:30:14 -0800 Subject: [webkit-dev] "using namespace" style guideline In-Reply-To: References: Message-ID: On Nov 10, 2009, at 7:41 PM, Chris Jerdonek wrote: > Hi, I have a question about the last of the WebKit Coding Style Guidelines: > > http://webkit.org/coding/coding-style.html > > It's the second of these two: > > 1. Any "using namespace" statements for a nested namespace whose parent namespace is also defined in a file must be declared within that namespace definition. > > 2. Any other "using namespace" statements must be declared before the first namespace definition in the file. No "using namespace" statements are permitted in header files. The guidelines are talking about non-header files. We should clarify that. -- Darin From darin at apple.com Tue Nov 10 20:32:54 2009 From: darin at apple.com (Darin Adler) Date: Tue, 10 Nov 2009 20:32:54 -0800 Subject: [webkit-dev] caching of static files In-Reply-To: References: Message-ID: <18ACC3B4-25B5-49CE-911A-0ACBB7224A81@apple.com> On Nov 10, 2009, at 2:29 PM, Rick Gigger wrote: > I have noticed that Safari and Firefox seem to use different strategies for caching static files. It seems that when I have the expiration headers set properly that Firefox does not request them at all until they are expired but Safari requests them gut gets back 304 "not modified" responses. Is one of those right or wrong? Does the http spec allow for either behavior? The behavior you are talking about is called revalidation. The http specification specifies when revalidation should be done. For a particular test case you can read the HTTP 1.1 specification and figure out if the behavior is correct. If the Safari behavior is incorrect, the bug could either be in the CFNetwork library or in WebKit. If the bug is in the CFNetwork library then it needs to be reported at but if it is in WebKit, you could instead report it at . If you don?t know which it is OK to start with WebKit. -- Darin From darin at apple.com Tue Nov 10 20:37:25 2009 From: darin at apple.com (Darin Adler) Date: Tue, 10 Nov 2009 20:37:25 -0800 Subject: [webkit-dev] Question on standards mode vs. site compatibility In-Reply-To: References: Message-ID: <1843848D-E180-4379-A71C-E087CF6C0A4E@apple.com> On Nov 2, 2009, at 11:19 PM, Chris Evans wrote: > Whilst mining a large list of URLs, I came across some sites that render incorrectly in WebKit but fine in IE. > > It turns out there exist some sites which declare themselves standards complaint in their HTML via their DTD. These sites then proceed to try and load CSS resources with the incorrect MIME type. This promptly fails due to standards mode. > > e.g. > http://web.pcc.gov.tw/ uses application/x-pointplus > http://www.emart.co.kr/index.jsp uses application/css > http://www.fotocolombo.it/shop/index.php uses text-css (note the hyphen in place of a slash) > application/octet stream also appears to be a favourite. That's unfortunate. Out of curiosity, how do these sites behave in Firefox? > What is "enforceCSSMIMETypeInStrictMode()"? Is it a global setting or is there some per-page metadata somewhere? It?s a setting for applications. For web browsers it is set to true. It is not per-page. > We can relax the MIME type list we enforce for "strict mode" without breaking ACID3, although I'm not even sure that's desirable? Is it worth me worrying about this at all or is the correct solution that these sites are just broken and need to fix themselves at some stage? (Pragmatically, I worry that these sites will never fix themselves so users of WebKit-based browsers are SOL). Sounds like a tough choice. It would be unfortunate to have to have a white list of sites that violate this rule. -- Darin -------------- next part -------------- An HTML attachment was scrubbed... URL: From darin at apple.com Tue Nov 10 20:39:18 2009 From: darin at apple.com (Darin Adler) Date: Tue, 10 Nov 2009 20:39:18 -0800 Subject: [webkit-dev] WTFNoncopyable namespace and ADL In-Reply-To: References: Message-ID: On Nov 8, 2009, at 12:21 AM, Chris Jerdonek wrote: > I have a question regarding JSC's WTFNoncopyable::Noncopyable class and argument-dependent lookup (ADL). It seems like an old decision may have been unintentionally undone in changeset 46933. I?m surprised that nothing depended on the argument-dependent lookup technique. We should see if we can demonstrate the the problem this causes. > It seems like either the WTFNoncopyable namespace should be changed to WTF and the comment removed, or else FastAllocBase should be put into its own namespace as well (or something equivalent). Yes, one of these should be done. But it?s not urgent. -- Darin From cevans at chromium.org Tue Nov 10 20:59:39 2009 From: cevans at chromium.org (Chris Evans) Date: Tue, 10 Nov 2009 20:59:39 -0800 Subject: [webkit-dev] Question on standards mode vs. site compatibility In-Reply-To: <1843848D-E180-4379-A71C-E087CF6C0A4E@apple.com> References: <1843848D-E180-4379-A71C-E087CF6C0A4E@apple.com> Message-ID: On Tue, Nov 10, 2009 at 8:37 PM, Darin Adler wrote: > On Nov 2, 2009, at 11:19 PM, Chris Evans wrote: > > Whilst mining a large list of URLs, I came across some sites that render > incorrectly in WebKit but fine in IE. > > It turns out there exist some sites which declare themselves standards > complaint in their HTML via their DTD. These sites then proceed to try and > load CSS resources with the incorrect MIME type. This promptly fails due to > standards mode. > > e.g. > http://web.pcc.gov.tw/ uses application/x-pointplus > http://www.emart.co.kr/index.jsp uses application/css > http://www.fotocolombo.it/shop/index.php uses text-css (note the hyphen in > place of a slash) > application/octet stream also appears to be a favourite. > > > That's unfortunate. Out of curiosity, how do these sites behave in Firefox? > Broken, in the same way. Fine in IE. > What is "enforceCSSMIMETypeInStrictMode()"? Is it a global setting or is > there some per-page metadata somewhere? > > > It?s a setting for applications. For web browsers it is set to true. It is > not per-page. > > > We can relax the MIME type list we enforce for "strict mode" without > breaking ACID3, although I'm not even sure that's desirable? Is it worth me > worrying about this at all or is the correct solution that these sites are > just broken and need to fix themselves at some stage? (Pragmatically, I > worry that these sites will never fix themselves so users of WebKit-based > browsers are SOL). > > > Sounds like a tough choice. It would be unfortunate to have to have a white > list of sites that violate this rule. > I agree we don't want to be listing sites. Our options would seem to be: - Do nothing - Permit application/x-point-plus and application/css as valid CSS MIME types. This would fix some unknown number of sites, and retain ACID3 compatibility. (ACID3 checks for CSS load failure with text/plain, I think). Cheers Chris > -- Darin > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ddkilzer at webkit.org Tue Nov 10 22:21:49 2009 From: ddkilzer at webkit.org (David Kilzer) Date: Tue, 10 Nov 2009 22:21:49 -0800 (PST) Subject: [webkit-dev] Question on standards mode vs. site compatibility In-Reply-To: References: <1843848D-E180-4379-A71C-E087CF6C0A4E@apple.com> Message-ID: <77739.92552.qm@web110805.mail.gq1.yahoo.com> Both Firefox and WebKit allow you to file evangelism bugs on any web site. Perhaps it would be best to try that approach first? Dave > >From: Chris Evans >To: Darin Adler >Cc: webkit-dev at lists.webkit.org >Sent: Tue, November 10, 2009 8:59:39 PM >Subject: Re: [webkit-dev] Question on standards mode vs. site compatibility > >>On Tue, Nov 10, 2009 at 8:37 PM, Darin Adler wrote: > >On Nov 2, 2009, at 11:19 PM, Chris Evans wrote: >> >>Whilst mining a large list of URLs, I came across some sites that render incorrectly in WebKit but fine in IE. >>> >>> >>>It turns out there exist some sites which declare themselves standards complaint in their HTML via their DTD. These sites then proceed to try and load CSS resources with the incorrect MIME type. This promptly fails due to standards mode. >>> >>> >>>e.g. >>>http://web.pcc.gov.tw/ uses application/x-pointplus >>>http://www.emart.co.kr/index.jsp uses application/css >>>http://www.fotocolombo.it/shop/index.php uses text-css (note the hyphen in place of a slash) >>>application/octet stream also appears to be a favourite. >> >> >>That's unfortunate. Out of curiosity, how do these sites behave in Firefox? > > >Broken, in the same way. Fine in IE. > > > >> >>What is "enforceCSSMIMETypeInStrictMode()"? Is it a global setting or is there some per-page metadata somewhere? >> >>It?s a setting for applications. For web browsers it is set to true. It is not per-page. >> >> >> >> >>We can relax the MIME type list we enforce for "strict mode" without breaking ACID3, although I'm not even sure that's desirable? Is it worth me worrying about this at all or is the correct solution that these sites are just broken and need to fix themselves at some stage? (Pragmatically, I worry that these sites will never fix themselves so users of WebKit-based browsers are SOL). >> >>Sounds like a tough choice. It would be unfortunate to have to have a white list of sites that violate this rule. > > >I agree we don't want to be listing sites. >Our options would seem to be: >- Do nothing >- Permit application/x-point-plus and application/css as valid CSS MIME types. This would fix some unknown number of sites, and retain ACID3 compatibility. (ACID3 checks for CSS load failure with text/plain, I think). > > >Cheers >Chris > > > >>>> -- Darin >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric at webkit.org Wed Nov 11 00:03:33 2009 From: eric at webkit.org (Eric Seidel) Date: Wed, 11 Nov 2009 00:03:33 -0800 Subject: [webkit-dev] InkML In-Reply-To: References: Message-ID: <1448d9f30911110003kf090ddbt7a8e0645dc422b2e@mail.gmail.com> Personally I think it makes more sense as a plugin. Are there any InkML files in existence? Would one want to view them in a web browser? If one wanted to view them in a web browser, it seems an XSL sheet which transformed the InkML into SVG/XHTML would be the easiest way to display them in a browser. -eric On Tue, Nov 3, 2009 at 11:30 PM, Ishan Ahuja wrote: > Hi, > > I was wondering if there are any plans of implementing InkML > (http://www.w3.org/2002/mmi/ink) rendering in webkit - or would you rather > have it as a plug-in. > > Thanks, > Ishan > _______________________________________________ > webkit-dev mailing list > webkit-dev at lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > From cmarrin at apple.com Wed Nov 11 07:31:26 2009 From: cmarrin at apple.com (Chris Marrin) Date: Wed, 11 Nov 2009 07:31:26 -0800 Subject: [webkit-dev] Running WebGL layout tests In-Reply-To: <921bb10911031235q224f17a3y2d8b81521f0546f6@mail.gmail.com> References: <921bb10911031235q224f17a3y2d8b81521f0546f6@mail.gmail.com> Message-ID: <67269248-0A03-41BA-A13B-276DCCE63221@apple.com> On Nov 3, 2009, at 12:35 PM, Kenneth Russell wrote: > Hi, > > Trying to run the WebGL layout tests in LayoutTests/fast/canvas/webgl. > Here's the command line I'm using: > > run-webkit-tests --debug LayoutTests/fast/canvas/webgl/[test > name.html] > > (I built WebKit --debug.) > > All of the tests fail while attempting to fetch the 3D context. > (TypeError: Result of expression 'context' [undefined] is not an > object.) The same tests run fine when run under "run-safari --debug". > > Do I need to do some other "defaults write" or other setup to allow > the layout test harness to run with WebGL enabled? So you're saying that the overridePreferences() call is no longer turning on the "WebKitWebGLEnabled" flag in DRT? That's what should turn on the option. What happens if you run: defaults write com.apple.Safari WebKitWebGLEnabled -bool YES and then run layout tests? ----- ~Chris cmarrin at apple.com From eric at webkit.org Wed Nov 11 10:35:38 2009 From: eric at webkit.org (Eric Seidel) Date: Wed, 11 Nov 2009 10:35:38 -0800 Subject: [webkit-dev] Layering weirdness in chrome tree In-Reply-To: <7789133a0911101202o7632f04bs2161c4e21432188f@mail.gmail.com> References: <3A398CD2-D563-4457-8D01-21273B7169F0@apple.com> <7789133a0911101202o7632f04bs2161c4e21432188f@mail.gmail.com> Message-ID: <1448d9f30911111035sf75147ay31ac84f1530bf913@mail.gmail.com> Would one of you mind filing a bug and CCing fishd and dglazkov? -eric On Tue, Nov 10, 2009 at 12:02 PM, Adam Barth wrote: > That sounds like a bug to me. ?Historically the chromium port hasn't > had a strong distinction between WebKit and WebCore/platform, but I > think it's a worthwhile distinction to make. > > Adam > > > On Tue, Nov 10, 2009 at 11:53 AM, Oliver Hunt wrote: >> I just noticed that there are a bunch of WebCore platform implementations >> being landed in Chrome's WebKit API rather than in WebCore/platform. ?This >> seems incorrect to me as there is no other place where this sort of >> mis-layering occurred, the obvious files that stand out are: >> >> ApplicationCacheHost.cpp >> GraphicsContext3D.cpp >> MediaPlayerPrivateChromium.cpp >> PlatformMessagePortChannel.* >> ResoureHandle.cpp >> DOMUtilitiesPrivate.* >> >> I see no obvious reason for these being placed in WebKit -- as far as I can >> tell these represent a layering violation: it's not possible to build the >> WebCore directory into it's own library due to the hard dependency on the >> chrome webkit 'api'. >> >> --Oliver >> >> _______________________________________________ >> webkit-dev mailing list >> webkit-dev at lists.webkit.org >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >> > _______________________________________________ > webkit-dev mailing list > webkit-dev at lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > From eric at webkit.org Wed Nov 11 10:36:37 2009 From: eric at webkit.org (Eric Seidel) Date: Wed, 11 Nov 2009 10:36:37 -0800 Subject: [webkit-dev] Layering weirdness in chrome tree In-Reply-To: <1448d9f30911111035sf75147ay31ac84f1530bf913@mail.gmail.com> References: <3A398CD2-D563-4457-8D01-21273B7169F0@apple.com> <7789133a0911101202o7632f04bs2161c4e21432188f@mail.gmail.com> <1448d9f30911111035sf75147ay31ac84f1530bf913@mail.gmail.com> Message-ID: <1448d9f30911111036v36017a9bl76409460e33af78e@mail.gmail.com> I expect that these are less design choices, and more historical artifacts to the WebKit layer (formerly part of the glue layer) being part of src.chromium.org until yesterday! :) -eric On Wed, Nov 11, 2009 at 10:35 AM, Eric Seidel wrote: > Would one of you mind filing a bug and CCing fishd and dglazkov? > > -eric > > On Tue, Nov 10, 2009 at 12:02 PM, Adam Barth wrote: >> That sounds like a bug to me. ?Historically the chromium port hasn't >> had a strong distinction between WebKit and WebCore/platform, but I >> think it's a worthwhile distinction to make. >> >> Adam >> >> >> On Tue, Nov 10, 2009 at 11:53 AM, Oliver Hunt wrote: >>> I just noticed that there are a bunch of WebCore platform implementations >>> being landed in Chrome's WebKit API rather than in WebCore/platform. ?This >>> seems incorrect to me as there is no other place where this sort of >>> mis-layering occurred, the obvious files that stand out are: >>> >>> ApplicationCacheHost.cpp >>> GraphicsContext3D.cpp >>> MediaPlayerPrivateChromium.cpp >>> PlatformMessagePortChannel.* >>> ResoureHandle.cpp >>> DOMUtilitiesPrivate.* >>> >>> I see no obvious reason for these being placed in WebKit -- as far as I can >>> tell these represent a layering violation: it's not possible to build the >>> WebCore directory into it's own library due to the hard dependency on the >>> chrome webkit 'api'. >>> >>> --Oliver >>> >>> _______________________________________________ >>> webkit-dev mailing list >>> webkit-dev at lists.webkit.org >>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >>> >> _______________________________________________ >> webkit-dev mailing list >> webkit-dev at lists.webkit.org >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >> > From hyatt at apple.com Wed Nov 11 10:40:56 2009 From: hyatt at apple.com (David Hyatt) Date: Wed, 11 Nov 2009 12:40:56 -0600 Subject: [webkit-dev] ruby annotation layout tests In-Reply-To: <4AF808C6.6050302@stud.u-szeged.hu> References: <4AF808C6.6050302@stud.u-szeged.hu> Message-ID: <8046E31F-8492-49D6-893E-9AC0680A921E@apple.com> I think it's better if they are japanese text, since that's the primary use case for ruby. dave On Nov 9, 2009, at 6:19 AM, Andras Becsi wrote: > Hello, I have a question about the following HTML5 ruby annotation (http://www.w3.org/TR/ruby/ > ) layout tests: > > fast/ruby/ruby-empty-rt.html > fast/ruby/ruby-length.html > fast/ruby/ruby-run-break.html > fast/ruby/ruby-runs-spans.html > fast/ruby/ruby-runs.html > fast/ruby/ruby-simple-rp.html > fast/ruby/ruby-simple.html > fast/ruby/ruby-trailing.html > fast/ruby/rubyDOM-insert-rt.html > fast/ruby/rubyDOM-insert-text1.html > fast/ruby/rubyDOM-insert-text2.html > fast/ruby/rubyDOM-insert-text3.html > fast/ruby/rubyDOM-remove-rt1.html > fast/ruby/rubyDOM-remove-rt2.html > fast/ruby/rubyDOM-remove-text1.html > fast/ruby/rubyDOM-remove-text2.html > > Is there an explicit need that the texts in these tests need to be > japanese? Could they be changed to have english texts in them and > add some tests that test if japanese fonts are supported correctly? > > Thanks in advance! > Andras (bbandix) > _______________________________________________ > webkit-dev mailing list > webkit-dev at lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev From hyatt at apple.com Wed Nov 11 10:42:42 2009 From: hyatt at apple.com (David Hyatt) Date: Wed, 11 Nov 2009 12:42:42 -0600 Subject: [webkit-dev] Question on standards mode vs. site compatibility In-Reply-To: References: <1843848D-E180-4379-A71C-E087CF6C0A4E@apple.com> Message-ID: <17F7E948-8852-453F-97B2-230775B80F26@apple.com> On Nov 10, 2009, at 10:59 PM, Chris Evans wrote: > > Our options would seem to be: > - Do nothing I am inclined to do nothing here assuming the set of sites that are broken is pretty small (and I suspect it is). dave From dglazkov at chromium.org Wed Nov 11 10:47:22 2009 From: dglazkov at chromium.org (Dimitri Glazkov) Date: Wed, 11 Nov 2009 10:47:22 -0800 Subject: [webkit-dev] Layering weirdness in chrome tree In-Reply-To: References: <3A398CD2-D563-4457-8D01-21273B7169F0@apple.com> Message-ID: Gah. I just realized this didn't go through to webkit-dev. Resending from the right email address. On Tue, Nov 10, 2009 at 12:46 PM, Dimitri Glazkov wrote: > Please pardon the dust -- upstreaming these files is just the first > step in getting a working port up. > > You're right, some of these are the artifact of extracting > inter-dependencies while staying in flight. Now that they're in WebKit > tree, we'll be able to move them into the proper places. > > :DG< > > On Tue, Nov 10, 2009 at 11:53 AM, Oliver Hunt wrote: >> I just noticed that there are a bunch of WebCore platform implementations >> being landed in Chrome's WebKit API rather than in WebCore/platform. ?This >> seems incorrect to me as there is no other place where this sort of >> mis-layering occurred, the obvious files that stand out are: >> >> ApplicationCacheHost.cpp >> GraphicsContext3D.cpp >> MediaPlayerPrivateChromium.cpp >> PlatformMessagePortChannel.* >> ResoureHandle.cpp >> DOMUtilitiesPrivate.* >> >> I see no obvious reason for these being placed in WebKit -- as far as I can >> tell these represent a layering violation: it's not possible to build the >> WebCore directory into it's own library due to the hard dependency on the >> chrome webkit 'api'. >> >> --Oliver >> >> _______________________________________________ >> webkit-dev mailing list >> webkit-dev at lists.webkit.org >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >> > From darin at apple.com Wed Nov 11 12:39:04 2009 From: darin at apple.com (Darin Adler) Date: Wed, 11 Nov 2009 12:39:04 -0800 Subject: [webkit-dev] caching of static files In-Reply-To: <7D7CC00F-34C4-46D3-95C7-0EE71BDF19C7@alpinenetworking.com> References: <18ACC3B4-25B5-49CE-911A-0ACBB7224A81@apple.com> <7D7CC00F-34C4-46D3-95C7-0EE71BDF19C7@alpinenetworking.com> Message-ID: Sorry, I should have been clearer the first time around. This absolutely is a misuse of this list. The list is for discussion of development of WebKit. It?s not to be used for reporting bugs. You can file a bug report with this information and continue the discussion there. -- Darin From mitsuru.nishibe at gmail.com Wed Nov 11 15:38:32 2009 From: mitsuru.nishibe at gmail.com (Mitsuru Nishibe) Date: Thu, 12 Nov 2009 08:38:32 +0900 Subject: [webkit-dev] (no subject) In-Reply-To: <757bd8dc0911111537u49f76360yc5388f5004f7335e@mail.gmail.com> References: <757bd8dc0911111537u49f76360yc5388f5004f7335e@mail.gmail.com> Message-ID: <757bd8dc0911111538t1294f1d5y755c06cd3478c516@mail.gmail.com> -------------- next part -------------- An HTML attachment was scrubbed... URL: From rolandsteiner at google.com Wed Nov 11 16:33:55 2009 From: rolandsteiner at google.com (Roland Steiner) Date: Thu, 12 Nov 2009 09:33:55 +0900 Subject: [webkit-dev] ruby annotation layout tests In-Reply-To: <8046E31F-8492-49D6-893E-9AC0680A921E@apple.com> References: <4AF808C6.6050302@stud.u-szeged.hu> <8046E31F-8492-49D6-893E-9AC0680A921E@apple.com> Message-ID: Yes, that was the reasoning why I used Japanese for those tests. - Roland On Thu, Nov 12, 2009 at 3:40 AM, David Hyatt wrote: > I think it's better if they are japanese text, since that's the primary use > case for ruby. > > dave > > > On Nov 9, 2009, at 6:19 AM, Andras Becsi wrote: > > Hello, I have a question about the following HTML5 ruby annotation ( >> http://www.w3.org/TR/ruby/) layout tests: >> >> fast/ruby/ruby-empty-rt.html >> fast/ruby/ruby-length.html >> fast/ruby/ruby-run-break.html >> fast/ruby/ruby-runs-spans.html >> fast/ruby/ruby-runs.html >> fast/ruby/ruby-simple-rp.html >> fast/ruby/ruby-simple.html >> fast/ruby/ruby-trailing.html >> fast/ruby/rubyDOM-insert-rt.html >> fast/ruby/rubyDOM-insert-text1.html >> fast/ruby/rubyDOM-insert-text2.html >> fast/ruby/rubyDOM-insert-text3.html >> fast/ruby/rubyDOM-remove-rt1.html >> fast/ruby/rubyDOM-remove-rt2.html >> fast/ruby/rubyDOM-remove-text1.html >> fast/ruby/rubyDOM-remove-text2.html >> >> Is there an explicit need that the texts in these tests need to be >> japanese? Could they be changed to have english texts in them and add some >> tests that test if japanese fonts are supported correctly? >> >> Thanks in advance! >> Andras (bbandix) >> _______________________________________________ >> webkit-dev mailing list >> webkit-dev at lists.webkit.org >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >> > > _______________________________________________ > webkit-dev mailing list > webkit-dev at lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr at google.com Wed Nov 11 16:50:47 2009 From: kbr at google.com (Kenneth Russell) Date: Wed, 11 Nov 2009 16:50:47 -0800 Subject: [webkit-dev] Running WebGL layout tests In-Reply-To: <67269248-0A03-41BA-A13B-276DCCE63221@apple.com> References: <921bb10911031235q224f17a3y2d8b81521f0546f6@mail.gmail.com> <67269248-0A03-41BA-A13B-276DCCE63221@apple.com> Message-ID: <921bb10911111650x7879c87cyd67a75b3869e0f20@mail.gmail.com> On Wed, Nov 11, 2009 at 7:31 AM, Chris Marrin wrote: > > On Nov 3, 2009, at 12:35 PM, Kenneth Russell wrote: > >> Hi, >> >> Trying to run the WebGL layout tests in LayoutTests/fast/canvas/webgl. >> Here's the command line I'm using: >> >> run-webkit-tests --debug LayoutTests/fast/canvas/webgl/[test name.html] >> >> (I built WebKit --debug.) >> >> All of the tests fail while attempting to fetch the 3D context. >> (TypeError: Result of expression 'context' [undefined] is not an >> object.) The same tests run fine when run under "run-safari --debug". >> >> Do I need to do some other "defaults write" or other setup to allow >> the layout test harness to run with WebGL enabled? > > > So you're saying that the overridePreferences() call is no longer turning on > the "WebKitWebGLEnabled" flag in DRT? That's what should turn on the option. > What happens if you run: > > ? ?defaults write com.apple.Safari WebKitWebGLEnabled -bool YES > > and then run layout tests? This is working fine now since https://bugs.webkit.org/show_bug.cgi?id=31088 is fixed. defaults write com.apple.Safari WebKitWebGLEnabled -bool YES has no effect on DumpRenderTree. -Ken From zecke at selfish.org Wed Nov 11 17:20:19 2009 From: zecke at selfish.org (Holger Freyther) Date: Thu, 12 Nov 2009 02:20:19 +0100 Subject: [webkit-dev] ruby annotation layout tests In-Reply-To: References: <4AF808C6.6050302@stud.u-szeged.hu> <8046E31F-8492-49D6-893E-9AC0680A921E@apple.com> Message-ID: <200911120220.20321.zecke@selfish.org> On Thursday 12 November 2009 01:33:55 Roland Steiner wrote: > Yes, that was the reasoning why I used Japanese for those tests. Which font do you propose to use for japanese? holger From chris.jerdonek at gmail.com Wed Nov 11 18:56:37 2009 From: chris.jerdonek at gmail.com (Chris Jerdonek) Date: Wed, 11 Nov 2009 18:56:37 -0800 Subject: [webkit-dev] "using namespace" style guideline In-Reply-To: References: Message-ID: On Tue, Nov 10, 2009 at 8:30 PM, Darin Adler wrote: > No "using namespace" statements are permitted in header files. The guidelines are talking about non-header files. We should clarify that. Thanks for the clarification. I will go ahead and try adding that. This is a good segue into another question I have. What is the current thinking on all of the "using WTF::..." statements at the end of many header files in JSC? For example, what was the original reason behind including those, and is there any chance that they will be taken out at a later date (or has that already been ruled out)? I searched a bit and didn't come across any discussion of this. --Chris From darin at apple.com Thu Nov 12 08:50:11 2009 From: darin at apple.com (Darin Adler) Date: Thu, 12 Nov 2009 08:50:11 -0800 Subject: [webkit-dev] "using namespace" style guideline In-Reply-To: References: Message-ID: <469DDF82-9576-4A0E-8876-29DDB05DF676@apple.com> On Nov 11, 2009, at 6:56 PM, Chris Jerdonek wrote: > What is the current thinking on all of the "using WTF::..." statements at the end of many header files in JSC? For example, what was the original reason behind including those, and is there any chance that they will be taken out at a later date (or has that already been ruled out)? I searched a bit and didn't come across any discussion of this. WTF uses namespacing differently than most libraries. We?re using it to disambiguate at link time, but not compile time.Having the symbols in a namespace at link time still has a substantial benefit, so it?s good to put things in a WTF namespace instead of just putting them outside any namespace. Maciej Stachowiak devised this scheme for WTF, and I think on balance it?s probably a good way to do things although I would probably not have chosen it myself, and would have used the more conventional scheme. Maciej and I and a few others at Apple discussed this a bit a few years back, but nobody on any WebKit mailing list ever raised the issue before. Since WTF is for use inside WebKit itself, I think we can stick with this approach unless we run into a substantial, concrete problem with it. I don?t think things would be better if we did this in the conventional way and either had to utter WTF::RefPtr and WTF::Vector in WebCore and JavaScriptCore header files, or every client of RefPtr had to include a certain header file with a "using WTF::RefPtr" in the WebCore or JavaScriptCore namespace. Similarly if many .cpp files had to have "using namespace WTF". For a while I was adding "using namespace WTF" to .cpp files because I did not understand our WTF namespacing approach. -- Darin From yaar at chromium.org Thu Nov 12 10:17:36 2009 From: yaar at chromium.org (Yaar Schnitman) Date: Thu, 12 Nov 2009 10:17:36 -0800 Subject: [webkit-dev] The Chromium WebKit API In-Reply-To: References: Message-ID: Hi, WebKit/chromium is now a live directory. We have completed committing the bulk of the Chromium WebKit API into WebKit/chromium and this code is now integrated to Chromium. Our next steps, as described below, are to commit a 2nd wave (much smaller) of API additions, and to port DumpRenderTree to the Chromium API. Best regards, Yaar On Thu, Nov 5, 2009 at 12:02 AM, Darin Fisher wrote: > *Please ignore this if you are not interested in the Chromium WebKit > API...* > > > I'm writing to announce that we have finished decoupling the Chromium > WebKit API from the rest of the Chromium repository, and so we are now ready to move it > to svn.webkit.org. The plan is for it to live under > WebKit/WebKit/chromium/ > . > > > *Some background:* > > Chromium began life using WebCore directly. A layer (named webkit/glue) > was added to the Chromium repository to help insulate most of the Chromium > repository from the fast moving WebCore codebase. However, that layer grew > to have many dependencies on lower layers in the Chromium repository (base, > net, etc.), and it was also coded using Google C++ style. > > For much of the past year (since Feb!), we have been working furiously to > eliminate those dependencies and convert to WebKit C++ style so that this > glue layer could live in the WebKit repository and thereby provide a clean > and stable API to WebCore for consumption by Chromium. The result is > something we have been calling our WebKit API. > > Over the past year, we also upstreamed all of our modifications to WebCore. > However, without the corresponding WebKit layer in plain sight, it is often > hard to understand some of the PLATFORM(CHROMIUM) code that lives in > WebCore. It is long overdue that we contribute our WebKit API layer into > svn.webkit.org. > > > *Next steps:* > > Within the coming days, we plan to commit the Chromium WebKit API into > WebKit/WebKit/chromium, and then throw all the requisite switches in the > Chromium repository to point the Chromium build at this code. Dimitri > Glazkov and Eric Seidel are going to be driving this effort. Thanks guys!! > > > *Future steps:* > > After the dust has settled with this move, we will still have some chores > left to do. > > There remain a number of WebCore dependencies in the Chromium repository > that we plan to eliminate. These will be eliminated by introducing > additional interfaces in the Chromium WebKit API. (We did not want to delay > the initial commit of the Chromium WebKit API waiting on these changes.) > > It will now be possible to port DumpRenderTree to the Chromium WebKit API, > and this is a task we will undertake in the following months. It'll be > great for the Chromium project to move to the same testing infrastructure > for layout tests as the rest of the WebKit community! > > > Regards, > -Darin > > _______________________________________________ > webkit-dev mailing list > webkit-dev at lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From abarth at webkit.org Thu Nov 12 11:37:19 2009 From: abarth at webkit.org (Adam Barth) Date: Thu, 12 Nov 2009 11:37:19 -0800 Subject: [webkit-dev] A bot-filled future? Message-ID: <7789133a0911121137l35bc1485w511d73e59544d4d1@mail.gmail.com> As the project grows, we need to scale our processes to match. In large part, that means automating as much work as possible. Commit-queue has done a good job of solving the "land patches from non-committers efficiently" problem, effectively removing that as a pain point. I'd like to ask you to open your hearts and your minds to the idea of automating more of our processes. Currently, I see the biggest pain-point in our process as the always-burgeoning pending-review list. It's difficult to automate the process of accepting good patches because that requires attention from experts. Instead, I think we should make it easier to reject bad patches. As a first step, I've started extending bugzilla-tool to be a try server in . Here's how this might work: 1) Contributor posts patch for review. 2) Committer marks patch with the try? flag. 3) The try-queue downloads, applies, builds, and tests the patch. 4) If all systems are go, the try-queue marks the patch as try+. Otherwise, it marks the patch as try- with an explanation of what went wrong. The try-queue will be purely optional and advisory. Hopefully a try- notation will encourage the contributor to post a new version of the patch that passes the try-queue. Further down the road, one can also imagine another bot that automates step (2) by scanning the pending-review list for untried patches and marking them as try? when the try-queue has unused bandwidth. Adam From kenneth.christiansen at openbossa.org Thu Nov 12 11:43:14 2009 From: kenneth.christiansen at openbossa.org (Kenneth Christiansen) Date: Thu, 12 Nov 2009 16:43:14 -0300 Subject: [webkit-dev] A bot-filled future? In-Reply-To: <7789133a0911121137l35bc1485w511d73e59544d4d1@mail.gmail.com> References: <7789133a0911121137l35bc1485w511d73e59544d4d1@mail.gmail.com> Message-ID: <927d01d20911121143k1508d345r17df9f8a77dc5635@mail.gmail.com> I think that sounds like a really good idea, and I can see my self using that when touching cross platform code. Kenneth On Thu, Nov 12, 2009 at 4:37 PM, Adam Barth wrote: > As the project grows, we need to scale our processes to match. ?In > large part, that means automating as much work as possible. > Commit-queue has done a good job of solving the "land patches from > non-committers efficiently" problem, effectively removing that as a > pain point. ?I'd like to ask you to open your hearts and your minds to > the idea of automating more of our processes. > > Currently, I see the biggest pain-point in our process as the > always-burgeoning pending-review list. ?It's difficult to automate the > process of accepting good patches because that requires attention from > experts. ?Instead, I think we should make it easier to reject bad > patches. ?As a first step, I've started extending bugzilla-tool to be > a try server in . > Here's how this might work: > > 1) Contributor posts patch for review. > 2) Committer marks patch with the try? flag. > 3) The try-queue downloads, applies, builds, and tests the patch. > 4) If all systems are go, the try-queue marks the patch as try+. > Otherwise, it marks the patch as try- with an explanation of what went > wrong. > > The try-queue will be purely optional and advisory. ?Hopefully a try- > notation will encourage the contributor to post a new version of the > patch that passes the try-queue. > > Further down the road, one can also imagine another bot that automates > step (2) by scanning the pending-review list for untried patches and > marking them as try? when the try-queue has unused bandwidth. > > Adam > _______________________________________________ > webkit-dev mailing list > webkit-dev at lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > -- Kenneth Rohde Christiansen Technical Lead / Software Engineer Qt Labs Americas, Nokia Technology Institute, INdT Phone +55 81 8895 6002 / E-mail kenneth.christiansen at openbossa.org From jorlow at chromium.org Thu Nov 12 12:41:11 2009 From: jorlow at chromium.org (Jeremy Orlow) Date: Thu, 12 Nov 2009 12:41:11 -0800 Subject: [webkit-dev] A bot-filled future? In-Reply-To: <927d01d20911121143k1508d345r17df9f8a77dc5635@mail.gmail.com> References: <7789133a0911121137l35bc1485w511d73e59544d4d1@mail.gmail.com> <927d01d20911121143k1508d345r17df9f8a77dc5635@mail.gmail.com> Message-ID: <5dd9e5c50911121241r53ffabf1t44b20f7c110539ae@mail.gmail.com> It's so easy to have code that builds on one platform but not another. Even if the try servers were only builders to begin with, I think they'd provide a lot of value to the project. On Thu, Nov 12, 2009 at 11:43 AM, Kenneth Christiansen < kenneth.christiansen at openbossa.org> wrote: > I think that sounds like a really good idea, and I can see my self > using that when touching cross platform code. > > Kenneth > > On Thu, Nov 12, 2009 at 4:37 PM, Adam Barth wrote: > > As the project grows, we need to scale our processes to match. In > > large part, that means automating as much work as possible. > > Commit-queue has done a good job of solving the "land patches from > > non-committers efficiently" problem, effectively removing that as a > > pain point. I'd like to ask you to open your hearts and your minds to > > the idea of automating more of our processes. > > > > Currently, I see the biggest pain-point in our process as the > > always-burgeoning pending-review list. It's difficult to automate the > > process of accepting good patches because that requires attention from > > experts. Instead, I think we should make it easier to reject bad > > patches. As a first step, I've started extending bugzilla-tool to be > > a try server in . > > Here's how this might work: > > > > 1) Contributor posts patch for review. > > 2) Committer marks patch with the try? flag. > > 3) The try-queue downloads, applies, builds, and tests the patch. > > 4) If all systems are go, the try-queue marks the patch as try+. > > Otherwise, it marks the patch as try- with an explanation of what went > > wrong. > > > > The try-queue will be purely optional and advisory. Hopefully a try- > > notation will encourage the contributor to post a new version of the > > patch that passes the try-queue. > > > > Further down the road, one can also imagine another bot that automates > > step (2) by scanning the pending-review list for untried patches and > > marking them as try? when the try-queue has unused bandwidth. > > > > Adam > > _______________________________________________ > > webkit-dev mailing list > > webkit-dev at lists.webkit.org > > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > > > > > -- > Kenneth Rohde Christiansen > Technical Lead / Software Engineer > Qt Labs Americas, Nokia Technology Institute, INdT > Phone +55 81 8895 6002 / E-mail kenneth.christiansen at openbossa.org > _______________________________________________ > webkit-dev mailing list > webkit-dev at lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bweinstein at apple.com Thu Nov 12 12:58:02 2009 From: bweinstein at apple.com (Brian Weinstein) Date: Thu, 12 Nov 2009 12:58:02 -0800 Subject: [webkit-dev] A bot-filled future? In-Reply-To: <5dd9e5c50911121241r53ffabf1t44b20f7c110539ae@mail.gmail.com> References: <7789133a0911121137l35bc1485w511d73e59544d4d1@mail.gmail.com> <927d01d20911121143k1508d345r17df9f8a77dc5635@mail.gmail.com> <5dd9e5c50911121241r53ffabf1t44b20f7c110539ae@mail.gmail.com> Message-ID: Seconded (or Thirded). I'd been working on a try-server using Chromium's try-change.py, but this seems like a much cleaner way to handle it, and ties into the Bugzilla workflow much better than my solution, and would be much easier to limit who can set the try bit, based on what we decide the policy to be. On Nov 12, 2009, at 12:41 PM, Jeremy Orlow wrote: > It's so easy to have code that builds on one platform but not another. Even if the try servers were only builders to begin with, I think they'd provide a lot of value to the project. > > On Thu, Nov 12, 2009 at 11:43 AM, Kenneth Christiansen wrote: > I think that sounds like a really good idea, and I can see my self > using that when touching cross platform code. > > Kenneth > > On Thu, Nov 12, 2009 at 4:37 PM, Adam Barth wrote: > > As the project grows, we need to scale our processes to match. In > > large part, that means automating as much work as possible. > > Commit-queue has done a good job of solving the "land patches from > > non-committers efficiently" problem, effectively removing that as a > > pain point. I'd like to ask you to open your hearts and your minds to > > the idea of automating more of our processes. > > > > Currently, I see the biggest pain-point in our process as the > > always-burgeoning pending-review list. It's difficult to automate the > > process of accepting good patches because that requires attention from > > experts. Instead, I think we should make it easier to reject bad > > patches. As a first step, I've started extending bugzilla-tool to be > > a try server in . > > Here's how this might work: > > > > 1) Contributor posts patch for review. > > 2) Committer marks patch with the try? flag. > > 3) The try-queue downloads, applies, builds, and tests the patch. > > 4) If all systems are go, the try-queue marks the patch as try+. > > Otherwise, it marks the patch as try- with an explanation of what went > > wrong. > > > > The try-queue will be purely optional and advisory. Hopefully a try- > > notation will encourage the contributor to post a new version of the > > patch that passes the try-queue. > > > > Further down the road, one can also imagine another bot that automates > > step (2) by scanning the pending-review list for untried patches and > > marking them as try? when the try-queue has unused bandwidth. > > > > Adam > > _______________________________________________ > > webkit-dev mailing list > > webkit-dev at lists.webkit.org > > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > > > > > -- > Kenneth Rohde Christiansen > Technical Lead / Software Engineer > Qt Labs Americas, Nokia Technology Institute, INdT > Phone +55 81 8895 6002 / E-mail kenneth.christiansen at openbossa.org > _______________________________________________ > webkit-dev mailing list > webkit-dev at lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > _______________________________________________ > webkit-dev mailing list > webkit-dev at lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From mrowe at apple.com Thu Nov 12 13:04:40 2009 From: mrowe at apple.com (Mark Rowe) Date: Thu, 12 Nov 2009 13:04:40 -0800 Subject: [webkit-dev] A bot-filled future? In-Reply-To: <7789133a0911121137l35bc1485w511d73e59544d4d1@mail.gmail.com> References: <7789133a0911121137l35bc1485w511d73e59544d4d1@mail.gmail.com> Message-ID: On 2009-11-12, at 11:37, Adam Barth wrote: > 1) Contributor posts patch for review. > 2) Committer marks patch with the try? flag. > 3) The try-queue downloads, applies, builds, and tests the patch. > 4) If all systems are go, the try-queue marks the patch as try+. > Otherwise, it marks the patch as try- with an explanation of what went > wrong. I have a few comments / questions about this: 1) People are already confused about how to handle the recently-added commit-queue flag. Adding an extra flag is going to increase the confusion. 2) What machines are going to be doing these tests, and on which platforms? 3) Which patches would this test? Running tests on an arbitrary patch uploaded in Bugzilla opens up the testing machine to executing arbitrary code unless there are limitations in place. - Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3166 bytes Desc: not available URL: From abarth at webkit.org Thu Nov 12 13:43:31 2009 From: abarth at webkit.org (Adam Barth) Date: Thu, 12 Nov 2009 13:43:31 -0800 Subject: [webkit-dev] A bot-filled future? In-Reply-To: References: <7789133a0911121137l35bc1485w511d73e59544d4d1@mail.gmail.com> Message-ID: <7789133a0911121343r5bebaa42o8591cd19162718c9@mail.gmail.com> On Thu, Nov 12, 2009 at 1:04 PM, Mark Rowe wrote: > On 2009-11-12, at 11:37, Adam Barth wrote: >> 1) Contributor posts patch for review. >> 2) Committer marks patch with the try? flag. >> 3) The try-queue downloads, applies, builds, and tests the patch. >> 4) If all systems are go, the try-queue marks the patch as try+. >> Otherwise, it marks the patch as try- with an explanation of what went >> wrong. > > I have a few comments / questions about this: I suspected you might, hence the post to this list. :) > 1) People are already confused about how to handle the recently-added commit-queue flag. ?Adding an extra flag is going to increase the confusion. Do you have other ideas about how to present the information? We want to make the information easily available to reviewers when they're reviewing patches. > 2) What machines are going to be doing these tests, and on which platforms? I was going to start by running the try-queue on a Mac laptop I don't use very often. If/when we want to expand coverage to other platforms, we can worry about where to get more machines. Ultimately, machines are much cheaper than people. I'm not worried about finding hardware. > 3) Which patches would this test? ?Running tests on an arbitrary patch uploaded in Bugzilla opens up the testing machine to executing arbitrary code unless there are limitations in place. My plan what to require a committer to sign-off on the patch (e.g., by setting the flag), the same way we require a committer to sign off for running the commit-queue or the build-bot. Adam From abarth at webkit.org Thu Nov 12 13:46:16 2009 From: abarth at webkit.org (Adam Barth) Date: Thu, 12 Nov 2009 13:46:16 -0800 Subject: [webkit-dev] A bot-filled future? In-Reply-To: <5dd9e5c50911121241r53ffabf1t44b20f7c110539ae@mail.gmail.com> References: <7789133a0911121137l35bc1485w511d73e59544d4d1@mail.gmail.com> <927d01d20911121143k1508d345r17df9f8a77dc5635@mail.gmail.com> <5dd9e5c50911121241r53ffabf1t44b20f7c110539ae@mail.gmail.com> Message-ID: <7789133a0911121346x274c41f9pc22e977896ec9232@mail.gmail.com> On Thu, Nov 12, 2009 at 12:41 PM, Jeremy Orlow wrote: > It's so easy to have code that builds on one platform but not another. ?Even > if the try servers were only builders to begin with, I think they'd provide > a lot of value to the project. That's a good idea, especially for ports that have perennially red tests. Adam From abarth at webkit.org Thu Nov 12 14:43:46 2009 From: abarth at webkit.org (Adam Barth) Date: Thu, 12 Nov 2009 14:43:46 -0800 Subject: [webkit-dev] A bot-filled future? In-Reply-To: References: <7789133a0911121137l35bc1485w511d73e59544d4d1@mail.gmail.com> Message-ID: <7789133a0911121443u79cb305n7f0663cb59f99a33@mail.gmail.com> On Thu, Nov 12, 2009 at 1:04 PM, Mark Rowe wrote: > 1) People are already confused about how to handle the recently-added commit-queue flag. ?Adding an extra flag is going to increase the confusion. I chatted with Eric about how to solve this problem. One option is to just try every change that has review? and add a comment to the bug about success / failure. That minimizes the UI surface and avoids adding yet-another-flag. Adam From mrowe at apple.com Thu Nov 12 14:49:20 2009 From: mrowe at apple.com (Mark Rowe) Date: Thu, 12 Nov 2009 14:49:20 -0800 Subject: [webkit-dev] A bot-filled future? In-Reply-To: <7789133a0911121443u79cb305n7f0663cb59f99a33@mail.gmail.com> References: <7789133a0911121137l35bc1485w511d73e59544d4d1@mail.gmail.com> <7789133a0911121443u79cb305n7f0663cb59f99a33@mail.gmail.com> Message-ID: <87279506-82B6-476C-BC28-4F5CB09C7FD5@apple.com> On 2009-11-12, at 14:43, Adam Barth wrote: > On Thu, Nov 12, 2009 at 1:04 PM, Mark Rowe wrote: >> 1) People are already confused about how to handle the recently-added commit-queue flag. Adding an extra flag is going to increase the confusion. > > I chatted with Eric about how to solve this problem. One option is to > just try every change that has review? and add a comment to the bug > about success / failure. That minimizes the UI surface and avoids > adding yet-another-flag. That doesn't seem to fit with your suggestion for how we deal with the risk of running arbitrary code on the test machines. - Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3166 bytes Desc: not available URL: From jorlow at chromium.org Thu Nov 12 14:50:02 2009 From: jorlow at chromium.org (Jeremy Orlow) Date: Thu, 12 Nov 2009 14:50:02 -0800 Subject: [webkit-dev] A bot-filled future? In-Reply-To: <7789133a0911121443u79cb305n7f0663cb59f99a33@mail.gmail.com> References: <7789133a0911121137l35bc1485w511d73e59544d4d1@mail.gmail.com> <7789133a0911121443u79cb305n7f0663cb59f99a33@mail.gmail.com> Message-ID: <5dd9e5c50911121450p3f0bb6efi48cc8c8040f5ec35@mail.gmail.com> That sounds good to me. As for the security issues: It seems like we could build code from anyone but only run the tests from committers. On Thu, Nov 12, 2009 at 2:43 PM, Adam Barth wrote: > On Thu, Nov 12, 2009 at 1:04 PM, Mark Rowe wrote: > > 1) People are already confused about how to handle the recently-added > commit-queue flag. Adding an extra flag is going to increase the confusion. > > I chatted with Eric about how to solve this problem. One option is to > just try every change that has review? and add a comment to the bug > about success / failure. That minimizes the UI surface and avoids > adding yet-another-flag. > > Adam > _______________________________________________ > webkit-dev mailing list > webkit-dev at lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bweinstein at apple.com Thu Nov 12 14:52:05 2009 From: bweinstein at apple.com (Brian Weinstein) Date: Thu, 12 Nov 2009 14:52:05 -0800 Subject: [webkit-dev] A bot-filled future? In-Reply-To: <5dd9e5c50911121450p3f0bb6efi48cc8c8040f5ec35@mail.gmail.com> References: <7789133a0911121137l35bc1485w511d73e59544d4d1@mail.gmail.com> <7789133a0911121443u79cb305n7f0663cb59f99a33@mail.gmail.com> <5dd9e5c50911121450p3f0bb6efi48cc8c8040f5ec35@mail.gmail.com> Message-ID: <7ECB658E-648A-4B36-B29D-DD420BFE78F7@apple.com> What if someone changed build-webkit or the build procedure in one of the vcproj's? On Nov 12, 2009, at 2:50 PM, Jeremy Orlow wrote: > That sounds good to me. > > As for the security issues: It seems like we could build code from anyone but only run the tests from committers. > > On Thu, Nov 12, 2009 at 2:43 PM, Adam Barth wrote: > On Thu, Nov 12, 2009 at 1:04 PM, Mark Rowe wrote: > > 1) People are already confused about how to handle the recently-added commit-queue flag. Adding an extra flag is going to increase the confusion. > > I chatted with Eric about how to solve this problem. One option is to > just try every change that has review? and add a comment to the bug > about success / failure. That minimizes the UI surface and avoids > adding yet-another-flag. > > Adam > _______________________________________________ > webkit-dev mailing list > webkit-dev at lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > _______________________________________________ > webkit-dev mailing list > webkit-dev at lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From mrowe at apple.com Thu Nov 12 14:53:47 2009 From: mrowe at apple.com (Mark Rowe) Date: Thu, 12 Nov 2009 14:53:47 -0800 Subject: [webkit-dev] A bot-filled future? In-Reply-To: <5dd9e5c50911121450p3f0bb6efi48cc8c8040f5ec35@mail.gmail.com> References: <7789133a0911121137l35bc1485w511d73e59544d4d1@mail.gmail.com> <7789133a0911121443u79cb305n7f0663cb59f99a33@mail.gmail.com> <5dd9e5c50911121450p3f0bb6efi48cc8c8040f5ec35@mail.gmail.com> Message-ID: <8B0F6ACE-ACCB-4D72-AFB1-AAE2187D26F4@apple.com> On 2009-11-12, at 14:50, Jeremy Orlow wrote: > That sounds good to me. > > As for the security issues: It seems like we could build code from anyone but only run the tests from committers. Building involves running code too. build-webkit, makefiles for dependencies, scripts in Xcode projects, etc. - Mark > > On Thu, Nov 12, 2009 at 2:43 PM, Adam Barth wrote: > On Thu, Nov 12, 2009 at 1:04 PM, Mark Rowe wrote: > > 1) People are already confused about how to handle the recently-added commit-queue flag. Adding an extra flag is going to increase the confusion. > > I chatted with Eric about how to solve this problem. One option is to > just try every change that has review? and add a comment to the bug > about success / failure. That minimizes the UI surface and avoids > adding yet-another-flag. > > Adam > _______________________________________________ > webkit-dev mailing list > webkit-dev at lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3166 bytes Desc: not available URL: From jorlow at chromium.org Thu Nov 12 14:54:23 2009 From: jorlow at chromium.org (Jeremy Orlow) Date: Thu, 12 Nov 2009 14:54:23 -0800 Subject: [webkit-dev] A bot-filled future? In-Reply-To: <7ECB658E-648A-4B36-B29D-DD420BFE78F7@apple.com> References: <7789133a0911121137l35bc1485w511d73e59544d4d1@mail.gmail.com> <7789133a0911121443u79cb305n7f0663cb59f99a33@mail.gmail.com> <5dd9e5c50911121450p3f0bb6efi48cc8c8040f5ec35@mail.gmail.com> <7ECB658E-648A-4B36-B29D-DD420BFE78F7@apple.com> Message-ID: <5dd9e5c50911121454g2b809081g35669273aa7e6e75@mail.gmail.com> Ok. The only run stuff uploaded by committers automatically? Maybe have a web page committers can visit to submit (i.e. vouch for) patches to be run through the bots? J On Thu, Nov 12, 2009 at 2:52 PM, Brian Weinstein wrote: > What if someone changed build-webkit or the build procedure in one of the > vcproj's? > > On Nov 12, 2009, at 2:50 PM, Jeremy Orlow wrote: > > That sounds good to me. > > As for the security issues: It seems like we could build code from anyone > but only run the tests from committers. > > On Thu, Nov 12, 2009 at 2:43 PM, Adam Barth wrote: > >> On Thu, Nov 12, 2009 at 1:04 PM, Mark Rowe wrote: >> > 1) People are already confused about how to handle the recently-added >> commit-queue flag. Adding an extra flag is going to increase the confusion. >> >> I chatted with Eric about how to solve this problem. One option is to >> just try every change that has review? and add a comment to the bug >> about success / failure. That minimizes the UI surface and avoids >> adding yet-another-flag. >> >> Adam >> _______________________________________________ >> webkit-dev mailing list >> webkit-dev at lists.webkit.org >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >> > > _______________________________________________ > webkit-dev mailing list > webkit-dev at lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric at webkit.org Thu Nov 12 15:19:01 2009 From: eric at webkit.org (Eric Seidel) Date: Thu, 12 Nov 2009 15:19:01 -0800 Subject: [webkit-dev] A bot-filled future? In-Reply-To: <87279506-82B6-476C-BC28-4F5CB09C7FD5@apple.com> References: <7789133a0911121137l35bc1485w511d73e59544d4d1@mail.gmail.com> <7789133a0911121443u79cb305n7f0663cb59f99a33@mail.gmail.com> <87279506-82B6-476C-BC28-4F5CB09C7FD5@apple.com> Message-ID: <1448d9f30911121519k13d3fc5agc12f0eaa16437a5e@mail.gmail.com> Agreed. Running every r=? patch through such a build-service is insecure. However if Adam wishes to run it on his own hardware, I certainly have no objections to such. :) -eric On Thu, Nov 12, 2009 at 2:49 PM, Mark Rowe wrote: > > On 2009-11-12, at 14:43, Adam Barth wrote: > >> On Thu, Nov 12, 2009 at 1:04 PM, Mark Rowe wrote: >>> 1) People are already confused about how to handle the recently-added commit-queue flag. ?Adding an extra flag is going to increase the confusion. >> >> I chatted with Eric about how to solve this problem. ?One option is to >> just try every change that has review? and add a comment to the bug >> about success / failure. ?That minimizes the UI surface and avoids >> adding yet-another-flag. > > That doesn't seem to fit with your suggestion for how we deal with the risk of running arbitrary code on the test machines. > > - Mark > > > _______________________________________________ > webkit-dev mailing list > webkit-dev at lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > From ojan at chromium.org Thu Nov 12 15:38:13 2009 From: ojan at chromium.org (Ojan Vafai) Date: Thu, 12 Nov 2009 15:38:13 -0800 Subject: [webkit-dev] A bot-filled future? In-Reply-To: References: <7789133a0911121137l35bc1485w511d73e59544d4d1@mail.gmail.com> <927d01d20911121143k1508d345r17df9f8a77dc5635@mail.gmail.com> <5dd9e5c50911121241r53ffabf1t44b20f7c110539ae@mail.gmail.com> Message-ID: <78dc8440911121538v1355bb33p4ff755a94a70e9d@mail.gmail.com> This approach doesn't lend itself as well to trying patches before putting them up for review. Specifically, I want to be able to try patches without spamming everyone with bugzilla mail. This is solvable in this bugzilla-based approach, but it doesn't lend itself to this as naturally, e.g. presumably there's a way to tell bugzilla not to send mail for a given comment. Also, it would be great if the commit-queue, try-server, whatever, had a UI like the buildbot waterfall. There's a couple advantages: 1. Can see the stdio as the tests run and get better information about why it failed. 2. Can grab layout test results from the try servers. This would reduce the need/occurence of committing Mac expectations and then cleaning up other platforms post commit. Ojan On Thu, Nov 12, 2009 at 12:58 PM, Brian Weinstein wrote: > Seconded (or Thirded). I'd been working on a try-server using Chromium's > try-change.py, but this seems like a much cleaner way to handle it, and ties > into the Bugzilla workflow much better than my solution, and would be much > easier to limit who can set the try bit, based on what we decide the policy > to be. > > On Nov 12, 2009, at 12:41 PM, Jeremy Orlow wrote: > > It's so easy to have code that builds on one platform but not another. > Even if the try servers were only builders to begin with, I think they'd > provide a lot of value to the project. > > On Thu, Nov 12, 2009 at 11:43 AM, Kenneth Christiansen < > kenneth.christiansen at openbossa.org> wrote: > >> I think that sounds like a really good idea, and I can see my self >> using that when touching cross platform code. >> >> Kenneth >> >> On Thu, Nov 12, 2009 at 4:37 PM, Adam Barth wrote: >> > As the project grows, we need to scale our processes to match. In >> > large part, that means automating as much work as possible. >> > Commit-queue has done a good job of solving the "land patches from >> > non-committers efficiently" problem, effectively removing that as a >> > pain point. I'd like to ask you to open your hearts and your minds to >> > the idea of automating more of our processes. >> > >> > Currently, I see the biggest pain-point in our process as the >> > always-burgeoning pending-review list. It's difficult to automate the >> > process of accepting good patches because that requires attention from >> > experts. Instead, I think we should make it easier to reject bad >> > patches. As a first step, I've started extending bugzilla-tool to be >> > a try server in . >> > Here's how this might work: >> > >> > 1) Contributor posts patch for review. >> > 2) Committer marks patch with the try? flag. >> > 3) The try-queue downloads, applies, builds, and tests the patch. >> > 4) If all systems are go, the try-queue marks the patch as try+. >> > Otherwise, it marks the patch as try- with an explanation of what went >> > wrong. >> > >> > The try-queue will be purely optional and advisory. Hopefully a try- >> > notation will encourage the contributor to post a new version of the >> > patch that passes the try-queue. >> > >> > Further down the road, one can also imagine another bot that automates >> > step (2) by scanning the pending-review list for untried patches and >> > marking them as try? when the try-queue has unused bandwidth. >> > >> > Adam >> > _______________________________________________ >> > webkit-dev mailing list >> > webkit-dev at lists.webkit.org >> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >> > >> >> >> >> -- >> Kenneth Rohde Christiansen >> Technical Lead / Software Engineer >> Qt Labs Americas, Nokia Technology Institute, INdT >> Phone +55 81 8895 6002 / E-mail kenneth.christiansen at openbossa.org >> _______________________________________________ >> webkit-dev mailing list >> webkit-dev at lists.webkit.org >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >> > > _______________________________________________ > webkit-dev mailing list > webkit-dev at lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > > > _______________________________________________ > webkit-dev mailing list > webkit-dev at lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jorlow at chromium.org Thu Nov 12 15:46:56 2009 From: jorlow at chromium.org (Jeremy Orlow) Date: Thu, 12 Nov 2009 15:46:56 -0800 Subject: [webkit-dev] A bot-filled future? In-Reply-To: <78dc8440911121538v1355bb33p4ff755a94a70e9d@mail.gmail.com> References: <7789133a0911121137l35bc1485w511d73e59544d4d1@mail.gmail.com> <927d01d20911121143k1508d345r17df9f8a77dc5635@mail.gmail.com> <5dd9e5c50911121241r53ffabf1t44b20f7c110539ae@mail.gmail.com> <78dc8440911121538v1355bb33p4ff755a94a70e9d@mail.gmail.com> Message-ID: <5dd9e5c50911121546s7e62244v2666c6d34e5fa2e7@mail.gmail.com> I think the main reason why we don't yet have a try server is that we block it on stuff like this...which is nice to have. It seems like we could get something basic up that worked for 90% of cases and then iterate on something more featureful. I think Adam has the right idea here. J On Thu, Nov 12, 2009 at 3:38 PM, Ojan Vafai wrote: > This approach doesn't lend itself as well to trying patches before putting > them up for review. Specifically, I want to be able to try patches without > spamming everyone with bugzilla mail. This is solvable in this > bugzilla-based approach, but it doesn't lend itself to this as > naturally, e.g. presumably there's a way to tell bugzilla not to send mail > for a given comment. > > Also, it would be great if the commit-queue, try-server, whatever, had a UI > like the buildbot waterfall. There's a couple advantages: > 1. Can see the stdio as the tests run and get better information about why > it failed. > 2. Can grab layout test results from the try servers. This would reduce the > need/occurence of committing Mac expectations and then cleaning up other > platforms post commit. > > Ojan > > On Thu, Nov 12, 2009 at 12:58 PM, Brian Weinstein wrote: > >> Seconded (or Thirded). I'd been working on a try-server using Chromium's >> try-change.py, but this seems like a much cleaner way to handle it, and ties >> into the Bugzilla workflow much better than my solution, and would be much >> easier to limit who can set the try bit, based on what we decide the policy >> to be. >> >> On Nov 12, 2009, at 12:41 PM, Jeremy Orlow wrote: >> >> It's so easy to have code that builds on one platform but not another. >> Even if the try servers were only builders to begin with, I think they'd >> provide a lot of value to the project. >> >> On Thu, Nov 12, 2009 at 11:43 AM, Kenneth Christiansen < >> kenneth.christiansen at openbossa.org> wrote: >> >>> I think that sounds like a really good idea, and I can see my self >>> using that when touching cross platform code. >>> >>> Kenneth >>> >>> On Thu, Nov 12, 2009 at 4:37 PM, Adam Barth wrote: >>> > As the project grows, we need to scale our processes to match. In >>> > large part, that means automating as much work as possible. >>> > Commit-queue has done a good job of solving the "land patches from >>> > non-committers efficiently" problem, effectively removing that as a >>> > pain point. I'd like to ask you to open your hearts and your minds to >>> > the idea of automating more of our processes. >>> > >>> > Currently, I see the biggest pain-point in our process as the >>> > always-burgeoning pending-review list. It's difficult to automate the >>> > process of accepting good patches because that requires attention from >>> > experts. Instead, I think we should make it easier to reject bad >>> > patches. As a first step, I've started extending bugzilla-tool to be >>> > a try server in . >>> > Here's how this might work: >>> > >>> > 1) Contributor posts patch for review. >>> > 2) Committer marks patch with the try? flag. >>> > 3) The try-queue downloads, applies, builds, and tests the patch. >>> > 4) If all systems are go, the try-queue marks the patch as try+. >>> > Otherwise, it marks the patch as try- with an explanation of what went >>> > wrong. >>> > >>> > The try-queue will be purely optional and advisory. Hopefully a try- >>> > notation will encourage the contributor to post a new version of the >>> > patch that passes the try-queue. >>> > >>> > Further down the road, one can also imagine another bot that automates >>> > step (2) by scanning the pending-review list for untried patches and >>> > marking them as try? when the try-queue has unused bandwidth. >>> > >>> > Adam >>> > _______________________________________________ >>> > webkit-dev mailing list >>> > webkit-dev at lists.webkit.org >>> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >>> > >>> >>> >>> >>> -- >>> Kenneth Rohde Christiansen >>> Technical Lead / Software Engineer >>> Qt Labs Americas, Nokia Technology Institute, INdT >>> Phone +55 81 8895 6002 / E-mail kenneth.christiansen at openbossa.org >>> _______________________________________________ >>> webkit-dev mailing list >>> webkit-dev at lists.webkit.org >>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >>> >> >> _______________________________________________ >> webkit-dev mailing list >> webkit-dev at lists.webkit.org >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >> >> >> >> _______________________________________________ >> webkit-dev mailing list >> webkit-dev at lists.webkit.org >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From abarth at webkit.org Thu Nov 12 15:48:03 2009 From: abarth at webkit.org (Adam Barth) Date: Thu, 12 Nov 2009 15:48:03 -0800 Subject: [webkit-dev] A bot-filled future? In-Reply-To: <78dc8440911121538v1355bb33p4ff755a94a70e9d@mail.gmail.com> References: <7789133a0911121137l35bc1485w511d73e59544d4d1@mail.gmail.com> <927d01d20911121143k1508d345r17df9f8a77dc5635@mail.gmail.com> <5dd9e5c50911121241r53ffabf1t44b20f7c110539ae@mail.gmail.com> <78dc8440911121538v1355bb33p4ff755a94a70e9d@mail.gmail.com> Message-ID: <7789133a0911121548x6e3f4efaw7830879214f42728@mail.gmail.com> I agree that this design doesn't solve the problem of writing patches more efficiently. That's not the goal. The goal is to reduce review latency by automating the mechanical parts of the review process. Adam On Thu, Nov 12, 2009 at 3:38 PM, Ojan Vafai wrote: > This approach doesn't lend itself as well to trying patches before putting > them up for review. Specifically, I want to be able to ?try patches without > spamming everyone with bugzilla mail. This is?solvable in this > bugzilla-based approach,?but it doesn't lend itself to this as > naturally,?e.g. presumably there's a way to tell bugzilla not to send mail > for a given comment. > > Also, it would be great if the commit-queue, try-server, whatever, had a UI > like the buildbot waterfall. There's a couple advantages: > 1. Can see the stdio as the tests run and get better information about why > it failed. > 2.?Can grab layout test results from the try servers. This would reduce the > need/occurence of committing Mac expectations and then cleaning up other > platforms post commit. > Ojan From aroben at apple.com Thu Nov 12 15:48:23 2009 From: aroben at apple.com (Adam Roben) Date: Thu, 12 Nov 2009 18:48:23 -0500 Subject: [webkit-dev] A bot-filled future? In-Reply-To: <78dc8440911121538v1355bb33p4ff755a94a70e9d@mail.gmail.com> References: <7789133a0911121137l35bc1485w511d73e59544d4d1@mail.gmail.com> <927d01d20911121143k1508d345r17df9f8a77dc5635@mail.gmail.com> <5dd9e5c50911121241r53ffabf1t44b20f7c110539ae@mail.gmail.com> <78dc8440911121538v1355bb33p4ff755a94a70e9d@mail.gmail.com> Message-ID: <104CF323-C84A-4F54-94FB-AF7B14BD3F8A@apple.com> On Nov 12, 2009, at 6:38 PM, Ojan Vafai wrote: > 2. Can grab layout test results from the try servers. This would reduce the need/occurence of committing Mac expectations and then cleaning up other platforms post commit. Without being able to see the loaded page on that platform, how do you know if the results are correct? (If you're able to verify the results just based on the test output, maybe the test should be cross-platform!) -Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric at webkit.org Thu Nov 12 15:51:57 2009 From: eric at webkit.org (Eric Seidel) Date: Thu, 12 Nov 2009 15:51:57 -0800 Subject: [webkit-dev] A bot-filled future? In-Reply-To: <1448d9f30911121551r3a44eb73r9fd617b71a3fb9a9@mail.gmail.com> References: <7789133a0911121137l35bc1485w511d73e59544d4d1@mail.gmail.com> <927d01d20911121143k1508d345r17df9f8a77dc5635@mail.gmail.com> <5dd9e5c50911121241r53ffabf1t44b20f7c110539ae@mail.gmail.com> <78dc8440911121538v1355bb33p4ff755a94a70e9d@mail.gmail.com> <104CF323-C84A-4F54-94FB-AF7B14BD3F8A@apple.com> <1448d9f30911121551r3a44eb73r9fd617b71a3fb9a9@mail.gmail.com> Message-ID: <1448d9f30911121551j1c53dd86nfb4df282368792e9@mail.gmail.com> On Thu, Nov 12, 2009 at 3:51 PM, Eric Seidel wrote: > I think Ojan is used to Chromium's world where there is a layout-test > rebaseling tool which knows how to suck expected results off of the > chromium try-bots, including new pixel test results. ?So he (and > others) are used to posting their patch for try and then getting back > the new results for all the platforms. ?You can "see" how a page looks > on that platform by looking at the pixel tests for that platform which > come back to you from the rebaselining tool/try-bots. > > As abarth mentioned, a very nice-to-have, but not part of his initial > stated goal. > > -eric > > On Thu, Nov 12, 2009 at 3:48 PM, Adam Roben wrote: >> On Nov 12, 2009, at 6:38 PM, Ojan Vafai wrote: >> >> 2.?Can grab layout test results from the try servers. This would reduce the >> need/occurence of committing Mac expectations and then cleaning up other >> platforms post commit. >> >> Without being able to see the loaded page on that platform, how do you know >> if the results are correct? >> (If you're able to verify the results just based on the test output, maybe >> the test should be cross-platform!) >> -Adam >> >> >> _______________________________________________ >> webkit-dev mailing list >> webkit-dev at lists.webkit.org >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >> >> > From ojan at chromium.org Thu Nov 12 15:59:44 2009 From: ojan at chromium.org (Ojan Vafai) Date: Thu, 12 Nov 2009 15:59:44 -0800 Subject: [webkit-dev] A bot-filled future? In-Reply-To: <104CF323-C84A-4F54-94FB-AF7B14BD3F8A@apple.com> References: <7789133a0911121137l35bc1485w511d73e59544d4d1@mail.gmail.com> <927d01d20911121143k1508d345r17df9f8a77dc5635@mail.gmail.com> <5dd9e5c50911121241r53ffabf1t44b20f7c110539ae@mail.gmail.com> <78dc8440911121538v1355bb33p4ff755a94a70e9d@mail.gmail.com> <104CF323-C84A-4F54-94FB-AF7B14BD3F8A@apple.com> Message-ID: <78dc8440911121559i21bf0c13k1a504b15b121d133@mail.gmail.com> To clarify, I think abarth's proposal is great and we shouldn't block it on other things a try-server could provide. Would just be nice to keep the "make writing patches more efficient" use-case in mind as we add other infrastructure to avoid needing, for example, a whole different set of servers for that. On Thu, Nov 12, 2009 at 3:48 PM, Adam Roben wrote: > On Nov 12, 2009, at 6:38 PM, Ojan Vafai wrote: > > 2. Can grab layout test results from the try servers. This would reduce the > need/occurence of committing Mac expectations and then cleaning up other > platforms post commit. > > Without being able to see the loaded page on that platform, how do you know > if the results are correct? > > (If you're able to verify the results just based on the test output, maybe > the test should be cross-platform!) > This entirely depends on the change you're making. For example, with a change that makes buttons 1px wider it's easy to verify from the layout test diff that the new results are correct. It's also easy to spot tests with "FAIL" or "PASS" in the output. :) Ojan -------------- next part -------------- An HTML attachment was scrubbed... URL: From rolandsteiner at google.com Thu Nov 12 18:37:28 2009 From: rolandsteiner at google.com (Roland Steiner) Date: Fri, 13 Nov 2009 11:37:28 +0900 Subject: [webkit-dev] ruby annotation layout tests In-Reply-To: <200911120220.20321.zecke@selfish.org> References: <4AF808C6.6050302@stud.u-szeged.hu> <8046E31F-8492-49D6-893E-9AC0680A921E@apple.com> <200911120220.20321.zecke@selfish.org> Message-ID: Hm, interesting - I have to admit I just now saw that most (all?) test that use non-English text are marked as Skipped for Windows (i.e., are in LayoutTests/platform/win/Skipped). Now, if there is a fundamental reason why such tests can't just be re-baselined (rendering incompatibilities between Windows versions perhaps?), then changing the tests in fast/ruby to simply use English text may well be the more prudent solution after all. Cheers, Roland -------------- next part -------------- An HTML attachment was scrubbed... URL: From aroben at apple.com Thu Nov 12 20:20:29 2009 From: aroben at apple.com (Adam Roben) Date: Thu, 12 Nov 2009 23:20:29 -0500 Subject: [webkit-dev] A bot-filled future? In-Reply-To: <78dc8440911121559i21bf0c13k1a504b15b121d133@mail.gmail.com> References: <7789133a0911121137l35bc1485w511d73e59544d4d1@mail.gmail.com> <927d01d20911121143k1508d345r17df9f8a77dc5635@mail.gmail.com> <5dd9e5c50911121241r53ffabf1t44b20f7c110539ae@mail.gmail.com> <78dc8440911121538v1355bb33p4ff755a94a70e9d@mail.gmail.com> <104CF323-C84A-4F54-94FB-AF7B14BD3F8A@apple.com> <78dc8440911121559i21bf0c13k1a504b15b121d133@mail.gmail.com> Message-ID: On Nov 12, 2009, at 6:59 PM, Ojan Vafai wrote: > On Thu, Nov 12, 2009 at 3:48 PM, Adam Roben wrote: > On Nov 12, 2009, at 6:38 PM, Ojan Vafai wrote: >> 2. Can grab layout test results from the try servers. This would reduce the need/occurence of committing Mac expectations and then cleaning up other platforms post commit. > > Without being able to see the loaded page on that platform, how do you know if the results are correct? > > (If you're able to verify the results just based on the test output, maybe the test should be cross-platform!) > > This entirely depends on the change you're making. For example, with a change that makes buttons 1px wider it's easy to verify from the layout test diff that the new results are correct. That's true. > It's also easy to spot tests with "FAIL" or "PASS" in the output. :) I'd hope that those tests would have cross-platform results, since clearly the condition is testable without having access to a full render tree dump. -Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpranke at chromium.org Thu Nov 12 21:00:52 2009 From: dpranke at chromium.org (Dirk Pranke) Date: Thu, 12 Nov 2009 21:00:52 -0800 Subject: [webkit-dev] ruby annotation layout tests In-Reply-To: References: <4AF808C6.6050302@stud.u-szeged.hu> <8046E31F-8492-49D6-893E-9AC0680A921E@apple.com> <200911120220.20321.zecke@selfish.org> Message-ID: <3726d1bf0911122100u5677e50chf9b28d9ccbaa7d2d@mail.gmail.com> FWIW, Chromium has version-specific diffs between XP and Vista/Win-7. I don't remember off-hand how bad the diffs where, but comparing the files in: http://src.chromium.org/viewvc/chrome/trunk/src/webkit/data/layout_tests/platform/chromium-win/LayoutTests/fast/ruby http://src.chromium.org/viewvc/chrome/trunk/src/webkit/data/layout_tests/platform/chromium-win-xp/LayoutTests/fast/ruby will show you. It wouldn't surprise me to see minor pixel diffs between the two, most of the east-asian script tests have them. -- Dirk On Thu, Nov 12, 2009 at 6:37 PM, Roland Steiner wrote: > Hm, interesting - I have to admit I just now saw that most (all?) test that > use non-English text are marked as Skipped for Windows (i.e., are in > LayoutTests/platform/win/Skipped). Now, if there is a fundamental reason why > such tests can't just be re-baselined (rendering incompatibilities between > Windows versions perhaps?), then changing the tests in fast/ruby to simply > use English text may well be the more prudent solution after all. > Cheers, > Roland > _______________________________________________ > webkit-dev mailing list > webkit-dev at lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > From ap at webkit.org Fri Nov 13 10:03:29 2009 From: ap at webkit.org (Alexey Proskuryakov) Date: Fri, 13 Nov 2009 10:03:29 -0800 Subject: [webkit-dev] Staging WebSocket protocol deployment Message-ID: <20FACD6D-03FC-4FA8-8350-1445B2E482F3@webkit.org> While WebSocket API is fairly stable, the discussion of underlying protocol at IETF is far from being done. It could be disruptive to ship our WebSocket implementation in a way that would effectively freeze the protocol. One way to achieve future compatibility is by using a different scheme for WebSocket URLs - e.g. "webkit-ws:" and "webkit-wss:" instead of "ws:" and "wss:", respectively. Depending on how protocol standardization goes, we could alias these later, or add a separate standards compliant implementation. I'm going to submit a patch to this effect, but would like to discuss the idea on the list first. - WBR, Alexey Proskuryakov From eric.carlson at apple.com Fri Nov 13 10:13:37 2009 From: eric.carlson at apple.com (Eric Carlson) Date: Fri, 13 Nov 2009 10:13:37 -0800 Subject: [webkit-dev] A bot-filled future? In-Reply-To: References: <7789133a0911121137l35bc1485w511d73e59544d4d1@mail.gmail.com> <927d01d20911121143k1508d345r17df9f8a77dc5635@mail.gmail.com> <5dd9e5c50911121241r53ffabf1t44b20f7c110539ae@mail.gmail.com> <78dc8440911121538v1355bb33p4ff755a94a70e9d@mail.gmail.com> <104CF323-C84A-4F54-94FB-AF7B14BD3F8A@apple.com> <78dc8440911121559i21bf0c13k1a504b15b121d133@mail.gmail.com> Message-ID: <857929D4-1A98-4143-B95D-B2DC93BE4E70@apple.com> On Nov 12, 2009, at 8:20 PM, Adam Roben wrote: > On Nov 12, 2009, at 6:59 PM, Ojan Vafai wrote: > >> It's also easy to spot tests with "FAIL" or "PASS" in the output. :) > > I'd hope that those tests would have cross-platform results, since > clearly the condition is testable without having access to a full > render tree dump. > Creating and maintaing cross-platform results is a real challenge in some cases. With HTMLMediaElement tests, for example, we have to deal with the fact that different ports uses different backend media engines and not all ports support support the same file formats and codecs. This means it can be impossible to predict results without actually running a tests in each port. Having a try server would be quite helpful for these types of tests. eric From jorlow at chromium.org Fri Nov 13 10:46:47 2009 From: jorlow at chromium.org (Jeremy Orlow) Date: Fri, 13 Nov 2009 10:46:47 -0800 Subject: [webkit-dev] Staging WebSocket protocol deployment In-Reply-To: <20FACD6D-03FC-4FA8-8350-1445B2E482F3@webkit.org> References: <20FACD6D-03FC-4FA8-8350-1445B2E482F3@webkit.org> Message-ID: <5dd9e5c50911131046m29098ea9m5ba1897b41314b74@mail.gmail.com> *cc'ing others involved in WebSockets (server and client side) I'm not very familiar with the IETF's efforts, but my understanding is that they were creating a competing protocol. Are they in fact creating something that they want to submit as a replacement to WebSockets? If so, why is WebSockets moving to last call? I'm not necessarily against this change, just confused by it. * On Fri, Nov 13, 2009 at 10:03 AM, Alexey Proskuryakov wrote: > > While WebSocket API is fairly stable, the discussion of underlying protocol > at IETF is far from being done. It could be disruptive to ship our WebSocket > implementation in a way that would effectively freeze the protocol. > > One way to achieve future compatibility is by using a different scheme for > WebSocket URLs - e.g. "webkit-ws:" and "webkit-wss:" instead of "ws:" and > "wss:", respectively. Depending on how protocol standardization goes, we > could alias these later, or add a separate standards compliant > implementation. > > I'm going to submit a patch to this effect, but would like to discuss the > idea on the list first. > > - WBR, Alexey Proskuryakov > > _______________________________________________ > webkit-dev mailing list > webkit-dev at lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From levin at chromium.org Fri Nov 13 11:14:34 2009 From: levin at chromium.org (David Levin) Date: Fri, 13 Nov 2009 11:14:34 -0800 Subject: [webkit-dev] Staging WebSocket protocol deployment In-Reply-To: <5dd9e5c50911131046m29098ea9m5ba1897b41314b74@mail.gmail.com> References: <20FACD6D-03FC-4FA8-8350-1445B2E482F3@webkit.org> <5dd9e5c50911131046m29098ea9m5ba1897b41314b74@mail.gmail.com> Message-ID: There is the browser side: http://www.w3.org/TR/2009/WD-websockets-20091029/ In that spec, it says This specification is being developed in conjunction with an Internet Draft for a wire protocol, the Web Socket Protocol, available from the IETF at the following location: - WebSocket Protocol Internet-Draft: http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol On Fri, Nov 13, 2009 at 10:46 AM, Jeremy Orlow wrote: > *cc'ing others involved in WebSockets (server and client side) > > I'm not very familiar with the IETF's efforts, but my understanding is that > they were creating a competing protocol. Are they in fact creating > something that they want to submit as a replacement to WebSockets? If so, > why is WebSockets moving to last call? > > I'm not necessarily against this change, just confused by it. > * > > On Fri, Nov 13, 2009 at 10:03 AM, Alexey Proskuryakov wrote: > >> >> While WebSocket API is fairly stable, the discussion of underlying >> protocol at IETF is far from being done. It could be disruptive to ship our >> WebSocket implementation in a way that would effectively freeze the >> protocol. >> >> One way to achieve future compatibility is by using a different scheme for >> WebSocket URLs - e.g. "webkit-ws:" and "webkit-wss:" instead of "ws:" and >> "wss:", respectively. Depending on how protocol standardization goes, we >> could alias these later, or add a separate standards compliant >> implementation. >> >> I'm going to submit a patch to this effect, but would like to discuss the >> idea on the list first. >> >> - WBR, Alexey Proskuryakov >> >> _______________________________________________ >> webkit-dev mailing list >> webkit-dev at lists.webkit.org >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >> > > > _______________________________________________ > webkit-dev mailing list > webkit-dev at lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yong.li.webkit at gmail.com Fri Nov 13 11:45:47 2009 From: yong.li.webkit at gmail.com (Yong Li) Date: Fri, 13 Nov 2009 14:45:47 -0500 Subject: [webkit-dev] String 4-byte alignment issue Message-ID: <774ecda50911131145o579cb686p36adecc5d0ebe09b@mail.gmail.com> Hi, Please take a look at bug 31475 https://bugs.webkit.org/show_bug.cgi?id=31475 There're 2 ways to fix this: 1. let StringImpl::create(UString...) create new copy if UString::data() is not aligned to 4 bytes. 2. remove dependencies on 4-byte aligment of String::characters(), probably just with #ifdef... Which one is better solution? -Yong -------------- next part -------------- An HTML attachment was scrubbed... URL: From jorlow at chromium.org Fri Nov 13 11:51:37 2009 From: jorlow at chromium.org (Jeremy Orlow) Date: Fri, 13 Nov 2009 11:51:37 -0800 Subject: [webkit-dev] Staging WebSocket protocol deployment In-Reply-To: References: <20FACD6D-03FC-4FA8-8350-1445B2E482F3@webkit.org> <5dd9e5c50911131046m29098ea9m5ba1897b41314b74@mail.gmail.com> Message-ID: <5dd9e5c50911131151s3e46f7bfm164ee571416a514f@mail.gmail.com> Oops...I missed that. SGTM then. On Fri, Nov 13, 2009 at 11:14 AM, David Levin wrote: > There is the browser side: > http://www.w3.org/TR/2009/WD-websockets-20091029/ > > In that spec, it says > > This specification is being developed in conjunction with an Internet > Draft for a wire protocol, the Web Socket Protocol, available from the IETF > at the following location: > > > - WebSocket Protocol Internet-Draft: > http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol > > > > On Fri, Nov 13, 2009 at 10:46 AM, Jeremy Orlow wrote: > >> *cc'ing others involved in WebSockets (server and client side) >> >> I'm not very familiar with the IETF's efforts, but my understanding is >> that they were creating a competing protocol. Are they in fact creating >> something that they want to submit as a replacement to WebSockets? If so, >> why is WebSockets moving to last call? >> >> I'm not necessarily against this change, just confused by it. >> * >> >> On Fri, Nov 13, 2009 at 10:03 AM, Alexey Proskuryakov wrote: >> >>> >>> While WebSocket API is fairly stable, the discussion of underlying >>> protocol at IETF is far from being done. It could be disruptive to ship our >>> WebSocket implementation in a way that would effectively freeze the >>> protocol. >>> >>> One way to achieve future compatibility is by using a different scheme >>> for WebSocket URLs - e.g. "webkit-ws:" and "webkit-wss:" instead of "ws:" >>> and "wss:", respectively. Depending on how protocol standardization goes, we >>> could alias these later, or add a separate standards compliant >>> implementation. >>> >>> I'm going to submit a patch to this effect, but would like to discuss the >>> idea on the list first. >>> >>> - WBR, Alexey Proskuryakov >>> >>> _______________________________________________ >>> webkit-dev mailing list >>> webkit-dev at lists.webkit.org >>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >>> >> >> >> _______________________________________________ >> webkit-dev mailing list >> webkit-dev at lists.webkit.org >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ojan at chromium.org Fri Nov 13 11:58:46 2009 From: ojan at chromium.org (Ojan Vafai) Date: Fri, 13 Nov 2009 11:58:46 -0800 Subject: [webkit-dev] Staging WebSocket protocol deployment In-Reply-To: <78dc8440911131147n47256758i60d968e78cb4043@mail.gmail.com> References: <20FACD6D-03FC-4FA8-8350-1445B2E482F3@webkit.org> <5dd9e5c50911131046m29098ea9m5ba1897b41314b74@mail.gmail.com> <78dc8440911131147n47256758i60d968e78cb4043@mail.gmail.com> Message-ID: <78dc8440911131158k60b97e48qeaa3914716bba81b@mail.gmail.com> > > This is a great idea. It would be a shame to put this out there and be stuck with a crippling set of design decisions as happened with LocalStorage. In practice, using WebSockets is a big enough change for web developers that adding the webkit- is nothing more than a minor inconvenience (if that) for early adopters. > Ojan On Fri, Nov 13, 2009 at 11:14 AM, David Levin wrote: > >> There is the browser side: >> http://www.w3.org/TR/2009/WD-websockets-20091029/ >> >> In that spec, it says >> >> This specification is being developed in conjunction with an Internet >> Draft for a wire protocol, the Web Socket Protocol, available from the IETF >> at the following location: >> >> >> - WebSocket Protocol Internet-Draft: >> http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol >> >> >> >> On Fri, Nov 13, 2009 at 10:46 AM, Jeremy Orlow wrote: >> >>> *cc'ing others involved in WebSockets (server and client side) >>> >>> I'm not very familiar with the IETF's efforts, but my understanding is >>> that they were creating a competing protocol. Are they in fact creating >>> something that they want to submit as a replacement to WebSockets? If so, >>> why is WebSockets moving to last call? >>> >>> I'm not necessarily against this change, just confused by it. >>> * >>> >>> On Fri, Nov 13, 2009 at 10:03 AM, Alexey Proskuryakov wrote: >>> >>>> >>>> While WebSocket API is fairly stable, the discussion of underlying >>>> protocol at IETF is far from being done. It could be disruptive to ship our >>>> WebSocket implementation in a way that would effectively freeze the >>>> protocol. >>>> >>>> One way to achieve future compatibility is by using a different scheme >>>> for WebSocket URLs - e.g. "webkit-ws:" and "webkit-wss:" instead of "ws:" >>>> and "wss:", respectively. Depending on how protocol standardization goes, we >>>> could alias these later, or add a separate standards compliant >>>> implementation. >>>> >>>> I'm going to submit a patch to this effect, but would like to discuss >>>> the idea on the list first. >>>> >>>> - WBR, Alexey Proskuryakov >>>> >>>> _______________________________________________ >>>> webkit-dev mailing list >>>> webkit-dev at lists.webkit.org >>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >>>> >>> >>> >>> _______________________________________________ >>> webkit-dev mailing list >>> webkit-dev at lists.webkit.org >>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >>> >>> >> >> _______________________________________________ >> webkit-dev mailing list >> webkit-dev at lists.webkit.org >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ap at webkit.org Fri Nov 13 12:34:07 2009 From: ap at webkit.org (Alexey Proskuryakov) Date: Fri, 13 Nov 2009 12:34:07 -0800 Subject: [webkit-dev] [webkit-changes] [50959] trunk/WebKitTools In-Reply-To: <20091113200427.E4B943226EAD@beta.macosforge.org> References: <20091113200427.E4B943226EAD@beta.macosforge.org> Message-ID: I'm not sure if this is a great approach. Previously, people with other default locales exercised code paths that aren't normally taken on U.S. systems, and thus could catch problems affecting shipping products early. It is beneficial that DRT results get more predictable, but tests are most useful when they fail, not when they pass :) - WBR, Alexey Proskuryakov 13.11.2009, ? 12:04, kenneth at webkit.org ???????(?): > Revision > 50959 > Author > kenneth at webkit.org > Date > 2009-11-13 12:04:24 -0800 (Fri, 13 Nov 2009) > Log Message > > Set the locale to C and not to the current one in use on the system. > > Reviewed by Simon Hausmann. > > * DumpRenderTree/qt/DumpRenderTree.cpp: > (WebCore::DumpRenderTree::resetToConsistentStateBeforeTesting): > Modified Paths > > trunk/WebKitTools/ChangeLog > trunk/WebKitTools/DumpRenderTree/qt/DumpRenderTree.cpp > Diff > > Modified: trunk/WebKitTools/ChangeLog (50958 => 50959) > > --- trunk/WebKitTools/ChangeLog 2009-11-13 19:56:43 UTC (rev 50958) > +++ trunk/WebKitTools/ChangeLog 2009-11-13 20:04:24 UTC (rev 50959) > @@ -1,3 +1,12 @@ > +2009-11-13 Kenneth Rohde Christiansen > + > + Reviewed by Simon Hausmann. > + > + Set the locale to C and not to the current one in use on > the system. > + > + * DumpRenderTree/qt/DumpRenderTree.cpp: > + > (WebCore::DumpRenderTree::resetToConsistentStateBeforeTesting): > + > 2009-11-13 Adam Roben > > Finish replacing worldIDs with world objects > Modified: trunk/WebKitTools/DumpRenderTree/qt/DumpRenderTree.cpp > (50958 => 50959) > > --- trunk/WebKitTools/DumpRenderTree/qt/DumpRenderTree.cpp > 2009-11-13 19:56:43 UTC (rev 50958) > +++ trunk/WebKitTools/DumpRenderTree/qt/DumpRenderTree.cpp > 2009-11-13 20:04:24 UTC (rev 50959) > @@ -304,8 +304,8 @@ > > m_page->undoStack()->clear(); > > - QLocale qlocale; > - QLocale::setDefault(qlocale); > + QLocale::setDefault(QLocale::c()); > + setlocale(LC_ALL, ""); > } > > void DumpRenderTree::open(const QUrl& aurl) > _______________________________________________ > webkit-changes mailing list > webkit-changes at lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-changes -------------- next part -------------- An HTML attachment was scrubbed... URL: From kenneth.christiansen at openbossa.org Fri Nov 13 12:43:26 2009 From: kenneth.christiansen at openbossa.org (Kenneth Christiansen) Date: Fri, 13 Nov 2009 17:43:26 -0300 Subject: [webkit-dev] [webkit-changes] [50959] trunk/WebKitTools In-Reply-To: References: <20091113200427.E4B943226EAD@beta.macosforge.org> Message-ID: <927d01d20911131243q404e7665u856362398db21dcc@mail.gmail.com> FYI this in not just related to Qt, as at least both win and mac have similar code. Kenneth On Fri, Nov 13, 2009 at 5:34 PM, Alexey Proskuryakov wrote: > > I'm not sure if this is a great approach. Previously, people with other > default locales exercised code paths that aren't normally taken on U.S. > systems, and thus could catch problems affecting shipping products early. > > It is beneficial that DRT results get more predictable, but tests are most > useful when they fail, not when they pass :) > > - WBR, Alexey Proskuryakov > > 13.11.2009, ? 12:04, kenneth at webkit.org ???????(?): > > Revision50959 > Authorkenneth at webkit.orgDate2009-11-13 12:04:24 -0800 (Fri, 13 Nov 2009)Log > Message > > Set the locale to C and not to the current one in use on the system. > > Reviewed by Simon Hausmann. > > * DumpRenderTree/qt/DumpRenderTree.cpp: > (WebCore::DumpRenderTree::resetToConsistentStateBeforeTesting): > > Modified Paths > > - trunk/WebKitTools/ChangeLog<#124ef40dcff4f255_trunkWebKitToolsChangeLog> > - trunk/WebKitTools/DumpRenderTree/qt/DumpRenderTree.cpp<#124ef40dcff4f255_trunkWebKitToolsDumpRenderTreeqtDumpRenderTreecpp> > > Diff > Modified: trunk/WebKitTools/ChangeLog (50958 => 50959) > > --- trunk/WebKitTools/ChangeLog 2009-11-13 19:56:43 UTC (rev 50958) > +++ trunk/WebKitTools/ChangeLog 2009-11-13 20:04:24 UTC (rev 50959)@@ -1,3 +1,12 @@+2009-11-13 Kenneth Rohde Christiansen > + > + Reviewed by Simon Hausmann. > + > + Set the locale to C and not to the current one in use on the system. > + > + * DumpRenderTree/qt/DumpRenderTree.cpp: > + (WebCore::DumpRenderTree::resetToConsistentStateBeforeTesting): > + 2009-11-13 Adam Roben Finish replacing worldIDs with world objects > > Modified: trunk/WebKitTools/DumpRenderTree/qt/DumpRenderTree.cpp (50958 => > 50959) > > --- trunk/WebKitTools/DumpRenderTree/qt/DumpRenderTree.cpp 2009-11-13 19:56:43 UTC (rev 50958) > +++ trunk/WebKitTools/DumpRenderTree/qt/DumpRenderTree.cpp 2009-11-13 20:04:24 UTC (rev 50959)@@ -304,8 +304,8 @@ m_page->undoStack()->clear(); - QLocale qlocale; > - QLocale::setDefault(qlocale);+ QLocale::setDefault(QLocale::c()); > + setlocale(LC_ALL, ""); } void DumpRenderTree::open(const QUrl& aurl) > > _______________________________________________ > webkit-changes mailing list > webkit-changes at lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-changes > > > > > _______________________________________________ > webkit-dev mailing list > webkit-dev at lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > -- Kenneth Rohde Christiansen Technical Lead / Software Engineer Qt Labs Americas, Nokia Technology Institute, INdT Phone +55 81 8895 6002 / E-mail kenneth.christiansen at openbossa.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From ap at webkit.org Fri Nov 13 12:52:41 2009 From: ap at webkit.org (Alexey Proskuryakov) Date: Fri, 13 Nov 2009 12:52:41 -0800 Subject: [webkit-dev] [webkit-changes] [50959] trunk/WebKitTools In-Reply-To: <927d01d20911131243q404e7665u856362398db21dcc@mail.gmail.com> References: <20091113200427.E4B943226EAD@beta.macosforge.org> <927d01d20911131243q404e7665u856362398db21dcc@mail.gmail.com> Message-ID: <47351112-C117-4359-8423-2983E2552047@webkit.org> 13.11.2009, ? 12:43, Kenneth Christiansen ???????(?): > FYI this in not just related to Qt, as at least both win and mac > have similar code. On the Mac, setlocale is called with "" locale. I'm not quite sure what that is - man page says it "denotes the native environment". If it's resetting locale to original, then it's the behavior I'm lobbying for. - WBR, Alexey Proskuryakov From darin at apple.com Fri Nov 13 12:55:01 2009 From: darin at apple.com (Darin Adler) Date: Fri, 13 Nov 2009 12:55:01 -0800 Subject: [webkit-dev] String 4-byte alignment issue In-Reply-To: <774ecda50911131145o579cb686p36adecc5d0ebe09b@mail.gmail.com> References: <774ecda50911131145o579cb686p36adecc5d0ebe09b@mail.gmail.com> Message-ID: <9426EC3E-CABB-4C0E-927C-8225610E47BC@apple.com> On Nov 13, 2009, at 11:45 AM, Yong Li wrote: > There're 2 ways to fix this: > > 1. let StringImpl::create(UString...) create new copy if UString::data() is not aligned to 4 bytes. > > 2. remove dependencies on 4-byte aligment of String::characters(), probably just with #ifdef... > > Which one is better solution? I think (2) is better. Comments in the bug. -- Darin From eric at webkit.org Fri Nov 13 13:08:02 2009 From: eric at webkit.org (Eric Seidel) Date: Fri, 13 Nov 2009 13:08:02 -0800 Subject: [webkit-dev] Bad Crasher Regression, pre-50919 Message-ID: <1448d9f30911131308i1d99e8b8y280106d002ac28ff@mail.gmail.com> As of 17:20 on 11/12/09 our bots and the Commit Queue started crashing like mad men. The Commit Queue has crashed 11 times since 11/12, after not having crashed in over 2 weeks. :) There seems to have been some regression relating to JSC objects. I've filed bugs, split by which test is crashing, however they're probably all the same root cause: https://bugs.webkit.org/show_bug.cgi?id=31453 https://bugs.webkit.org/show_bug.cgi?id=31460 https://bugs.webkit.org/show_bug.cgi?id=31461 https://bugs.webkit.org/show_bug.cgi?id=31480 https://bugs.webkit.org/show_bug.cgi?id=31481 If anyone has any clue what could be causing this regression, I'm all ears. :) -eric From gyuyoung at gmail.com Wed Nov 11 06:16:43 2009 From: gyuyoung at gmail.com (Gyuyoung Kim) Date: Wed, 11 Nov 2009 23:16:43 +0900 Subject: [webkit-dev] A question related to memory usage of webkit engine Message-ID: Hello, I have a quesition about memory usage of webkit. When I run GtkLauncher, the GtkLauncher goes to the www.google.com. The memory usage of GtkLauncher is about 22MB measured by top command. Then, GtkLaucher's memory usage becomes larger by about 50MB when GtkLauncher goes to the heavy websites, for example, nytimes.com, cnn.com, abc.com and so on. However, when GtkLauncher goes back to the google.com, the GtkLauncher's memory usage is still around 50MB. it seems to me GtkLauncher just returns a little memory to system. I would like to know why webkit engine doesn't return heap memory to system when go back to the simple website(google). In mobile environment, I think this situation can be a problem. I suspected that FastMalloc stores memory blocks. But, even though FastMalloc is disabled, memory usage of webkit engine is same situation as FastMalloc is enabled. Or, does webkit engine store webpages? (page cache?) Does anyone know the reason? Please let me know. Thanks, Gyuyoung Kim -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric at webkit.org Fri Nov 13 14:02:52 2009 From: eric at webkit.org (Eric Seidel) Date: Fri, 13 Nov 2009 14:02:52 -0800 Subject: [webkit-dev] Bad Crasher Regression, pre-50919 In-Reply-To: <1448d9f30911131308i1d99e8b8y280106d002ac28ff@mail.gmail.com> References: <1448d9f30911131308i1d99e8b8y280106d002ac28ff@mail.gmail.com> Message-ID: <1448d9f30911131402i27e13196l225de22070a2cb5f@mail.gmail.com> Since these all look like the same bug, I'm just going to make: https://bugs.webkit.org/show_bug.cgi?id=31461 be the master bug, and dupe the rest to it. On Fri, Nov 13, 2009 at 1:08 PM, Eric Seidel wrote: > As of 17:20 on 11/12/09 our bots and the Commit Queue started crashing > like mad men. > > The Commit Queue has crashed 11 times since 11/12, after not having > crashed in over 2 weeks. :) > > > There seems to have been some regression relating to JSC objects. > > I've filed bugs, split by which test is crashing, however they're > probably all the same root cause: > https://bugs.webkit.org/show_bug.cgi?id=31453 > https://bugs.webkit.org/show_bug.cgi?id=31460 > https://bugs.webkit.org/show_bug.cgi?id=31461 > https://bugs.webkit.org/show_bug.cgi?id=31480 > https://bugs.webkit.org/show_bug.cgi?id=31481 > > If anyone has any clue what could be causing this regression, I'm all ears. :) > > -eric > From ian at hixie.ch Fri Nov 13 15:01:19 2009 From: ian at hixie.ch (Ian Hickson) Date: Fri, 13 Nov 2009 23:01:19 +0000 (UTC) Subject: [webkit-dev] Staging WebSocket protocol deployment In-Reply-To: <5dd9e5c50911131046m29098ea9m5ba1897b41314b74@mail.gmail.com> References: <20FACD6D-03FC-4FA8-8350-1445B2E482F3@webkit.org> <5dd9e5c50911131046m29098ea9m5ba1897b41314b74@mail.gmail.com> Message-ID: On Fri, 13 Nov 2009, Jeremy Orlow wrote: > > I'm not very familiar with the IETF's efforts, but my understanding is > that they were creating a competing protocol. Are they in fact creating > something that they want to submit as a replacement to WebSockets? If > so, why is WebSockets moving to last call? The IETF is just a bunch of open mailing lists, there's no "they" that doesn't include us. The WebSocket protocol is pretty stable at this point. I doubt it will change much. The recent IETF meeting indicated that most people agree that we want something like WebSockets, and it has already received several years of public review. I wouldn't worry about changing the schemes or anything like that; if the protocol _does_ change in non-backwards-compatible ways, then we'll just change the protocol to not step on this code. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From jorlow at chromium.org Fri Nov 13 15:49:12 2009 From: jorlow at chromium.org (Jeremy Orlow) Date: Fri, 13 Nov 2009 15:49:12 -0800 Subject: [webkit-dev] Staging WebSocket protocol deployment In-Reply-To: References: <20FACD6D-03FC-4FA8-8350-1445B2E482F3@webkit.org> <5dd9e5c50911131046m29098ea9m5ba1897b41314b74@mail.gmail.com> Message-ID: <5dd9e5c50911131549k79dd37a3p87bbec9dc4ca5559@mail.gmail.com> On Fri, Nov 13, 2009 at 3:01 PM, Ian Hickson wrote: > On Fri, 13 Nov 2009, Jeremy Orlow wrote: > > > > I'm not very familiar with the IETF's efforts, but my understanding is > > that they were creating a competing protocol. Are they in fact creating > > something that they want to submit as a replacement to WebSockets? If > > so, why is WebSockets moving to last call? > > The IETF is just a bunch of open mailing lists, there's no "they" that > doesn't include us. > Sorry I wasn't clear in my word choice. I'm actually on one of the lists, though I obviously don't follow it too closely. :-) The WebSocket protocol is pretty stable at this point. I doubt it will > change much. The recent IETF meeting indicated that most people agree that > we want something like WebSockets, and it has already received several > years of public review. > > I wouldn't worry about changing the schemes or anything like that; if the > protocol _does_ change in non-backwards-compatible ways, then we'll just > change the protocol to not step on this code. Just to be clear, you're saying that it's fairly unlikely that it's going to change in a backwards compatible way? I ask because there's not much time left to make such decisions before it goes into Chrome 4 without the "webkit-" prefix. And once that ship sails, there's not much of a point to adding it. J -------------- next part -------------- An HTML attachment was scrubbed... URL: From jorlow at chromium.org Fri Nov 13 15:58:12 2009 From: jorlow at chromium.org (Jeremy Orlow) Date: Fri, 13 Nov 2009 15:58:12 -0800 Subject: [webkit-dev] Staging WebSocket protocol deployment In-Reply-To: <5dd9e5c50911131549k79dd37a3p87bbec9dc4ca5559@mail.gmail.com> References: <20FACD6D-03FC-4FA8-8350-1445B2E482F3@webkit.org> <5dd9e5c50911131046m29098ea9m5ba1897b41314b74@mail.gmail.com> <5dd9e5c50911131549k79dd37a3p87bbec9dc4ca5559@mail.gmail.com> Message-ID: <5dd9e5c50911131558h4bca3aaam10ccb9671af61576@mail.gmail.com> On Fri, Nov 13, 2009 at 3:49 PM, Jeremy Orlow wrote: > On Fri, Nov 13, 2009 at 3:01 PM, Ian Hickson wrote: > >> On Fri, 13 Nov 2009, Jeremy Orlow wrote: >> > >> > I'm not very familiar with the IETF's efforts, but my understanding is >> > that they were creating a competing protocol. Are they in fact creating >> > something that they want to submit as a replacement to WebSockets? If >> > so, why is WebSockets moving to last call? >> >> The IETF is just a bunch of open mailing lists, there's no "they" that >> doesn't include us. >> > > Sorry I wasn't clear in my word choice. I'm actually on one of the lists, > though I obviously don't follow it too closely. :-) > > The WebSocket protocol is pretty stable at this point. I doubt it will >> change much. The recent IETF meeting indicated that most people agree that >> we want something like WebSockets, and it has already received several >> years of public review. >> >> I wouldn't worry about changing the schemes or anything like that; if the >> protocol _does_ change in non-backwards-compatible ways, then we'll just >> change the protocol to not step on this code. > > > Just to be clear, you're saying that it's fairly unlikely that it's going > to change in a backwards compatible way? > > I ask because there's not much time left to make such decisions before it > goes into Chrome 4 without the "webkit-" prefix. And once that ship sails, > there's not much of a point to adding it. > On the other hand, as Ojan pointed out, LocalStorage is a perfect example of an API that was thought to be good and stable that became a disaster. Maybe it is best to put it behind a prefix until we have a better understanding of the beast and some real world implementation experience of the complete stack (not just the part in the browser). +1 for AP's plan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From abarth at webkit.org Fri Nov 13 16:06:25 2009 From: abarth at webkit.org (Adam Barth) Date: Fri, 13 Nov 2009 16:06:25 -0800 Subject: [webkit-dev] Staging WebSocket protocol deployment In-Reply-To: <5dd9e5c50911131558h4bca3aaam10ccb9671af61576@mail.gmail.com> References: <20FACD6D-03FC-4FA8-8350-1445B2E482F3@webkit.org> <5dd9e5c50911131046m29098ea9m5ba1897b41314b74@mail.gmail.com> <5dd9e5c50911131549k79dd37a3p87bbec9dc4ca5559@mail.gmail.com> <5dd9e5c50911131558h4bca3aaam10ccb9671af61576@mail.gmail.com> Message-ID: <7789133a0911131606g1fda8a98yb8b95daa0eb6d87f@mail.gmail.com> On Fri, Nov 13, 2009 at 3:58 PM, Jeremy Orlow wrote: > +1 for AP's plan. There's nothing magical about ws and wss. We can change those names later if we change the protocol (just as easily as we can change webkit-ws). Adam From ojan at chromium.org Fri Nov 13 16:07:06 2009 From: ojan at chromium.org (Ojan Vafai) Date: Fri, 13 Nov 2009 16:07:06 -0800 Subject: [webkit-dev] Staging WebSocket protocol deployment In-Reply-To: References: <20FACD6D-03FC-4FA8-8350-1445B2E482F3@webkit.org> <5dd9e5c50911131046m29098ea9m5ba1897b41314b74@mail.gmail.com> Message-ID: <78dc8440911131607m1110e032j33fbd9afa979fdb7@mail.gmail.com> On Fri, Nov 13, 2009 at 3:01 PM, Ian Hickson wrote: > I wouldn't worry about changing the schemes or anything like that; if the > protocol _does_ change in non-backwards-compatible ways, then we'll just > change the protocol to not step on this code. What's the harm in prefixing the scheme for now? I see harm when we do this sort of thing for every minor feature, but supporting WebSockets isn't just a minor tweak to a web application. Ojan -------------- next part -------------- An HTML attachment was scrubbed... URL: From levin at google.com Fri Nov 13 16:01:25 2009 From: levin at google.com (David Levin) Date: Fri, 13 Nov 2009 16:01:25 -0800 Subject: [webkit-dev] Staging WebSocket protocol deployment In-Reply-To: <5dd9e5c50911131549k79dd37a3p87bbec9dc4ca5559@mail.gmail.com> References: <20FACD6D-03FC-4FA8-8350-1445B2E482F3@webkit.org> <5dd9e5c50911131046m29098ea9m5ba1897b41314b74@mail.gmail.com> <5dd9e5c50911131549k79dd37a3p87bbec9dc4ca5559@mail.gmail.com> Message-ID: On Fri, Nov 13, 2009 at 3:49 PM, Jeremy Orlow wrote: > On Fri, Nov 13, 2009 at 3:01 PM, Ian Hickson wrote: > >> On Fri, 13 Nov 2009, Jeremy Orlow wrote: >> > >> > I'm not very familiar with the IETF's efforts, but my understanding is >> > that they were creating a competing protocol. Are they in fact creating >> > something that they want to submit as a replacement to WebSockets? If >> > so, why is WebSockets moving to last call? >> >> The IETF is just a bunch of open mailing lists, there's no "they" that >> doesn't include us. >> > > Sorry I wasn't clear in my word choice. I'm actually on one of the lists, > though I obviously don't follow it too closely. :-) > > The WebSocket protocol is pretty stable at this point. I doubt it will >> change much. The recent IETF meeting indicated that most people agree that >> we want something like WebSockets, and it has already received several >> years of public review. >> >> I wouldn't worry about changing the schemes or anything like that; if the >> protocol _does_ change in non-backwards-compatible ways, then we'll just >> change the protocol to not step on this code. > > > Just to be clear, you're saying that it's fairly unlikely that it's going > to change in a backwards compatible way? > He's saying if the protocol changes to be incompatible, then it will no longer be ws:, wss: > > I ask because there's not much time left to make such decisions before it > goes into Chrome 4 without the "webkit-" prefix. And once that ship sails, > there's not much of a point to adding it. > > J > > _______________________________________________ > webkit-dev mailing list > webkit-dev at lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mjs at apple.com Fri Nov 13 17:00:10 2009 From: mjs at apple.com (Maciej Stachowiak) Date: Fri, 13 Nov 2009 17:00:10 -0800 Subject: [webkit-dev] Staging WebSocket protocol deployment In-Reply-To: <7789133a0911131606g1fda8a98yb8b95daa0eb6d87f@mail.gmail.com> References: <20FACD6D-03FC-4FA8-8350-1445B2E482F3@webkit.org> <5dd9e5c50911131046m29098ea9m5ba1897b41314b74@mail.gmail.com> <5dd9e5c50911131549k79dd37a3p87bbec9dc4ca5559@mail.gmail.com> <5dd9e5c50911131558h4bca3aaam10ccb9671af61576@mail.gmail.com> <7789133a0911131606g1fda8a98yb8b95daa0eb6d87f@mail.gmail.com> Message-ID: On Nov 13, 2009, at 4:06 PM, Adam Barth wrote: > On Fri, Nov 13, 2009 at 3:58 PM, Jeremy Orlow > wrote: >> +1 for AP's plan. > > There's nothing magical about ws and wss. We can change those names > later if we change the protocol (just as easily as we can change > webkit-ws). My impression from the IETF mailing list is as follows: (a) The IETF is likely to charter a Working Group to work on the WebSocket protocol. (b) It will specifically be more or less based on the WebSocket protocol as specified today. (c) There is a lack of consensus about some details (such as whether the baseline should support multiplexing, whether messages should always be length-prefixed and not sentinel-terminated, etc). I don't want to give the likely future IETF WG participants the impression that we're trying to lock in the protocol and pre-empt decisions on potential issues of controversy. I think we (the WebKit community) would really like the WebSocket protocol to succeed, but I don't think we care about some of the fine details enough to try to lock them down or pick a fight with the IETF. I will also add that there are times when rushing to ship features has turned out to be somewhat regrettable in the past. Thus I suggested that we should look into ways to avoid prematurely locking in the protocol. In particular, if the standard changes incompatibly relative to what we ship but there are already sites using the current protocol, I'd like it to be possible for WebKit to support both new-style and old-style sites. Here are some options: (1) For now, ship with webkit-prefixed versions of the URL schemes (if the protocol changes incompatibly, we can make the standard ones use something different; if it doesn't, we can just make it an alias.) This is basically Alexey's proposal. (2) Use the same URL scheme, but rely on some provision for versioning in the WebSocket protocol itself. I don't think there is anything suitable currently. In particular we would need to be able to negotiate the protocol version to use with the site, so both v1 and v2 sites would work. And I don't think there's time to add version negotiation to the spec and implement it before various vendor ship dates. (3) Use ws: or wss: for now, but plan to change the URL scheme in the standard if the protocol does change incompatibly. This assumes buy-in from the specifiers of the protocol I like (1) best, because it's totally future-proof and not presumptuous. I think Ian and Adam Barth are effectively suggesting (3), but I feel like it sends a bad message to assume the eventual IETF Working Group will work around our compatibility needs. Worse yet, they may choose not to do so. Either way, I'd like us to have a plan where we can show we are not trying to pre-empt decisions about the details of the protocol. Regards, Maciej -------------- next part -------------- An HTML attachment was scrubbed... URL: From jorlow at chromium.org Fri Nov 13 16:39:54 2009 From: jorlow at chromium.org (Jeremy Orlow) Date: Fri, 13 Nov 2009 16:39:54 -0800 Subject: [webkit-dev] Staging WebSocket protocol deployment In-Reply-To: References: <20FACD6D-03FC-4FA8-8350-1445B2E482F3@webkit.org> <5dd9e5c50911131046m29098ea9m5ba1897b41314b74@mail.gmail.com> <5dd9e5c50911131549k79dd37a3p87bbec9dc4ca5559@mail.gmail.com> Message-ID: <5dd9e5c50911131639k7b20b932u8fe0d730d545b6bd@mail.gmail.com> On Fri, Nov 13, 2009 at 4:01 PM, David Levin wrote: > > > On Fri, Nov 13, 2009 at 3:49 PM, Jeremy Orlow wrote: > >> On Fri, Nov 13, 2009 at 3:01 PM, Ian Hickson wrote: >> >>> On Fri, 13 Nov 2009, Jeremy Orlow wrote: >>> > >>> > I'm not very familiar with the IETF's efforts, but my understanding is >>> > that they were creating a competing protocol. Are they in fact >>> creating >>> > something that they want to submit as a replacement to WebSockets? If >>> > so, why is WebSockets moving to last call? >>> >>> The IETF is just a bunch of open mailing lists, there's no "they" that >>> doesn't include us. >>> >> >> Sorry I wasn't clear in my word choice. I'm actually on one of the lists, >> though I obviously don't follow it too closely. :-) >> >> The WebSocket protocol is pretty stable at this point. I doubt it will >>> change much. The recent IETF meeting indicated that most people agree >>> that >>> we want something like WebSockets, and it has already received several >>> years of public review. >>> >>> I wouldn't worry about changing the schemes or anything like that; if the >>> protocol _does_ change in non-backwards-compatible ways, then we'll just >>> change the protocol to not step on this code. >> >> >> Just to be clear, you're saying that it's fairly unlikely that it's going >> to change in a backwards compatible way? >> > > He's saying if the protocol changes to be incompatible, then it will no > longer be ws:, wss: > Yes, but once a browser ships ws/wss then we're stuck with that version of the protocol. If it starts to catch on, then browsers will need to implement it for a very long time to come. That's what happened with LocalStorage. By using webkit-ws/webkit-wss we're giving ourselves some wiggle-room until we're sure we're happy with the protocol. And I'm not convinced that we'll know whether we're happy until we have some data from real-world use of WebSockets. (Which should start coming in soon after Chrome 4 ships.) > I ask because there's not much time left to make such decisions before it >> goes into Chrome 4 without the "webkit-" prefix. And once that ship sails, >> there's not much of a point to adding it. >> >> J >> >> _______________________________________________ >> webkit-dev mailing list >> webkit-dev at lists.webkit.org >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ian at hixie.ch Fri Nov 13 17:43:20 2009 From: ian at hixie.ch (Ian Hickson) Date: Sat, 14 Nov 2009 01:43:20 +0000 (UTC) Subject: [webkit-dev] Staging WebSocket protocol deployment In-Reply-To: <5dd9e5c50911131639k7b20b932u8fe0d730d545b6bd@mail.gmail.com> References: <20FACD6D-03FC-4FA8-8350-1445B2E482F3@webkit.org> <5dd9e5c50911131046m29098ea9m5ba1897b41314b74@mail.gmail.com> <5dd9e5c50911131549k79dd37a3p87bbec9dc4ca5559@mail.gmail.com> <5dd9e5c50911131639k7b20b932u8fe0d730d545b6bd@mail.gmail.com> Message-ID: On Fri, 13 Nov 2009, Jeremy Orlow wrote: > > By using webkit-ws/webkit-wss we're giving ourselves some wiggle-room until > we're sure we're happy with the protocol. Not really. It just means that we might end up stuck with "webkit-ws:" instead of "ws:". -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From jorlow at chromium.org Fri Nov 13 17:45:43 2009 From: jorlow at chromium.org (Jeremy Orlow) Date: Fri, 13 Nov 2009 17:45:43 -0800 Subject: [webkit-dev] Staging WebSocket protocol deployment In-Reply-To: References: <20FACD6D-03FC-4FA8-8350-1445B2E482F3@webkit.org> <5dd9e5c50911131046m29098ea9m5ba1897b41314b74@mail.gmail.com> <5dd9e5c50911131549k79dd37a3p87bbec9dc4ca5559@mail.gmail.com> <5dd9e5c50911131639k7b20b932u8fe0d730d545b6bd@mail.gmail.com> Message-ID: <5dd9e5c50911131745g10b71199ldbea9a3ae1b3e76d@mail.gmail.com> I don't buy that at all. There's plenty of features with the webkit- prefix and I think it's pretty clear to developers what that means. On Fri, Nov 13, 2009 at 5:43 PM, Ian Hickson wrote: > On Fri, 13 Nov 2009, Jeremy Orlow wrote: > > > > By using webkit-ws/webkit-wss we're giving ourselves some wiggle-room > until > > we're sure we're happy with the protocol. > > Not really. It just means that we might end up stuck with "webkit-ws:" > instead of "ws:". > > -- > Ian Hickson U+1047E )\._.,--....,'``. fL > http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' > -------------- next part -------------- An HTML attachment was scrubbed... URL: From abarth at webkit.org Fri Nov 13 18:01:02 2009 From: abarth at webkit.org (Adam Barth) Date: Fri, 13 Nov 2009 18:01:02 -0800 Subject: [webkit-dev] Staging WebSocket protocol deployment In-Reply-To: References: <20FACD6D-03FC-4FA8-8350-1445B2E482F3@webkit.org> <5dd9e5c50911131046m29098ea9m5ba1897b41314b74@mail.gmail.com> <5dd9e5c50911131549k79dd37a3p87bbec9dc4ca5559@mail.gmail.com> <5dd9e5c50911131639k7b20b932u8fe0d730d545b6bd@mail.gmail.com> Message-ID: <7789133a0911131801g3627dbfcrfdec4d00feb940f4@mail.gmail.com> On Fri, Nov 13, 2009 at 5:43 PM, Ian Hickson wrote: > On Fri, 13 Nov 2009, Jeremy Orlow wrote: >> >> By using webkit-ws/webkit-wss we're giving ourselves some wiggle-room until >> we're sure we're happy with the protocol. > > Not really. It just means that we might end up stuck with "webkit-ws:" > instead of "ws:". Does the IETF WG have a timeline? My understanding is that IETF WG take at least a year to do anything. Even the timeline for the cookie WG is a year, and we're just speccing widely implemented behavior. I don't think we want to be stuck with webkit-ws forever. Another possibility is x-ws, implying that it's experimental. Honestly, if IETF going to break the protocol, they might as well use a new scheme, like websocket or hybi. This discussion reminds me of . Adam From eric at webkit.org Fri Nov 13 18:32:22 2009 From: eric at webkit.org (Eric Seidel) Date: Fri, 13 Nov 2009 18:32:22 -0800 Subject: [webkit-dev] Unexpected Outage: commit-queue Message-ID: <1448d9f30911131832q5c2b4d10vf98239dc0c9fc1d7@mail.gmail.com> I've turned off the commit-queue until we can find a solution to https://bugs.webkit.org/show_bug.cgi?id=31461. The commit-queue was rejecting more than half the patches queued in it due to that bug, rendering it useless. I'll post to webkit-dev once the queue is turned on again (hopefully Monday). -eric p.s. You can always check the status of the queue by loading http://webkit-commit-queue.appspot.com/ From ian at hixie.ch Sat Nov 14 16:39:35 2009 From: ian at hixie.ch (Ian Hickson) Date: Sun, 15 Nov 2009 00:39:35 +0000 (UTC) Subject: [webkit-dev] Staging WebSocket protocol deployment In-Reply-To: <5dd9e5c50911131745g10b71199ldbea9a3ae1b3e76d@mail.gmail.com> References: <20FACD6D-03FC-4FA8-8350-1445B2E482F3@webkit.org> <5dd9e5c50911131046m29098ea9m5ba1897b41314b74@mail.gmail.com> <5dd9e5c50911131549k79dd37a3p87bbec9dc4ca5559@mail.gmail.com> <5dd9e5c50911131639k7b20b932u8fe0d730d545b6bd@mail.gmail.com> <5dd9e5c50911131745g10b71199ldbea9a3ae1b3e76d@mail.gmail.com> Message-ID: On Fri, 13 Nov 2009, Jeremy Orlow wrote: > > I don't buy that at all. There's plenty of features with the webkit- > prefix and I think it's pretty clear to developers what that means. IMHO it makes no difference to authors if they have to use "webkit-ws:" or "ws:" -- either way, they might come to depend on it, and either way if other browsers want to be compatible with code written for us, they have to use the same value. The features where we have the webkit- prefix are CSS properties and values. There, there's no problem with each browser vendor doing their own extension, since you can list multiple properties. This doesn't apply to URLs like here. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Sat Nov 14 16:41:33 2009 From: ian at hixie.ch (Ian Hickson) Date: Sun, 15 Nov 2009 00:41:33 +0000 (UTC) Subject: [webkit-dev] Staging WebSocket protocol deployment In-Reply-To: <7789133a0911131801g3627dbfcrfdec4d00feb940f4@mail.gmail.com> References: <20FACD6D-03FC-4FA8-8350-1445B2E482F3@webkit.org> <5dd9e5c50911131046m29098ea9m5ba1897b41314b74@mail.gmail.com> <5dd9e5c50911131549k79dd37a3p87bbec9dc4ca5559@mail.gmail.com> <5dd9e5c50911131639k7b20b932u8fe0d730d545b6bd@mail.gmail.com> <7789133a0911131801g3627dbfcrfdec4d00feb940f4@mail.gmail.com> Message-ID: On Fri, 13 Nov 2009, Adam Barth wrote: > > Does the IETF WG have a timeline? The IETF WG doesn't event exist yet. > My understanding is that IETF WG take at least a year to do anything. They take as long as we (the community) let them take. As far as I'm concerned, the WebSocket feature is very mature. The IETF is late to this party; WebSocket has been under development since 2005. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From Peter.Blenessy at sonyericsson.com Sun Nov 15 11:19:13 2009 From: Peter.Blenessy at sonyericsson.com (=?iso-8859-1?Q?Bl=E9nessy=2C_P=E9ter?=) Date: Sun, 15 Nov 2009 20:19:13 +0100 Subject: [webkit-dev] help Message-ID: ----- Original Message ----- From:"webkit-dev-request at lists.webkit.org" To:"webkit-dev at lists.webkit.org" Sent:15/11/2009 16:00 Subject:webkit-dev Digest, Vol 54, Issue 16 Send webkit-dev mailing list submissions to webkit-dev at lists.webkit.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev or, via email, send a message with subject or body 'help' to webkit-dev-request at lists.webkit.org You can reach the person managing the list at webkit-dev-owner at lists.webkit.org When replying, please edit your Subject line so it is more specific than "Re: Contents of webkit-dev digest..." Today's Topics: 1. Re: Staging WebSocket protocol deployment (Ian Hickson) 2. Re: Staging WebSocket protocol deployment (Ian Hickson) ---------------------------------------------------------------------- Message: 1 Date: Sun, 15 Nov 2009 00:39:35 +0000 (UTC) From: Ian Hickson To: Jeremy Orlow Cc: Fumitoshi Ukai (????) , Alexey Proskuryakov , Noel Gordon , WebKit Development Subject: Re: [webkit-dev] Staging WebSocket protocol deployment Message-ID: Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 13 Nov 2009, Jeremy Orlow wrote: > > I don't buy that at all. There's plenty of features with the webkit- > prefix and I think it's pretty clear to developers what that means. IMHO it makes no difference to authors if they have to use "webkit-ws:" or "ws:" -- either way, they might come to depend on it, and either way if other browsers want to be compatible with code written for us, they have to use the same value. The features where we have the webkit- prefix are CSS properties and values. There, there's no problem with each browser vendor doing their own extension, since you can list multiple properties. This doesn't apply to URLs like here. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ------------------------------ Message: 2 Date: Sun, 15 Nov 2009 00:41:33 +0000 (UTC) From: Ian Hickson To: Adam Barth Cc: Fumitoshi Ukai (????) , Alexey Proskuryakov , Noel Gordon , WebKit Development Subject: Re: [webkit-dev] Staging WebSocket protocol deployment Message-ID: Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 13 Nov 2009, Adam Barth wrote: > > Does the IETF WG have a timeline? The IETF WG doesn't event exist yet. > My understanding is that IETF WG take at least a year to do anything. They take as long as we (the community) let them take. As far as I'm concerned, the WebSocket feature is very mature. The IETF is late to this party; WebSocket has been under development since 2005. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ------------------------------ _______________________________________________ webkit-dev mailing list webkit-dev at lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev End of webkit-dev Digest, Vol 54, Issue 16 ****************************************** From abarth at webkit.org Sun Nov 15 15:19:24 2009 From: abarth at webkit.org (Adam Barth) Date: Sun, 15 Nov 2009 15:19:24 -0800 Subject: [webkit-dev] Staging WebSocket protocol deployment In-Reply-To: <7789133a0911131801g3627dbfcrfdec4d00feb940f4@mail.gmail.com> References: <20FACD6D-03FC-4FA8-8350-1445B2E482F3@webkit.org> <5dd9e5c50911131046m29098ea9m5ba1897b41314b74@mail.gmail.com> <5dd9e5c50911131549k79dd37a3p87bbec9dc4ca5559@mail.gmail.com> <5dd9e5c50911131639k7b20b932u8fe0d730d545b6bd@mail.gmail.com> <7789133a0911131801g3627dbfcrfdec4d00feb940f4@mail.gmail.com> Message-ID: <7789133a0911151519y3d8fc1des53773430b9afd5f5@mail.gmail.com> On Fri, Nov 13, 2009 at 6:01 PM, Adam Barth wrote: > Does the IETF WG have a timeline? ?My understanding is that IETF WG > take at least a year to do anything. Here's the timeline for the HyBi WG: http://trac.tools.ietf.org/bof/trac/wiki/HyBi Goals and Milestones: --------------------- Mar-2010: WGLC on the Design Space characterization (Informational) May-2010: WGLC on Requirements document on Short term solution Jul-2010: WGLC on Requirements document on Long term solution Nov-2010: Requirements to IESG Mar-2011: WGLC on Short term solution improvements Nov-2011: WGLC on Long term solution protocol I read this as one year for requirements and another year for a protocol assuming the WG stays on schedule. Adam From yuzo at google.com Sun Nov 15 17:18:09 2009 From: yuzo at google.com (Yuzo Fujishima) Date: Mon, 16 Nov 2009 10:18:09 +0900 Subject: [webkit-dev] Staging WebSocket protocol deployment In-Reply-To: <7789133a0911151519y3d8fc1des53773430b9afd5f5@mail.gmail.com> References: <20FACD6D-03FC-4FA8-8350-1445B2E482F3@webkit.org> <5dd9e5c50911131046m29098ea9m5ba1897b41314b74@mail.gmail.com> <5dd9e5c50911131549k79dd37a3p87bbec9dc4ca5559@mail.gmail.com> <5dd9e5c50911131639k7b20b932u8fe0d730d545b6bd@mail.gmail.com> <7789133a0911131801g3627dbfcrfdec4d00feb940f4@mail.gmail.com> <7789133a0911151519y3d8fc1des53773430b9afd5f5@mail.gmail.com> Message-ID: <9124e09b0911151718u654a4deaoc5fbb863caf58c04@mail.gmail.com> Hi, I'm against prefixing with "webkit-" because of the following reasons. Reason 1: It connotes that the feature is experimental. That means there will be less developers seriously use that feature. Without serious use, we'll have less serious feedbacks from the real world. If the Web Socket has serious flaws, we should rather know them sooner than later. I'd say only serious uses can help us find the flaws faster. Reason 2: What should other browser vendors do? Should they use chrome-ws, firefox-ws, ie-ws, opera-ws, ..., etc? I believe at least developers will not happy with that. If the vendors need to reach the consensus on the common experimental name, say prelim-ws, then why not just use ws instead? Yuzo On Mon, Nov 16, 2009 at 8:19 AM, Adam Barth wrote: > On Fri, Nov 13, 2009 at 6:01 PM, Adam Barth wrote: > > Does the IETF WG have a timeline? My understanding is that IETF WG > > take at least a year to do anything. > Here's the timeline for the HyBi WG: > http://trac.tools.ietf.org/bof/trac/wiki/HyBi > Goals and Milestones: > --------------------- > Mar-2010: WGLC on the Design Space characterization (Informational) > May-2010: WGLC on Requirements document on Short term solution > Jul-2010: WGLC on Requirements document on Long term solution > Nov-2010: Requirements to IESG > Mar-2011: WGLC on Short term solution improvements > Nov-2011: WGLC on Long term solution protocol > I read this as one year for requirements and another year for a > protocol assuming the WG stays on schedule. > Adam > _______________________________________________ > webkit-dev mailing list > webkit-dev at lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From ian at hixie.ch Sun Nov 15 18:53:38 2009 From: ian at hixie.ch (Ian Hickson) Date: Mon, 16 Nov 2009 02:53:38 +0000 (UTC) Subject: [webkit-dev] Staging WebSocket protocol deployment In-Reply-To: <7789133a0911151519y3d8fc1des53773430b9afd5f5@mail.gmail.com> References: <20FACD6D-03FC-4FA8-8350-1445B2E482F3@webkit.org> <5dd9e5c50911131046m29098ea9m5ba1897b41314b74@mail.gmail.com> <5dd9e5c50911131549k79dd37a3p87bbec9dc4ca5559@mail.gmail.com> <5dd9e5c50911131639k7b20b932u8fe0d730d545b6bd@mail.gmail.com> <7789133a0911131801g3627dbfcrfdec4d00feb940f4@mail.gmail.com> <7789133a0911151519y3d8fc1des53773430b9afd5f5@mail.gmail.com> Message-ID: On Sun, 15 Nov 2009, Adam Barth wrote: > > On Fri, Nov 13, 2009 at 6:01 PM, Adam Barth wrote: > > Does the IETF WG have a timeline? ?My understanding is that IETF WG > > take at least a year to do anything. > > Here's the timeline for the HyBi WG: > > http://trac.tools.ietf.org/bof/trac/wiki/HyBi > > Goals and Milestones: > --------------------- > Mar-2010: WGLC on the Design Space characterization (Informational) > May-2010: WGLC on Requirements document on Short term solution > Jul-2010: WGLC on Requirements document on Long term solution > Nov-2010: Requirements to IESG > Mar-2011: WGLC on Short term solution improvements > Nov-2011: WGLC on Long term solution protocol > > I read this as one year for requirements and another year for a > protocol assuming the WG stays on schedule. Then I guess WebSockets will be a WHATWG spec. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From chris.jerdonek at gmail.com Sun Nov 15 21:57:48 2009 From: chris.jerdonek at gmail.com (Chris Jerdonek) Date: Sun, 15 Nov 2009 21:57:48 -0800 Subject: [webkit-dev] "using namespace" style guideline In-Reply-To: References: Message-ID: On Tue, Nov 10, 2009 at 8:30 PM, Darin Adler wrote: > No "using namespace" statements are permitted in header files. The guidelines are talking about non-header files. We should clarify that. Thanks for your later reply explaining the history behind the "using WTF::..." statements. It sounds reasonable. I have a couple more questions related to the rule above though. (For everyone else's benefit, this rule now appears on the web site). I found there to be seven files in WebKit that don't follow this rule, and I wanted to double-check whether there should be any exceptions to it. In particular, the following file uses "using namespace WTF::Unicode" five times, but within the bodies of various template definitions: http://trac.webkit.org/browser/trunk/WebCore/platform/text/BidiResolver.h (see line 304, for example) Is this also not okay? The following is another example. The using statement for this one appears at the beginning, outside of any definitions, but the file seems to be central: http://trac.webkit.org/browser/trunk/JavaScriptGlue/JSUtils.h It uses "using namespace JSC". My second question is whether the guideline above should apply, for the same reason, to all "using" statements within header files -- and not just to "using namespace" statements. Statements of the form "using WTF::..." would be exceptions. You've already discussed those here: https://lists.webkit.org/pipermail/webkit-dev/2009-November/010453.html I checked, and there are only about 40 files in all of WebKit that wouldn't currently be following this -- slightly less than half of which are in JSC. --Chris From gns at gnome.org Mon Nov 16 05:06:35 2009 From: gns at gnome.org (Gustavo Noronha Silva) Date: Mon, 16 Nov 2009 11:06:35 -0200 Subject: [webkit-dev] On the greeness of the GTK+ bot Message-ID: <1258376795.5592.37.camel@goiaba.horta> Hey, Keeping the GTK+ buildbot green has been a real challenge for many reasons, but looking back at previous discussions we had regarding this, I think we have come a long way. Over the last few weeks we (mainly Xan!) put some hard work on getting the bot green by fixing bugs, opening bug reports, and skipping tests. One of the issues we usually have lots of trouble with is patches regressing our tests that people do not notice. We have had some good experiences regarding this recently: a patch to modify how the media tests were run broke all our media tests for the third time since we stabilized them, but the change was backed out to be reworked. The second one was the work to get shadows support in cairo, which regressed 2 tests of ours. Because we were paying attention we were able to quickly spot them, and the people involved could fix them before their regressive nature was lost in time, and they ended up on the Skipped list. I would like to ask of people checking in changes that they try to pay as much attention to our release bot as they are paying to Mac bots. We will do our best to keep them green, but it gets very difficult to do it when people are checking in stuff that breaks our tests all the time, and not paying attention to them. In summary, I would like to see this kind of behavior applied to our bots as well: https://bugs.webkit.org/show_bug.cgi?id=29329 This "it can't remain like that; we need to either skip, check in a platform-specific result or back out the change" would help us a lot. Thanks! P.S. I think it is important to note there are a number of tests failing intermittently, mainly inspector ones, but that seems to be happening on all the bots, so bear with us there =). -- Gustavo Noronha Silva GNOME Project From abarth at webkit.org Mon Nov 16 05:24:22 2009 From: abarth at webkit.org (Adam Barth) Date: Mon, 16 Nov 2009 05:24:22 -0800 Subject: [webkit-dev] On the greeness of the GTK+ bot In-Reply-To: <1258376795.5592.37.camel@goiaba.horta> References: <1258376795.5592.37.camel@goiaba.horta> Message-ID: <7789133a0911160524r49132d08j9373c3873089535b@mail.gmail.com> Eric and I are working on a bot that might help this situation. Essentially, the bot will try out patches on Qt and GTK and add a comment to the bug if the patch regresses the build. Our plan is to start with compiling, but we'd eventually like to run the tests as well. Of course, the bots won't guarantee that folks won't break the GTK build, but at least they'll be breaking it with malice aforethought. Adam On Mon, Nov 16, 2009 at 5:06 AM, Gustavo Noronha Silva wrote: > Hey, > > Keeping the GTK+ buildbot green has been a real challenge for many > reasons, but looking back at previous discussions we had regarding this, > I think we have come a long way. Over the last few weeks we (mainly > Xan!) put some hard work on getting the bot green by fixing bugs, > opening bug reports, and skipping tests. > > One of the issues we usually have lots of trouble with is patches > regressing our tests that people do not notice. We have had some good > experiences regarding this recently: a patch to modify how the media > tests were run broke all our media tests for the third time since we > stabilized them, but the change was backed out to be reworked. > > The second one was the work to get shadows support in cairo, which > regressed 2 tests of ours. Because we were paying attention we were able > to quickly spot them, and the people involved could fix them before > their regressive nature was lost in time, and they ended up on the > Skipped list. > > I would like to ask of people checking in changes that they try to pay > as much attention to our release bot as they are paying to Mac bots. We > will do our best to keep them green, but it gets very difficult to do it > when people are checking in stuff that breaks our tests all the time, > and not paying attention to them. In summary, I would like to see this > kind of behavior applied to our bots as well: > > ? ? ? ?https://bugs.webkit.org/show_bug.cgi?id=29329 > > This "it can't remain like that; we need to either skip, check in a > platform-specific result or back out the change" would help us a lot. > > Thanks! > > P.S. I think it is important to note there are a number of tests failing > intermittently, mainly inspector ones, but that seems to be happening on > all the bots, so bear with us there =). > > -- > Gustavo Noronha Silva > GNOME Project > > _______________________________________________ > webkit-dev mailing list > webkit-dev at lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > From gns at gnome.org Mon Nov 16 05:33:20 2009 From: gns at gnome.org (Gustavo Noronha Silva) Date: Mon, 16 Nov 2009 11:33:20 -0200 Subject: [webkit-dev] On the greeness of the GTK+ bot In-Reply-To: <7789133a0911160524r49132d08j9373c3873089535b@mail.gmail.com> References: <1258376795.5592.37.camel@goiaba.horta> <7789133a0911160524r49132d08j9373c3873089535b@mail.gmail.com> Message-ID: <1258378400.5592.42.camel@goiaba.horta> On Mon, 2009-11-16 at 05:24 -0800, Adam Barth wrote: > Eric and I are working on a bot that might help this situation. > Essentially, the bot will try out patches on Qt and GTK and add a > comment to the bug if the patch regresses the build. Our plan is to > start with compiling, but we'd eventually like to run the tests as > well. That sounds like an awesome idea. Thanks for working on it. Build breakages themselves have become less of an issue for us in recent times - people are definitely more aware of our bots, and are acting on fixing them when they break. I think such an automated approach to running the build, and tests for upcoming patches will surely help with giving this a second step forward. See you, -- Gustavo Noronha Silva GNOME Project From xan at gnome.org Mon Nov 16 05:56:03 2009 From: xan at gnome.org (Xan Lopez) Date: Mon, 16 Nov 2009 15:56:03 +0200 Subject: [webkit-dev] On the greeness of the GTK+ bot In-Reply-To: <1258378400.5592.42.camel@goiaba.horta> References: <1258376795.5592.37.camel@goiaba.horta> <7789133a0911160524r49132d08j9373c3873089535b@mail.gmail.com> <1258378400.5592.42.camel@goiaba.horta> Message-ID: On Mon, Nov 16, 2009 at 3:33 PM, Gustavo Noronha Silva wrote: > On Mon, 2009-11-16 at 05:24 -0800, Adam Barth wrote: >> Eric and I are working on a bot that might help this situation. >> Essentially, the bot will try out patches on Qt and GTK and add a >> comment to the bug if the patch regresses the build. ?Our plan is to >> start with compiling, but we'd eventually like to run the tests as >> well. > > That sounds like an awesome idea. Thanks for working on it. Build > breakages themselves have become less of an issue for us in recent times > - people are definitely more aware of our bots, and are acting on fixing > them when they break. > > I think such an automated approach to running the build, and tests for > upcoming patches will surely help with giving this a second step > forward. This is nice to see, but as Gustavo says build breakage is not too much an issue at the moment for us: the build does not break very often, and when it does people usually take the time to figure out what happened and either do fix it themselves or poke us about it. That being said, this could be improved in any number of ways and I'm happy to see it getting ever better. What is effectively a black hole with respect to our time is the tests breakage, though. We get new tests failing very regularly (either through new tests or through new code making old tests fail), and once the bots are red people tend to pay even less attention to them, so they spiral out of control in a positive feedback loop until we have tests failing in the double digits in a matter of days (or hours!). Of course in an ideal world we'd have a team big enough to always have at least one person looking at this and fixing the problems the moment they arise, but unfortunately this is not the case. I realize this is a very complicated problem to fix unless we throw more people at it from our side, but maybe we could all agree in some basic guidelines to make things a bit better: - If you are adding new functionality + tests that you *know* will fail in some bots, open a bug describing what we should implement to get it working, and skip all new tests with a reference to the bug number. This should be relatively easy to do for the person who implemented the functionality in the first place, and would save everyone lots of time in the long run. - If your new code makes a previously passing test(s) fail in a port other than your own, you have two choices: * If you know what's going on and think this is a bug in the port, you can propose a patch yourself, or open a bug with your ideas and skip the tests with a reference to the bug number. Get the port maintainers on the loop ASAP. * If you have no idea of what's going on, maybe Eric's proposed hard-line policy kicks in: you either figure it out quick and propose something, or the patch is rolled out until things are clear; regressions in tests in any port are as bad as build breakages, so early roll out is preferred to having the bots red for a long time. As I said, this is a complex problem, but I think at the very least having a clear picture of what is expected of everyone with respect to failing tests in the bots would be a good start to make things easier. Xan > > See you, > > -- > Gustavo Noronha Silva > GNOME Project > > _______________________________________________ > webkit-dev mailing list > webkit-dev at lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > From ap at webkit.org Mon Nov 16 09:45:04 2009 From: ap at webkit.org (Alexey Proskuryakov) Date: Mon, 16 Nov 2009 09:45:04 -0800 Subject: [webkit-dev] Staging WebSocket protocol deployment In-Reply-To: <9124e09b0911151718u654a4deaoc5fbb863caf58c04@mail.gmail.com> References: <20FACD6D-03FC-4FA8-8350-1445B2E482F3@webkit.org> <5dd9e5c50911131046m29098ea9m5ba1897b41314b74@mail.gmail.com> <5dd9e5c50911131549k79dd37a3p87bbec9dc4ca5559@mail.gmail.com> <5dd9e5c50911131639k7b20b932u8fe0d730d545b6bd@mail.gmail.com> <7789133a0911131801g3627dbfcrfdec4d00feb940f4@mail.gmail.com> <7789133a0911151519y3d8fc1des53773430b9afd5f5@mail.gmail.com> <9124e09b0911151718u654a4deaoc5fbb863caf58c04@mail.gmail.com> Message-ID: 15.11.2009, ? 17:18, Yuzo Fujishima ???????: > Reason 1: It connotes that the feature is experimental. That means > there > will be less developers seriously use that feature. Without serious > use, > we'll have less serious feedbacks from the real world. If the Web > Socket > has serious flaws, we should rather know them sooner than later. I'd > say > only serious uses can help us find the flaws faster. It doesn't seem that wide use is possible before the protocol evolves into something that works with all proxies - or before a heavyweight service forces network administrators to update their proxies for compatibility with the existing protocol. Frankly, I think that the former is more likely. The only case that is likely to work on Internet reliably right now is running over SSL, which negates some of the protocol's strengths - it will no longer be as efficient as it's meant to be. In order to enable port sharing, this also requires one to serve documents over https, which is an additional cost. > Reason 2: What should other browser vendors do? Should they use > chrome-ws, firefox-ws, ie-ws, opera-ws, ..., etc? I believe at least > developers > will not happy with that. If the vendors need to reach the consensus > on the > common experimental name, say prelim-ws, then why not just use ws > instead? In practice, this means half a dozen lines of browser detection code - which does not matter when deploying a technology of this magnitude, as already mentioned in this thread. It seems that a common argument against using a name other than "ws" is that a scheme is just an opaque identifier, so it doesn't matter which name to use, so we can just change the name later, if necessary. I don't think that this is a strong argument - if the name doesn't matter in the long run (which I wouldn't agree with, but anyway), why sweat about what the name is during experimental rollout of the feature? - WBR, Alexey Proskuryakov From dglazkov at chromium.org Mon Nov 16 09:47:54 2009 From: dglazkov at chromium.org (Dimitri Glazkov) Date: Mon, 16 Nov 2009 09:47:54 -0800 Subject: [webkit-dev] On the greeness of the GTK+ bot In-Reply-To: References: <1258376795.5592.37.camel@goiaba.horta> <7789133a0911160524r49132d08j9373c3873089535b@mail.gmail.com> <1258378400.5592.42.camel@goiaba.horta> Message-ID: On Mon, Nov 16, 2009 at 5:56 AM, Xan Lopez wrote: > On Mon, Nov 16, 2009 at 3:33 PM, Gustavo Noronha Silva wrote: >> On Mon, 2009-11-16 at 05:24 -0800, Adam Barth wrote: >>> Eric and I are working on a bot that might help this situation. >>> Essentially, the bot will try out patches on Qt and GTK and add a >>> comment to the bug if the patch regresses the build. ?Our plan is to >>> start with compiling, but we'd eventually like to run the tests as >>> well. >> >> That sounds like an awesome idea. Thanks for working on it. Build >> breakages themselves have become less of an issue for us in recent times >> - people are definitely more aware of our bots, and are acting on fixing >> them when they break. >> >> I think such an automated approach to running the build, and tests for >> upcoming patches will surely help with giving this a second step >> forward. > > This is nice to see, but as Gustavo says build breakage is not too > much an issue at the moment for us: the build does not break very > often, and when it does people usually take the time to figure out > what happened and either do fix it themselves or poke us about it. > That being said, this could be improved in any number of ways and I'm > happy to see it getting ever better. > > What is effectively a black hole with respect to our time is the tests > breakage, though. We get new tests failing very regularly (either > through new tests or through new code making old tests fail), and once > the bots are red people tend to pay even less attention to them, so > they spiral out of control in a positive feedback loop until we have > tests failing in the double digits in a matter of days (or hours!). Of > course in an ideal world we'd have a team big enough to always have at > least one person looking at this and fixing the problems the moment > they arise, but unfortunately this is not the case. This is a huge issue with the Chromium port as well. We spend quite a bit of effort tracking down failing tests, only to discover that the failure is due to one-port baselines or new functionality added to DRT. I wonder if the approach we have today in regards to tests is not sustainable with multiple vibrant ports, each spending way to much time catching up. :DG< From leavengood at gmail.com Mon Nov 16 11:16:08 2009 From: leavengood at gmail.com (Ryan Leavengood) Date: Mon, 16 Nov 2009 14:16:08 -0500 Subject: [webkit-dev] On the greeness of the GTK+ bot In-Reply-To: References: <1258376795.5592.37.camel@goiaba.horta> <7789133a0911160524r49132d08j9373c3873089535b@mail.gmail.com> <1258378400.5592.42.camel@goiaba.horta> Message-ID: On Mon, Nov 16, 2009 at 12:47 PM, Dimitri Glazkov wrote: > > This is a huge issue with the Chromium port as well. We spend quite a > bit of effort tracking down failing tests, only to discover that the > failure is due to one-port baselines or new functionality added to > DRT. I wonder if the approach we have today in regards to tests is not > sustainable with multiple vibrant ports, each spending way to much > time catching up. This is also a big concern for our tiny group working on the Haiku port. While we are not nearly at the stage of GTK, Qt or Chromium, we hope to get there one day, and it would be frustrating to have our tests broken or our (future) build bot constantly red due to other port's changes. Given how many people are having pain with this, it seems some change might be warranted. Unfortunately I don't feel qualified enough to suggest anything. But I think there is enough cumulative experience on all sides to come up with a good solution. -- Regards, Ryan From darin at apple.com Mon Nov 16 13:28:47 2009 From: darin at apple.com (Darin Adler) Date: Mon, 16 Nov 2009 13:28:47 -0800 Subject: [webkit-dev] "using namespace" style guideline In-Reply-To: References: Message-ID: On Nov 15, 2009, at 9:57 PM, Chris Jerdonek wrote: > In particular, the following file uses "using namespace WTF::Unicode" five times, but within the bodies of various template definitions: > > http://trac.webkit.org/browser/trunk/WebCore/platform/text/BidiResolver.h > > (see line 304, for example) > > Is this also not okay? This is fine. If the "using namespace" is scoped to a particular function, then it?s not the same thing we?re talking about. > The following is another example. The using statement for this one appears at the beginning, outside of any definitions, but the file seems to be central: > > http://trac.webkit.org/browser/trunk/JavaScriptGlue/JSUtils.h > > It uses "using namespace JSC". JavaScriptGlue does not follow the WebKit coding style ? there?s no need to look at files inside the JavaScriptGlue directory when considering matters of style. > My second question is whether the guideline above should apply, for the same reason, to all "using" statements within header files -- and not just to "using namespace" statements. Statements of the form "using WTF::..." would be exceptions. You've already discussed those here: > > https://lists.webkit.org/pipermail/webkit-dev/2009-November/010453.html > > I checked, and there are only about 40 files in all of WebKit that wouldn't currently be following this -- slightly less than half of which are in JSC. Probably. We?d have to discuss specific examples to be sure. -- Darin From codedread at gmail.com Mon Nov 16 14:23:28 2009 From: codedread at gmail.com (Jeff Schiller) Date: Mon, 16 Nov 2009 16:23:28 -0600 Subject: [webkit-dev] Non-Scaling Stroke feature (SVGT 1.2) Message-ID: Hello, I am interested in having broader support for non-scaling stroke on SVG shapes. This is a SVGT 1.2 feature: http://www.w3.org/TR/SVGTiny12/painting.html#NonScalingStroke This adds a CSS property and attribute: vector-effect. This property can have three values: none (default), inherit, or non-scaling-stroke. When non-scaling-stroke, the stroke (outline) of a shape would maintain its specified width regardless of the transforms applied to the shape. This is very useful when importing foreign SVG into new documents and in GIS/mapping scenarios (for instance, zooming in on a map would not "fatten" the driving directions path). I realize that WebKit has been generally not interested in SVGT 1.2, but I feel it makes sense to cherry-pick certain features that really do improve SVG on the web. Non-scaling stroke is one of these features. FWIW, Opera has implemented this feature since version 9.5. I have opened a bug and supplied a patch that gets this off the ground in WebKit: https://bugs.webkit.org/show_bug.cgi?id=31438 I only need to figure out how to add some tests (need to understand how pixel tests work in WebKit). Darin Adler requested that I bring this up on this list for discussion. Thanks, Jeff Schiller From ggaren at apple.com Mon Nov 16 18:48:26 2009 From: ggaren at apple.com (Geoffrey Garen) Date: Mon, 16 Nov 2009 18:48:26 -0800 Subject: [webkit-dev] A bot-filled future? In-Reply-To: <7789133a0911121137l35bc1485w511d73e59544d4d1@mail.gmail.com> References: <7789133a0911121137l35bc1485w511d73e59544d4d1@mail.gmail.com> Message-ID: <2543BC0F-C8CC-455C-AD9E-9883D8344018@apple.com> A try bot would help me a lot. As others have mentioned, being able to see output from build+test is a big deal. I understand why you want to start with a Mac bot, and I applaud starting small. However, bear in mind that lots of WebKit contributors work primarily on the Mac, so they probably won't get any use out of a Mac try bot, and you probably won't get any feedback from them until the try bot expands to cover other platforms. Geoff On Nov 12, 2009, at 11:37 AM, Adam Barth wrote: > As the project grows, we need to scale our processes to match. In > large part, that means automating as much work as possible. > Commit-queue has done a good job of solving the "land patches from > non-committers efficiently" problem, effectively removing that as a > pain point. I'd like to ask you to open your hearts and your minds to > the idea of automating more of our processes. > > Currently, I see the biggest pain-point in our process as the > always-burgeoning pending-review list. It's difficult to automate the > process of accepting good patches because that requires attention from > experts. Instead, I think we should make it easier to reject bad > patches. As a first step, I've started extending bugzilla-tool to be > a try server in . > Here's how this might work: > > 1) Contributor posts patch for review. > 2) Committer marks patch with the try? flag. > 3) The try-queue downloads, applies, builds, and tests the patch. > 4) If all systems are go, the try-queue marks the patch as try+. > Otherwise, it marks the patch as try- with an explanation of what went > wrong. > > The try-queue will be purely optional and advisory. Hopefully a try- > notation will encourage the contributor to post a new version of the > patch that passes the try-queue. > > Further down the road, one can also imagine another bot that automates > step (2) by scanning the pending-review list for untried patches and > marking them as try? when the try-queue has unused bandwidth. > > Adam > _______________________________________________ > webkit-dev mailing list > webkit-dev at lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev From chris.jerdonek at gmail.com Mon Nov 16 19:54:15 2009 From: chris.jerdonek at gmail.com (Chris Jerdonek) Date: Mon, 16 Nov 2009 19:54:15 -0800 Subject: [webkit-dev] normalizing namespace indenting Message-ID: I am contemplating a script to normalize the namespace indenting across our code to match our guidelines, so I wanted to clarify two things. First, it seems like the original motive was to avoid pointlessly indenting nearly the whole file: https://lists.webkit.org/pipermail/webkit-dev/2009-September/010002.html So, I was wondering if we can clarify the rule to apply only to the outermost namespace declaration. Otherwise, files with nested namespaces like the following become harder to read: http://trac.webkit.org/browser/trunk/JavaScriptCore/wtf/FastAllocBase.h (Consecutive declarations like "namespace JSC { namespace WREC {" would be treated as a single declaration for the purpose of this rule.) Second, do people prefer nested namespace blocks to end with the fully-qualified name (e.g. // namespace JSC::WREC) or just the final name (e.g. // namespace WREC)? I have seen both. --Chris From vbs85 at gmx.de Mon Nov 16 22:35:27 2009 From: vbs85 at gmx.de (Dirk Schulze) Date: Tue, 17 Nov 2009 07:35:27 +0100 Subject: [webkit-dev] Non-Scaling Stroke feature (SVGT 1.2) In-Reply-To: References: Message-ID: <1258439727.29274.13.camel@dirk-laptop> Hi, I thougt that we already had a bug about this. It is a good idea to support this feature in general. Even if our support for SVG 1.1 is not perfect, we should think about some features of SVG 1.2 like media support and also non scaling strokes. But implementing non scaling strokes is not that easy. On SVG we transform the context multiple times (translate, scale, skew) and stroke the path at the end. We may think about transforming the path instead of the context but there might be more problems on doing that. -Dirk Am Montag, den 16.11.2009, 16:23 -0600 schrieb Jeff Schiller: > Hello, > > I am interested in having broader support for non-scaling stroke on > SVG shapes. This is a SVGT 1.2 feature: > http://www.w3.org/TR/SVGTiny12/painting.html#NonScalingStroke > > This adds a CSS property and attribute: vector-effect. This property > can have three values: none (default), inherit, or > non-scaling-stroke. > > When non-scaling-stroke, the stroke (outline) of a shape would > maintain its specified width regardless of the transforms applied to > the shape. This is very useful when importing foreign SVG into new > documents and in GIS/mapping scenarios (for instance, zooming in on a > map would not "fatten" the driving directions path). > > I realize that WebKit has been generally not interested in SVGT 1.2, > but I feel it makes sense to cherry-pick certain features that really > do improve SVG on the web. Non-scaling stroke is one of these > features. FWIW, Opera has implemented this feature since version 9.5. > > I have opened a bug and supplied a patch that gets this off the ground > in WebKit: https://bugs.webkit.org/show_bug.cgi?id=31438 I only need > to figure out how to add some tests (need to understand how pixel > tests work in WebKit). > > Darin Adler requested that I bring this up on this list for discussion. > > Thanks, > Jeff Schiller > _______________________________________________ > webkit-dev mailing list > webkit-dev at lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev From codedread at gmail.com Mon Nov 16 22:37:13 2009 From: codedread at gmail.com (Jeff Schiller) Date: Tue, 17 Nov 2009 00:37:13 -0600 Subject: [webkit-dev] Non-Scaling Stroke feature (SVGT 1.2) In-Reply-To: <1258439607.29274.10.camel@dirk-laptop> References: <1258439607.29274.10.camel@dirk-laptop> Message-ID: Hi Dirk, I wasn't aware of another bug, sorry. Actually on the patch that I have already attached to that bug, it seems to work in the few test cases I've been able to find (my own and a couple from the SVGT 1.2 test suite). While stroking, I transform the path with the CTM of the context and un-transform the context (with its inverse matrix). Then I undo that after stroking. The only thing that may be a problem is the dirty rectangle that is created by paths with non-scaled-strokes. I need to look at that after generating some tests. Regards, Jeff On Tue, Nov 17, 2009 at 12:33 AM, Dirk Schulze wrote: > Hi, > > I thougt that we already had a bug about this. It is a good idea to > support this feature in general. Even if our support for SVG 1.1 is not > perfect, we should think about some features of SVG 1.2 like media > support and also non scaling strokes. But implementing non scaling > strokes is not that easy. On SVG we transform the context multiple times > (translate, scale, skew) and stroke the path at the end. We may think > about transforming the path instead of the context but there might be > more problems on doing that. > > -Dirk > > Am Montag, den 16.11.2009, 16:23 -0600 schrieb Jeff Schiller: >> Hello, >> >> I am interested in having broader support for non-scaling stroke on >> SVG shapes. ?This is a SVGT 1.2 feature: >> http://www.w3.org/TR/SVGTiny12/painting.html#NonScalingStroke >> >> This adds a CSS property and attribute: vector-effect. ?This property >> can have three values: ?none (default), inherit, or >> non-scaling-stroke. >> >> When non-scaling-stroke, the stroke (outline) of a shape would >> maintain its specified width regardless of the transforms applied to >> the shape. ?This is very useful when importing foreign SVG into new >> documents and in GIS/mapping scenarios (for instance, zooming in on a >> map would not "fatten" the driving directions path). >> >> I realize that WebKit has been generally not interested in SVGT 1.2, >> but I feel it makes sense to cherry-pick certain features that really >> do improve SVG on the web. ?Non-scaling stroke is one of these >> features. ?FWIW, Opera has implemented this feature since version 9.5. >> >> I have opened a bug and supplied a patch that gets this off the ground >> in WebKit: ?https://bugs.webkit.org/show_bug.cgi?id=31438 ?I only need >> to figure out how to add some tests (need to understand how pixel >> tests work in WebKit). >> >> Darin Adler requested that I bring this up on this list for discussion. >> >> Thanks, >> Jeff Schiller >> _______________________________________________ >> webkit-dev mailing list >> webkit-dev at lists.webkit.org >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > > From abecsi at inf.u-szeged.hu Tue Nov 17 02:46:28 2009 From: abecsi at inf.u-szeged.hu (Andras Becsi) Date: Tue, 17 Nov 2009 11:46:28 +0100 Subject: [webkit-dev] On the greeness of the GTK+ bot In-Reply-To: References: <1258376795.5592.37.camel@goiaba.horta> <7789133a0911160524r49132d08j9373c3873089535b@mail.gmail.com> <1258378400.5592.42.camel@goiaba.horta> Message-ID: <4B027F04.9030300@inf.u-szeged.hu> Hello, for us too, as many of you poited out before me, the main issue is not build breakage while maintaining the QtWebKit buildbot - because these are most of the time trivial fixes - but tracking down the previously passing but after-the-night failing tests. Because of the timezone differences most of the work on the Mac port is done when we here in Europe are in our sleeping-quarters, and a green bot will most certainly be red in the morning and a non-green bot gets out of sight very quickly. However, I find the idea of the try-bots great, because this takes the right direction to a future where try-bots also test the layout tests. We are monitoring changes and their effect on our buildbot and tracking down incremental failures and flakey tests which cause false alarm and disrupt the trustiness of our bot. Another huge problem is, as Dimitri pointed out too, that in most cases we miss a certain DRT feature to run a test correctly. If we spend more effort improving (and btw fixing) DRT and the test infrastructure than improving and fixing the port itself then there might be a problem with the layout-testing approach on multiple ports. BR: Andras (bbandix) Dimitri Glazkov ?rta: > On Mon, Nov 16, 2009 at 5:56 AM, Xan Lopez wrote: >> On Mon, Nov 16, 2009 at 3:33 PM, Gustavo Noronha Silva wrote: >>> On Mon, 2009-11-16 at 05:24 -0800, Adam Barth wrote: >>>> Eric and I are working on a bot that might help this situation. >>>> Essentially, the bot will try out patches on Qt and GTK and add a >>>> comment to the bug if the patch regresses the build. Our plan is to >>>> start with compiling, but we'd eventually like to run the tests as >>>> well. >>> That sounds like an awesome idea. Thanks for working on it. Build >>> breakages themselves have become less of an issue for us in recent times >>> - people are definitely more aware of our bots, and are acting on fixing >>> them when they break. >>> >>> I think such an automated approach to running the build, and tests for >>> upcoming patches will surely help with giving this a second step >>> forward. >> This is nice to see, but as Gustavo says build breakage is not too >> much an issue at the moment for us: the build does not break very >> often, and when it does people usually take the time to figure out >> what happened and either do fix it themselves or poke us about it. >> That being said, this could be improved in any number of ways and I'm >> happy to see it getting ever better. >> >> What is effectively a black hole with respect to our time is the tests >> breakage, though. We get new tests failing very regularly (either >> through new tests or through new code making old tests fail), and once >> the bots are red people tend to pay even less attention to them, so >> they spiral out of control in a positive feedback loop until we have >> tests failing in the double digits in a matter of days (or hours!). Of >> course in an ideal world we'd have a team big enough to always have at >> least one person looking at this and fixing the problems the moment >> they arise, but unfortunately this is not the case. > > This is a huge issue with the Chromium port as well. We spend quite a > bit of effort tracking down failing tests, only to discover that the > failure is due to one-port baselines or new functionality added to > DRT. I wonder if the approach we have today in regards to tests is not > sustainable with multiple vibrant ports, each spending way to much > time catching up. > > :DG< > _______________________________________________ > webkit-dev mailing list > webkit-dev at lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev From jorlow at chromium.org Tue Nov 17 04:25:12 2009 From: jorlow at chromium.org (Jeremy Orlow) Date: Tue, 17 Nov 2009 12:25:12 +0000 Subject: [webkit-dev] Staging WebSocket protocol deployment In-Reply-To: References: <20FACD6D-03FC-4FA8-8350-1445B2E482F3@webkit.org> <5dd9e5c50911131549k79dd37a3p87bbec9dc4ca5559@mail.gmail.com> <5dd9e5c50911131639k7b20b932u8fe0d730d545b6bd@mail.gmail.com> <7789133a0911131801g3627dbfcrfdec4d00feb940f4@mail.gmail.com> <7789133a0911151519y3d8fc1des53773430b9afd5f5@mail.gmail.com> <9124e09b0911151718u654a4deaoc5fbb863caf58c04@mail.gmail.com> Message-ID: <5dd9e5c50911170425p3f29c413g79b115c35c512427@mail.gmail.com> On Mon, Nov 16, 2009 at 5:45 PM, Alexey Proskuryakov wrote: > > 15.11.2009, ? 17:18, Yuzo Fujishima ???????: > > > Reason 1: It connotes that the feature is experimental. That means there >> will be less developers seriously use that feature. Without serious use, >> we'll have less serious feedbacks from the real world. If the Web Socket >> has serious flaws, we should rather know them sooner than later. I'd say >> only serious uses can help us find the flaws faster. >> > > > It doesn't seem that wide use is possible before the protocol evolves into > something that works with all proxies - or before a heavyweight service > forces network administrators to update their proxies for compatibility with > the existing protocol. Frankly, I think that the former is more likely. > > The only case that is likely to work on Internet reliably right now is > running over SSL, which negates some of the protocol's strengths - it will > no longer be as efficient as it's meant to be. In order to enable port > sharing, this also requires one to serve documents over https, which is an > additional cost. You're right that WebSocket users will need to use SSL to get around proxy issues, but I don't think it's actually that big of a deal. I know of several sites looking at using them; all are planning on using SSL, and I'm not aware of any being particularly concerned about this. As for the proxy issues themselves: they're not going to go away any time soon. And the longer we label this protocol as experimental, the longer it's going to take for things to move forward. > Reason 2: What should other browser vendors do? Should they use >> chrome-ws, firefox-ws, ie-ws, opera-ws, ..., etc? I believe at least >> developers >> will not happy with that. If the vendors need to reach the consensus on >> the >> common experimental name, say prelim-ws, then why not just use ws instead? >> > > In practice, this means half a dozen lines of browser detection code - > which does not matter when deploying a technology of this magnitude, as > already mentioned in this thread. > That's not the matter. The matter is what this signals to people considering using WebSockets. Each UA having their own code typically signals that things are non-standard, which is not true in this case. > It seems that a common argument against using a name other than "ws" is > that a scheme is just an opaque identifier, so it doesn't matter which name > to use, so we can just change the name later, if necessary. I don't think > that this is a strong argument - if the name doesn't matter in the long run > (which I wouldn't agree with, but anyway), why sweat about what the name is > during experimental rollout of the feature? > This argument works both for and against. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tonikitoo at gmail.com Tue Nov 17 04:44:13 2009 From: tonikitoo at gmail.com (tonikitoo (Antonio Gomes)) Date: Tue, 17 Nov 2009 08:44:13 -0400 Subject: [webkit-dev] Error handling support in DRT. In-Reply-To: <7eb9ad710911091835l12130624m76a7c813ef0c4ef6@mail.gmail.com> References: <7eb9ad710911061049y42508555o151764d058a88da1@mail.gmail.com> <7eb9ad710911091835l12130624m76a7c813ef0c4ef6@mail.gmail.com> Message-ID: <7eb9ad710911170444m4a467ff8s94c484d7612c76c6@mail.gmail.com> It was agreed on IRC that having DRTs able to handle error pages in not a bad thing, but good since it brings DRT closer to a real browsers behavior. Hence, I moved on here and implemented it for QT's DRT (see https://bugs.webkit.org/show_bug.cgi?id=31509#c0). Currently the single test depending on it is fast/history/back-forward-reset-after-error-handling.html (see https://bugs.webkit.org/show_bug.cgi?id=30573), which is in gtk, win and mac 'Skipped' for now. Also, I've filed follow up bugs for each of these DRT to track down the implementation of such feature for their DRTs: * MAC -> https://bugs.webkit.org/show_bug.cgi?id=31555 * GTK -> https://bugs.webkit.org/show_bug.cgi?id=31556 * WIN -> https://bugs.webkit.org/show_bug.cgi?id=31557 Regards -- --Antonio Gomes From gns at gnome.org Tue Nov 17 05:04:20 2009 From: gns at gnome.org (Gustavo Noronha Silva) Date: Tue, 17 Nov 2009 11:04:20 -0200 Subject: [webkit-dev] A bot-filled future? In-Reply-To: <2543BC0F-C8CC-455C-AD9E-9883D8344018@apple.com> References: <7789133a0911121137l35bc1485w511d73e59544d4d1@mail.gmail.com> <2543BC0F-C8CC-455C-AD9E-9883D8344018@apple.com> Message-ID: <1258463061.30103.0.camel@goiaba.horta> On Mon, 2009-11-16 at 18:48 -0800, Geoffrey Garen wrote: > I understand why you want to start with a Mac bot, and I applaud > starting small. However, bear in mind that lots of WebKit contributors > work primarily on the Mac, so they probably won't get any use out of a > Mac try bot, and you probably won't get any feedback from them until > the try bot expands to cover other platforms. I believe the idea is in fact to start with a GTK+/Qt on Linux bot (since it should be simpler to setup). See you, -- Gustavo Noronha Silva GNOME Project From ejpbruel at gmail.com Tue Nov 17 07:37:51 2009 From: ejpbruel at gmail.com (=?ISO-8859-1?Q?Eddy_Bru=EBl?=) Date: Tue, 17 Nov 2009 16:37:51 +0100 Subject: [webkit-dev] WebScripting protocol: valueForUndefinedKey: never gets called Message-ID: <3321f8b20911170737t5b4d91a0u22802644ebecf495@mail.gmail.com> Hi everybody, I am in the process of writing some code in ObjC, which would allow me to make calls from Javascript to C++ objects implementing a simple reflection interface (it basically allows you to associated indices with names, and perform operations such as getting/setting/calling on these indices). In order to do this, I created a simple ObjC wrapper object around the C++ interface, which implements the WebScripting protocol. However, since this wrapper object does not have any member variables (they are all hidden behind the C++ interface), I cannot expose these to Javascript directly. Instead, I've tried to make them available using KVC, specifically by using the methods valueForUndefinedKey: and setValue:forUndefinedKey:. For isKeyExcludedFromWebScript: and isSelectorExcludedFromWebScript: I simply always return YES. Setting properties like this seems to work fine. The method get called, and I simply forward it to the reflection interface. Getting properties, on the other hand, does not seem to work: valueForUndefinedKey: simply does not get called. At all. I found an entry on the Apple mailing lists of somebody seemingly having the same problem as me. Unfortunately, there was no answer: http://lists.apple.com/archives/webkitsdk-dev/2008/Oct/msg00021.html Am I overlooking something? Are there any other methods I need to override in order for this to work? Or is it simply a bug in WebKit, since this approach to exposing properties seems to be non-standard, at least. Any feedback on this issue would be very much appreciated! :-) Cheers, Eddy -------------- next part -------------- An HTML attachment was scrubbed... URL: From ggaren at apple.com Tue Nov 17 11:36:19 2009 From: ggaren at apple.com (Geoffrey Garen) Date: Tue, 17 Nov 2009 11:36:19 -0800 Subject: [webkit-dev] A bot-filled future? In-Reply-To: <1258463061.30103.0.camel@goiaba.horta> References: <7789133a0911121137l35bc1485w511d73e59544d4d1@mail.gmail.com> <2543BC0F-C8CC-455C-AD9E-9883D8344018@apple.com> <1258463061.30103.0.camel@goiaba.horta> Message-ID: <1B7FCED1-87F2-4978-9EBD-3F3D112CBA59@apple.com> > I believe the idea is in fact to start with a GTK+/Qt on Linux bot > (since it should be simpler to setup). Neat. Geoff From ggaren at apple.com Tue Nov 17 12:02:18 2009 From: ggaren at apple.com (Geoffrey Garen) Date: Tue, 17 Nov 2009 12:02:18 -0800 Subject: [webkit-dev] WebScripting protocol: valueForUndefinedKey: never gets called In-Reply-To: <3321f8b20911170737t5b4d91a0u22802644ebecf495@mail.gmail.com> References: <3321f8b20911170737t5b4d91a0u22802644ebecf495@mail.gmail.com> Message-ID: <2D52CAE5-DB4B-4C5C-ADCC-C016E1D3DAC8@apple.com> Hi Eddy. This seems like a bug to me. Would you be willing to file it at bugs.webkit.org? I have a guess at a possible work-around. In the class where you've implemented valueForUndefinedKey:, try also implementing invokeUndefinedMethodFromWebScript:withArguments:. Thanks, Geoff On Nov 17, 2009, at 7:37 AM, Eddy Bru?l wrote: > Hi everybody, > > I am in the process of writing some code in ObjC, which would allow > me to make calls from Javascript to C++ objects implementing a > simple reflection interface (it basically allows you to associated > indices with names, and perform operations such as > getting/setting/calling on these indices). > > In order to do this, I created a simple ObjC wrapper object around the > C++ interface, which implements the WebScripting protocol. However, > since this wrapper object does not have any member variables (they > are all hidden behind the C++ interface), I cannot expose these to > Javascript directly. > > Instead, I've tried to make them available using KVC, specifically by > using the methods valueForUndefinedKey: and > setValue:forUndefinedKey:. For isKeyExcludedFromWebScript: and > isSelectorExcludedFromWebScript: I simply always return YES. > > Setting properties like this seems to work fine. The method get called, > and I simply forward it to the reflection interface. Getting properties, on > the other hand, does not seem to work: valueForUndefinedKey: simply > does not get called. At all. > > I found an entry on the Apple mailing lists of somebody seemingly > having the same problem as me. Unfortunately, there was no answer: > http://lists.apple.com/archives/webkitsdk-dev/2008/Oct/msg00021.html > > Am I overlooking something? Are there any other methods I need to > override in order for this to work? Or is it simply a bug in WebKit, since > this approach to exposing properties seems to be non-standard, at least. > > Any feedback on this issue would be very much appreciated! :-) > > Cheers, > > > Eddy > > > > > > > > > > _______________________________________________ > webkit-dev mailing list > webkit-dev at lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From mjs at apple.com Tue Nov 17 13:08:40 2009 From: mjs at apple.com (Maciej Stachowiak) Date: Tue, 17 Nov 2009 13:08:40 -0800 Subject: [webkit-dev] Staging WebSocket protocol deployment In-Reply-To: <9124e09b0911151718u654a4deaoc5fbb863caf58c04@mail.gmail.com> References: <20FACD6D-03FC-4FA8-8350-1445B2E482F3@webkit.org> <5dd9e5c50911131046m29098ea9m5ba1897b41314b74@mail.gmail.com> <5dd9e5c50911131549k79dd37a3p87bbec9dc4ca5559@mail.gmail.com> <5dd9e5c50911131639k7b20b932u8fe0d730d545b6bd@mail.gmail.com> <7789133a0911131801g3627dbfcrfdec4d00feb940f4@mail.gmail.com> <7789133a0911151519y3d8fc1des53773430b9afd5f5@mail.gmail.com> <9124e09b0911151718u654a4deaoc5fbb863caf58c04@mail.gmail.com> Message-ID: <4E82A81D-0C99-4A60-9534-6ED08B23E770@apple.com> On Nov 15, 2009, at 5:18 PM, Yuzo Fujishima wrote: > Hi, > > I'm against prefixing with "webkit-" because of the following reasons. > > Reason 1: It connotes that the feature is experimental. That means > there > will be less developers seriously use that feature. Without serious > use, > we'll have less serious feedbacks from the real world. If the Web > Socket > has serious flaws, we should rather know them sooner than later. I'd > say > only serious uses can help us find the flaws faster. I think this captures the root of the disagreement. Personally, I would like to do something to send the message that WebSocket is still somewhat experimental. It's true that the spec has been in development for a long time. But we are only now seeing the first client-side and server-side implementations. A number of issues were discovered in that process, and I'd personally like to see some more experimental implementations before we lose the ability to make incompatible changes. See below for some specific suggestions. > > Reason 2: What should other browser vendors do? Should they use > chrome-ws, firefox-ws, ie-ws, opera-ws, ..., etc? I believe at least > developers > will not happy with that. If the vendors need to reach the consensus > on the > common experimental name, say prelim-ws, then why not just use ws > instead? Historically, we haven't had a problem with WebKit-prefixed features - it seems that other browser vendors implement under their own prefix and content adapts to deal. Anyway, getting back to the suggestions... I think it's reasonable at this point to indicate that the WebSocket protocol is somewhat experimental (probably more so than the API). I will recommend doing something along those lines for the next release of Safari. If we can get rough consensus within the WebKit community that we should label the protocol experimental, and how we should do so, then we can just make the change in WebKit and vendor releases will follow along. Here is an extended list of ideas (ones that I think are practically doable): 1) Change the URI schemes to "webkit-ws" and "webkit-wss" - the vendor prefix strategy. 2) Change the URI schemes to "x-ws" and "x-wss" - a vendor-independent experimental prefix. 3) Don't change the URI schemes at all, but communicate in some public way that the protocol is not completely locked down yet, and we are largely looking for early adopter feedback. We could do this in the form of a WebKit blog post, for example. And we could reinforce that in developer documentation for WebKit-based products. 4) Support both unprefixed and prefixed URI schemes, and in addition publicize that we will maintain compatibility for the prefixed URI scheme but the unprefixed version may have to change (combo of 3 and either 1 or 2). 5) Make the feature runtime switchable (using some semi-hidden UI) and off by default. I'd like to hear opinions on which of these is best. I'd also like to hear if anyone feels that we should send the message that the WebSocket Protocol is production quality and we promise full compatibility going forward. Does anyone truly feel this way? Regards, Maciej From limi at mozilla.com Tue Nov 17 14:19:42 2009 From: limi at mozilla.com (Alexander Limi) Date: Tue, 17 Nov 2009 14:19:42 -0800 Subject: [webkit-dev] Making browsers faster: Resource Packages In-Reply-To: <2ef6228a0911161947w1067225bxdfe0eccd00e37bd8@mail.gmail.com> References: <2ef6228a0911161947w1067225bxdfe0eccd00e37bd8@mail.gmail.com> Message-ID: <2ef6228a0911171419v11497707je3c219856d66e150@mail.gmail.com> Good people of Webkit! We'd all like for the web to be faster, and therefore I'd love your feedback on my proposal ? it would be great to see support for this in additional browsers, not just Firefox: http://limi.net/articles/resource-packages/ Summary: What if there was a backwards compatible way to transfer all of the resources that are used on every single page in your site ? CSS, JS, images, anything else ? in a single HTTP request at the start of the first visit to the page? This is what Resource Package support in browsers will let you do. Looking forward to hear your thoughts on this. Thanks! -- Alexander Limi ? Firefox User Experience ? http://limi.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From hyatt at apple.com Tue Nov 17 14:30:27 2009 From: hyatt at apple.com (David Hyatt) Date: Tue, 17 Nov 2009 16:30:27 -0600 Subject: [webkit-dev] Making browsers faster: Resource Packages In-Reply-To: <2ef6228a0911171419v11497707je3c219856d66e150@mail.gmail.com> References: <2ef6228a0911161947w1067225bxdfe0eccd00e37bd8@mail.gmail.com> <2ef6228a0911171419v11497707je3c219856d66e150@mail.gmail.com> Message-ID: I have many of the same concerns mentioned here: http://ajaxian.com/archives/resource-packages-making-a-faster-web-via-packaging dave (hyatt at apple.com) On Nov 17, 2009, at 4:19 PM, Alexander Limi wrote: > Good people of Webkit! > > We'd all like for the web to be faster, and therefore I'd love your > feedback on my proposal ? it would be great to see support for this > in additional browsers, not just Firefox: > > http://limi.net/articles/resource-packages/ > > Summary: > What if there was a backwards compatible way to transfer all of the > resources that are used on every single page in your site ? CSS, JS, > images, anything else ? in a single HTTP request at the start of the > first visit to the page? This is what Resource Package support in > browsers will let you do. > > Looking forward to hear your thoughts on this. > > Thanks! > > -- > Alexander Limi ? Firefox User Experience ? http://limi.net > > _______________________________________________ > webkit-dev mailing list > webkit-dev at lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From limi at mozilla.com Tue Nov 17 14:36:49 2009 From: limi at mozilla.com (Alexander Limi) Date: Tue, 17 Nov 2009 14:36:49 -0800 Subject: [webkit-dev] Making browsers faster: Resource Packages In-Reply-To: References: <2ef6228a0911161947w1067225bxdfe0eccd00e37bd8@mail.gmail.com> <2ef6228a0911171419v11497707je3c219856d66e150@mail.gmail.com> Message-ID: <2ef6228a0911171436s61730851q97677a5847e1f515@mail.gmail.com> Could you be more specific? Most of the comments seem to be a result of people not actually reading the spec. As for the comments in the article itself: - You still do parallel downloads, and you can have multiple resource packages. - The zip can have expiry headers, and can be invalidated using ETags. If you can pull out the specific questions, I'm happy to answer them. -- Alexander Limi ? Firefox User Experience ? http://limi.net On Tue, Nov 17, 2009 at 2:30 PM, David Hyatt wrote: > I have many of the same concerns mentioned here: > > > http://ajaxian.com/archives/resource-packages-making-a-faster-web-via-packaging > > dave > (hyatt at apple.com) > > On Nov 17, 2009, at 4:19 PM, Alexander Limi wrote: > > Good people of Webkit! > > We'd all like for the web to be faster, and therefore I'd love your > feedback on my proposal ? it would be great to see support for this in > additional browsers, not just Firefox: > > http://limi.net/articles/resource-packages/ > > Summary: > What if there was a backwards compatible way to transfer all of the > resources that are used on every single page in your site ? CSS, JS, images, > anything else ? in a single HTTP request at the start of the first visit to > the page? This is what Resource Package support in browsers will let you do. > > Looking forward to hear your thoughts on this. > > Thanks! > > -- > Alexander Limi ? Firefox User Experience ? http://limi.net > > _______________________________________________ > webkit-dev mailing list > webkit-dev at lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pkasting at google.com Tue Nov 17 14:44:13 2009 From: pkasting at google.com (Peter Kasting) Date: Tue, 17 Nov 2009 14:44:13 -0800 Subject: [webkit-dev] Making browsers faster: Resource Packages In-Reply-To: <2ef6228a0911171419v11497707je3c219856d66e150@mail.gmail.com> References: <2ef6228a0911161947w1067225bxdfe0eccd00e37bd8@mail.gmail.com> <2ef6228a0911171419v11497707je3c219856d66e150@mail.gmail.com> Message-ID: On Tue, Nov 17, 2009 at 2:19 PM, Alexander Limi wrote: > We'd all like for the web to be faster, and therefore I'd love your > feedback on my proposal > I have read the whole document, but I read it quickly, so please do point out places where I've overlooked an obvious response. Reduced parallelism is a big concern of mine. Lots of sites make heavy use of resource sharding across many hostnames to take advantage of multiple connections, which this defeats. You say in this thread that "you still do parallel downloads", but it seems to me that you either download this zip in parallel with anything not in the zip (meaning you run out of parallelism faster the more the author makes use of this technique), or else you potentially download in parallel multiple copies of the same resource (one in the zip, one outside), neither of which is good. I am concerned about the instruction to prefer the packaged resources to any separate resources. This seems to increase the maintenance burden since you can never incrementally override the contents of a package, but always have to repackage. One of your stated goals is to avoid downloading resources you already have, but even with manifests, I see no way to do this, since the client can't actually tell the server "only send items x, y, and z". If an author has resources only used on some pages, then he can either make multiple packages (more maintenance burden and exacerbates problem above), or include everything in one package (may result in downloading excessive resources for pages where clients don't need them). You note that SPDY has to be implemented by both UAs and web servers, but conversely this proposal needs to be implemented by UAs and _authors_. I would rather burden the guys writing Apache than the guys making webpages, and I think if a technique is extremely useful, it's easier to get support into Apache than into, say, 50% of the webpages out there. PK -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamesr at google.com Tue Nov 17 15:00:37 2009 From: jamesr at google.com (James Robinson) Date: Tue, 17 Nov 2009 15:00:37 -0800 Subject: [webkit-dev] Making browsers faster: Resource Packages In-Reply-To: <2ef6228a0911171419v11497707je3c219856d66e150@mail.gmail.com> References: <2ef6228a0911161947w1067225bxdfe0eccd00e37bd8@mail.gmail.com> <2ef6228a0911171419v11497707je3c219856d66e150@mail.gmail.com> Message-ID: On Tue, Nov 17, 2009 at 2:19 PM, Alexander Limi wrote: > > Good people of Webkit! > > We'd all like for the web to be faster, and therefore I'd love your feedback on my proposal ? it would be great to see support for this in additional browsers, not just Firefox: > > http://limi.net/articles/resource-packages/ > > Summary: > What if there was a backwards compatible way to transfer all of the resources that are used on every single page in your site ? CSS, JS, images, anything else ? in a single HTTP request at the start of the first visit to the page? This is what Resource Package support in browsers will let you do. > > Looking forward to hear your thoughts on this. It seems like a browser will have to essentially stop rendering until it has finished downloading the entire .zip and examined it. This will most likely slow down the time taken to render parts of the page as they arrive. From the blog post: "A given browser will probably block downloading any resources until the lists of files that are available in resource packages have been accounted for ? or there may be a way to do opportunistic requests or similar, we leave this up to the browser vendor unless there?s a compelling reason to specify how this should work." This also means that a browser would have to stop tokenizing the HTML when it hits the next > > href="site-resources.zip" /> > > The browser should start downloading a.js and b.js before > site-resources.zip. Therefore, as a developer, if I have page-specific > resources, I have some ability to get those downloading before the > manifest-blocking issue of resource packages. > I'm not totally clear on how this works today, so this might be groundless, but doesn't this present a potential problem? a.js gets included early in the page, the browser finishes loading it, it starts getting used, and then the browser encounters a resource bundle that contains a different a.js. I can also imagine scripts doing a document.write that adds a link to a resource bundle, causing similar potential issues with various already-loaded resources. PK -------------- next part -------------- An HTML attachment was scrubbed... URL: From barraclough at apple.com Wed Nov 18 00:40:29 2009 From: barraclough at apple.com (Gavin Barraclough) Date: Wed, 18 Nov 2009 00:40:29 -0800 Subject: [webkit-dev] jit for arm In-Reply-To: <1297.160.114.36.211.1258530385.squirrel@webmail.inf.u-szeged.hu> References: <21e1012a0911040832g5f20a17bjc551b8ef294460ac@mail.gmail.com> <21e1012a0911040837j763f0fe2t2fb2819e8704def6@mail.gmail.com> <1297.160.114.36.211.1258530385.squirrel@webmail.inf.u-szeged.hu> Message-ID: <24DB2612-6458-4560-8E6C-70E602D52C20@apple.com> From http://lists.webkit.org/: List Description webkit-help [no description available] Hmmm, yes, there would seem to be some scope to make that a little more descriptive! ;-) G. On Nov 17, 2009, at 11:46 PM, Zoltan Herczeg wrote: > Hi, > > seems the original mail was sent to both webkit-dev and webkit-help. > My > reply was on webkit-help, and the discussion continued there. > > https://lists.webkit.org/pipermail/webkit-help/2009-November/000380.html > > Perhaps we should clarify better the purpose of these mailing lists, > since > if people can't decide which list is better for them, they do double > posts. > > Zoltan > >> On Nov 4, 2009, at 8:37 AM, ll Jefferry wrote: >> >>> Hi, >>> >>> when i reading the jit for arm source code, i am not very clear the >>> functionality of the flowing functions: >>> ctiTrampoline >> >> This code is used when entering from the C runtime into JIT generated >> code. JIT generated code does not necessarily respect C calling >> conventions, so this routine sets up the stack frame, preserves >> registers, etc, as necessary to allow the JIT code to be run. >> >>> ctiVMThrowTrampoline >> >> To perform certain operations the JIT will call back into C code. >> Usually the C callback can just return in a perfectly normal fashion >> and continue execution once it has completed, however in the case >> that >> an exception is thrown special handling is required to change the >> control flow. The return address of the C callback is instead >> changed >> to point to this, and this piece of code handles looking up the >> exception handler at which execution will be resumed. >> >>> ctiOpThrowNotCaught >> >> This is used to from within cti_op_throw, which implements the >> 'throw' >> keyword in JavaScript. The cti_op_throw method will attempt to look >> up a handler routine that catches the exception. However if the >> exception is not caught it is necessary to force an early termination >> of JIT execution. The cti_op_throw C callback always modifies its >> return address, either to point to the code for the appropriate >> exception handler to catch the exception, or to ctiOpThrowNotCaught >> if >> no handler is found. >> >>> >>> could you explain to me? >>> and another question is that: in cacheFlush function, why the >>> system call number is 0xf0002? if it is defined by the toolchain? >> >> Zoltan, Gabor? >> >>> >>> >>> thanks! >>> >>> BR, >>> Jeff >>> >>> _______________________________________________ >>> webkit-dev mailing list >>> webkit-dev at lists.webkit.org >>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >> >> _______________________________________________ >> webkit-dev mailing list >> webkit-dev at lists.webkit.org >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >> > > From jorlow at chromium.org Wed Nov 18 02:37:51 2009 From: jorlow at chromium.org (Jeremy Orlow) Date: Wed, 18 Nov 2009 10:37:51 +0000 Subject: [webkit-dev] Staging WebSocket protocol deployment In-Reply-To: References: <20FACD6D-03FC-4FA8-8350-1445B2E482F3@webkit.org> <5dd9e5c50911131549k79dd37a3p87bbec9dc4ca5559@mail.gmail.com> <5dd9e5c50911131639k7b20b932u8fe0d730d545b6bd@mail.gmail.com> <7789133a0911131801g3627dbfcrfdec4d00feb940f4@mail.gmail.com> <7789133a0911151519y3d8fc1des53773430b9afd5f5@mail.gmail.com> <9124e09b0911151718u654a4deaoc5fbb863caf58c04@mail.gmail.com> <4E82A81D-0C99-4A60-9534-6ED08B23E770@apple.com> Message-ID: <5dd9e5c50911180237i728039f8j5963e00201a77363@mail.gmail.com> I think 3 sounds best. 4 seems reasonable. If we need to go with 1 or 2, we should talk to Mozilla to decide whether to "standardize" on the x or use our own prefixes. If we go with option 3, I think a WebKit blog post would be a good way to make out intentions for WebSockets clear. On Wed, Nov 18, 2009 at 4:38 AM, Fumitoshi Ukai (????) wrote: > > > On Wed, Nov 18, 2009 at 6:08 AM, Maciej Stachowiak wrote: > >> >> On Nov 15, 2009, at 5:18 PM, Yuzo Fujishima wrote: >> >> Hi, >>> >>> I'm against prefixing with "webkit-" because of the following reasons. >>> >>> Reason 1: It connotes that the feature is experimental. That means there >>> will be less developers seriously use that feature. Without serious use, >>> we'll have less serious feedbacks from the real world. If the Web Socket >>> has serious flaws, we should rather know them sooner than later. I'd say >>> only serious uses can help us find the flaws faster. >>> >> >> I think this captures the root of the disagreement. Personally, I would >> like to do something to send the message that WebSocket is still somewhat >> experimental. It's true that the spec has been in development for a long >> time. But we are only now seeing the first client-side and server-side >> implementations. A number of issues were discovered in that process, and I'd >> personally like to see some more experimental implementations before we lose >> the ability to make incompatible changes. See below for some specific >> suggestions. >> >> >> >>> Reason 2: What should other browser vendors do? Should they use >>> chrome-ws, firefox-ws, ie-ws, opera-ws, ..., etc? I believe at least >>> developers >>> will not happy with that. If the vendors need to reach the consensus on >>> the >>> common experimental name, say prelim-ws, then why not just use ws >>> instead? >>> >> >> Historically, we haven't had a problem with WebKit-prefixed features - it >> seems that other browser vendors implement under their own prefix and >> content adapts to deal. >> >> Anyway, getting back to the suggestions... I think it's reasonable at this >> point to indicate that the WebSocket protocol is somewhat experimental >> (probably more so than the API). I will recommend doing something along >> those lines for the next release of Safari. If we can get rough consensus >> within the WebKit community that we should label the protocol experimental, >> and how we should do so, then we can just make the change in WebKit and >> vendor releases will follow along. >> >> Here is an extended list of ideas (ones that I think are practically >> doable): >> >> 1) Change the URI schemes to "webkit-ws" and "webkit-wss" - the vendor >> prefix strategy. >> 2) Change the URI schemes to "x-ws" and "x-wss" - a vendor-independent >> experimental prefix. >> 3) Don't change the URI schemes at all, but communicate in some public way >> that the protocol is not completely locked down yet, and we are largely >> looking for early adopter feedback. We could do this in the form of a WebKit >> blog post, for example. And we could reinforce that in developer >> documentation for WebKit-based products. >> 4) Support both unprefixed and prefixed URI schemes, and in addition >> publicize that we will maintain compatibility for the prefixed URI scheme >> but the unprefixed version may have to change (combo of 3 and either 1 or >> 2). >> 5) Make the feature runtime switchable (using some semi-hidden UI) and off >> by default. >> >> I'd like to hear opinions on which of these is best. >> > > I vote option (3). > > Even if we keep current protocol stack with prefixed URI, I'm wondering > any websocket server implementation will keep compatibility with procotol of > our prefixed URI.. > Or, if some websocket server implementation keeps compatible with prefixed > URI, I believe it's worse situation for future. > -- > ukai > >> >> I'd also like to hear if anyone feels that we should send the message that >> the WebSocket Protocol is production quality and we promise full >> compatibility going forward. Does anyone truly feel this way? >> >> Regards, >> Maciej >> >> > > _______________________________________________ > webkit-dev mailing list > webkit-dev at lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pmuellr at muellerware.org Wed Nov 18 07:49:19 2009 From: pmuellr at muellerware.org (Patrick Mueller) Date: Wed, 18 Nov 2009 10:49:19 -0500 Subject: [webkit-dev] Making browsers faster: Resource Packages In-Reply-To: <2ef6228a0911171419v11497707je3c219856d66e150@mail.gmail.com> References: <2ef6228a0911161947w1067225bxdfe0eccd00e37bd8@mail.gmail.com> <2ef6228a0911171419v11497707je3c219856d66e150@mail.gmail.com> Message-ID: Alexander Limi wrote: > Good people of Webkit! > > We'd all like for the web to be faster, and therefore I'd love your feedback > on my proposal ? it would be great to see support for this in additional > browsers, not just Firefox: > > http://limi.net/articles/resource-packages/ > > Summary: > What if there was a backwards compatible way to transfer all of the > resources that are used on every single page in your site ? CSS, JS, images, > anything else ? in a single HTTP request at the start of the first visit to > the page? This is what Resource Package support in browsers will let you do. > > Looking forward to hear your thoughts on this. I happened to open a bug on this, early this morning: https://bugs.webkit.org/show_bug.cgi?id=31621 WebKit already supports something similiar - webarchive's. Main difference being that webarchives contain the main resource as well as the sub-resources. Perhaps some of the same machinery can be reused there though. Though ... makes me wonder ... why not have a mode of supporting the main resource as well? Go from two downloads down to one. You'd just need a convention for specifying the "main" resource in the .zip file ... -- Patrick Mueller - http://muellerware.org From pmuellr at muellerware.org Wed Nov 18 08:01:27 2009 From: pmuellr at muellerware.org (Patrick Mueller) Date: Wed, 18 Nov 2009 11:01:27 -0500 Subject: [webkit-dev] WebKit on the server side In-Reply-To: References: Message-ID: Sergiy Temnikov wrote: > Hi, > > We are working on a new application server that uses WebKit for > server-side JavaScript execution (and remote JavaScript debugging > too). ... For example, the first thing we had to > deal with is the JS debugger. Debugger interface is defined in > JavaScriptCore but its implementation lives in WebCore. Most of the > debugger's implementation is abstract except for the part which sends > event notifications to pages and frames objects which are GUI > dependent and so can not be used in a faceless server application. So > we basically copied the source of the existing debugger, commented > out GUI related calls and added some stuff to transform it into a > debugger which can be controlled remotely over the network. I would > be happy to contribute to the WebKit project to add a layer of > abstraction to the existing debugger implementation to cut its > dependence on GUI and move it to JavaScriptCore from WebCore's > inspector. It would be interesting to see this. Open a bug and contribute a patch. There's two reasons I think this is interesting: - would be useful for embedded clients. For instance, if this is the current state-of-the-art for debugging Palm's WebOS apps, which are (in my understanding) running in WebKit - http://is.gd/4RKuh - then a remote debug interface would be incredibly useful, assuming you had a nice client. - just cleaning up the interfaces between the debugger and debugging clients to begin with would probably be useful. -- Patrick Mueller - http://muellerware.org From ejpbruel at gmail.com Wed Nov 18 09:06:43 2009 From: ejpbruel at gmail.com (=?ISO-8859-1?Q?Eddy_Bru=EBl?=) Date: Wed, 18 Nov 2009 18:06:43 +0100 Subject: [webkit-dev] Made a debug build of WebKit.Framework. GDB ignores breakpoints? Message-ID: <3321f8b20911180906i110d2d89q5d010f25a81cdd4b@mail.gmail.com> Hi guys, I recently found a potential bug in WebKit: https://bugs.webkit.org/show_bug.cgi?id=31607 It's fairly crucial for me that this feature should work as advocated (or that there is at least a possible workaround for it), so I thought I'd take a shot a finding the bug myself. I've checked out the most recent WebKit sources, and made a debug build. I then linked my program against the resulting WebKit.Framework, and used the headers in the corresponding WebKit.Framework/Headers directory. I can now set breakpoints in my own code, and then do a stack trace to see which WebKit source file I came from. Problem is, next I tried setting breakpoints in these source files, but these seem to be completely ignored by GDB altogether. It stops execution just fine on the breakpoints in my own source file, just not on those in the WebKit source files (even though these functions are part of the stack trace, and are therefore definitely being called). Without any way of setting breakpoints in the WebKit source code I have no realistic hope of ever finding the problem myself, so I hope you guys can help me out here. Is there anything obvious that I'm doing wrong here? I'm fairly new at debugging external libraries, so maybe I am overlooking something. Cheers, Eddy -------------- next part -------------- An HTML attachment was scrubbed... URL: From darin at apple.com Wed Nov 18 09:53:22 2009 From: darin at apple.com (Darin Adler) Date: Wed, 18 Nov 2009 09:53:22 -0800 Subject: [webkit-dev] descriptions of mailing lists In-Reply-To: <24DB2612-6458-4560-8E6C-70E602D52C20@apple.com> References: <21e1012a0911040832g5f20a17bjc551b8ef294460ac@mail.gmail.com> <21e1012a0911040837j763f0fe2t2fb2819e8704def6@mail.gmail.com> <1297.160.114.36.211.1258530385.squirrel@webmail.inf.u-szeged.hu> <24DB2612-6458-4560-8E6C-70E602D52C20@apple.com> Message-ID: <356BCBCF-2DD9-4C53-A776-40CCE17A6FF8@apple.com> On Nov 18, 2009, at 12:40 AM, Gavin Barraclough wrote: > From http://lists.webkit.org/: > List Description > webkit-help [no description available] > > Hmmm, yes, there would seem to be some scope to make that a little more descriptive! ;-) describes the lists. webkit-help is for requests for help with building webkit, using WebKit's APIs, embedding WebKit, porting WebKit, and so forth. webkit-dev is for discussion of WebKit development. We should get those same descriptions visible at lists.webkit.org, and, I suppose, get more strict about sending people to webkit-help instead of webkit-dev when they arrive in the wrong place. And refine those descriptions if they are not specific enough. -- Darin From ap at webkit.org Wed Nov 18 10:03:21 2009 From: ap at webkit.org (Alexey Proskuryakov) Date: Wed, 18 Nov 2009 10:03:21 -0800 Subject: [webkit-dev] normalizing namespace indenting In-Reply-To: References: Message-ID: <9F758CC1-E5CB-40BF-BF0F-3E9A07694806@webkit.org> 16.11.2009, ? 19:54, Chris Jerdonek ???????(?): > Second, do people prefer nested namespace blocks to end with the > fully-qualified name (e.g. // namespace JSC::WREC) or just the final > name (e.g. // namespace WREC)? I have seen both. I actually prefer no comment after the namespace ending brace. If I have any concerns about namespaces not being properly closed, I won't believe the comment anyway, and will check by double-clicking on the closing brace to select the block. And if I trust that the namespace structure is correct, then it's just visual noise. - WBR, Alexey Proskuryakov From darin at apple.com Wed Nov 18 10:07:07 2009 From: darin at apple.com (Darin Adler) Date: Wed, 18 Nov 2009 10:07:07 -0800 Subject: [webkit-dev] normalizing namespace indenting In-Reply-To: <9F758CC1-E5CB-40BF-BF0F-3E9A07694806@webkit.org> References: <9F758CC1-E5CB-40BF-BF0F-3E9A07694806@webkit.org> Message-ID: <24EE8AFB-867E-4A68-AE14-7B3B7355494E@apple.com> On Nov 18, 2009, at 10:03 AM, Alexey Proskuryakov wrote: > I actually prefer no comment after the namespace ending brace. If I have any concerns about namespaces not being properly closed, I won't believe the comment anyway, and will check by double-clicking on the closing brace to select the block. And if I trust that the namespace structure is correct, then it's just visual noise. I agree with Alexey on this point. -- Darin From ap at webkit.org Wed Nov 18 10:22:48 2009 From: ap at webkit.org (Alexey Proskuryakov) Date: Wed, 18 Nov 2009 10:22:48 -0800 Subject: [webkit-dev] Made a debug build of WebKit.Framework. GDB ignores breakpoints? In-Reply-To: <3321f8b20911180906i110d2d89q5d010f25a81cdd4b@mail.gmail.com> References: <3321f8b20911180906i110d2d89q5d010f25a81cdd4b@mail.gmail.com> Message-ID: <56ACC620-A43E-4755-8DB5-49679C386725@webkit.org> 18.11.2009, ? 9:06, Eddy Bru?l ???????(?): > I've checked out the most recent WebKit sources, and made a debug > build. I then linked my > program against the resulting WebKit.Framework, and used the headers > in the corresponding > WebKit.Framework/Headers directory Did you try the steps in ? There is no need to rebuild your application against a local WebKit build. - WBR, Alexey Proskuryakov From JasonR at bsquare.com Wed Nov 18 10:50:48 2009 From: JasonR at bsquare.com (Jason Rukman) Date: Wed, 18 Nov 2009 10:50:48 -0800 Subject: [webkit-dev] how to run mozilla test cases one by one using JSC In-Reply-To: References: <21e1012a0911060014q78a5cdb0sa0d2d07ab97ea427@mail.gmail.com> Message-ID: I had to do this same thing as I didn't have perl on our platform. I found modifying the perl script to output just the commands instead of actually running them was helpful. I could then just grab this output and run it wherever. Regards, Jason. -----Original Message----- From: webkit-dev-bounces at lists.webkit.org [mailto:webkit-dev-bounces at lists.webkit.org] On Behalf Of Oliver Hunt Sent: Tuesday, November 17, 2009 3:47 PM To: ll Jefferry Cc: WebKit Development Subject: Re: [webkit-dev] how to run mozilla test cases one by one using JSC You should simply copy the entire command line you see in the run-javascriptcore-tests output, eg. /path/to/jsc -s -f ./ecma/shell.js -f ./ecma/Date/15.9.5.17.js --Oliver On Nov 6, 2009, at 12:14 AM, ll Jefferry wrote: > Hi, > > I bring up webkit with jit on my stb box. I want to test the jit if it is fine. When i run the mozilla test cases, i found that it need the perl tools. But my platform has not the perl environment, my question is that: > > can i run the test cases one by one under shell environment? such us ./jsc -f xxxx.js > and can you tell me how to do this? when i run "./jsc -f ./emac/array/15-4.1.js", it always exit with code 3. That means it get error. > > > BR, > Jeff > _______________________________________________ > webkit-dev mailing list > webkit-dev at lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev _______________________________________________ webkit-dev mailing list webkit-dev at lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev From limi at mozilla.com Wed Nov 18 11:56:30 2009 From: limi at mozilla.com (Alexander Limi) Date: Wed, 18 Nov 2009 11:56:30 -0800 Subject: [webkit-dev] Making browsers faster: Resource Packages In-Reply-To: <2ef6228a0911171756v4562fc55n4812808fd9b782dd@mail.gmail.com> References: <2ef6228a0911161947w1067225bxdfe0eccd00e37bd8@mail.gmail.com> <2ef6228a0911171419v11497707je3c219856d66e150@mail.gmail.com> <2ef6228a0911171736j6f93322and9c79b7f73bdeb1e@mail.gmail.com> <2ef6228a0911171756v4562fc55n4812808fd9b782dd@mail.gmail.com> Message-ID: <2ef6228a0911181156q4f7f8ea5x33466ec39791602c@mail.gmail.com> On Tue, Nov 17, 2009 at 5:56 PM, Alexander Limi wrote: > On Tue, Nov 17, 2009 at 5:53 PM, James Robinson wrote: > >> Yes, actual numbers would be nice to have. > > > Steve Souders just emailed me some preliminary numbers from a bunch of > major web sites, so that should be on his blog shortly. > Numbers are up: http://www.stevesouders.com/blog/2009/11/18/fewer-requests-through-resource-packages/ -- Alexander Limi ? Firefox User Experience ? http://limi.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at belshe.com Wed Nov 18 14:47:37 2009 From: mike at belshe.com (Mike Belshe) Date: Wed, 18 Nov 2009 14:47:37 -0800 Subject: [webkit-dev] Making browsers faster: Resource Packages In-Reply-To: <2ef6228a0911181156q4f7f8ea5x33466ec39791602c@mail.gmail.com> References: <2ef6228a0911161947w1067225bxdfe0eccd00e37bd8@mail.gmail.com> <2ef6228a0911171419v11497707je3c219856d66e150@mail.gmail.com> <2ef6228a0911171736j6f93322and9c79b7f73bdeb1e@mail.gmail.com> <2ef6228a0911171756v4562fc55n4812808fd9b782dd@mail.gmail.com> <2ef6228a0911181156q4f7f8ea5x33466ec39791602c@mail.gmail.com> Message-ID: <2a10ed240911181447u3c11c24bu53ce7cac2d293a41@mail.gmail.com> Overall, I think the general idea. I'm concerned about the head-of-line blocking that it introduces. If an administrator poorly constructs the bundle, he could significantly hurt perf. Instead of using gzip, you could use a framer which chunked items before gzipping. This might be more trouble than it is worth. Inside the browser, the caching is going to be kind of annoying. Example: Say foo.zip contains foo.gif and baz.gif, and foo.zip expires in one week. When the browser downloads the manifest, it needs to "unfold it" and store foo.gif and baz.gif in the cache. Then, a week later, if the browser tries to use foo.gif, it will be expired; does the browser fetch foo.zip? or just foo.gif? Obviously, either will "work". But now you've got an inconsistent cache. If you hit another page which references foo.zip next, you'll download the whole zip file when all you needed was bar.gif. This is probably a minor problem - I can't see this being very significant in practice. Did you consider having the resources for a bundle be addressed such as: http://www.foo.com/bundle.zip/foo.gif ? This would eliminate the problem of two names for the same resource. Maybe this was your intent - the spec was unclear about the identity (URL) of the bundled resources. I think it is a good enough idea to warrant an implementation. Once we have data about performance, it will be clear whether this should be made official or not. Mike On Wed, Nov 18, 2009 at 11:56 AM, Alexander Limi wrote: > On Tue, Nov 17, 2009 at 5:56 PM, Alexander Limi wrote: > >> On Tue, Nov 17, 2009 at 5:53 PM, James Robinson wrote: >> >>> Yes, actual numbers would be nice to have. >> >> >> Steve Souders just emailed me some preliminary numbers from a bunch of >> major web sites, so that should be on his blog shortly. >> > > Numbers are up: > > http://www.stevesouders.com/blog/2009/11/18/fewer-requests-through-resource-packages/ > > > -- > Alexander Limi ? Firefox User Experience ? http://limi.net > > > > _______________________________________________ > webkit-dev mailing list > webkit-dev at lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at belshe.com Wed Nov 18 14:48:06 2009 From: mike at belshe.com (Mike Belshe) Date: Wed, 18 Nov 2009 14:48:06 -0800 Subject: [webkit-dev] Making browsers faster: Resource Packages In-Reply-To: <2a10ed240911181447u3c11c24bu53ce7cac2d293a41@mail.gmail.com> References: <2ef6228a0911161947w1067225bxdfe0eccd00e37bd8@mail.gmail.com> <2ef6228a0911171419v11497707je3c219856d66e150@mail.gmail.com> <2ef6228a0911171736j6f93322and9c79b7f73bdeb1e@mail.gmail.com> <2ef6228a0911171756v4562fc55n4812808fd9b782dd@mail.gmail.com> <2ef6228a0911181156q4f7f8ea5x33466ec39791602c@mail.gmail.com> <2a10ed240911181447u3c11c24bu53ce7cac2d293a41@mail.gmail.com> Message-ID: <2a10ed240911181448r67ea9e1mc31c2db5ce70e278@mail.gmail.com> On Wed, Nov 18, 2009 at 2:47 PM, Mike Belshe wrote: > Overall, I think the general idea. I meant to say "Overall I like the general idea" > > I'm concerned about the head-of-line blocking that it introduces. If an > administrator poorly constructs the bundle, he could significantly hurt > perf. Instead of using gzip, you could use a framer which chunked items > before gzipping. This might be more trouble than it is worth. > > Inside the browser, the caching is going to be kind of annoying. Example: > Say foo.zip contains foo.gif and baz.gif, and foo.zip expires in one week. > When the browser downloads the manifest, it needs to "unfold it" and store > foo.gif and baz.gif in the cache. Then, a week later, if the browser tries > to use foo.gif, it will be expired; does the browser fetch foo.zip? or just > foo.gif? Obviously, either will "work". But now you've got an inconsistent > cache. If you hit another page which references foo.zip next, you'll > download the whole zip file when all you needed was bar.gif. This is > probably a minor problem - I can't see this being very significant in > practice. Did you consider having the resources for a bundle be addressed > such as: http://www.foo.com/bundle.zip/foo.gif ? This would eliminate > the problem of two names for the same resource. Maybe this was your intent > - the spec was unclear about the identity (URL) of the bundled resources. > > I think it is a good enough idea to warrant an implementation. Once we > have data about performance, it will be clear whether this should be made > official or not. > > Mike > > > On Wed, Nov 18, 2009 at 11:56 AM, Alexander Limi wrote: > >> On Tue, Nov 17, 2009 at 5:56 PM, Alexander Limi wrote: >> >>> On Tue, Nov 17, 2009 at 5:53 PM, James Robinson wrote: >>> >>>> Yes, actual numbers would be nice to have. >>> >>> >>> Steve Souders just emailed me some preliminary numbers from a bunch of >>> major web sites, so that should be on his blog shortly. >>> >> >> Numbers are up: >> >> http://www.stevesouders.com/blog/2009/11/18/fewer-requests-through-resource-packages/ >> >> >> -- >> Alexander Limi ? Firefox User Experience ? http://limi.net >> >> >> >> _______________________________________________ >> webkit-dev mailing list >> webkit-dev at lists.webkit.org >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric at webkit.org Wed Nov 18 14:57:54 2009 From: eric at webkit.org (Eric Seidel) Date: Wed, 18 Nov 2009 14:57:54 -0800 Subject: [webkit-dev] Unexpected Outage: commit-queue In-Reply-To: <1448d9f30911171558h717f740ex54e97dbec73f84e0@mail.gmail.com> References: <1448d9f30911131832q5c2b4d10vf98239dc0c9fc1d7@mail.gmail.com> <1448d9f30911171558h717f740ex54e97dbec73f84e0@mail.gmail.com> Message-ID: <1448d9f30911181457v6b1f0397m65a4c5979af558c7@mail.gmail.com> Update: The commit-queue is BACK! Huzzah! Thanks to Dimity for his fix. It looks like https://bugs.webkit.org/show_bug.cgi?id=31615 was the major cause of the crashes. I expect there still may be some flakiness, but our bots seem to be staying green and hopefully most of the false rejections will be gone. If your patch is still waiting in the queue (7 of the 14 pending have been processed already), you can check on it here: http://webkit-commit-queue.appspot.com/ -eric On Tue, Nov 17, 2009 at 3:58 PM, Eric Seidel wrote: > Update: > > The queue is still down. ?I tried turning it on this morning and of > the 5 patches I let it process, it rejected 4 of them due to > https://bugs.webkit.org/show_bug.cgi?id=31461 before I turned it off. > > Good news: some progress has been made towards understanding > https://bugs.webkit.org/show_bug.cgi?id=30835 (which is likely the > same root cause as https://bugs.webkit.org/show_bug.cgi?id=31461). > > I'll post again when the queue is back on. > > -eric > > On Fri, Nov 13, 2009 at 6:32 PM, Eric Seidel wrote: >> I've turned off the commit-queue until we can find a solution to >> https://bugs.webkit.org/show_bug.cgi?id=31461. >> >> The commit-queue was rejecting more than half the patches queued in it >> due to that bug, rendering it useless. >> >> I'll post to webkit-dev once the queue is turned on again (hopefully Monday). >> >> -eric >> >> p.s. You can always check the status of the queue by loading >> http://webkit-commit-queue.appspot.com/ >> > From limi at mozilla.com Wed Nov 18 14:59:15 2009 From: limi at mozilla.com (Alexander Limi) Date: Wed, 18 Nov 2009 14:59:15 -0800 Subject: [webkit-dev] Making browsers faster: Resource Packages In-Reply-To: <2a10ed240911181447u3c11c24bu53ce7cac2d293a41@mail.gmail.com> References: <2ef6228a0911161947w1067225bxdfe0eccd00e37bd8@mail.gmail.com> <2ef6228a0911171419v11497707je3c219856d66e150@mail.gmail.com> <2ef6228a0911171736j6f93322and9c79b7f73bdeb1e@mail.gmail.com> <2ef6228a0911171756v4562fc55n4812808fd9b782dd@mail.gmail.com> <2ef6228a0911181156q4f7f8ea5x33466ec39791602c@mail.gmail.com> <2a10ed240911181447u3c11c24bu53ce7cac2d293a41@mail.gmail.com> Message-ID: <2ef6228a0911181459y4d00135dp93f94f361bdaace4@mail.gmail.com> Cool, thanks for the feedback. It does seem like most people (well, outside of this list ;) like the direction a lot. The one issue that I agree with, and would like to find an elegant solution to, is how to specify the manifest in the HTML instead of in the zip file to reduce blocking and start parsing earlier. I can't say that I know enough about HTML specifics to have an immediately useful answer here, I assume the tag can't have content inside of it that could serve as the manifest? -- Alexander Limi ? Firefox User Experience ? http://limi.net On Wed, Nov 18, 2009 at 2:47 PM, Mike Belshe wrote: > Overall, I think the general idea. > > I'm concerned about the head-of-line blocking that it introduces. If an > administrator poorly constructs the bundle, he could significantly hurt > perf. Instead of using gzip, you could use a framer which chunked items > before gzipping. This might be more trouble than it is worth. > > Inside the browser, the caching is going to be kind of annoying. Example: > Say foo.zip contains foo.gif and baz.gif, and foo.zip expires in one week. > When the browser downloads the manifest, it needs to "unfold it" and store > foo.gif and baz.gif in the cache. Then, a week later, if the browser tries > to use foo.gif, it will be expired; does the browser fetch foo.zip? or just > foo.gif? Obviously, either will "work". But now you've got an inconsistent > cache. If you hit another page which references foo.zip next, you'll > download the whole zip file when all you needed was bar.gif. This is > probably a minor problem - I can't see this being very significant in > practice. Did you consider having the resources for a bundle be addressed > such as: http://www.foo.com/bundle.zip/foo.gif ? This would eliminate > the problem of two names for the same resource. Maybe this was your intent > - the spec was unclear about the identity (URL) of the bundled resources. > > I think it is a good enough idea to warrant an implementation. Once we > have data about performance, it will be clear whether this should be made > official or not. > > Mike > > > On Wed, Nov 18, 2009 at 11:56 AM, Alexander Limi wrote: > >> On Tue, Nov 17, 2009 at 5:56 PM, Alexander Limi wrote: >> >>> On Tue, Nov 17, 2009 at 5:53 PM, James Robinson wrote: >>> >>>> Yes, actual numbers would be nice to have. >>> >>> >>> Steve Souders just emailed me some preliminary numbers from a bunch of >>> major web sites, so that should be on his blog shortly. >>> >> >> Numbers are up: >> >> http://www.stevesouders.com/blog/2009/11/18/fewer-requests-through-resource-packages/ >> >> >> -- >> Alexander Limi ? Firefox User Experience ? http://limi.net >> >> >> >> _______________________________________________ >> webkit-dev mailing list >> webkit-dev at lists.webkit.org >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at sixteenk.net Wed Nov 18 15:14:43 2009 From: steve at sixteenk.net (Steve Tickle) Date: Wed, 18 Nov 2009 23:14:43 +0000 Subject: [webkit-dev] Making browsers faster: Resource Packages In-Reply-To: <2a10ed240911181448r67ea9e1mc31c2db5ce70e278@mail.gmail.com> References: <2ef6228a0911161947w1067225bxdfe0eccd00e37bd8@mail.gmail.com> <2ef6228a0911171419v11497707je3c219856d66e150@mail.gmail.com> <2ef6228a0911171736j6f93322and9c79b7f73bdeb1e@mail.gmail.com> <2ef6228a0911171756v4562fc55n4812808fd9b782dd@mail.gmail.com> <2ef6228a0911181156q4f7f8ea5x33466ec39791602c@mail.gmail.com> <2a10ed240911181447u3c11c24bu53ce7cac2d293a41@mail.gmail.com> <2a10ed240911181448r67ea9e1mc31c2db5ce70e278@mail.gmail.com> Message-ID: Hi All, As a game developer with interests in mobile, I'd like to say overall, I think the idea sucks. Incorrectly implemented clients will end up downloading large resources multiple times, and web masters are sure to start adding every resource to pages that don't need them. As I see it, the load time issue only occurs on first load anyway, as properly implemented clients and servers should use cache directives to avoid unnecessary connections. If the first load case is a major concern (as in mobile), web masters should optimise their pages so that resources are amalgamated wherever possible. If you truly want better interactive performance from websites, add a streaming connectionless facility atop UDP, rather than complicating matters with an ad-hoc application level HTML hack. Regards, Steve 2009/11/18 Mike Belshe > > > On Wed, Nov 18, 2009 at 2:47 PM, Mike Belshe wrote: > >> Overall, I think the general idea. > > > I meant to say "Overall I like the general idea" > > > >> >> I'm concerned about the head-of-line blocking that it introduces. If an >> administrator poorly constructs the bundle, he could significantly hurt >> perf. Instead of using gzip, you could use a framer which chunked items >> before gzipping. This might be more trouble than it is worth. >> >> Inside the browser, the caching is going to be kind of annoying. Example: >> Say foo.zip contains foo.gif and baz.gif, and foo.zip expires in one week. >> When the browser downloads the manifest, it needs to "unfold it" and store >> foo.gif and baz.gif in the cache. Then, a week later, if the browser tries >> to use foo.gif, it will be expired; does the browser fetch foo.zip? or just >> foo.gif? Obviously, either will "work". But now you've got an inconsistent >> cache. If you hit another page which references foo.zip next, you'll >> download the whole zip file when all you needed was bar.gif. This is >> probably a minor problem - I can't see this being very significant in >> practice. Did you consider having the resources for a bundle be addressed >> such as: http://www.foo.com/bundle.zip/foo.gif ? This would eliminate >> the problem of two names for the same resource. Maybe this was your intent >> - the spec was unclear about the identity (URL) of the bundled resources. >> >> I think it is a good enough idea to warrant an implementation. Once we >> have data about performance, it will be clear whether this should be made >> official or not. >> >> Mike >> >> >> On Wed, Nov 18, 2009 at 11:56 AM, Alexander Limi wrote: >> >>> On Tue, Nov 17, 2009 at 5:56 PM, Alexander Limi wrote: >>> >>>> On Tue, Nov 17, 2009 at 5:53 PM, James Robinson wrote: >>>> >>>>> Yes, actual numbers would be nice to have. >>>> >>>> >>>> Steve Souders just emailed me some preliminary numbers from a bunch of >>>> major web sites, so that should be on his blog shortly. >>>> >>> >>> Numbers are up: >>> >>> http://www.stevesouders.com/blog/2009/11/18/fewer-requests-through-resource-packages/ >>> >>> >>> -- >>> Alexander Limi ? Firefox User Experience ? http://limi.net >>> >>> >>> >>> _______________________________________________ >>> webkit-dev mailing list >>> webkit-dev at lists.webkit.org >>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >>> >>> >> > > _______________________________________________ > webkit-dev mailing list > webkit-dev at lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > -- Steve Tickle sixteenk - Refined software development for mobile and web t: +44 151 324 2816 m: +44 7950 052 976 w: sixteenk.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpranke at chromium.org Wed Nov 18 15:54:56 2009 From: dpranke at chromium.org (Dirk Pranke) Date: Wed, 18 Nov 2009 15:54:56 -0800 Subject: [webkit-dev] Making browsers faster: Resource Packages In-Reply-To: <2a10ed240911181447u3c11c24bu53ce7cac2d293a41@mail.gmail.com> References: <2ef6228a0911161947w1067225bxdfe0eccd00e37bd8@mail.gmail.com> <2ef6228a0911171419v11497707je3c219856d66e150@mail.gmail.com> <2ef6228a0911171736j6f93322and9c79b7f73bdeb1e@mail.gmail.com> <2ef6228a0911171756v4562fc55n4812808fd9b782dd@mail.gmail.com> <2ef6228a0911181156q4f7f8ea5x33466ec39791602c@mail.gmail.com> <2a10ed240911181447u3c11c24bu53ce7cac2d293a41@mail.gmail.com> Message-ID: <3726d1bf0911181554l6e510590xf56d67b2b19958f5@mail.gmail.com> On Wed, Nov 18, 2009 at 2:47 PM, Mike Belshe wrote: > Overall, I think the general idea. > I'm concerned about the head-of-line blocking that it introduces. ?If an > administrator poorly constructs the bundle, he could significantly hurt > perf. ?Instead of using gzip, you could use a framer which chunked items > before gzipping. ?This might be more trouble than it is worth. > Inside the browser, the caching is going to be kind of annoying. ?Example: > ?Say foo.zip contains foo.gif and baz.gif, and foo.zip expires in one week. > ? When the browser downloads the manifest, it needs to "unfold it" and store > foo.gif and baz.gif in the cache. ?Then, a week later, if the browser tries > to use foo.gif, it will be expired; does the browser fetch foo.zip? ?or just > foo.gif? ?Obviously, either will "work". ?But now you've got an inconsistent > cache. ?If you hit another page which references foo.zip next, you'll > download the whole zip file when all you needed was bar.gif. ?This is > probably a minor problem - I can't see this being very significant in > practice. ?Did you consider having the resources for a bundle be addressed > such as: ?http://www.foo.com/bundle.zip/foo.gif ?? ?This would eliminate the > problem of two names for the same resource. ?Maybe this was your intent - > the spec was unclear about the identity (URL) of the bundled resources. > I think it is a good enough idea to warrant an implementation. ?Once we have > data about performance, it will be clear whether this should be made > official or not. > Mike > Another caching-related issue involves versioning of the archives. If version 2 of a zip contains only a few files modified since version 1, and I have version 1 cached, is there some way to take advantage of that? Can SDCH be helpful here? Also, you explicitly note that all the files in the archive should have the same expiry, but I wonder if there are ways (and if its useful) to drop that restriction as well. I think there's a lot of space for research and evaluation here, and I agree with Mike that this is a good enough idea to warrant an implementation and experimentation. -- Dirk > On Wed, Nov 18, 2009 at 11:56 AM, Alexander Limi wrote: >> >> On Tue, Nov 17, 2009 at 5:56 PM, Alexander Limi wrote: >>> >>> On Tue, Nov 17, 2009 at 5:53 PM, James Robinson >>> wrote: >>>> >>>> Yes, actual numbers would be nice to have. >>> >>> Steve Souders just emailed me some preliminary numbers from a bunch of >>> major web sites, so that should be on his blog shortly. >> >> Numbers are up: >> >> http://www.stevesouders.com/blog/2009/11/18/fewer-requests-through-resource-packages/ >> >> -- >> Alexander Limi ? Firefox User Experience ? http://limi.net >> >> >> >> _______________________________________________ >> webkit-dev mailing list >> webkit-dev at lists.webkit.org >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >> > > > _______________________________________________ > webkit-dev mailing list > webkit-dev at lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > From pkasting at google.com Wed Nov 18 15:57:55 2009 From: pkasting at google.com (Peter Kasting) Date: Wed, 18 Nov 2009 15:57:55 -0800 Subject: [webkit-dev] Making browsers faster: Resource Packages In-Reply-To: <3726d1bf0911181554l6e510590xf56d67b2b19958f5@mail.gmail.com> References: <2ef6228a0911161947w1067225bxdfe0eccd00e37bd8@mail.gmail.com> <2ef6228a0911171419v11497707je3c219856d66e150@mail.gmail.com> <2ef6228a0911171736j6f93322and9c79b7f73bdeb1e@mail.gmail.com> <2ef6228a0911171756v4562fc55n4812808fd9b782dd@mail.gmail.com> <2ef6228a0911181156q4f7f8ea5x33466ec39791602c@mail.gmail.com> <2a10ed240911181447u3c11c24bu53ce7cac2d293a41@mail.gmail.com> <3726d1bf0911181554l6e510590xf56d67b2b19958f5@mail.gmail.com> Message-ID: On Wed, Nov 18, 2009 at 3:54 PM, Dirk Pranke wrote: > Another caching-related issue involves versioning of the archives. If > version 2 of a zip contains only a few files modified since version 1, > and I have version 1 cached, is there some way to take advantage of > that? This is a specific case of my more general question, "One of your stated goals is to avoid downloading resources you already have, but even with manifests, I see no way to do this, since the client can't actually tell the server 'only send items x, y, and z'." This was the one point Alexander didn't copy in his reply mail. PK -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.jerdonek at gmail.com Wed Nov 18 18:51:26 2009 From: chris.jerdonek at gmail.com (Chris Jerdonek) Date: Wed, 18 Nov 2009 18:51:26 -0800 Subject: [webkit-dev] normalizing namespace indenting In-Reply-To: References: Message-ID: On Tue, Nov 17, 2009 at 10:39 PM, Darin Adler wrote: > On Nov 16, 2009, at 7:54 PM, Chris Jerdonek wrote: > >> So, I was wondering if we can clarify the rule to apply only to the outermost namespace declaration. > > Yes, I think we can. > >> (Consecutive declarations like "namespace JSC { namespace WREC {" would be treated as a single declaration for the purpose of this rule.) > > Neat idea, I think. Thanks. The idea stems from a syntactic sugar for "using" blocks in C# (different meaning of "using" from C++). Instead of doing this-- using (Resource resource1 = new Resource()) { using (Resource resource2 = new Resource()) { ... } } You can do this: using (Resource resource1 = new Resource()) using (Resource resource2 = new Resource()) { ... } --Chris From wangtao.adi at gmail.com Wed Nov 18 23:58:47 2009 From: wangtao.adi at gmail.com (Tony Wang) Date: Thu, 19 Nov 2009 15:58:47 +0800 Subject: [webkit-dev] function RecordSpan() in JavaScriptCore/wtf/FastMalloc.cpp Message-ID: Hi all, I am using WebKit-r51075, the lastest WebKit version. now the question: 1, line 1354 of RecordSpan() in JavaScriptCore/wtf/FastMalloc.cpp : if (span->length > 1) 2, "span->length" is type "uintptr_t", while "1" is int, are there any error potentials for this compare? 3, I run GtkLauncher on my embedded linux platform and got "signal SIGBUS" here 4, the error comes from byte-padding mostly, so, would the expression bring such issue here? 5, if it is, how to fix then? Thanks in Advance, Tony Wang -------------- next part -------------- An HTML attachment was scrubbed... URL: From ejpbruel at gmail.com Thu Nov 19 07:07:22 2009 From: ejpbruel at gmail.com (=?ISO-8859-1?Q?Eddy_Bru=EBl?=) Date: Thu, 19 Nov 2009 16:07:22 +0100 Subject: [webkit-dev] Made a debug build of WebKit.Framework. GDB ignores breakpoints? In-Reply-To: <3321f8b20911190640h7f42d1dfi989ef013a6947124@mail.gmail.com> References: <3321f8b20911180906i110d2d89q5d010f25a81cdd4b@mail.gmail.com> <56ACC620-A43E-4755-8DB5-49679C386725@webkit.org> <3321f8b20911190640q5b073b50v5d14b9856e950f61@mail.gmail.com> <3321f8b20911190640h7f42d1dfi989ef013a6947124@mail.gmail.com> Message-ID: <3321f8b20911190707u1c0e7a15xd10e02a0e93d6f1a@mail.gmail.com> Problem solved. If I keep the XCode project for WebCore open whilst debugging my own application, breakpoints suddenly work. On Thu, Nov 19, 2009 at 3:40 PM, Eddy Bru?l wrote: > > > ---------- Forwarded message ---------- > From: Eddy Bru?l > Date: Thu, Nov 19, 2009 at 3:40 PM > Subject: Re: [webkit-dev] Made a debug build of WebKit.Framework. GDB > ignores breakpoints? > To: Alexey Proskuryakov > > > I have now. I built my application against the WebKit Framework that came > with OS X, > then tried setting as custom executable in the WebCore project. Running it > starts my > project, alright, but any breakpoints I set in Webcore source files are > still merrily > ignored by GDB. What's going on? > > On Wed, Nov 18, 2009 at 7:22 PM, Alexey Proskuryakov wrote: > >> >> 18.11.2009, ? 9:06, Eddy Bru?l ???????(?): >> >> >> I've checked out the most recent WebKit sources, and made a debug build. >>> I then linked my >>> program against the resulting WebKit.Framework, and used the headers in >>> the corresponding >>> WebKit.Framework/Headers directory >>> >> >> >> Did you try the steps in ? There >> is no need to rebuild your application against a local WebKit build. >> >> - WBR, Alexey Proskuryakov >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsherry at adobe.com Thu Nov 19 07:24:35 2009 From: rsherry at adobe.com (Rudi Sherry) Date: Thu, 19 Nov 2009 07:24:35 -0800 Subject: [webkit-dev] Made a debug build of WebKit.Framework. GDB ignores breakpoints? In-Reply-To: <3321f8b20911190707u1c0e7a15xd10e02a0e93d6f1a@mail.gmail.com> References: <3321f8b20911180906i110d2d89q5d010f25a81cdd4b@mail.gmail.com> <56ACC620-A43E-4755-8DB5-49679C386725@webkit.org> <3321f8b20911190640q5b073b50v5d14b9856e950f61@mail.gmail.com> <3321f8b20911190640h7f42d1dfi989ef013a6947124@mail.gmail.com> <3321f8b20911190707u1c0e7a15xd10e02a0e93d6f1a@mail.gmail.com> Message-ID: <3FF651F4-FD1A-4A8A-9709-A9F166D6AAA4@adobe.com> Before starting to debug, see the menu item Debug->Show- >SharedLibraries... See that the default for "User Libraries" is "Default (External)". That means that anything that is NOT being built by your project (i.e. the WebCore framework), when it gets loaded, will only load exported symbols. You're not hitting the breakpoints because it's not loading the symbols for WebCore so can't resolve the breakpoints. In Preferences->Debugging, turn OFF "Load symbols lazily" and that should allow you to debug without keeping the WebCore library open. Don't know if you have to quit Xcode and relaunch in order to make that stick, you might have to. Rudi On Nov 19, 2009, at 7:07 AM, Eddy Bru?l wrote: > Problem solved. If I keep the XCode project for WebCore open whilst > debugging my own application, breakpoints suddenly work. > > On Thu, Nov 19, 2009 at 3:40 PM, Eddy Bru?l > wrote: > > > ---------- Forwarded message ---------- > From: Eddy Bru?l > Date: Thu, Nov 19, 2009 at 3:40 PM > Subject: Re: [webkit-dev] Made a debug build of WebKit.Framework. > GDB ignores breakpoints? > To: Alexey Proskuryakov > > > I have now. I built my application against the WebKit Framework that > came with OS X, > then tried setting as custom executable in the WebCore project. > Running it starts my > project, alright, but any breakpoints I set in Webcore source files > are still merrily > ignored by GDB. What's going on? > > On Wed, Nov 18, 2009 at 7:22 PM, Alexey Proskuryakov > wrote: > > 18.11.2009, ? 9:06, Eddy Bru?l ???????(?): > > > I've checked out the most recent WebKit sources, and made a debug > build. I then linked my > program against the resulting WebKit.Framework, and used the headers > in the corresponding > WebKit.Framework/Headers directory > > > Did you try the steps in ? > There is no need to rebuild your application against a local WebKit > build. > > - WBR, Alexey Proskuryakov > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From darin at apple.com Thu Nov 19 10:35:05 2009 From: darin at apple.com (Darin Adler) Date: Thu, 19 Nov 2009 10:35:05 -0800 Subject: [webkit-dev] function RecordSpan() in JavaScriptCore/wtf/FastMalloc.cpp In-Reply-To: References: Message-ID: This question is for webkit-help, not webkit-dev. See for the purposes of the lists. -- Darin From gns at gnome.org Thu Nov 19 11:59:10 2009 From: gns at gnome.org (Gustavo Noronha Silva) Date: Thu, 19 Nov 2009 17:59:10 -0200 Subject: [webkit-dev] How to deal with localized strings In-Reply-To: References: Message-ID: <1258660750.28940.11.camel@goiaba.horta> On Fri, 2009-08-28 at 17:21 +0200, Michelangelo De Simone wrote: > 2009/8/28 Michelangelo De Simone : > > > Any illuminating suggestion?:) > > It's nice to self-answer:) Anyway, there's no need for "illuminating > suggestions", returning an empty String on each port seems a good > choice.:) Sorry I am very late =). I got here from the test failure for GTK+. I think a better approach for our port at least would be to have the default, untranslated strings, instead of empty strings. I am going to patch the code to add the expected strings for the test. Thanks, -- Gustavo Noronha Silva GNOME Project From codedread at gmail.com Thu Nov 19 12:29:31 2009 From: codedread at gmail.com (Jeff Schiller) Date: Thu, 19 Nov 2009 14:29:31 -0600 Subject: [webkit-dev] Non-Scaling Stroke feature (SVGT 1.2) In-Reply-To: References: <1258439607.29274.10.camel@dirk-laptop> Message-ID: Does anyone else have any comments on this? I was told to bring it up here for discussion. Based on no one screaming bloody murder, I intend to continue working on the patch. Currently non-scaling-stroke seems to work fine for colored strokes. There is a bug with gradient strokes that I will work out. I also need to implement some tests for this - I'm not very happy with how pixel tests work in WebKit-land (per platform comparing to rasters). Is there anything like Mozilla's reftests in WebKit? https://developer.mozilla.org/en/Creating_reftest-based_unit_tests In this case, I'd generate reference SVG that has the constant stroke in green and then test the non-scaling-stroke against this reference rendering. Then I wouldn't have to worry about platform-specific renderings as the two renderings of SVGs should match. Regards, Jeff On Tue, Nov 17, 2009 at 12:37 AM, Jeff Schiller wrote: > Hi Dirk, > > I wasn't aware of another bug, sorry. > > Actually on the patch that I have already attached to that bug, it > seems to work in the few test cases I've been able to find (my own and > a couple from the SVGT 1.2 test suite). ?While stroking, I transform > the path with the CTM of the context and un-transform the context > (with its inverse matrix). ?Then I undo that after stroking. > > The only thing that may be a problem is the dirty rectangle that is > created by paths with non-scaled-strokes. ?I need to look at that > after generating some tests. > > Regards, > Jeff > > On Tue, Nov 17, 2009 at 12:33 AM, Dirk Schulze wrote: >> Hi, >> >> I thougt that we already had a bug about this. It is a good idea to >> support this feature in general. Even if our support for SVG 1.1 is not >> perfect, we should think about some features of SVG 1.2 like media >> support and also non scaling strokes. But implementing non scaling >> strokes is not that easy. On SVG we transform the context multiple times >> (translate, scale, skew) and stroke the path at the end. We may think >> about transforming the path instead of the context but there might be >> more problems on doing that. >> >> -Dirk >> >> Am Montag, den 16.11.2009, 16:23 -0600 schrieb Jeff Schiller: >>> Hello, >>> >>> I am interested in having broader support for non-scaling stroke on >>> SVG shapes. ?This is a SVGT 1.2 feature: >>> http://www.w3.org/TR/SVGTiny12/painting.html#NonScalingStroke >>> >>> This adds a CSS property and attribute: vector-effect. ?This property >>> can have three values: ?none (default), inherit, or >>> non-scaling-stroke. >>> >>> When non-scaling-stroke, the stroke (outline) of a shape would >>> maintain its specified width regardless of the transforms applied to >>> the shape. ?This is very useful when importing foreign SVG into new >>> documents and in GIS/mapping scenarios (for instance, zooming in on a >>> map would not "fatten" the driving directions path). >>> >>> I realize that WebKit has been generally not interested in SVGT 1.2, >>> but I feel it makes sense to cherry-pick certain features that really >>> do improve SVG on the web. ?Non-scaling stroke is one of these >>> features. ?FWIW, Opera has implemented this feature since version 9.5. >>> >>> I have opened a bug and supplied a patch that gets this off the ground >>> in WebKit: ?https://bugs.webkit.org/show_bug.cgi?id=31438 ?I only need >>> to figure out how to add some tests (need to understand how pixel >>> tests work in WebKit). >>> >>> Darin Adler requested that I bring this up on this list for discussion. >>> >>> Thanks, >>> Jeff Schiller >>> _______________________________________________ >>> webkit-dev mailing list >>> webkit-dev at lists.webkit.org >>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >> >> >> > From godyee at gmail.com Thu Nov 19 17:46:48 2009 From: godyee at gmail.com (=?UTF-8?B?UnlhblllZS/lj7bmmZQ=?=) Date: Fri, 20 Nov 2009 09:46:48 +0800 Subject: [webkit-dev] is there any method to get current focus widget in webkit? Message-ID: <2eeb9e8e0911191746r4319713ehdd31b49f553a4264@mail.gmail.com> I am working on inputmethod base on our webkit/qtopia. I want apply this funtion,make inputmethod window can follow cursor position.so I must get current focused widget ,so I can tell it can input or not ,even it's position in window. but in QT ,I can only get QWebView. any suggestion can help me about this ,thanks -- RyanYee From dimich at chromium.org Thu Nov 19 19:35:30 2009 From: dimich at chromium.org (Dmitry Titov) Date: Thu, 19 Nov 2009 19:35:30 -0800 Subject: [webkit-dev] GlobalScript in WebKit Message-ID: <28040fc60911191935o7dc5c5edndd696ee6c31607ac@mail.gmail.com> Hi webkit! I'm starting to work on actual implementation of GlobalScript experimental API and started to post patches (hopefully in reviewable portions). There is an uber-bugwhich has plan of implementation. The current plan is to get it in under ENABLE_GLOBAL_SCRIPT, with both JSC and v8 bindings (first with JSC because at the moment JSC bindings are easier to work with and I'd wish WebKit not to have 1-engine-only features ever). I'd be glad to know if there are suggestions, ideas or concerns of any kind... For example, if there is no interest in JSC bindings, it can be hard to get them reviewed by someone who knows them well. It'd be better to know that earlier. Thanks! Dmitry -------------- next part -------------- An HTML attachment was scrubbed... URL: From jparent+webkit at gmail.com Fri Nov 20 14:49:03 2009 From: jparent+webkit at gmail.com (Julie Parent) Date: Fri, 20 Nov 2009 14:49:03 -0800 Subject: [webkit-dev] Reducing layout test flakiness Message-ID: <4fec56850911201449x6f7d9ad2l9bf786c5dac346c5@mail.gmail.com> In Chromium-land, we have been working to eliminate flaky layout tests. One thing that has helped us gain insight into flaky tests is the flakiness dashboard. I'd love to see this available for webkit.org as well. I'm happy to do the work to set up the dashboard itself, but one thing we'd need is for run-webkit-tests to output an extra json file, and for the build bots to store this file. Is a flakiness dashboard something you'd be interested in? Is storing the extra data file ok (the largest chromium.org one is < 1MB and the webkit.orgones should be much smaller since it is based on # failing tests)? Anyone who knows Perl interested in adding the support to run-webkit-tests to output the json (we can provide details on the format)? Julie Q: Why do we care about flaky layout tests? A: They cost us time. Specfically, they cause the commit-queue to reject good patches, lead engineers to spend extra time spent determining if they caused the tree to go red, mask real regressions because the tree was already red, put an extra burden on ports trying to determine if their port is bad or the test is just bad, etc. Q: How can I help fix flaky tests/not introduce more flaky tests? A: One big, easily fixable, source of flakiness is setTimeouts. Whenever possible, use specific events rather than relying on setTimeouts. Don't use setTimeout to wait for resources to load. Use onload events instead (iframe, image, body all have onload events). If there are no events possible, and you need time to elapse before checking something, provide a little extra wiggle room. Q: Do you have examples of these sorts of easy fixes? A: Timeout increase: http://trac.webkit.org/changeset/51150. Remove extra watchdog setTimeout: http://trac.webkit.org/changeset/51120. Remove unnecessary setTimeout: http://trac.webkit.org/changeset/51088. Use onload to detect iframe loading: http://trac.webkit.org/changeset/49592 Q. I am still reading, can I see a pretty picture? A: Sure. Here is the dashboard results clearly showing 2 tests that got fixed. You can see the flakiness before (to the right) and the new non-flakiness after (to the left). http://src.chromium.org/viewvc/chrome/trunk/src/webkit/tools/layout_tests/flakiness_dashboard.html#tests=LayoutTests%2Ftransitions%2Fzero-duration-with-non-zero-delay-end.html%20LayoutTests%2Ffast%2Fencoding%2Fchar-encoding.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From mjs at apple.com Sat Nov 21 02:20:39 2009 From: mjs at apple.com (Maciej Stachowiak) Date: Sat, 21 Nov 2009 02:20:39 -0800 Subject: [webkit-dev] Reducing layout test flakiness In-Reply-To: <4fec56850911201449x6f7d9ad2l9bf786c5dac346c5@mail.gmail.com> References: <4fec56850911201449x6f7d9ad2l9bf786c5dac346c5@mail.gmail.com> Message-ID: On Nov 20, 2009, at 2:49 PM, Julie Parent wrote: > In Chromium-land, we have been working to eliminate flaky layout > tests. One thing that has helped us gain insight into flaky tests > is the flakiness dashboard. I'd love to see this available for > webkit.org as well. I'm happy to do the work to set up the > dashboard itself, but one thing we'd need is for run-webkit-tests to > output an extra json file, and for the build bots to store this file. > > Is a flakiness dashboard something you'd be interested in? Is > storing the extra data file ok (the largest chromium.org one is < > 1MB and the webkit.org ones should be much smaller since it is based > on # failing tests)? Anyone who knows Perl interested in adding the > support to run-webkit-tests to output the json (we can provide > details on the format)? Sounds like a good plan to me. > > Julie > > Q: Why do we care about flaky layout tests? > A: They cost us time. Specfically, they cause the commit-queue to > reject good patches, lead engineers to spend extra time spent > determining if they caused the tree to go red, mask real regressions > because the tree was already red, put an extra burden on ports > trying to determine if their port is bad or the test is just bad, etc. > > Q: How can I help fix flaky tests/not introduce more flaky tests? > A: One big, easily fixable, source of flakiness is setTimeouts. > Whenever possible, use specific events rather than relying on > setTimeouts. Don't use setTimeout to wait for resources to load. > Use onload events instead (iframe, image, body all have onload > events). If there are no events possible, and you need time to > elapse before checking something, provide a little extra wiggle room. This is something we should watch for when writing new tests and reviewing patches that include tests. If the test case uses setTimeout or setInterval, that should be a huge red flag. > > Q: Do you have examples of these sorts of easy fixes? > A: Timeout increase: http://trac.webkit.org/changeset/51150. Remove > extra watchdog setTimeout: http://trac.webkit.org/changeset/51120. > Remove unnecessary setTimeout: http://trac.webkit.org/changeset/ > 51088. Use onload to detect iframe loading: http://trac.webkit.org/changeset/49592 > > Q. I am still reading, can I see a pretty picture? > A: Sure. Here is the dashboard results clearly showing 2 tests that > got fixed. You can see the flakiness before (to the right) and the > new non-flakiness after (to the left). http://src.chromium.org/viewvc/chrome/trunk/src/webkit/tools/layout_tests/flakiness_dashboard.html#tests > =LayoutTests%2Ftransitions%2Fzero-duration-with-non-zero-delay- > end.html%20LayoutTests%2Ffast%2Fencoding%2Fchar-encoding.html > _______________________________________________ > webkit-dev mailing list > webkit-dev at lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at belshe.com Sat Nov 21 14:34:49 2009 From: mike at belshe.com (Mike Belshe) Date: Sat, 21 Nov 2009 14:34:49 -0800 Subject: [webkit-dev] Making browsers faster: Resource Packages In-Reply-To: References: <2ef6228a0911161947w1067225bxdfe0eccd00e37bd8@mail.gmail.com> <2ef6228a0911171419v11497707je3c219856d66e150@mail.gmail.com> <2ef6228a0911171736j6f93322and9c79b7f73bdeb1e@mail.gmail.com> <2ef6228a0911171756v4562fc55n4812808fd9b782dd@mail.gmail.com> <2ef6228a0911181156q4f7f8ea5x33466ec39791602c@mail.gmail.com> <2a10ed240911181447u3c11c24bu53ce7cac2d293a41@mail.gmail.com> <3726d1bf0911181554l6e510590xf56d67b2b19958f5@mail.gmail.com> Message-ID: <2a10ed240911211434q6492412cw339b39af60850936@mail.gmail.com> Alexander - when you do the testing on this, one case I'd really like to see results on is this: Page contains a resource bundle, and the bundle contains a bunch of stylesheets, JS and other, but DOES NOT include one of the CSS files. Immediately following the , put a reference to the style sheet not included in the bundle. When the browser sees the link to the CSS, which is critical to the page download, does it wait for the resource bundle to load (I realize that technically it only needs to get the manifest)? If not, it might download it twice (since it doesn't know the status of the bundle yet). Now simulate over a 200ms RTT link. I believe you've just added a full RT to get the CSS, which was critical for layout. Overall PLT won't suffer the full RTT, but time-to-first-paint will. Mike On Wed, Nov 18, 2009 at 3:57 PM, Peter Kasting wrote: > On Wed, Nov 18, 2009 at 3:54 PM, Dirk Pranke wrote: > >> Another caching-related issue involves versioning of the archives. If >> version 2 of a zip contains only a few files modified since version 1, >> and I have version 1 cached, is there some way to take advantage of >> that? > > > This is a specific case of my more general question, "One of your stated > goals is to avoid downloading resources you already have, but even with > manifests, I see no way to do this, since the client can't actually tell the > server 'only send items x, y, and z'." This was the one point Alexander > didn't copy in his reply mail. > > PK > -------------- next part -------------- An HTML attachment was scrubbed... URL: From limi at mozilla.com Sat Nov 21 15:12:55 2009 From: limi at mozilla.com (Alexander Limi) Date: Sat, 21 Nov 2009 15:12:55 -0800 Subject: [webkit-dev] Making browsers faster: Resource Packages In-Reply-To: <4B0870FF.60408@souders.org> References: <2ef6228a0911161947w1067225bxdfe0eccd00e37bd8@mail.gmail.com> <2ef6228a0911171736j6f93322and9c79b7f73bdeb1e@mail.gmail.com> <2ef6228a0911171756v4562fc55n4812808fd9b782dd@mail.gmail.com> <2ef6228a0911181156q4f7f8ea5x33466ec39791602c@mail.gmail.com> <2a10ed240911181447u3c11c24bu53ce7cac2d293a41@mail.gmail.com> <3726d1bf0911181554l6e510590xf56d67b2b19958f5@mail.gmail.com> <2a10ed240911211434q6492412cw339b39af60850936@mail.gmail.com> <4B0870FF.60408@souders.org> Message-ID: <2ef6228a0911211512y4f0dc47bx1b94e69643fb935d@mail.gmail.com> Yeah, that sounds about right. Remember that I'm a UI designer, so I'll have to defer to some of the other Mozilla people on the benchmark/testing side, but we'll definitely take stuff like this into account. I'm also looking for a good syntax for how to specify the manifest content in the actual HTML document, suggestions welcome. This way, you wouldn't even have to wait for the manifest file. -- Alexander Limi ? Firefox User Experience ? http://limi.net On Sat, Nov 21, 2009 at 3:00 PM, Steve Souders wrote: > Here's my understanding of how this would work: In addition to the > resource package LINK and the not-packaged stylesheet LINK, you still need > LINKs for the other stylesheets. So the page could look like this: > > > > > > or this: > > > > > > Browsers probably shouldn't download any other resources until they've > gotten the manifest.txt. In the first case, there isn't an extra RT > (assuming in-package-A.css is the first file in the package), and the page > should render faster, esp in IE < 7 (if all the resources are on the same > domain). In the second case there, is an extra RT delay for painting. > Presumably, "core" stylesheets are packaged and come first, and > page-specific stylesheets aren't packaged and come last, so the first > situation is more typical. > > -Steve > > > > Mike Belshe wrote: > > Alexander - when you do the testing on this, one case I'd really like to > see results on is this: > > Page contains a resource bundle, and the bundle contains a bunch of > stylesheets, JS and other, but DOES NOT include one of the CSS files. > Immediately following the , put a reference to the > style sheet not included in the bundle. > > When the browser sees the link to the CSS, which is critical to the page > download, does it wait for the resource bundle to load (I realize that > technically it only needs to get the manifest)? If not, it might download > it twice (since it doesn't know the status of the bundle yet). > > Now simulate over a 200ms RTT link. I believe you've just added a full > RT to get the CSS, which was critical for layout. Overall PLT won't suffer > the full RTT, but time-to-first-paint will. > > Mike > > > On Wed, Nov 18, 2009 at 3:57 PM, Peter Kasting wrote: > >> On Wed, Nov 18, 2009 at 3:54 PM, Dirk Pranke wrote: >> >>> Another caching-related issue involves versioning of the archives. If >>> version 2 of a zip contains only a few files modified since version 1, >>> and I have version 1 cached, is there some way to take advantage of >>> that? >> >> >> This is a specific case of my more general question, "One of your stated >> goals is to avoid downloading resources you already have, but even with >> manifests, I see no way to do this, since the client can't actually tell the >> server 'only send items x, y, and z'." This was the one point Alexander >> didn't copy in his reply mail. >> >> PK >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pkasting at google.com Sat Nov 21 15:43:01 2009 From: pkasting at google.com (Peter Kasting) Date: Sat, 21 Nov 2009 15:43:01 -0800 Subject: [webkit-dev] Making browsers faster: Resource Packages In-Reply-To: <2ef6228a0911211512y4f0dc47bx1b94e69643fb935d@mail.gmail.com> References: <2ef6228a0911161947w1067225bxdfe0eccd00e37bd8@mail.gmail.com> <2ef6228a0911171756v4562fc55n4812808fd9b782dd@mail.gmail.com> <2ef6228a0911181156q4f7f8ea5x33466ec39791602c@mail.gmail.com> <2a10ed240911181447u3c11c24bu53ce7cac2d293a41@mail.gmail.com> <3726d1bf0911181554l6e510590xf56d67b2b19958f5@mail.gmail.com> <2a10ed240911211434q6492412cw339b39af60850936@mail.gmail.com> <4B0870FF.60408@souders.org> <2ef6228a0911211512y4f0dc47bx1b94e69643fb935d@mail.gmail.com> Message-ID: On Sat, Nov 21, 2009 at 3:12 PM, Alexander Limi wrote: > I'm also looking for a good syntax for how to specify the manifest content > in the actual HTML document, suggestions welcome. This way, you wouldn't > even have to wait for the manifest file. The WHATWG list may be a better place to obtain that kind of feedback. PK -------------- next part -------------- An HTML attachment was scrubbed... URL: From limi at mozilla.com Sat Nov 21 16:03:16 2009 From: limi at mozilla.com (Alexander Limi) Date: Sat, 21 Nov 2009 16:03:16 -0800 Subject: [webkit-dev] Making browsers faster: Resource Packages In-Reply-To: References: <2ef6228a0911161947w1067225bxdfe0eccd00e37bd8@mail.gmail.com> <2ef6228a0911171756v4562fc55n4812808fd9b782dd@mail.gmail.com> <2ef6228a0911181156q4f7f8ea5x33466ec39791602c@mail.gmail.com> <2a10ed240911181447u3c11c24bu53ce7cac2d293a41@mail.gmail.com> <3726d1bf0911181554l6e510590xf56d67b2b19958f5@mail.gmail.com> <2a10ed240911211434q6492412cw339b39af60850936@mail.gmail.com> <4B0870FF.60408@souders.org> <2ef6228a0911211512y4f0dc47bx1b94e69643fb935d@mail.gmail.com> Message-ID: <2ef6228a0911211603i1b4d86afh60e4dc5099fa9a55@mail.gmail.com> On Sat, Nov 21, 2009 at 3:43 PM, Peter Kasting wrote: > On Sat, Nov 21, 2009 at 3:12 PM, Alexander Limi wrote: > >> I'm also looking for a good syntax for how to specify the manifest content >> in the actual HTML document, suggestions welcome. This way, you wouldn't >> even have to wait for the manifest file. > > > The WHATWG list may be a better place to obtain that kind of feedback. > Yeah, $DEITY forbid I should actually ask people who implement browsers. ;) -- Alexander Limi ? Firefox User Experience ? http://limi.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From pkasting at google.com Sat Nov 21 23:19:37 2009 From: pkasting at google.com (Peter Kasting) Date: Sat, 21 Nov 2009 23:19:37 -0800 Subject: [webkit-dev] Making browsers faster: Resource Packages In-Reply-To: <2088762345.196501258851036988.JavaMail.root@cm-mail03.mozilla.org> References: <1234107025.196461258850944550.JavaMail.root@cm-mail03.mozilla.org> <2088762345.196501258851036988.JavaMail.root@cm-mail03.mozilla.org> Message-ID: On Sat, Nov 21, 2009 at 4:50 PM, Vladimir Vukicevic wrote: > > Another option is: > > > > > > > > Assuming that's an acceptable load order for the CSS, that should guarantee > that the browsers will start loading the unpackaged CSS regardless of > whether they delay all other loads until the manifest loads. > I thought the whole point was to try and see what kinds of effects happened when authors didn't use this perfectly. (I would be a lot more positive about this technique if it was much harder to misuse in ways that slow down page loads.) PK -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at belshe.com Sun Nov 22 18:52:54 2009 From: mike at belshe.com (Mike Belshe) Date: Sun, 22 Nov 2009 18:52:54 -0800 Subject: [webkit-dev] Making browsers faster: Resource Packages In-Reply-To: <4B0870FF.60408@souders.org> References: <2ef6228a0911161947w1067225bxdfe0eccd00e37bd8@mail.gmail.com> <2ef6228a0911171736j6f93322and9c79b7f73bdeb1e@mail.gmail.com> <2ef6228a0911171756v4562fc55n4812808fd9b782dd@mail.gmail.com> <2ef6228a0911181156q4f7f8ea5x33466ec39791602c@mail.gmail.com> <2a10ed240911181447u3c11c24bu53ce7cac2d293a41@mail.gmail.com> <3726d1bf0911181554l6e510590xf56d67b2b19958f5@mail.gmail.com> <2a10ed240911211434q6492412cw339b39af60850936@mail.gmail.com> <4B0870FF.60408@souders.org> Message-ID: <2a10ed240911221852j71efb5en6ee90578be766386@mail.gmail.com> On Sat, Nov 21, 2009 at 3:00 PM, Steve Souders wrote: > Here's my understanding of how this would work: In addition to the > resource package LINK and the not-packaged stylesheet LINK, you still need > LINKs for the other stylesheets. So the page could look like this: > > > > > > or this: > > > > > > Browsers probably shouldn't download any other resources until they've > gotten the manifest.txt. In the first case, there isn't an extra RT > (assuming in-package-A.css is the first file in the package), and the page > should render faster, esp in IE < 7 (if all the resources are on the same > domain). In the second case there, is an extra RT delay for painting. > Presumably, "core" stylesheets are packaged and come first, and > page-specific stylesheets aren't packaged and come last, so the first > situation is more typical. > CSS and JS can't be declared in arbitrary orders. So while your argument is good (about when the extra RTT exists), in practice, it is not always an option. If there are 3 scripts, two which can't be bundled and one which can, then you may or may not suffer the extra RT. This is really subtle stuff - web designers could think they are speeding up their pages when they're slowing them down. The tools need to prevent that. It can't be manual. Mike > > -Steve > > > > Mike Belshe wrote: > > Alexander - when you do the testing on this, one case I'd really like to > see results on is this: > > Page contains a resource bundle, and the bundle contains a bunch of > stylesheets, JS and other, but DOES NOT include one of the CSS files. > Immediately following the , put a reference to the > style sheet not included in the bundle. > > When the browser sees the link to the CSS, which is critical to the page > download, does it wait for the resource bundle to load (I realize that > technically it only needs to get the manifest)? If not, it might download > it twice (since it doesn't know the status of the bundle yet). > > Now simulate over a 200ms RTT link. I believe you've just added a full > RT to get the CSS, which was critical for layout. Overall PLT won't suffer > the full RTT, but time-to-first-paint will. > > Mike > > > On Wed, Nov 18, 2009 at 3:57 PM, Peter Kasting wrote: > >> On Wed, Nov 18, 2009 at 3:54 PM, Dirk Pranke wrote: >> >>> Another caching-related issue involves versioning of the archives. If >>> version 2 of a zip contains only a few files modified since version 1, >>> and I have version 1 cached, is there some way to take advantage of >>> that? >> >> >> This is a specific case of my more general question, "One of your stated >> goals is to avoid downloading resources you already have, but even with >> manifests, I see no way to do this, since the client can't actually tell the >> server 'only send items x, y, and z'." This was the one point Alexander >> didn't copy in his reply mail. >> >> PK >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cmarrin at apple.com Tue Nov 24 07:39:21 2009 From: cmarrin at apple.com (Chris Marrin) Date: Tue, 24 Nov 2009 07:39:21 -0800 Subject: [webkit-dev] New requirement for building on Windows coming Message-ID: I've submitted a patch for accelerated compositing support on Windows. I hope to land it today. When I do it will require d3d9.lib to link. The feature will be turned off at first, but the build still needs to find the library. So the build-bots will need to be updated with DirectX 9.0 SDK Update (December 2004): http://www.microsoft.com/downloads/details.aspx?FamilyId=4E825A37-0C94-4421-9EC8-156E52525D11&displaylang=en You'll also need to add a path to this SDK in your MSDev Include and Library paths. The WebKit build-bots have already been updated, but external ones should make the changes in preparation. I'll br adding this info to webkit.org today. ----- ~Chris cmarrin at apple.com From aroben at apple.com Tue Nov 24 07:52:11 2009 From: aroben at apple.com (Adam Roben) Date: Tue, 24 Nov 2009 10:52:11 -0500 Subject: [webkit-dev] New requirement for building on Windows coming In-Reply-To: References: Message-ID: <102063C6-9EDD-4EE2-AD17-7A59B2EBEC34@apple.com> On Nov 24, 2009, at 10:39 AM, Chris Marrin wrote: > I've submitted a patch for accelerated compositing support on Windows. I hope to land it today. When I do it will require d3d9.lib to link. The feature will be turned off at first, but the build still needs to find the library. So the build-bots will need to be updated with DirectX 9.0 SDK Update (December 2004): > > http://www.microsoft.com/downloads/details.aspx?FamilyId=4E825A37-0C94-4421-9EC8-156E52525D11&displaylang=en > > You'll also need to add a path to this SDK in your MSDev Include and Library paths. The WebKit build-bots have already been updated, but external ones should make the changes in preparation. > > I'll br adding this info to webkit.org today. I think it would be better to make this a runtime dependency. We can accomplish this using the macros in WebCore/platform/SoftLinking.h. Let's talk about this offline. -Adam From aroben at apple.com Tue Nov 24 07:52:56 2009 From: aroben at apple.com (Adam Roben) Date: Tue, 24 Nov 2009 10:52:56 -0500 Subject: [webkit-dev] New requirement for building on Windows coming In-Reply-To: <102063C6-9EDD-4EE2-AD17-7A59B2EBEC34@apple.com> References: <102063C6-9EDD-4EE2-AD17-7A59B2EBEC34@apple.com> Message-ID: <4D75FF33-2E66-4956-BB1A-373DE610E07D@apple.com> On Nov 24, 2009, at 10:52 AM, Adam Roben wrote: > On Nov 24, 2009, at 10:39 AM, Chris Marrin wrote: > >> I've submitted a patch for accelerated compositing support on Windows. I hope to land it today. When I do it will require d3d9.lib to link. The feature will be turned off at first, but the build still needs to find the library. So the build-bots will need to be updated with DirectX 9.0 SDK Update (December 2004): >> >> http://www.microsoft.com/downloads/details.aspx?FamilyId=4E825A37-0C94-4421-9EC8-156E52525D11&displaylang=en >> >> You'll also need to add a path to this SDK in your MSDev Include and Library paths. The WebKit build-bots have already been updated, but external ones should make the changes in preparation. >> >> I'll br adding this info to webkit.org today. > > I think it would be better to make this a runtime dependency. We can accomplish this using the macros in WebCore/platform/SoftLinking.h. Let's talk about this offline. I mean WebCore/platform/win/SoftLinking.h. -Adam From aroben at apple.com Tue Nov 24 09:46:54 2009 From: aroben at apple.com (Adam Roben) Date: Tue, 24 Nov 2009 12:46:54 -0500 Subject: [webkit-dev] New requirement for building on Windows coming In-Reply-To: <102063C6-9EDD-4EE2-AD17-7A59B2EBEC34@apple.com> References: <102063C6-9EDD-4EE2-AD17-7A59B2EBEC34@apple.com> Message-ID: <12D47369-7842-48C6-A1D2-B50E28735E2B@apple.com> On Nov 24, 2009, at 10:52 AM, Adam Roben wrote: > On Nov 24, 2009, at 10:39 AM, Chris Marrin wrote: > >> I've submitted a patch for accelerated compositing support on Windows. I hope to land it today. When I do it will require d3d9.lib to link. The feature will be turned off at first, but the build still needs to find the library. So the build-bots will need to be updated with DirectX 9.0 SDK Update (December 2004): >> >> http://www.microsoft.com/downloads/details.aspx?FamilyId=4E825A37-0C94-4421-9EC8-156E52525D11&displaylang=en >> >> You'll also need to add a path to this SDK in your MSDev Include and Library paths. The WebKit build-bots have already been updated, but external ones should make the changes in preparation. >> >> I'll br adding this info to webkit.org today. > > I think it would be better to make this a runtime dependency. We can accomplish this using the macros in WebCore/platform/SoftLinking.h. Let's talk about this offline. On second thought, even if we soft-link, we'll still have dependencies on the D3D headers... -Adam From ap at webkit.org Tue Nov 24 11:12:15 2009 From: ap at webkit.org (Alexey Proskuryakov) Date: Tue, 24 Nov 2009 11:12:15 -0800 Subject: [webkit-dev] New requirement for building on Windows coming In-Reply-To: <12D47369-7842-48C6-A1D2-B50E28735E2B@apple.com> References: <102063C6-9EDD-4EE2-AD17-7A59B2EBEC34@apple.com> <12D47369-7842-48C6-A1D2-B50E28735E2B@apple.com> Message-ID: <059D132A-147E-42EE-8A51-A63ED8080D98@webkit.org> On 24.11.2009, at 9:46, Adam Roben wrote: > On second thought, even if we soft-link, we'll still have > dependencies on the D3D headers... Can we make a local copy of those? - WBR, Alexey Proskuryakov From ap at webkit.org Tue Nov 24 11:13:04 2009 From: ap at webkit.org (Alexey Proskuryakov) Date: Tue, 24 Nov 2009 11:13:04 -0800 Subject: [webkit-dev] New requirement for building on Windows coming In-Reply-To: <059D132A-147E-42EE-8A51-A63ED8080D98@webkit.org> References: <102063C6-9EDD-4EE2-AD17-7A59B2EBEC34@apple.com> <12D47369-7842-48C6-A1D2-B50E28735E2B@apple.com> <059D132A-147E-42EE-8A51-A63ED8080D98@webkit.org> Message-ID: <822BDA5E-D985-4424-A232-C67EEF218358@webkit.org> On 24.11.2009, at 11:12, Alexey Proskuryakov wrote: > Can we make a local copy of those? On a second thought, the license likely doesn't permit that. - WBR, Alexey Proskuryakov From sfalken at apple.com Tue Nov 24 11:17:32 2009 From: sfalken at apple.com (Steve Falkenburg) Date: Tue, 24 Nov 2009 11:17:32 -0800 Subject: [webkit-dev] New requirement for building on Windows coming In-Reply-To: <059D132A-147E-42EE-8A51-A63ED8080D98@webkit.org> References: <102063C6-9EDD-4EE2-AD17-7A59B2EBEC34@apple.com> <12D47369-7842-48C6-A1D2-B50E28735E2B@apple.com> <059D132A-147E-42EE-8A51-A63ED8080D98@webkit.org> Message-ID: On Nov 24, 2009, at 11:12 AM, Alexey Proskuryakov wrote: > Can we make a local copy of those? > For internal developers, we should just submit the SDK into B&I and then it can be included in the SDK we install already to C:\AppleInternal. Probably we can just submit what we have checked into the internal tree here: https://trac-safari.apple.com/repository/safari/browser/trunk/Safari/Libraries/win/DirectX-SDK-2004-12 -steve From sfalken at apple.com Tue Nov 24 11:20:09 2009 From: sfalken at apple.com (Steve Falkenburg) Date: Tue, 24 Nov 2009 11:20:09 -0800 Subject: [webkit-dev] New requirement for building on Windows coming In-Reply-To: References: <102063C6-9EDD-4EE2-AD17-7A59B2EBEC34@apple.com> <12D47369-7842-48C6-A1D2-B50E28735E2B@apple.com> <059D132A-147E-42EE-8A51-A63ED8080D98@webkit.org> Message-ID: <781871E0-8AFB-485C-9052-71CD35033643@apple.com> On Nov 24, 2009, at 11:17 AM, Steve Falkenburg wrote: > Probably we can just submit what we have checked into the internal treees/win/DirectX-SDK-2004-12 Of course that wouldn't help open source contributors, so installing the SDK as a prerequisite for development makes sense. -steve From cmarrin at apple.com Tue Nov 24 16:19:21 2009 From: cmarrin at apple.com (Chris Marrin) Date: Tue, 24 Nov 2009 16:19:21 -0800 Subject: [webkit-dev] New requirement for building on Windows coming In-Reply-To: <059D132A-147E-42EE-8A51-A63ED8080D98@webkit.org> References: <102063C6-9EDD-4EE2-AD17-7A59B2EBEC34@apple.com> <12D47369-7842-48C6-A1D2-B50E28735E2B@apple.com> <059D132A-147E-42EE-8A51-A63ED8080D98@webkit.org> Message-ID: <34B5C8A3-9ED8-4D57-B8C2-33D23DA84FD2@apple.com> On Nov 24, 2009, at 11:12 AM, Alexey Proskuryakov wrote: > > On 24.11.2009, at 9:46, Adam Roben wrote: > >> On second thought, even if we soft-link, we'll still have dependencies on the D3D headers... > > > Can we make a local copy of those? I've used the DXSDK_DIR env var to handle both the include and lib locations. This all seems to work fine and will only require the DX SDK when we turn on ACCELERATED_COMPOSITING. Given that, do we still need soft-linking or a local copy of the headers? ----- ~Chris cmarrin at apple.com From abarth at webkit.org Tue Nov 24 19:14:27 2009 From: abarth at webkit.org (Adam Barth) Date: Tue, 24 Nov 2009 19:14:27 -0800 Subject: [webkit-dev] innerStaticHTML Message-ID: <7789133a0911241914j61a267deuf174dad5486fc6e1@mail.gmail.com> In the below message to the WHATWG, Ian suggests that vendors experiment with an API that makes it easier for web developers to programmatically add static HTML content to their pages without XSSing themselves: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-June/020191.html I think we should do as he recommends. If no one objects, I'll add this to my list of things to work on. Adam From mjs at apple.com Tue Nov 24 20:39:56 2009 From: mjs at apple.com (Maciej Stachowiak) Date: Tue, 24 Nov 2009 20:39:56 -0800 Subject: [webkit-dev] innerStaticHTML In-Reply-To: <7789133a0911241914j61a267deuf174dad5486fc6e1@mail.gmail.com> References: <7789133a0911241914j61a267deuf174dad5486fc6e1@mail.gmail.com> Message-ID: <8FCDBCE8-3C69-474A-9A5C-04F3955EA8D3@apple.com> On Nov 24, 2009, at 7:14 PM, Adam Barth wrote: > In the below message to the WHATWG, Ian suggests that vendors > experiment with an API that makes it easier for web developers to > programmatically add static HTML content to their pages without XSSing > themselves: > > http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-June/020191.html > > I think we should do as he recommends. If no one objects, I'll add > this to my list of things to work on. I think innerStaticHTML is a good idea. Is there also a use case for the "static" equivalent of insertAdjacentHTML()? - Maciej From abarth at webkit.org Tue Nov 24 22:37:23 2009 From: abarth at webkit.org (Adam Barth) Date: Tue, 24 Nov 2009 22:37:23 -0800 Subject: [webkit-dev] innerStaticHTML In-Reply-To: <8FCDBCE8-3C69-474A-9A5C-04F3955EA8D3@apple.com> References: <7789133a0911241914j61a267deuf174dad5486fc6e1@mail.gmail.com> <8FCDBCE8-3C69-474A-9A5C-04F3955EA8D3@apple.com> Message-ID: <7789133a0911242237t2fc4e93ak95173b018b71b4fb@mail.gmail.com> On Tue, Nov 24, 2009 at 8:39 PM, Maciej Stachowiak wrote: > On Nov 24, 2009, at 7:14 PM, Adam Barth wrote: >> In the below message to the WHATWG, Ian suggests that vendors >> experiment with an API that makes it easier for web developers to >> programmatically add static HTML content to their pages without XSSing >> themselves: >> >> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-June/020191.html >> >> I think we should do as he recommends. ?If no one objects, I'll add >> this to my list of things to work on. > > I think innerStaticHTML is a good idea. Is there also a use case for the > "static" equivalent of insertAdjacentHTML()? I think we should experiment with the minimal API that seems useful. If the experiment is a success, we can scale it up. Michal suggested to me off-list and another possibility is to have an API that works like this: var jail = document.createElement("jail"); document.getElementById("foo"); jail.innerHTML = untrusted_string; We could do something similar with attributes: var jail = document.getElementById("foo"); jail.setAttribute("sandbox", "yes-please"); jail.innerHTML = untrusted_string; One of the nice things about using a DOM API is we don't have to worry about crazy parsing issues. Adam From mjs at apple.com Tue Nov 24 23:21:14 2009 From: mjs at apple.com (Maciej Stachowiak) Date: Tue, 24 Nov 2009 23:21:14 -0800 Subject: [webkit-dev] innerStaticHTML In-Reply-To: <7789133a0911242237t2fc4e93ak95173b018b71b4fb@mail.gmail.com> References: <7789133a0911241914j61a267deuf174dad5486fc6e1@mail.gmail.com> <8FCDBCE8-3C69-474A-9A5C-04F3955EA8D3@apple.com> <7789133a0911242237t2fc4e93ak95173b018b71b4fb@mail.gmail.com> Message-ID: <57307917-9060-4B0E-B8D3-5FD4DE4AF1C0@apple.com> On Nov 24, 2009, at 10:37 PM, Adam Barth wrote: > On Tue, Nov 24, 2009 at 8:39 PM, Maciej Stachowiak > wrote: >> On Nov 24, 2009, at 7:14 PM, Adam Barth wrote: >>> In the below message to the WHATWG, Ian suggests that vendors >>> experiment with an API that makes it easier for web developers to >>> programmatically add static HTML content to their pages without >>> XSSing >>> themselves: >>> >>> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-June/020191.html >>> >>> I think we should do as he recommends. If no one objects, I'll add >>> this to my list of things to work on. >> >> I think innerStaticHTML is a good idea. Is there also a use case >> for the >> "static" equivalent of insertAdjacentHTML()? > > I think we should experiment with the minimal API that seems useful. > If the experiment is a success, we can scale it up. > > Michal suggested to me off-list and another possibility is to have an > API that works like this: > > var jail = document.createElement("jail"); > document.getElementById("foo"); > jail.innerHTML = untrusted_string; > > We could do something similar with attributes: > > var jail = document.getElementById("foo"); > jail.setAttribute("sandbox", "yes-please"); > jail.innerHTML = untrusted_string; > > One of the nice things about using a DOM API is we don't have to worry > about crazy parsing issues. If we tie it to an element or attribute, people may be tempted to just do it in markup, which would be insecure. Regards, Maciej From godyee at gmail.com Wed Nov 25 00:50:14 2009 From: godyee at gmail.com (=?UTF-8?B?UnlhblllZS/lj7bmmZQ=?=) Date: Wed, 25 Nov 2009 16:50:14 +0800 Subject: [webkit-dev] is there any method to get current focus widget in webkit? In-Reply-To: <2eeb9e8e0911191746r4319713ehdd31b49f553a4264@mail.gmail.com> References: <2eeb9e8e0911191746r4319713ehdd31b49f553a4264@mail.gmail.com> Message-ID: <2eeb9e8e0911250050g49dc09fdo76a71c1a288ab641@mail.gmail.com> I have find way to do it,my code bool QWebPage::canInput(QRect &pos) { bool ret=false; #if 0 Frame *frame = d->page->focusController()->focusedFrame(); qDebug()<<"ryan can input1:"<<(frame?1:0); #endif WebCore::Frame *frame1 = d->page->focusController()->focusedOrMainFrame(); Node * cur=frame1->document()->focusedNode(); if(cur){ qDebug("node:%s:%d",cur->nodeName().latin1().data(),cur->nodeType()); pos=QRect(cur->getRect()); qDebug("node :%d,%d,%d,%d",pos.x(),pos.y(),pos.width(),pos.height()); } else { pos=QRect(0,0,0,0); qDebug("node null"); } WebCore::Editor *editor = frame1->editor(); ret=(editor->canEdit()?true:false); qDebug()<<"ryan can input2:"<: > I am working on inputmethod base on our webkit/qtopia. > I want apply this funtion,make inputmethod window can follow cursor > position.so I must > get current focused widget ,so I can tell it can input or not ,even > it's position in window. > but in QT ,I can only get QWebView. > any suggestion can help me about this ,thanks > > -- > RyanYee > -- RyanYee From abarth at webkit.org Wed Nov 25 06:05:15 2009 From: abarth at webkit.org (Adam Barth) Date: Wed, 25 Nov 2009 06:05:15 -0800 Subject: [webkit-dev] innerStaticHTML In-Reply-To: <57307917-9060-4B0E-B8D3-5FD4DE4AF1C0@apple.com> References: <7789133a0911241914j61a267deuf174dad5486fc6e1@mail.gmail.com> <8FCDBCE8-3C69-474A-9A5C-04F3955EA8D3@apple.com> <7789133a0911242237t2fc4e93ak95173b018b71b4fb@mail.gmail.com> <57307917-9060-4B0E-B8D3-5FD4DE4AF1C0@apple.com> Message-ID: <7789133a0911250605p4982ece5y33c6a0200be366d4@mail.gmail.com> On Tue, Nov 24, 2009 at 11:21 PM, Maciej Stachowiak wrote: > If we tie it to an element or attribute, people may be tempted to just do it > in markup, which would be insecure. Maybe we should have a DOM API called webkitJailChildren("no-script-for-you") on Node that prevents future children from running script. Making it a DOM API prevents authors from trying to turn the feature on with markup. On Tue, Nov 24, 2009 at 11:27 PM, Michal Zalewski wrote: > > ...unsanitized user content... > I'd rather not go this route in our initial implementation. I think we should target the use case of a web site receiving an untrusted string via cross-origin XMLHttpRequest or postMessage. Adam From darin at chromium.org Wed Nov 25 09:55:12 2009 From: darin at chromium.org (Darin Fisher) Date: Wed, 25 Nov 2009 09:55:12 -0800 Subject: [webkit-dev] Why are some layout tests renamed with a suffix of -disabled? Message-ID: Why are some layout tests renamed with a suffix of -disabled? Why aren't such tests simply added to the skipped list? Is -disabled simply the old way? -Darin -------------- next part -------------- An HTML attachment was scrubbed... URL: From mitz at apple.com Wed Nov 25 10:35:19 2009 From: mitz at apple.com (Dan Bernstein) Date: Wed, 25 Nov 2009 10:35:19 -0800 Subject: [webkit-dev] Why are some layout tests renamed with a suffix of -disabled? In-Reply-To: References: Message-ID: <3CE5F062-E4C5-455C-8FD7-0B89020786EF@apple.com> On Nov 25, 2009, at 9:55 AM, Darin Fisher wrote: > Why are some layout tests renamed with a suffix of -disabled? Why aren't such tests simply added to the skipped list? Is -disabled simply the old way? Usually a test is disabled, with a bug filed to re-enable it, when a WebKit bug makes it impossible to run the test (e.g. it crashes DumpRenderTree) or makes the test produce different results on each run (this can also be a bug in the test). The skipped lists are platform-specific, so they are not a good way to deal with such situations. From darin at chromium.org Wed Nov 25 10:38:15 2009 From: darin at chromium.org (Darin Fisher) Date: Wed, 25 Nov 2009 10:38:15 -0800 Subject: [webkit-dev] Why are some layout tests renamed with a suffix of -disabled? In-Reply-To: <3CE5F062-E4C5-455C-8FD7-0B89020786EF@apple.com> References: <3CE5F062-E4C5-455C-8FD7-0B89020786EF@apple.com> Message-ID: On Wed, Nov 25, 2009 at 10:35 AM, Dan Bernstein wrote: > > On Nov 25, 2009, at 9:55 AM, Darin Fisher wrote: > > > Why are some layout tests renamed with a suffix of -disabled? Why aren't > such tests simply added to the skipped list? Is -disabled simply the old > way? > > Usually a test is disabled, with a bug filed to re-enable it, when a WebKit > bug makes it impossible to run the test (e.g. it crashes DumpRenderTree) or > makes the test produce different results on each run (this can also be a bug > in the test). The skipped lists are platform-specific, so they are not a > good way to deal with such situations. My concern is that some tests may pass on some ports but not others. If the tests are -disabled, then it prevents them from being run on ports where the tests function properly. Since skipped lists prevent the test from being executed, doesn't it solve the problem of disabling a test for ports that can't handle it? What am I missing? :-) -Darin -------------- next part -------------- An HTML attachment was scrubbed... URL: From mitz at apple.com Wed Nov 25 10:44:05 2009 From: mitz at apple.com (Dan Bernstein) Date: Wed, 25 Nov 2009 10:44:05 -0800 Subject: [webkit-dev] Why are some layout tests renamed with a suffix of -disabled? In-Reply-To: References: <3CE5F062-E4C5-455C-8FD7-0B89020786EF@apple.com> Message-ID: <4AADEDF1-5127-4E9E-9CC1-EAA13BA0A329@apple.com> On Nov 25, 2009, at 10:38 AM, Darin Fisher wrote: > On Wed, Nov 25, 2009 at 10:35 AM, Dan Bernstein wrote: > > On Nov 25, 2009, at 9:55 AM, Darin Fisher wrote: > > > Why are some layout tests renamed with a suffix of -disabled? Why aren't such tests simply added to the skipped list? Is -disabled simply the old way? > > Usually a test is disabled, with a bug filed to re-enable it, when a WebKit bug makes it impossible to run the test (e.g. it crashes DumpRenderTree) or makes the test produce different results on each run (this can also be a bug in the test). The skipped lists are platform-specific, so they are not a good way to deal with such situations. > > My concern is that some tests may pass on some ports but not others. For such cases, the skipped list is the way to go. > If the tests are -disabled, then it prevents them from being run on ports where the tests function properly. I see now that I didn?t make myself clear. By ?WebKit bug? above I meant a bug that affects all ports and platforms (maybe I should have said ?a core WebKit bug? or ?a WebCore bug? :-) ). > Since skipped lists prevent the test from being executed, doesn't it solve the problem of disabling a test for ports that can't handle it? What am I missing? :-) The ?tests that crash/hang/behave unpredictably on all ports? part. There aren?t many -disabled tests, and I think it?s a good idea to audit them and make sure that (a) they can?t be re-enabled (b) they can?t just be skipped on some platforms and run on others and (c) there?s a bug filed on re-enabling them (or fixing the reason why they can?t be enabled). -------------- next part -------------- An HTML attachment was scrubbed... URL: From darin at chromium.org Wed Nov 25 10:53:43 2009 From: darin at chromium.org (Darin Fisher) Date: Wed, 25 Nov 2009 10:53:43 -0800 Subject: [webkit-dev] Why are some layout tests renamed with a suffix of -disabled? In-Reply-To: <4AADEDF1-5127-4E9E-9CC1-EAA13BA0A329@apple.com> References: <3CE5F062-E4C5-455C-8FD7-0B89020786EF@apple.com> <4AADEDF1-5127-4E9E-9CC1-EAA13BA0A329@apple.com> Message-ID: On Wed, Nov 25, 2009 at 10:44 AM, Dan Bernstein wrote: > > On Nov 25, 2009, at 10:38 AM, Darin Fisher wrote: > > On Wed, Nov 25, 2009 at 10:35 AM, Dan Bernstein wrote: > >> >> On Nov 25, 2009, at 9:55 AM, Darin Fisher wrote: >> >> > Why are some layout tests renamed with a suffix of -disabled? Why >> aren't such tests simply added to the skipped list? Is -disabled simply the >> old way? >> >> Usually a test is disabled, with a bug filed to re-enable it, when a >> WebKit bug makes it impossible to run the test (e.g. it crashes >> DumpRenderTree) or makes the test produce different results on each run >> (this can also be a bug in the test). The skipped lists are >> platform-specific, so they are not a good way to deal with such situations. > > > My concern is that some tests may pass on some ports but not others. > > > For such cases, the skipped list is the way to go. > > If the tests are -disabled, then it prevents them from being run on ports > where the tests function properly. > > > I see now that I didn?t make myself clear. By ?WebKit bug? above I meant a > bug that affects all ports and platforms (maybe I should have said ?a core > WebKit bug? or ?a WebCore bug? :-) ). > > Since skipped lists prevent the test from being executed, doesn't it solve > the problem of disabling a test for ports that can't handle it? What am I > missing? :-) > > > The ?tests that crash/hang/behave unpredictably on all ports? part. > > There aren?t many -disabled tests, and I think it?s a good idea to audit > them and make sure that (a) they can?t be re-enabled (b) they can?t just be > skipped on some platforms and run on others and (c) there?s a bug filed on > re-enabling them (or fixing the reason why they can?t be enabled). > This makes sense now. Thanks for clarifying. -Darin -------------- next part -------------- An HTML attachment was scrubbed... URL: From lcamtuf at google.com Tue Nov 24 23:46:48 2009 From: lcamtuf at google.com (Michal Zalewski) Date: Tue, 24 Nov 2009 23:46:48 -0800 Subject: [webkit-dev] innerStaticHTML In-Reply-To: <22b17c0a0911242327w68a3c1cdh83aa1503769c65db@mail.gmail.com> References: <7789133a0911241914j61a267deuf174dad5486fc6e1@mail.gmail.com> <8FCDBCE8-3C69-474A-9A5C-04F3955EA8D3@apple.com> <7789133a0911242237t2fc4e93ak95173b018b71b4fb@mail.gmail.com> <22b17c0a0911242327w68a3c1cdh83aa1503769c65db@mail.gmail.com> Message-ID: <22b17c0a0911242346h5a57a4d7i414a3c29cfb6930d@mail.gmail.com> >>> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-June/020191.html > I think we should experiment with the minimal API that seems useful. > If the experiment is a success, we can scale it up. Apologies if I am rehashing something discussed earlier, but I think it would be easy to run into some subtle problems with an API such as .safeInnerHTML API, when mixed with .innerHTML. The approach where input is sanitized upon assignment (and the original is not stored anywhere) is possibly the best, but may still lead to trouble. One possibility is the behavior of innerHTML on or <textarea> elements, which seems inconsistent and potentially dangerous across browsers; and in general, innerHTML manipulation following safeInnerHTML assignments seem like an easy way to accidentally mess things up on web application side. Deferred sanitization triggered by safeInnerHTML assignments is another possibility, but it creates a whole lot other issues, e.g.: foo.safeInnerHTML = '<a href="' + user_string + '">...</a>' foo.innerHTML += '<br>Ta-dah!'; ...or: foo.safeInnerHTML = '<a href="' + user_string + '">...</a>' bar.innerHTML = foo.safeInnerHTML; Tainting elements that had their contents accessed via .safeInnerHTML, and then tracking and propagating this data, is one way to avoid problems - but it introduces significant complexity and would be pretty opaque to developers; especially when dealing with .innerHTML on outer or nested elements. I think the syntax outlined in Adam's post is much safer, would definitely require far fewer implementation-level challenges, and would introduce fewer gotchas for web app developers by tying sanitization to a well-defined output container, rather than one of several content access methods. More importantly, it is also easily extensible to a solution that could be utilized by non-JS pages, as its logical 1:1 equivalent would be a nonced, locked element, say: <span secure_mode="$random_server_generated_nonce"> ...unsanitized user content... </span secure_mode="$random_server_generated_nonce"> This is not a fortunate syntax, but illustrates the idea reasonably well. The boundaries are guarded, so the approach is safe as long as the server can produce decent random boundaries, and the benefit is that server-generated pages can benefit from lightweight sanitization without the need to do all content rendering dynamically with client-side JS - which would make a huge difference. /mz From lcamtuf at google.com Wed Nov 25 10:25:41 2009 From: lcamtuf at google.com (Michal Zalewski) Date: Wed, 25 Nov 2009 10:25:41 -0800 Subject: [webkit-dev] innerStaticHTML In-Reply-To: <7789133a0911250605p4982ece5y33c6a0200be366d4@mail.gmail.com> References: <7789133a0911241914j61a267deuf174dad5486fc6e1@mail.gmail.com> <8FCDBCE8-3C69-474A-9A5C-04F3955EA8D3@apple.com> <7789133a0911242237t2fc4e93ak95173b018b71b4fb@mail.gmail.com> <57307917-9060-4B0E-B8D3-5FD4DE4AF1C0@apple.com> <7789133a0911250605p4982ece5y33c6a0200be366d4@mail.gmail.com> Message-ID: <22b17c0a0911251025v1c6c2da0r804def3f2140eab3@mail.gmail.com> > I'd rather not go this route in our initial implementation. ?I think > we should target the use case of a web site receiving an untrusted > string via cross-origin XMLHttpRequest or postMessage. Fair enough. OTOH, this solves a very narrow problem. If we have an implementation that at least extends to a non-JS solution without the need to create a wholly separate mechanism should there eventually be desire to make a difference in this area, it's a win. So, child-locked tags appeal to me a whole lot more than a variant of .innerHTML. Cheers, /mz From pundarickr at gmail.com Wed Nov 18 20:55:19 2009 From: pundarickr at gmail.com (pundarik rajkhowa) Date: Thu, 19 Nov 2009 10:25:19 +0530 Subject: [webkit-dev] Webkit render tree dump Message-ID: <e9a2579e0911182055w20e39a09r122821944f4830c5@mail.gmail.com> Hi, I have a doubt regarding the content of webkit render tree dump. In this dump, do we only print the HTML node information(body, div etc) or we print the style information also(font-weight, text-decoration etc). From what I have seen, it looks like only node information is printed. In such a case how a bug is caught if it is related to style attributes ? regards, Pundarik -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091119/216df77b/attachment.html> From rryk.ua at gmail.com Wed Nov 25 12:15:04 2009 From: rryk.ua at gmail.com (Sergiy Byelozyorov) Date: Wed, 25 Nov 2009 22:15:04 +0200 Subject: [webkit-dev] ImageLoader class Message-ID: <c29c50990911251215x2a96fb83i8d362e186bcb61f@mail.gmail.com> Hello, I am writing my own class using ImageLoader. Can somebody, please, help me with these questions: 1. How do I know that the image was loaded already? Can I set up callback somehow? 2. What should functions sourceURI() and dispatchLoadEvent() do? 3. What is pixel format for m_imageLoader.image()->image()->data()->data()? Is this the right way to access loaded image raw pixel data? 4. How can I handle animations (e.g. GIF files)? How do I know when the next image in the animation suquence is ready? Another callback? 5. Which image formats are supported? Can I add my own, like HDR? Thank you. Sergiy -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091125/fed85f77/attachment.html> From mjs at apple.com Wed Nov 25 12:30:58 2009 From: mjs at apple.com (Maciej Stachowiak) Date: Wed, 25 Nov 2009 12:30:58 -0800 Subject: [webkit-dev] innerStaticHTML In-Reply-To: <7789133a0911250605p4982ece5y33c6a0200be366d4@mail.gmail.com> References: <7789133a0911241914j61a267deuf174dad5486fc6e1@mail.gmail.com> <8FCDBCE8-3C69-474A-9A5C-04F3955EA8D3@apple.com> <7789133a0911242237t2fc4e93ak95173b018b71b4fb@mail.gmail.com> <57307917-9060-4B0E-B8D3-5FD4DE4AF1C0@apple.com> <7789133a0911250605p4982ece5y33c6a0200be366d4@mail.gmail.com> Message-ID: <E0AA13FF-899C-4BA4-BC96-A0105D685E5F@apple.com> On Nov 25, 2009, at 6:05 AM, Adam Barth wrote: > On Tue, Nov 24, 2009 at 11:21 PM, Maciej Stachowiak <mjs at apple.com> > wrote: >> If we tie it to an element or attribute, people may be tempted to >> just do it >> in markup, which would be insecure. > > Maybe we should have a DOM API called > webkitJailChildren("no-script-for-you") on Node that prevents future > children from running script. Making it a DOM API prevents authors > from trying to turn the feature on with markup. Interesting idea. This seems potentially trickier to implement than just innerStaticHTML, since nearly every method that mutates the DOM will have to check jail status. innerStaticHTML could be limited in scope to only operations that happen as part of parsing. > On Tue, Nov 24, 2009 at 11:27 PM, Michal Zalewski > <lcamtuf at google.com> wrote: >> <span secure_mode="$random_server_generated_nonce"> >> ...unsanitized user content... >> </span secure_mode="$random_server_generated_nonce"> > > I'd rather not go this route in our initial implementation. I think > we should target the use case of a web site receiving an untrusted > string via cross-origin XMLHttpRequest or postMessage. One obvious likely use case is for sites that wish to sanitize user- generated content, for example comment sections of blogs. innerStaticHTML is actually decent for that use case. Not quite as nice as markup, but I'm wary of introducing parser complexity to defend against hostile content that tries to prematurely close the jail. Regards, Maciej -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091125/ea8b193f/attachment.html> From abarth at webkit.org Wed Nov 25 12:34:24 2009 From: abarth at webkit.org (Adam Barth) Date: Wed, 25 Nov 2009 12:34:24 -0800 Subject: [webkit-dev] innerStaticHTML In-Reply-To: <E0AA13FF-899C-4BA4-BC96-A0105D685E5F@apple.com> References: <7789133a0911241914j61a267deuf174dad5486fc6e1@mail.gmail.com> <8FCDBCE8-3C69-474A-9A5C-04F3955EA8D3@apple.com> <7789133a0911242237t2fc4e93ak95173b018b71b4fb@mail.gmail.com> <57307917-9060-4B0E-B8D3-5FD4DE4AF1C0@apple.com> <7789133a0911250605p4982ece5y33c6a0200be366d4@mail.gmail.com> <E0AA13FF-899C-4BA4-BC96-A0105D685E5F@apple.com> Message-ID: <7789133a0911251234g7b335260l7dac1985c7250f6e@mail.gmail.com> On Wed, Nov 25, 2009 at 12:30 PM, Maciej Stachowiak <mjs at apple.com> wrote: > On Nov 25, 2009, at 6:05 AM, Adam Barth wrote: > > Maybe we should have a DOM API called > > webkitJailChildren("no-script-for-you") on Node that prevents future > > children from running script. ?Making it a DOM API prevents authors > > from trying to turn the feature on with markup. > > Interesting idea. This seems potentially trickier to implement than just > innerStaticHTML, since nearly every method that mutates the DOM will have to > check jail status. innerStaticHTML could be limited in scope to only > operations that happen as part of parsing. Instead of checking every DOM mutation, we could just walk the parent pointers before executing a script to see if an ancestor is jailed. Adam From mjs at apple.com Wed Nov 25 13:25:30 2009 From: mjs at apple.com (Maciej Stachowiak) Date: Wed, 25 Nov 2009 13:25:30 -0800 Subject: [webkit-dev] innerStaticHTML In-Reply-To: <7789133a0911251234g7b335260l7dac1985c7250f6e@mail.gmail.com> References: <7789133a0911241914j61a267deuf174dad5486fc6e1@mail.gmail.com> <8FCDBCE8-3C69-474A-9A5C-04F3955EA8D3@apple.com> <7789133a0911242237t2fc4e93ak95173b018b71b4fb@mail.gmail.com> <57307917-9060-4B0E-B8D3-5FD4DE4AF1C0@apple.com> <7789133a0911250605p4982ece5y33c6a0200be366d4@mail.gmail.com> <E0AA13FF-899C-4BA4-BC96-A0105D685E5F@apple.com> <7789133a0911251234g7b335260l7dac1985c7250f6e@mail.gmail.com> Message-ID: <0620D569-E3B0-458E-9138-3F5C1AA61DD7@apple.com> On Nov 25, 2009, at 12:34 PM, Adam Barth wrote: > On Wed, Nov 25, 2009 at 12:30 PM, Maciej Stachowiak <mjs at apple.com> > wrote: >> On Nov 25, 2009, at 6:05 AM, Adam Barth wrote: >>> Maybe we should have a DOM API called >>> webkitJailChildren("no-script-for-you") on Node that prevents future >>> children from running script. Making it a DOM API prevents authors >>> from trying to turn the feature on with markup. >> >> Interesting idea. This seems potentially trickier to implement than >> just >> innerStaticHTML, since nearly every method that mutates the DOM >> will have to >> check jail status. innerStaticHTML could be limited in scope to only >> operations that happen as part of parsing. > > Instead of checking every DOM mutation, we could just walk the parent > pointers before executing a script to see if an ancestor is jailed. A few thoughts: 1) Presumably we'd want to block instantiation of plugins and Java applets too, or the scripting restriction becomes toothless. Perhaps also iframes, unless the scripting restriction is intended to propagate across frame boundaries. 2) Capturing all points at which script execution occurs and tracing them back to the originating element may be tricky. javascript: URIs are one potentially subtle example. By the time the JavaScript for those gets executed, I believe we no longer know the originating element, the way the code is currently structured. 3) It seems like the rule "don't execute JS" might not be quite what is desired, since it would (presumably) prevent the parent itself from using event listeners on nodes in the jail. IMO the best treatment for event listeners would be to prevent them from being created by attributes, rather than to prevent them from executing. 4) Do we need to strip or rename id, name and class values to prevent interference with the containing page's use of getElementById() and such? Caja does. Regards, Maciej From abarth at webkit.org Wed Nov 25 13:33:35 2009 From: abarth at webkit.org (Adam Barth) Date: Wed, 25 Nov 2009 13:33:35 -0800 Subject: [webkit-dev] innerStaticHTML In-Reply-To: <0620D569-E3B0-458E-9138-3F5C1AA61DD7@apple.com> References: <7789133a0911241914j61a267deuf174dad5486fc6e1@mail.gmail.com> <8FCDBCE8-3C69-474A-9A5C-04F3955EA8D3@apple.com> <7789133a0911242237t2fc4e93ak95173b018b71b4fb@mail.gmail.com> <57307917-9060-4B0E-B8D3-5FD4DE4AF1C0@apple.com> <7789133a0911250605p4982ece5y33c6a0200be366d4@mail.gmail.com> <E0AA13FF-899C-4BA4-BC96-A0105D685E5F@apple.com> <7789133a0911251234g7b335260l7dac1985c7250f6e@mail.gmail.com> <0620D569-E3B0-458E-9138-3F5C1AA61DD7@apple.com> Message-ID: <7789133a0911251333s4c76da8kec483c9d0abbc056@mail.gmail.com> On Wed, Nov 25, 2009 at 1:25 PM, Maciej Stachowiak <mjs at apple.com> wrote: > On Nov 25, 2009, at 12:34 PM, Adam Barth wrote: >> On Wed, Nov 25, 2009 at 12:30 PM, Maciej Stachowiak <mjs at apple.com> wrote: >>> On Nov 25, 2009, at 6:05 AM, Adam Barth wrote: >>>> Maybe we should have a DOM API called >>>> webkitJailChildren("no-script-for-you") on Node that prevents future >>>> children from running script. ?Making it a DOM API prevents authors >>>> from trying to turn the feature on with markup. >>> >>> Interesting idea. This seems potentially trickier to implement than just >>> innerStaticHTML, since nearly every method that mutates the DOM will have >>> to >>> check jail status. innerStaticHTML could be limited in scope to only >>> operations that happen as part of parsing. >> >> Instead of checking every DOM mutation, we could just walk the parent >> pointers before executing a script to see if an ancestor is jailed. I don't have a complete design in mind. I could try to write up a design document. > A few thoughts: > > 1) Presumably we'd want to block instantiation of plugins and Java applets > too, or the scripting restriction becomes toothless. Perhaps also iframes, > unless the scripting restriction is intended to propagate across frame > boundaries. Yes. Also the <base> element. Essentially, all the same APIs that are currently restricted by the XSSAuditor. > 2) Capturing all points at which script execution occurs and tracing them > back to the originating element may be tricky. javascript: URIs are one > potentially subtle example. By the time the JavaScript for those gets > executed, I believe we no longer know the originating element, the way the > code is currently structured. The way I would do this is to teach HTMLAnchorElement and friends not to hand off JavaScript URLs to FrameLoader if their parent is jailed. I'm not sure how many such interception points we'd need. > 3) It seems like the rule "don't execute JS" might not be quite what is > desired, since it would (presumably) prevent the parent itself from using > event listeners on nodes in the jail. IMO the best treatment for event > listeners would be to prevent them from being created by attributes, rather > than to prevent them from executing. Agreed. We'd want to stop inline event listeners from being created on jailed nodes. > 4) Do we need to strip or rename id, name and class values to prevent > interference with the containing page's use of getElementById() and such? > Caja does. I think this is an order of magnitude less important that direct script execution. There are going to be advanced use cases for which Caja is the right answer. The other way to skin this cat, by the way, is to implement the seamless attribute on iframes. That gives you a similar sort of design using the @sandbox attribute and solves many of your above concerns, e.g. by creating a new namespace for @ids. Maybe we should try that first or in parallel? Adam From lcamtuf at google.com Wed Nov 25 13:45:33 2009 From: lcamtuf at google.com (Michal Zalewski) Date: Wed, 25 Nov 2009 13:45:33 -0800 Subject: [webkit-dev] innerStaticHTML In-Reply-To: <7789133a0911251333s4c76da8kec483c9d0abbc056@mail.gmail.com> References: <7789133a0911241914j61a267deuf174dad5486fc6e1@mail.gmail.com> <8FCDBCE8-3C69-474A-9A5C-04F3955EA8D3@apple.com> <7789133a0911242237t2fc4e93ak95173b018b71b4fb@mail.gmail.com> <57307917-9060-4B0E-B8D3-5FD4DE4AF1C0@apple.com> <7789133a0911250605p4982ece5y33c6a0200be366d4@mail.gmail.com> <E0AA13FF-899C-4BA4-BC96-A0105D685E5F@apple.com> <7789133a0911251234g7b335260l7dac1985c7250f6e@mail.gmail.com> <0620D569-E3B0-458E-9138-3F5C1AA61DD7@apple.com> <7789133a0911251333s4c76da8kec483c9d0abbc056@mail.gmail.com> Message-ID: <22b17c0a0911251345k34da0558q2f04406b7ec397f5@mail.gmail.com> > The other way to skin this cat, by the way, is to implement the > seamless attribute on iframes. ?That gives you a similar sort of > design using the @sandbox attribute and solves many of your above > concerns, e.g. by creating a new namespace for @ids. ?Maybe we should > try that first or in parallel? I would think that in practice, IFRAMEs would, at least psychologically, be significantly less useful to web app developers. This is due to the fact that frames are conceptually more difficult to properly position and size to accommodate any dynamically inserted text; are more cumbersome to pre-populate with data on server-side (extra HTTP roundtrips or opaque data: URLs). Also, are renderer implementations actually ready to handle hundreds of seamless IFRAMEs on a page with the performance footprint not exceeding that of spans and divs? /mz From mjs at apple.com Wed Nov 25 13:49:39 2009 From: mjs at apple.com (Maciej Stachowiak) Date: Wed, 25 Nov 2009 13:49:39 -0800 Subject: [webkit-dev] innerStaticHTML In-Reply-To: <7789133a0911251333s4c76da8kec483c9d0abbc056@mail.gmail.com> References: <7789133a0911241914j61a267deuf174dad5486fc6e1@mail.gmail.com> <8FCDBCE8-3C69-474A-9A5C-04F3955EA8D3@apple.com> <7789133a0911242237t2fc4e93ak95173b018b71b4fb@mail.gmail.com> <57307917-9060-4B0E-B8D3-5FD4DE4AF1C0@apple.com> <7789133a0911250605p4982ece5y33c6a0200be366d4@mail.gmail.com> <E0AA13FF-899C-4BA4-BC96-A0105D685E5F@apple.com> <7789133a0911251234g7b335260l7dac1985c7250f6e@mail.gmail.com> <0620D569-E3B0-458E-9138-3F5C1AA61DD7@apple.com> <7789133a0911251333s4c76da8kec483c9d0abbc056@mail.gmail.com> Message-ID: <162EEBCF-96FE-49FC-A458-3C84EF37E062@apple.com> On Nov 25, 2009, at 1:33 PM, Adam Barth wrote: > On Wed, Nov 25, 2009 at 1:25 PM, Maciej Stachowiak <mjs at apple.com> > wrote: >> On Nov 25, 2009, at 12:34 PM, Adam Barth wrote: >>> On Wed, Nov 25, 2009 at 12:30 PM, Maciej Stachowiak >>> <mjs at apple.com> wrote: >>>> On Nov 25, 2009, at 6:05 AM, Adam Barth wrote: >>>>> Maybe we should have a DOM API called >>>>> webkitJailChildren("no-script-for-you") on Node that prevents >>>>> future >>>>> children from running script. Making it a DOM API prevents >>>>> authors >>>>> from trying to turn the feature on with markup. >>>> >>>> Interesting idea. This seems potentially trickier to implement >>>> than just >>>> innerStaticHTML, since nearly every method that mutates the DOM >>>> will have >>>> to >>>> check jail status. innerStaticHTML could be limited in scope to >>>> only >>>> operations that happen as part of parsing. >>> >>> Instead of checking every DOM mutation, we could just walk the >>> parent >>> pointers before executing a script to see if an ancestor is jailed. > > I don't have a complete design in mind. I could try to write up a > design document. Sounds like we could use one given the potential complications. > >> A few thoughts: >> >> 1) Presumably we'd want to block instantiation of plugins and Java >> applets >> too, or the scripting restriction becomes toothless. Perhaps also >> iframes, >> unless the scripting restriction is intended to propagate across >> frame >> boundaries. > > Yes. Also the <base> element. Essentially, all the same APIs that > are currently restricted by the XSSAuditor. > >> 2) Capturing all points at which script execution occurs and >> tracing them >> back to the originating element may be tricky. javascript: URIs are >> one >> potentially subtle example. By the time the JavaScript for those gets >> executed, I believe we no longer know the originating element, the >> way the >> code is currently structured. > > The way I would do this is to teach HTMLAnchorElement and friends not > to hand off JavaScript URLs to FrameLoader if their parent is jailed. > I'm not sure how many such interception points we'd need. Not sure either. Two others I can think of are SVGAElement and HTMLFormElement. > >> 3) It seems like the rule "don't execute JS" might not be quite >> what is >> desired, since it would (presumably) prevent the parent itself from >> using >> event listeners on nodes in the jail. IMO the best treatment for >> event >> listeners would be to prevent them from being created by >> attributes, rather >> than to prevent them from executing. > > Agreed. We'd want to stop inline event listeners from being created > on jailed nodes. > >> 4) Do we need to strip or rename id, name and class values to prevent >> interference with the containing page's use of getElementById() and >> such? >> Caja does. > > I think this is an order of magnitude less important that direct > script execution. There are going to be advanced use cases for which > Caja is the right answer. Caja wants to let you actually run script in the jail without interfering with the containing page - I definitely don't think we should target that. But preventing the content from interfering with the containing page seems in-scope. I agree this particular threat is less risky than actual script execution. > The other way to skin this cat, by the way, is to implement the > seamless attribute on iframes. That gives you a similar sort of > design using the @sandbox attribute and solves many of your above > concerns, e.g. by creating a new namespace for @ids. Maybe we should > try that first or in parallel? Indeed, it can cover some similar use cases. I don't know if it's good for comment sections - one iframe per comment would be quite heavyweight. If there is any active content *around* each comment (like edit or reply buttons) then you might not be able to use one for all of them. In such a case I think innerStaticHTML (or moral equivalent via jailed nodes) would be a more suitable solution. If you have only a small number of untrusted content regions then seamless iframes could be a good solution and it might be easier to be really confident of the implementation (since all cross-frame access of any kind is already doing a security check, and turning off scripting or plugins wholesale for a frame can be done in a very localized way). OTOH it would require render tree expertise to implement the layout aspects. Regards, Maciej From mjs at apple.com Wed Nov 25 14:01:56 2009 From: mjs at apple.com (Maciej Stachowiak) Date: Wed, 25 Nov 2009 14:01:56 -0800 Subject: [webkit-dev] innerStaticHTML In-Reply-To: <22b17c0a0911251345k34da0558q2f04406b7ec397f5@mail.gmail.com> References: <7789133a0911241914j61a267deuf174dad5486fc6e1@mail.gmail.com> <8FCDBCE8-3C69-474A-9A5C-04F3955EA8D3@apple.com> <7789133a0911242237t2fc4e93ak95173b018b71b4fb@mail.gmail.com> <57307917-9060-4B0E-B8D3-5FD4DE4AF1C0@apple.com> <7789133a0911250605p4982ece5y33c6a0200be366d4@mail.gmail.com> <E0AA13FF-899C-4BA4-BC96-A0105D685E5F@apple.com> <7789133a0911251234g7b335260l7dac1985c7250f6e@mail.gmail.com> <0620D569-E3B0-458E-9138-3F5C1AA61DD7@apple.com> <7789133a0911251333s4c76da8kec483c9d0abbc056@mail.gmail.com> <22b17c0a0911251345k34da0558q2f04406b7ec397f5@mail.gmail.com> Message-ID: <85C7DE47-FDAE-4B29-A0EC-50E4C4B08213@apple.com> On Nov 25, 2009, at 1:45 PM, Michal Zalewski wrote: >> The other way to skin this cat, by the way, is to implement the >> seamless attribute on iframes. That gives you a similar sort of >> design using the @sandbox attribute and solves many of your above >> concerns, e.g. by creating a new namespace for @ids. Maybe we should >> try that first or in parallel? > > I would think that in practice, IFRAMEs would, at least > psychologically, be significantly less useful to web app developers. > > This is due to the fact that frames are conceptually more difficult to > properly position and size to accommodate any dynamically inserted > text; Seamless iframes would address this first problem by participating in the layout of the containing page. > are more cumbersome to pre-populate with data on server-side > (extra HTTP roundtrips or opaque data: URLs). Also, are renderer > implementations actually ready to handle hundreds of seamless IFRAMEs > on a page with the performance footprint not exceeding that of spans > and divs? But not these last two problems (though I think you can still document.write() into a sandboxed seamless iframe, making it not much less convenient than the staticInnerHTML solution). Regards, Maciej From sam.weinig at gmail.com Wed Nov 25 20:30:59 2009 From: sam.weinig at gmail.com (Sam Weinig) Date: Wed, 25 Nov 2009 23:30:59 -0500 Subject: [webkit-dev] GlobalScript in WebKit In-Reply-To: <28040fc60911191935o7dc5c5edndd696ee6c31607ac@mail.gmail.com> References: <28040fc60911191935o7dc5c5edndd696ee6c31607ac@mail.gmail.com> Message-ID: <63a07bb10911252030g360f902fh81cc04734aa1f0b2@mail.gmail.com> Hi Dmitry, As I have noted to others on the Chrome team, I do not think this is good idea and I don't think we should have it in WebKit. It adds extra complexity to WebKit and gives little beyond what is possible using inter-window communication and SharedWorkers. I think we need to give more time for large applications to adopt designs around workers before we reverse course, at which point, we should again discuss this in the standards community. -Sam On Thu, Nov 19, 2009 at 10:35 PM, Dmitry Titov <dimich at chromium.org> wrote: > Hi webkit! > > I'm starting to work on actual implementation of GlobalScript experimental > API <http://docs.google.com/View?id=dxv3cth_2rnj9wffz> and started to post > patches (hopefully in reviewable portions). There is an uber-bug<https://bugs.webkit.org/show_bug.cgi?id=31317>which has plan of implementation. > > The current plan is to get it in under ENABLE_GLOBAL_SCRIPT, with both JSC > and v8 bindings (first with JSC because at the moment JSC bindings are > easier to work with and I'd wish WebKit not to have 1-engine-only features > ever). > > I'd be glad to know if there are suggestions, ideas or concerns of any > kind... For example, if there is no interest in JSC bindings, it can be hard > to get them reviewed by someone who knows them well. It'd be better to know > that earlier. > > Thanks! > Dmitry > > _______________________________________________ > webkit-dev mailing list > webkit-dev at lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091125/d4d77a7f/attachment.html> From dimich at chromium.org Wed Nov 25 21:41:46 2009 From: dimich at chromium.org (Dmitry Titov) Date: Wed, 25 Nov 2009 21:41:46 -0800 Subject: [webkit-dev] GlobalScript in WebKit In-Reply-To: <63a07bb10911252030g360f902fh81cc04734aa1f0b2@mail.gmail.com> References: <28040fc60911191935o7dc5c5edndd696ee6c31607ac@mail.gmail.com> <63a07bb10911252030g360f902fh81cc04734aa1f0b2@mail.gmail.com> Message-ID: <28040fc60911252141i6f1ff2c3o89dd9514699d14a7@mail.gmail.com> Hi Sam! Thanks a lot for sharing your perspective! I really wish your reply had, in addition to the statement of the opinion, an argument or just more explanation of why you think so. I think we covered SharedWorkers and inter-window communication in the previous discussions and in the design doc. BTW, could you tell what's the 'course' that would be reverted? Dmitry On Wed, Nov 25, 2009 at 8:30 PM, Sam Weinig <sam.weinig at gmail.com> wrote: > Hi Dmitry, > As I have noted to others on the Chrome team, I do not think this is good > idea and I don't think we should have it in WebKit. ?It adds extra > complexity to WebKit and gives little beyond what is possible using > inter-window communication and SharedWorkers. I think we need to give more > time for large applications to adopt designs around workers before we > reverse course, at which point, we should again discuss this in the > standards community. > -Sam > > On Thu, Nov 19, 2009 at 10:35 PM, Dmitry Titov <dimich at chromium.org> wrote: >> >> Hi webkit! >> I'm starting to?work?on actual implementation of?GlobalScript experimental >> API and started to post patches (hopefully in reviewable portions).?There is >> an uber-bug which has plan of implementation. >> The current plan is to get it in under ENABLE_GLOBAL_SCRIPT, with both JSC >> and v8 bindings (first with JSC because at the moment JSC bindings are >> easier to work with and I'd wish WebKit not to have 1-engine-only features >> ever). >> I'd be glad to know if there are suggestions, ideas or concerns of any >> kind... For example, if there is no interest in JSC bindings, it can be hard >> to get them reviewed by someone who?knows?them well. It'd be better to know >> that earlier. >> Thanks! >> Dmitry >> _______________________________________________ >> webkit-dev mailing list >> webkit-dev at lists.webkit.org >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >> > > From pkasting at google.com Wed Nov 25 22:16:21 2009 From: pkasting at google.com (Peter Kasting) Date: Wed, 25 Nov 2009 22:16:21 -0800 Subject: [webkit-dev] GlobalScript in WebKit In-Reply-To: <28040fc60911252141i6f1ff2c3o89dd9514699d14a7@mail.gmail.com> References: <28040fc60911191935o7dc5c5edndd696ee6c31607ac@mail.gmail.com> <63a07bb10911252030g360f902fh81cc04734aa1f0b2@mail.gmail.com> <28040fc60911252141i6f1ff2c3o89dd9514699d14a7@mail.gmail.com> Message-ID: <d62cf1d10911252216m48d212c4i72e3d571e2a41018@mail.gmail.com> On Wed, Nov 25, 2009 at 9:41 PM, Dmitry Titov <dimich at chromium.org> wrote: > BTW, could you tell what's the 'course' that would be reverted? Meaning, "before we decide that SharedWorkers and inter-window communication are insufficient, and a further proposal should be entertained by the standards community". PK -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091125/c4692811/attachment.html> From abarth at webkit.org Wed Nov 25 22:30:01 2009 From: abarth at webkit.org (Adam Barth) Date: Wed, 25 Nov 2009 22:30:01 -0800 Subject: [webkit-dev] innerStaticHTML In-Reply-To: <162EEBCF-96FE-49FC-A458-3C84EF37E062@apple.com> References: <7789133a0911241914j61a267deuf174dad5486fc6e1@mail.gmail.com> <8FCDBCE8-3C69-474A-9A5C-04F3955EA8D3@apple.com> <7789133a0911242237t2fc4e93ak95173b018b71b4fb@mail.gmail.com> <57307917-9060-4B0E-B8D3-5FD4DE4AF1C0@apple.com> <7789133a0911250605p4982ece5y33c6a0200be366d4@mail.gmail.com> <E0AA13FF-899C-4BA4-BC96-A0105D685E5F@apple.com> <7789133a0911251234g7b335260l7dac1985c7250f6e@mail.gmail.com> <0620D569-E3B0-458E-9138-3F5C1AA61DD7@apple.com> <7789133a0911251333s4c76da8kec483c9d0abbc056@mail.gmail.com> <162EEBCF-96FE-49FC-A458-3C84EF37E062@apple.com> Message-ID: <7789133a0911252230o7060a0aaj28cedb52b5932ef2@mail.gmail.com> On Wed, Nov 25, 2009 at 1:49 PM, Maciej Stachowiak <mjs at apple.com> wrote: > On Nov 25, 2009, at 1:33 PM, Adam Barth wrote: >> I don't have a complete design in mind. ?I could try to write up a >> design document. > > Sounds like we could use one given the potential complications. I've sketched out a complete design here: http://docs.google.com/Doc?id=dd4p8wc4_12sm65qbk4 I've given the participants in this thread write access so they can add notes / ideas. If you'd like write access, let me know. Adam From dimich at chromium.org Thu Nov 26 09:44:20 2009 From: dimich at chromium.org (Dmitry Titov) Date: Thu, 26 Nov 2009 09:44:20 -0800 Subject: [webkit-dev] GlobalScript in WebKit In-Reply-To: <d62cf1d10911252216m48d212c4i72e3d571e2a41018@mail.gmail.com> References: <28040fc60911191935o7dc5c5edndd696ee6c31607ac@mail.gmail.com> <63a07bb10911252030g360f902fh81cc04734aa1f0b2@mail.gmail.com> <28040fc60911252141i6f1ff2c3o89dd9514699d14a7@mail.gmail.com> <d62cf1d10911252216m48d212c4i72e3d571e2a41018@mail.gmail.com> Message-ID: <28040fc60911260944h63f0cab0q52256439c11fc46a@mail.gmail.com> What I meant was it would be nice, for the sake of discussion, to share the experience of real life applications that used SharedWorkers or inter-window communications for sharing of significant portions of code and data. Google apps may be a partial example but it is a real life example of concrete issues with proposed solution that sounds pretty generic and useful for other web apps. It is only prudent to take their feedback rather then replace it with our own theories about future of the web. No doubt this is a new mechanism and it's good to question it, since it has costs even as experimental API. Gut feelings vary, some app devs say they need it to solve real issues, we dont hear from other app devs who were facing similar issues and solved it differently. Seems there is no strong argument to kill it nor bless it. Why don't make it experimental and see? If it was possible to implement it in extension or plugin, we would run it as another Gears-like experiment, but it can not be done in a plugin... I believe there could be good arguments that simply didn't surface yet, and hope to hear them. Dmitry. On Wed, Nov 25, 2009 at 10:16 PM, Peter Kasting <pkasting at google.com> wrote: > On Wed, Nov 25, 2009 at 9:41 PM, Dmitry Titov <dimich at chromium.org> wrote: > >> BTW, could you tell what's the 'course' that would be reverted? > > > Meaning, "before we decide that SharedWorkers and inter-window > communication are insufficient, and a further proposal should be entertained > by the standards community". > > PK > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091126/8dd5e003/attachment.html> From xytsoft at gmail.com Sat Nov 28 00:09:48 2009 From: xytsoft at gmail.com (pattin.shieh) Date: Sat, 28 Nov 2009 16:09:48 +0800 Subject: [webkit-dev] Why Page::setMainFrame use PassRefPtr type parameter? Message-ID: <480f09ee0911280009n6b357a8ejabd3df7232325183@mail.gmail.com> Look at this:void Page::setMainFrame(PassRefPtr<Frame> mainFrame). Why use PassRefPtr? Infact,change to following will work same: void Page::setMainFrame(Frame *mainFrame) 1).Look into the function source code: m_mainFrame = mainFrame; --> call "operator=(T* optr)",reference count +1 It mean that if change to "Frame *mainFrame" ,will call mainFrame->ref(); 2).Using "PassRefPtr<Frame> mainFrame": m_mainFrame = mainFrame; --> call "operator=(const PassRefPtr<T>& o)",reference count no change But,reference count was changed when the function is called: page->setMainFrame(this); --> call "PassRefPtr(T* ptr) : m_ptr(ptr) { if (ptr) ptr->ref(); }", reference count +1 So,The "PassRefPtr<Frame> mainFrame" and the "Frame *mainFrame" cause same reference count. But use "PassRefPtr<Frame>" will call new operation! -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091128/16d85833/attachment.html> From abarth at webkit.org Sat Nov 28 02:21:38 2009 From: abarth at webkit.org (Adam Barth) Date: Sat, 28 Nov 2009 02:21:38 -0800 Subject: [webkit-dev] style-queue entering beta Message-ID: <7789133a0911280221p48bd53cdk8e1d730160124936@mail.gmail.com> One of the bots that Eric and I have been working on is about to come online. This bot is a "style bot" that runs check-webkit-style on patches that have been nominated for review. I'd like to ask your patience while we work out the kinks. You can skip the rest of this email if you're not interested in the nitty gritty. == Summary == The primary goal of the style-queue is to reduce review latency by (1) giving immediate feedback to contributors and (2) making human reviewer more efficient by relieving them of mechanical tasks (like asking for tabs to be replaced with spaces). The style-queue scans the set of patches that are pending-review for new patches. When it finds a new patch, the bot runs check-webkit-style on the patch. If check-webkit-style finds style errors, the bot comments on the bug. == Social Contract == The style-queue is purely informative. You're free to ignore it's comments. Ideally, the bot should be silent unless it has something interesting to say. If we decide that style-queue is too chatty, we can change check-webkit-style to report fewer errors. One corollary of this social contract is that the style-queue doesn't inform you when your patch passes the style check (because most patches should pass, right?). We can re-visit this design choice later if it turns out we really want to know when the check succeeds. == Response to Previous Feedback == When I floated this idea on webkit-dev previously (in the "bot-filled future" thread), I got a bunch of useful feedback. Here's how we incorporated that feedback into the current design: 1) "Adding an extra flags is going to cause confusion." The style-queue does not add any flags to Bugzilla. Instead of storing it's state in Bugzilla flags (like commit-queue does), we built an AppEngine web service to hold the queue's persistent state. Instead of indicating style errors with a negative flag, the bot adds a comment to the bug. 2) "What machines are going to be doing these tests, and on which platforms?" The style-queue runs on a machine in my apartment that runs Mac OS X. The style-queue is platform independent, so this is less of an issue for style-queue than it is for a build-queue. 3) "Which patches would this test?" The style-queue tests any patch marked "review?". This design avoids the need for additional flags or indications that a patch should be run through the queue. 4) "Running tests on an arbitrary patches [opens a security hole]." Instead of running check-webkit-style from it's own working copy, the style-queue runs check-webkit-style from a separate working copy. While it's true you could haxor my machine by committing an evil copy of check-webkit-style, I'm already running that risk whenever I type "svn up". == Frequently Asked Questions == Q1: If the style-queue doesn't complain, does that mean my patch has correct style? A1: Unfortunately, no. First of all, check-webkit-style has false negatives. Hopefully, the script will improve over time, but it will never be perfect. Second, the style-queue is only able to check patches that successfully download and apply to top-of-tree. If your patch does not apply to top-of-tree (e.g., because it depends on another patch), then style-queue won't say anything. Q2: How can I see whether style-queue processed my patch? A2: There isn't a great way to do this yet. The data is stored in the webkit-commit-queue.appspot.com web service, but we haven't built a front-end for it yet. If you have a strong stomach, you can look at the endpoint the bot itself uses http://webkit-commit-queue.appspot.com/patch-status/style-queue/12345 where 12345 is the ID of your attachment. If you'd like to have a better status display, feel free to hack on WebKitTools/QueueStatusServer and send me or Eric patches to review. In the long term, there's no reason we can't have an awesome UI. Q3: This bot is going to run amock! How can I keep track of all it's evil deeds? A3: If you want to see what the bots are doing, you can subscribe to the following email list: http://groups.google.com/group/webkit-bot-watchers Whenever the bots touch a bug, they're supposed to add this address to the CC list. This functionality is very new, so we might not have every case covered yet. If you see the bot misbehaving, let me or Eric know. We'll correct the issue ASAP. Q4: Checking style is fine and dandy, but I was hoping for a build-queue! A4: My next project is to get a build-queue working for Qt. The build-queue will share a lot of infrastructure with the style-queue, but making the style-queue was easier because check-webkit-style is a lot faster than build-webkit. :) Q5: When are you flipping the switch? A5: Either today or tomorrow, depending on when I find a stretch of time to babysit the queue through whatever initial troubles it has. My working copy of the style-queue is about five patches ahead of trunk. It would be nice to have those patches committed before flipping the switch, but it's not necessary. Thanks for reading to the end, and I hope you find the style-queue useful. Adam From avshabanov at gmail.com Sat Nov 28 03:16:26 2009 From: avshabanov at gmail.com (Alexander Shabanov) Date: Sat, 28 Nov 2009 14:16:26 +0300 Subject: [webkit-dev] Why it is not possible to appendChild on elements created by DOMParser? Message-ID: <43a7c3700911280316t6e5764fdp230ae89d18fbe468@mail.gmail.com> Hi all, Sorry for silly question but I think that it might be a nice feature to webkit. The following code works in Mozilla Firefox 3.5, but it does not work in webkit-based browsers: var parser = new DOMParser(); var str = "<p>This is a test</p>"; var doc = parser.parseFromString(str, "text/xml"); document.body.appendChild(doc.documentElement.firstChild); I found that specification to DOMParser does not guarantee that the result of DOMParser's parseFromX methods can be directly used in the original document. Nevertheless I believe that it would be quite a useful feature, at least it won't require JS code to create DOM-compliant content from the parsed one. May be I missed something and webkit offers a way of quick adaptation of the parsed content to the original DOM tree? Thanks in advance. P.S.: even though Firefox provides such a feature, a style specification in the following code will take no effect: var parser = new DOMParser(); var str = "<p style='color: red;'>This is a test</p>"; var doc = parser.parseFromString(str, "text/xml"); document.body.appendChild(doc.documentElement.firstChild); -- Best regards, Alexander Shabanov From mjs at apple.com Sat Nov 28 10:21:00 2009 From: mjs at apple.com (Maciej Stachowiak) Date: Sat, 28 Nov 2009 10:21:00 -0800 Subject: [webkit-dev] style-queue entering beta In-Reply-To: <7789133a0911280221p48bd53cdk8e1d730160124936@mail.gmail.com> References: <7789133a0911280221p48bd53cdk8e1d730160124936@mail.gmail.com> Message-ID: <F2C13DF1-4E57-491F-BE16-3D8D1315BEB2@apple.com> Sounds like a good idea in general. Some comments below: On Nov 28, 2009, at 2:21 AM, Adam Barth wrote: > One of the bots that Eric and I have been working on is about to come > online. This bot is a "style bot" that runs check-webkit-style on > patches that have been nominated for review. I'd like to ask your > patience while we work out the kinks. > > You can skip the rest of this email if you're not interested in the > nitty gritty. > > == Summary == > > The primary goal of the style-queue is to reduce review latency by (1) > giving immediate feedback to contributors and (2) making human > reviewer more efficient by relieving them of mechanical tasks (like > asking for tabs to be replaced with spaces). > > The style-queue scans the set of patches that are pending-review for > new patches. When it finds a new patch, the bot runs > check-webkit-style on the patch. If check-webkit-style finds style > errors, the bot comments on the bug. > > == Social Contract == > > The style-queue is purely informative. You're free to ignore it's > comments. Ideally, the bot should be silent unless it has something > interesting to say. If we decide that style-queue is too chatty, we > can change check-webkit-style to report fewer errors. > > One corollary of this social contract is that the style-queue doesn't > inform you when your patch passes the style check (because most > patches should pass, right?). We can re-visit this design choice > later if it turns out we really want to know when the check succeeds. To actually relieve reviewers of the burden of manual style review, it seems like the bot would have to record when a patch passes the style check. Otherwise, how can you tell whether a patch has passed the check, or if the bot just hasn't run on it yet? Would anyone object to seeing the information that a patch has passed an automated style check in a comment? > > == Response to Previous Feedback == > > When I floated this idea on webkit-dev previously (in the "bot-filled > future" thread), I got a bunch of useful feedback. Here's how we > incorporated that feedback into the current design: > > 1) "Adding an extra flags is going to cause confusion." The > style-queue does not add any flags to Bugzilla. Instead of storing > it's state in Bugzilla flags (like commit-queue does), we built an > AppEngine web service to hold the queue's persistent state. Instead > of indicating style errors with a negative flag, the bot adds a > comment to the bug. It does seem that flags are noisy in an unappealing way, but it would be much better (IMO) to store this information in the bugzilla database instead of externally. Is there any way we can do that? Could we make a flag that is hidden in the default UI, or use specially formatted comments that the bot knows how to recognize? > > 2) "What machines are going to be doing these tests, and on which > platforms?" The style-queue runs on a machine in my apartment that > runs Mac OS X. The style-queue is platform independent, so this is > less of an issue for style-queue than it is for a build-queue. > > 3) "Which patches would this test?" The style-queue tests any patch > marked "review?". This design avoids the need for additional flags or > indications that a patch should be run through the queue. > > 4) "Running tests on an arbitrary patches [opens a security hole]." > Instead of running check-webkit-style from it's own working copy, the > style-queue runs check-webkit-style from a separate working copy. > While it's true you could haxor my machine by committing an evil copy > of check-webkit-style, I'm already running that risk whenever I type > "svn up". > > == Frequently Asked Questions == > > Q1: If the style-queue doesn't complain, does that mean my patch has > correct style? > > A1: Unfortunately, no. First of all, check-webkit-style has false > negatives. Hopefully, the script will improve over time, but it will > never be perfect. Second, the style-queue is only able to check > patches that successfully download and apply to top-of-tree. If your > patch does not apply to top-of-tree (e.g., because it depends on > another patch), then style-queue won't say anything. > > Q2: How can I see whether style-queue processed my patch? > > A2: There isn't a great way to do this yet. The data is stored in the > webkit-commit-queue.appspot.com web service, but we haven't built a > front-end for it yet. If you have a strong stomach, you can look at > the endpoint the bot itself uses > > http://webkit-commit-queue.appspot.com/patch-status/style-queue/12345 > > where 12345 is the ID of your attachment. If you'd like to have a > better status display, feel free to hack on > WebKitTools/QueueStatusServer and send me or Eric patches to review. > In the long term, there's no reason we can't have an awesome UI. > > Q3: This bot is going to run amock! How can I keep track of all it's > evil deeds? > > A3: If you want to see what the bots are doing, you can subscribe to > the following email list: > > http://groups.google.com/group/webkit-bot-watchers > > Whenever the bots touch a bug, they're supposed to add this address to > the CC list. This functionality is very new, so we might not have > every case covered yet. If you see the bot misbehaving, let me or > Eric know. We'll correct the issue ASAP. > > Q4: Checking style is fine and dandy, but I was hoping for a build- > queue! > > A4: My next project is to get a build-queue working for Qt. The > build-queue will share a lot of infrastructure with the style-queue, > but making the style-queue was easier because check-webkit-style is a > lot faster than build-webkit. :) > > Q5: When are you flipping the switch? > > A5: Either today or tomorrow, depending on when I find a stretch of > time to babysit the queue through whatever initial troubles it has. > My working copy of the style-queue is about five patches ahead of > trunk. It would be nice to have those patches committed before > flipping the switch, but it's not necessary. > > Thanks for reading to the end, and I hope you find the style-queue > useful. > > Adam > _______________________________________________ > webkit-dev mailing list > webkit-dev at lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev From abarth at webkit.org Sat Nov 28 10:53:06 2009 From: abarth at webkit.org (Adam Barth) Date: Sat, 28 Nov 2009 10:53:06 -0800 Subject: [webkit-dev] style-queue entering beta In-Reply-To: <F2C13DF1-4E57-491F-BE16-3D8D1315BEB2@apple.com> References: <7789133a0911280221p48bd53cdk8e1d730160124936@mail.gmail.com> <F2C13DF1-4E57-491F-BE16-3D8D1315BEB2@apple.com> Message-ID: <7789133a0911281053p571cb44ek369389e6de165766@mail.gmail.com> On Sat, Nov 28, 2009 at 10:21 AM, Maciej Stachowiak <mjs at apple.com> wrote: > On Nov 28, 2009, at 2:21 AM, Adam Barth wrote: >> 1) "Adding an extra flags is going to cause confusion." ?The >> style-queue does not add any flags to Bugzilla. ?Instead of storing >> it's state in Bugzilla flags (like commit-queue does), we built an >> AppEngine web service to hold the queue's persistent state. ?Instead >> of indicating style errors with a negative flag, the bot adds a >> comment to the bug. > > It does seem that flags are noisy in an unappealing way, but it would be > much better (IMO) to store this information in the bugzilla database instead > of externally. Is there any way we can do that? >From an implementation point of view, either way is easy now that we've got the infrastructure built. It's a question of which you'd prefer. > Could we make a flag that is > hidden in the default UI, or use specially formatted comments that the bot > knows how to recognize? >From my point of view, a hidden flag could work. We considered specially formatted comments, but that would make the bot more chatty. For example, if the style-queue has some internal error that prevents it from processing the patch, it wants to remember that, but it doesn't want to spam the bug with that information. I'm not sure representing all the state in Bugzilla is necessary. We should represent the "most interesting" state (e.g., pass / fail) there. For the rest, we can have a dashboard similar to build.webkit.org that shows the status of various patches before they are committed. I've started sketching something rough here: http://webkit-commit-queue.appspot.com/static/details.html You can imagine clicking those squares to see the full log of what happened. For example, if the build failed on Qt, you might want to see the full output of build-webkit --qt, but we don't need to post all that to Bugzilla. The comment might just say: Patch 86912 did not build on Qt. Build log: http://webkit-commit-queue.appspot.com/patch-status/build-queue-qt/86912/all At a higher level, I'm sympathetic to Mark's concerns about what the system will look like when we have a number of bots. Bugzilla flags work well for receiving input from humans. There are lots of choices for how to present output. For example, another option is to have a bunch of colored squares next to each attachment that represent that patch's row on the dashboard. Adam From mjs at apple.com Sat Nov 28 22:44:52 2009 From: mjs at apple.com (Maciej Stachowiak) Date: Sat, 28 Nov 2009 22:44:52 -0800 Subject: [webkit-dev] style-queue entering beta In-Reply-To: <7789133a0911281053p571cb44ek369389e6de165766@mail.gmail.com> References: <7789133a0911280221p48bd53cdk8e1d730160124936@mail.gmail.com> <F2C13DF1-4E57-491F-BE16-3D8D1315BEB2@apple.com> <7789133a0911281053p571cb44ek369389e6de165766@mail.gmail.com> Message-ID: <E247E5EA-9C40-4DFD-9151-CD957D553176@apple.com> On Nov 28, 2009, at 10:53 AM, Adam Barth wrote: > On Sat, Nov 28, 2009 at 10:21 AM, Maciej Stachowiak <mjs at apple.com> > wrote: >> On Nov 28, 2009, at 2:21 AM, Adam Barth wrote: >>> 1) "Adding an extra flags is going to cause confusion." The >>> style-queue does not add any flags to Bugzilla. Instead of storing >>> it's state in Bugzilla flags (like commit-queue does), we built an >>> AppEngine web service to hold the queue's persistent state. Instead >>> of indicating style errors with a negative flag, the bot adds a >>> comment to the bug. >> >> It does seem that flags are noisy in an unappealing way, but it >> would be >> much better (IMO) to store this information in the bugzilla >> database instead >> of externally. Is there any way we can do that? > > From an implementation point of view, either way is easy now that > we've got the infrastructure built. It's a question of which you'd > prefer. > >> Could we make a flag that is >> hidden in the default UI, or use specially formatted comments that >> the bot >> knows how to recognize? > > From my point of view, a hidden flag could work. We considered > specially formatted comments, but that would make the bot more chatty. > For example, if the style-queue has some internal error that prevents > it from processing the patch, it wants to remember that, but it > doesn't want to spam the bug with that information. > > I'm not sure representing all the state in Bugzilla is necessary. We > should represent the "most interesting" state (e.g., pass / fail) > there. For the rest, we can have a dashboard similar to > build.webkit.org that shows the status of various patches before they > are committed. I've started sketching something rough here: > > http://webkit-commit-queue.appspot.com/static/details.html Pass/fail status sounds fine to me. I agree that an error by the bot should not be highly visible in the bug, as that is not as useful to the review and submitter as Pass or Fail and Here's the Mistakes. > > You can imagine clicking those squares to see the full log of what > happened. For example, if the build failed on Qt, you might want to > see the full output of build-webkit --qt, but we don't need to post > all that to Bugzilla. The comment might just say: Looks like a decent design. > > Patch 86912 did not build on Qt. Build log: > http://webkit-commit-queue.appspot.com/patch-status/build-queue-qt/86912/all > > At a higher level, I'm sympathetic to Mark's concerns about what the > system will look like when we have a number of bots. Bugzilla flags > work well for receiving input from humans. There are lots of choices > for how to present output. For example, another option is to have a > bunch of colored squares next to each attachment that represent that > patch's row on the dashboard. > > Adam From kenneth.christiansen at openbossa.org Sun Nov 29 08:26:00 2009 From: kenneth.christiansen at openbossa.org (Kenneth Christiansen) Date: Sun, 29 Nov 2009 13:26:00 -0300 Subject: [webkit-dev] style-queue entering beta In-Reply-To: <E247E5EA-9C40-4DFD-9151-CD957D553176@apple.com> References: <7789133a0911280221p48bd53cdk8e1d730160124936@mail.gmail.com> <F2C13DF1-4E57-491F-BE16-3D8D1315BEB2@apple.com> <7789133a0911281053p571cb44ek369389e6de165766@mail.gmail.com> <E247E5EA-9C40-4DFD-9151-CD957D553176@apple.com> Message-ID: <927d01d20911290826j47498051g950fc2a849f94e55@mail.gmail.com> Maybe in the case of failure, provide a link to further information? Kenneth On Sun, Nov 29, 2009 at 3:44 AM, Maciej Stachowiak <mjs at apple.com> wrote: > > On Nov 28, 2009, at 10:53 AM, Adam Barth wrote: > > On Sat, Nov 28, 2009 at 10:21 AM, Maciej Stachowiak <mjs at apple.com> >> wrote: >> >>> On Nov 28, 2009, at 2:21 AM, Adam Barth wrote: >>> >>>> 1) "Adding an extra flags is going to cause confusion." The >>>> style-queue does not add any flags to Bugzilla. Instead of storing >>>> it's state in Bugzilla flags (like commit-queue does), we built an >>>> AppEngine web service to hold the queue's persistent state. Instead >>>> of indicating style errors with a negative flag, the bot adds a >>>> comment to the bug. >>>> >>> >>> It does seem that flags are noisy in an unappealing way, but it would be >>> much better (IMO) to store this information in the bugzilla database >>> instead >>> of externally. Is there any way we can do that? >>> >> >> From an implementation point of view, either way is easy now that >> we've got the infrastructure built. It's a question of which you'd >> prefer. >> >> Could we make a flag that is >>> hidden in the default UI, or use specially formatted comments that the >>> bot >>> knows how to recognize? >>> >> >> From my point of view, a hidden flag could work. We considered >> specially formatted comments, but that would make the bot more chatty. >> For example, if the style-queue has some internal error that prevents >> it from processing the patch, it wants to remember that, but it >> doesn't want to spam the bug with that information. >> >> I'm not sure representing all the state in Bugzilla is necessary. We >> should represent the "most interesting" state (e.g., pass / fail) >> there. For the rest, we can have a dashboard similar to >> build.webkit.org that shows the status of various patches before they >> are committed. I've started sketching something rough here: >> >> http://webkit-commit-queue.appspot.com/static/details.html >> > > Pass/fail status sounds fine to me. I agree that an error by the bot should > not be highly visible in the bug, as that is not as useful to the review and > submitter as Pass or Fail and Here's the Mistakes. > > > >> You can imagine clicking those squares to see the full log of what >> happened. For example, if the build failed on Qt, you might want to >> see the full output of build-webkit --qt, but we don't need to post >> all that to Bugzilla. The comment might just say: >> > > Looks like a decent design. > > > >> Patch 86912 did not build on Qt. Build log: >> >> http://webkit-commit-queue.appspot.com/patch-status/build-queue-qt/86912/all >> >> At a higher level, I'm sympathetic to Mark's concerns about what the >> system will look like when we have a number of bots. Bugzilla flags >> work well for receiving input from humans. There are lots of choices >> for how to present output. For example, another option is to have a >> bunch of colored squares next to each attachment that represent that >> patch's row on the dashboard. >> >> Adam >> > > _______________________________________________ > webkit-dev mailing list > webkit-dev at lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > -- Kenneth Rohde Christiansen Technical Lead / Senior Software Engineer Qt Labs Americas, Nokia Technology Institute, INdT Phone +55 81 8895 6002 / E-mail kenneth.christiansen at openbossa.org -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091129/a5560a6c/attachment.html> From bedney at technicalpursuit.com Sun Nov 29 08:38:21 2009 From: bedney at technicalpursuit.com (William Edney) Date: Sun, 29 Nov 2009 10:38:21 -0600 Subject: [webkit-dev] localStorage quota limit Message-ID: <0D5D73B4-AC40-479F-A8CF-354CEC226385@technicalpursuit.com> All - I've been discussing the localStorage quota limit over on this bug with Jeremy Orlow: https://bugs.webkit.org/show_bug.cgi?id=31791 To recap from the discussions on that bug: Jeremy has implemented the localStorage quota on the latest Webkit builds. This caused my usage of localStorage to fail, because as a JS programmer, I assumed that 5MB meant '5 million characters' of storage. This assumption holds true on Firefox 3.5.X+ and IE8, but fails on Webkit since it stores things into localStorage as UTF-16. One option we discussed on that bug was getting the spec folks to alter the spec in one of three ways: - specify the quota in terms of 'characters' (or Strings, or whatever) thereby abstracting away the encoding problem entirely. - specify UTF-8 so that 'MB = characters' - specify a JS API such that the encoding could be specified. Jeremy wasn't too taken with any of these proposals, and in any case, they probably need to be taken up on the W3 group defining this stuff, not here. In any case, as Jeremy states in Comment #5 of the bug report, "the spec's mentioning of 5mb is really just an example". And when I filed this bug on Mozilla's Bugzilla tracker: https://bugzilla.mozilla.org/show_bug.cgi?id=461684 another comment there points out the same thing. (Note that this bug was originally filed to see if the Mozilla guys would raise their quota to 10MB to match IE8 and, since they don't use double-byte encoding, I was really asking for '10 million characters' there :-)). Given that, an increase from 5MB to 10MB would 'solve my immediate problem'. And, without going back to the spec folks, I'm not sure that much more can be done here. Jeremy wanted me to post to get the discussion started (and hopefully attain some consensus :-) ), so let's discuss :-). Thanks in advance! Cheers, - Bill -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091129/3b2f6895/attachment.html> From ajmas at sympatico.ca Sun Nov 29 07:11:07 2009 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sun, 29 Nov 2009 10:11:07 -0500 Subject: [webkit-dev] HTML Layers above plugin Message-ID: <BLU0-SMTP61C82C48D33FA22ADB4A8BC5980@phx.gbl> Hi, I am currently investigating the possibility of using a web container for an HTPC system. As part of the design I am looking at is to use the multiple tab views to embed the necessary elements. One would concentrate on the menu and another on the embedded player (via plugin). For the view showing the plug-in I have two approaches that I am looking at, where is either work with with plug-in developers to add the necessary chrome needed to display the play various information or to somehow overlay 'controls' in HTML. If I do create a layer with a z-index above the video plugin it will get obstructed by the plugin. On the other hand I am able to hide the layer with the plug-in without any issue. Is there are a way to draw HTML above the plugin? If not is there any technical reason why something like this could not be implemented? Andr?-John From chris.jerdonek at gmail.com Sun Nov 29 09:26:49 2009 From: chris.jerdonek at gmail.com (Chris Jerdonek) Date: Sun, 29 Nov 2009 09:26:49 -0800 Subject: [webkit-dev] style-queue entering beta Message-ID: <dacc8d1a0911290926v5be045e6tb425b94bac0f378b@mail.gmail.com> On Sat, Nov 28, 2009, Adam Barth wrote: > One of the bots that Eric and I have been working on is about to come > online. This bot is a "style bot" that runs check-webkit-style on > patches that have been nominated for review. This seems like a good effort, thanks. A couple minor comments below on the first question in your FAQ: > == Frequently Asked Questions == > > Q1: If the style-queue doesn't complain, does that mean my patch has > correct style? > > A1: Unfortunately, no. ?First of all, check-webkit-style has false > negatives. It seems like this answers the different question, "If the style-queue complains, does that mean my patch has incorrect style?" > Hopefully, the script will improve over time, but it will > never be perfect. Can you elaborate on this? For example, are you saying there is a basic reason that the script will always have bugs? Without knowing too much about the script, it seems like it wouldn't be too hard to at least make the false negatives go away. Or are you simply saying that the guidelines and script will never fully capture what we mean by "correct style"? > Second, the style-queue is only able to check > patches that successfully download and apply to top-of-tree. If your > patch does not apply to top-of-tree (e.g., because it depends on > another patch), then style-queue won't say anything. Thanks, --Chris From abarth at webkit.org Sun Nov 29 09:35:05 2009 From: abarth at webkit.org (Adam Barth) Date: Sun, 29 Nov 2009 09:35:05 -0800 Subject: [webkit-dev] style-queue entering beta In-Reply-To: <dacc8d1a0911290926v5be045e6tb425b94bac0f378b@mail.gmail.com> References: <dacc8d1a0911290926v5be045e6tb425b94bac0f378b@mail.gmail.com> Message-ID: <7789133a0911290935q46be9ac0l700cc7ca72710ca7@mail.gmail.com> On Sun, Nov 29, 2009 at 9:26 AM, Chris Jerdonek <chris.jerdonek at gmail.com> wrote: > On Sat, Nov 28, 2009, ?Adam Barth wrote: >> A1: Unfortunately, no. ?First of all, check-webkit-style has false >> negatives. > > It seems like this answers the different question, "If the style-queue > complains, does that mean my patch has incorrect style?" Yes, that too. I would call that a false positive, but you're right that check-webkit-style probably has both kinds of bugs. >> Hopefully, the script will improve over time, but it will >> never be perfect. > > Can you elaborate on this? ?For example, are you saying there is a > basic reason that the script will always have bugs? ?Without knowing > too much about the script, it seems like it wouldn't be too hard to at > least make the false negatives go away. ?Or are you simply saying that > the guidelines and script will never fully capture what we mean by > "correct style"? Does this mean you're volunteering to remove all the false positives and false negatives? :) One basic reason the script isn't perfect is that it's doesn't have a full C++ / Objective-C++ parser. I think it uses regular expressions. Anyway, I just wanted to set expectations that the tool might not be perfect. Adam From evan at chromium.org Sun Nov 29 10:07:22 2009 From: evan at chromium.org (Evan Martin) Date: Sun, 29 Nov 2009 10:07:22 -0800 Subject: [webkit-dev] HTML Layers above plugin In-Reply-To: <BLU0-SMTP61C82C48D33FA22ADB4A8BC5980@phx.gbl> References: <BLU0-SMTP61C82C48D33FA22ADB4A8BC5980@phx.gbl> Message-ID: <9f43d19d0911291007x2a69bc05q5bb6a73b03fb733b@mail.gmail.com> On Sun, Nov 29, 2009 at 7:11 AM, Andre-John Mas <ajmas at sympatico.ca> wrote: > I am currently investigating the possibility of using a web container for an HTPC system. As part of the design I am looking at is to use the multiple tab views to embed the necessary elements. One would concentrate on the menu and another on the embedded player (via plugin). For the view showing the plug-in I have two approaches that I am looking at, where is either work with with plug-in developers to add the necessary chrome needed to display the play various information or to somehow overlay 'controls' in HTML. > > If I do create a layer with a z-index above the video plugin it will get obstructed by the plugin. On the other hand I am able to hide the layer with the plug-in without any issue. Is there are a way to draw HTML above the plugin? If not is there any technical reason why something like this could not be implemented? This is a web development question and probably not appropriate for this list, but: - If the plugin is windowed, consulting your favorite search engine for [iframe shim] will put you on the right track. - If the plugin supports windowless mode, it layers like a normal HTML element. E.g. see [flash wmode] for discussion of this for Flash. From kevino at theolliviers.com Sun Nov 29 10:27:07 2009 From: kevino at theolliviers.com (Kevin Ollivier) Date: Sun, 29 Nov 2009 10:27:07 -0800 Subject: [webkit-dev] Platform API for Uniscribe/ComplexTextController? Message-ID: <562D1953-F82A-4DD8-99C3-8F801ABAC767@theolliviers.com> Hi all, The wx port is starting to look at getting proper support for complex text, and one of the first places I started looking at was the Win and Mac port implementations. I noticed that the complex text code in FontWin.cpp and FontComplexTextMac.cpp is largely the same, passing the heavy lifting down to their respective complex text controllers, and I actually wondered if they could be merged if there were some tweaks to the APIs to make them compatible. That led me to wonder if we couldn't make ComplexTextController one of our platform classes and have USE() defines to determine the implementation. Then we could move the drawComplexText, floatWidthForComplexText, and offsetForPositionForComplexText into Font.cpp guarded by that USE() define. The wx port can provide the native font handles the Win/Mac controllers need, so it'd really be great if we could just add these into our build to get complex text support working without having to implement the complex text methods differently for each platform. BTW, I actually already did get UniscribeController compiling, actually, but on Windows I had to have the build script copy it to platform/graphics/wx because MSVC implicitly puts the current directory first on the path, which was causing it to pick up platform/graphics/win/FontPlatformData.h instead of the wx one when compiling that file. :( So that's something else that would need to be addressed if ports can start sharing these files. Thanks, Kevin From chris.jerdonek at gmail.com Sun Nov 29 17:00:59 2009 From: chris.jerdonek at gmail.com (Chris Jerdonek) Date: Sun, 29 Nov 2009 17:00:59 -0800 Subject: [webkit-dev] style-queue entering beta In-Reply-To: <7789133a0911290935q46be9ac0l700cc7ca72710ca7@mail.gmail.com> References: <dacc8d1a0911290926v5be045e6tb425b94bac0f378b@mail.gmail.com> <7789133a0911290935q46be9ac0l700cc7ca72710ca7@mail.gmail.com> Message-ID: <dacc8d1a0911291700s6de913e0oae5ecdd90af889b1@mail.gmail.com> On Sun, Nov 29, 2009 at 9:35 AM, Adam Barth <abarth at webkit.org> wrote: > On Sun, Nov 29, 2009 at 9:26 AM, Chris Jerdonek > <chris.jerdonek at gmail.com> wrote: >> On Sat, Nov 28, 2009, ?Adam Barth wrote: >>> Hopefully, the script will improve over time, but it will >>> never be perfect. >> >> Can you elaborate on this? ?For example, are you saying there is a >> basic reason that the script will always have bugs? ?Without knowing >> too much about the script, it seems like it wouldn't be too hard to at >> least make the false negatives go away. ?Or are you simply saying that >> the guidelines and script will never fully capture what we mean by >> "correct style"? > > Does this mean you're volunteering to remove all the false positives > and false negatives? ?:) I was hoping to work on the script eventually, which is partly why I asked for elaboration. All that I meant above is that one could potentially disable (for the bot) the style tests that report false violations, or else reduce their confidence score. That way, if the style bot flags a patch, it is guaranteed to be meaningful without looking at the details of the report. This can only be done, though, if the problems with the script are not so basic that they affect most or many of the tests. (The reverse is not as straightforward, though. It does not seem as easy to change the script -- in a useful way -- so that if it reports that a patch has met the guidelines, then the patch really meets the guidelines.) > One basic reason the script isn't perfect is that it's doesn't have a > full C++ / Objective-C++ parser. If we could go this route, would we prefer it? --Chris From abarth at webkit.org Sun Nov 29 17:55:32 2009 From: abarth at webkit.org (Adam Barth) Date: Sun, 29 Nov 2009 17:55:32 -0800 Subject: [webkit-dev] style-queue entering beta In-Reply-To: <dacc8d1a0911291700s6de913e0oae5ecdd90af889b1@mail.gmail.com> References: <dacc8d1a0911290926v5be045e6tb425b94bac0f378b@mail.gmail.com> <7789133a0911290935q46be9ac0l700cc7ca72710ca7@mail.gmail.com> <dacc8d1a0911291700s6de913e0oae5ecdd90af889b1@mail.gmail.com> Message-ID: <7789133a0911291755i4b2ccdfei5c0c6a43ac76fcb3@mail.gmail.com> Yeah, I think improving the script would be great. I'm not actually an expert on how it works internally, but I think David Levin is. It's easy for the bot to pass a flag to the script if that would be helpful. In general, I think we should give it a try and iterate to remove the biggest pain points. Thanks! Adam On Sun, Nov 29, 2009 at 5:00 PM, Chris Jerdonek <chris.jerdonek at gmail.com> wrote: > On Sun, Nov 29, 2009 at 9:35 AM, Adam Barth <abarth at webkit.org> wrote: > >> On Sun, Nov 29, 2009 at 9:26 AM, Chris Jerdonek >> <chris.jerdonek at gmail.com> wrote: >>> On Sat, Nov 28, 2009, ?Adam Barth wrote: >>>> Hopefully, the script will improve over time, but it will >>>> never be perfect. >>> >>> Can you elaborate on this? ?For example, are you saying there is a >>> basic reason that the script will always have bugs? ?Without knowing >>> too much about the script, it seems like it wouldn't be too hard to at >>> least make the false negatives go away. ?Or are you simply saying that >>> the guidelines and script will never fully capture what we mean by >>> "correct style"? >> >> Does this mean you're volunteering to remove all the false positives >> and false negatives? ?:) > > I was hoping to work on the script eventually, which is partly why I > asked for elaboration. > > All that I meant above is that one could potentially disable (for the > bot) the style tests that report false violations, or else reduce > their confidence score. ?That way, if the style bot flags a patch, it > is guaranteed to be meaningful without looking at the details of the > report. ?This can only be done, though, if the problems with the > script are not so basic that they affect most or many of the tests. > > (The reverse is not as straightforward, though. ?It does not seem as > easy to change the script -- in a useful way -- so that if it reports > that a patch has met the guidelines, then the patch really meets the > guidelines.) > >> One basic reason the script isn't perfect is that it's doesn't have a >> full C++ / Objective-C++ parser. > > If we could go this route, would we prefer it? > > --Chris > From levin at chromium.org Sun Nov 29 23:11:52 2009 From: levin at chromium.org (David Levin) Date: Sun, 29 Nov 2009 23:11:52 -0800 Subject: [webkit-dev] style-queue entering beta In-Reply-To: <7789133a0911291755i4b2ccdfei5c0c6a43ac76fcb3@mail.gmail.com> References: <dacc8d1a0911290926v5be045e6tb425b94bac0f378b@mail.gmail.com> <7789133a0911290935q46be9ac0l700cc7ca72710ca7@mail.gmail.com> <dacc8d1a0911291700s6de913e0oae5ecdd90af889b1@mail.gmail.com> <7789133a0911291755i4b2ccdfei5c0c6a43ac76fcb3@mail.gmail.com> Message-ID: <b902e34a0911292311w5c941643x878ac4b7409729d2@mail.gmail.com> fwiw, I'm not aware of any bad error reports that people are hitting in practice although as Adam mentioned it is possible for various reasons. If we hit any incorrect warnings with any frequency, we should disable them or fix them. Of course, there are a lots of WebKit style guidelines that it doesn't catch. > One basic reason the script isn't perfect is that it's doesn't have a > full C++ / Objective-C++ parser. If we could go this route, would we prefer it? It may be a really good thing. It would depend on how complicated the tool/code got. As far as this tool goes, it is derived from an open source version of what Google uses in house and then originally adapted for WebKit by Shinichiro Hamaji. It primarily relies on regex. In the past I wrote a closed source tool that used a parser to do style fixes in lots of ways, and I appreciated the exactness of the results. One nice thing about the current code is that it is pretty accessible to new folks. I don't think that was as true of the tool I wrote on top of the parser which examined and manipulated syntax trees. Dave PS In fact, some checks by various folks in WebKit were made to catch less things in order to avoid false negatives because noisy incorrect tools are just annoying (and imo frequently are justifiably ignored). On Sun, Nov 29, 2009 at 5:55 PM, Adam Barth <abarth at webkit.org> wrote: > Yeah, I think improving the script would be great. I'm not actually > an expert on how it works internally, but I think David Levin is. > It's easy for the bot to pass a flag to the script if that would be > helpful. In general, I think we should give it a try and iterate to > remove the biggest pain points. > > Thanks! > Adam > > > On Sun, Nov 29, 2009 at 5:00 PM, Chris Jerdonek > <chris.jerdonek at gmail.com> wrote: > > On Sun, Nov 29, 2009 at 9:35 AM, Adam Barth <abarth at webkit.org> wrote: > > > >> On Sun, Nov 29, 2009 at 9:26 AM, Chris Jerdonek > >> <chris.jerdonek at gmail.com> wrote: > >>> On Sat, Nov 28, 2009, Adam Barth wrote: > >>>> Hopefully, the script will improve over time, but it will > >>>> never be perfect. > >>> > >>> Can you elaborate on this? For example, are you saying there is a > >>> basic reason that the script will always have bugs? Without knowing > >>> too much about the script, it seems like it wouldn't be too hard to at > >>> least make the false negatives go away. Or are you simply saying that > >>> the guidelines and script will never fully capture what we mean by > >>> "correct style"? > >> > >> Does this mean you're volunteering to remove all the false positives > >> and false negatives? :) > > > > I was hoping to work on the script eventually, which is partly why I > > asked for elaboration. > > > > All that I meant above is that one could potentially disable (for the > > bot) the style tests that report false violations, or else reduce > > their confidence score. That way, if the style bot flags a patch, it > > is guaranteed to be meaningful without looking at the details of the > > report. This can only be done, though, if the problems with the > > script are not so basic that they affect most or many of the tests. > > > > (The reverse is not as straightforward, though. It does not seem as > > easy to change the script -- in a useful way -- so that if it reports > > that a patch has met the guidelines, then the patch really meets the > > guidelines.) > > > >> One basic reason the script isn't perfect is that it's doesn't have a > >> full C++ / Objective-C++ parser. > > > > If we could go this route, would we prefer it? > > > > --Chris > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091129/b69c984f/attachment.html> From avshabanov at gmail.com Mon Nov 30 03:17:26 2009 From: avshabanov at gmail.com (Alexander Shabanov) Date: Mon, 30 Nov 2009 14:17:26 +0300 Subject: [webkit-dev] appendChild does not work for elements produced by DOMParser Message-ID: <43a7c3700911300317l7774b564sa4802cd46edbd206@mail.gmail.com> Hi all, Sorry for silly question but I think that it might be a nice feature to webkit. The following code works in Mozilla Firefox 3.5, but it does not work in webkit-based browsers: var parser = new DOMParser(); var str = "<p>This is a test</p>"; var doc = parser.parseFromString(str, "text/xml"); document.body.appendChild(doc.documentElement.firstChild); I found that specification to DOMParser does not guarantee that the result of DOMParser's parseFromX methods can be directly used in the original document. Nevertheless I believe that it would be quite a useful feature, at least it won't require JS code to create DOM-compliant content from the parsed one. May be I missed something and webkit offers a way of quick adaptation of the parsed content to the original DOM tree? Thanks in advance. P.S.: even though Firefox provides such a feature, a style specification in the following code will take no effect: var parser = new DOMParser(); var str = "<p style='color: red;'>This is a test</p>"; var doc = parser.parseFromString(str, "text/xml"); document.body.appendChild(doc.documentElement.firstChild); -- Best regards, Alexander Shabanov From mjs at apple.com Mon Nov 30 04:58:50 2009 From: mjs at apple.com (Maciej Stachowiak) Date: Mon, 30 Nov 2009 04:58:50 -0800 Subject: [webkit-dev] appendChild does not work for elements produced by DOMParser In-Reply-To: <43a7c3700911300317l7774b564sa4802cd46edbd206@mail.gmail.com> References: <43a7c3700911300317l7774b564sa4802cd46edbd206@mail.gmail.com> Message-ID: <4A6879C4-6073-4C5B-9BEA-2290C1456F1A@apple.com> On Nov 30, 2009, at 3:17 AM, Alexander Shabanov wrote: > Hi all, > > Sorry for silly question but I think that it might be a nice feature > to webkit. > The following code works in Mozilla Firefox 3.5, but it does not work > in webkit-based browsers: > > var parser = new DOMParser(); > var str = "<p>This is a test</p>"; > var doc = parser.parseFromString(str, "text/xml"); > document.body.appendChild(doc.documentElement.firstChild); If you change the last step to this, it will work in WebKit-based browsers: document .body.appendChild(document.importNode(doc.documentElement.firstChild)); The Gecko engine is more generous about allowing implicit cross- document adoption. We allow it in only a few cases, and in theory it is not supposed to be allowed at all (without the importNode call) according to the DOM Core spec. That being said, if this is a compat issue on real sites we can change to be more Gecko-like. > > I found that specification to DOMParser does not guarantee that the > result of DOMParser's parseFromX methods can > be directly used in the original document. > Nevertheless I believe that it would be quite a useful feature, at > least it won't require JS code to create DOM-compliant content from > the parsed one. > May be I missed something and webkit offers a way of quick adaptation > of the parsed content to the original DOM tree? > Thanks in advance. > > P.S.: even though Firefox provides such a feature, a style > specification in the following code will take no effect: > var parser = new DOMParser(); > var str = "<p style='color: red;'>This is a test</p>"; > var doc = parser.parseFromString(str, "text/xml"); > document.body.appendChild(doc.documentElement.firstChild); Probably because parsing with DOMParser parses as XML, thus you get a <p> element that's not an HTML element (it is in the null namespace instead of the HTML namespace). To get an HTML p element you need to either do this: var str = "<p xmlns='http://www.w3.org/1999/xhtml/' style='color: red;'>This is a test</p>"; or just use innerHTML or createContextualFragment to directly insert HTML text into a document. Regards, Maciej From avshabanov at gmail.com Mon Nov 30 07:20:27 2009 From: avshabanov at gmail.com (Alexander Shabanov) Date: Mon, 30 Nov 2009 18:20:27 +0300 Subject: [webkit-dev] appendChild does not work for elements produced by DOMParser In-Reply-To: <4A6879C4-6073-4C5B-9BEA-2290C1456F1A@apple.com> References: <43a7c3700911300317l7774b564sa4802cd46edbd206@mail.gmail.com> <4A6879C4-6073-4C5B-9BEA-2290C1456F1A@apple.com> Message-ID: <43a7c3700911300720i562c9495yd9a380de675a98b1@mail.gmail.com> 2009/11/30 Maciej Stachowiak <mjs at apple.com>: >... > Probably because parsing with DOMParser parses as XML, thus you get a <p> > element that's not an HTML element (it is in the null namespace instead of > the HTML namespace). To get an HTML p element you need to either do this: > > ? ? ?var str = "<p xmlns='http://www.w3.org/1999/xhtml/' style='color: > red;'>This is a test</p>"; > > or just use innerHTML or createContextualFragment to directly insert HTML > text into a document. Thank you, importNode works fine for my snippet given above. But style information is omitted no matter whether xmlns attribute specified or not. This is because I was wrong about using doc.documentElement.firstChild, I suppose doc.documentElement shall be used instead: var str = "<p xmlns='http://www.w3.org/1999/xhtml/' style='color: red;'>This is a test</p>"; var parser = new DOMParser(); var doc = parser.parseFromString(str, "text/xml"); document.body.appendChild(doc.documentElement); And the fun thing is how different Gecko and WebKit(with the only difference in added call to document.importNode) handle the code given above. Gecko: Node inserted, text is visible but in black, e.g. style is still omitted and Firebug indicates, that inserted element has no style information, at the same time it indicates that style attribute exists in the DOM tree. WebKit: Node inserted but in the strange way. Text content is not visible on the screen. WebInspector indicates that new <p> node exists in the DOM tree but without it's content and closing tag and with xmlns and style attributes. I believe that this is because I'm playing with DOMParser in the wrong way. Could you please clarify what is the error here? > > Regards, > Maciej > > -- Best regards, Alexander Shabanov From mbensi at pleyo.com Mon Nov 30 08:58:40 2009 From: mbensi at pleyo.com (Mario Bensi) Date: Mon, 30 Nov 2009 17:58:40 +0100 Subject: [webkit-dev] display:none Message-ID: <200911301758.41083.mbensi@pleyo.com> Hello, I have a question on css propertie "display:none". If I try to load this example : <html> <body> <div style="visibility: hidden; display: none;"> <object type="test/test" id="test"></object> </div> </body> </html> On WebKit the createPlugin is never called and we can't access to script part of my plugin, the plugin are not instantiated. If I try the same page on Firefox it works, my plugin are correctly instanciated but not diplayed, like I want. After read http://www.w3.org/TR/CSS21/visuren.html#display-prop for me the plugin must be instantiated, but no space will be reserved in the layout for it, and no box will be created. is a bug in webkit ? Or I misunderstood something in specification ? Best Regards, -- Mario Bensi Join OWB team on freenode IRC, channel #owb Web-enabler for CE devices www.pleyo.com Follow us on twitter : twitter.com/pleyo tel : +339 70 447 544 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091130/de9fff0d/attachment.html> From dglazkov at chromium.org Mon Nov 30 09:55:21 2009 From: dglazkov at chromium.org (Dimitri Glazkov) Date: Mon, 30 Nov 2009 09:55:21 -0800 Subject: [webkit-dev] GlobalScript in WebKit In-Reply-To: <28040fc60911260944h63f0cab0q52256439c11fc46a@mail.gmail.com> References: <28040fc60911191935o7dc5c5edndd696ee6c31607ac@mail.gmail.com> <63a07bb10911252030g360f902fh81cc04734aa1f0b2@mail.gmail.com> <28040fc60911252141i6f1ff2c3o89dd9514699d14a7@mail.gmail.com> <d62cf1d10911252216m48d212c4i72e3d571e2a41018@mail.gmail.com> <28040fc60911260944h63f0cab0q52256439c11fc46a@mail.gmail.com> Message-ID: <fbbf8c7c0911300955k4b0463afy59ab48fbb70feb3f@mail.gmail.com> Reading this, I am reminded of a great commentary by Alex Russell, written nearly 3 years ago: http://alex.dojotoolkit.org/2007/12/the-w3c-cannot-save-us/ Despite of what I may think about SharedScript, I am certain that waiting -- whether for standards community or Web developers to embrace or reject our ideas -- is not the right answer. If we really want to move the Web platform forward, we can't afford a feedback cycle this long. Especially, when we have an opportunity for close collaboration with Web developers of some of the most JS-intensive Web properties. Experimenting is great. We should experiment. This doesn't mean we shouldn't discuss technical merits of the proposed solution, including more efficient ways of accomplishing the same thing. :DG< On Thu, Nov 26, 2009 at 9:44 AM, Dmitry Titov <dimich at chromium.org> wrote: > What I meant was it would be nice, for the sake of discussion, to share the > experience of real life applications that used SharedWorkers or inter-window > communications for sharing of significant portions of code and data. Google > apps may be a partial example but it is a real life example of concrete > issues with proposed solution that sounds pretty generic and useful for > other web apps. It is only prudent to take their feedback rather then > replace it with our own theories about future of the web. No doubt this is a > new mechanism and it's good to question it, since it has costs even as > experimental API. Gut feelings vary, some app devs say they need it to solve > real issues, we dont hear from other app devs who were facing similar issues > and solved it differently. Seems there is no strong argument to kill it nor > bless it. Why don't make it experimental and see? If it was possible to > implement it in extension or plugin, we would run it as another Gears-like > experiment, but it can not be done in a plugin... I believe there could be > good arguments that simply didn't surface yet, and hope to hear them. > Dmitry. > > On Wed, Nov 25, 2009 at 10:16 PM, Peter Kasting <pkasting at google.com> wrote: >> >> On Wed, Nov 25, 2009 at 9:41 PM, Dmitry Titov <dimich at chromium.org> wrote: >>> >>> BTW, could you tell what's the 'course' that would be reverted? >> >> Meaning, "before we decide that SharedWorkers and inter-window >> communication are insufficient, and a further proposal should be entertained >> by the standards community". >> PK > > _______________________________________________ > webkit-dev mailing list > webkit-dev at lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > From darin at apple.com Mon Nov 30 10:56:41 2009 From: darin at apple.com (Darin Adler) Date: Mon, 30 Nov 2009 10:56:41 -0800 Subject: [webkit-dev] display:none In-Reply-To: <200911301758.41083.mbensi@pleyo.com> References: <200911301758.41083.mbensi@pleyo.com> Message-ID: <48DE475C-CDFF-4CDB-BBC7-2BF2D1F935D5@apple.com> You have sent your mail to the wrong mailing list. The right one is webkit-help. See this page for details: http://webkit.org/contact.html > After read http://www.w3.org/TR/CSS21/visuren.html#display-prop for me the plugin must be instantiated What you describe seems to be a bug where HTML5 describes something different from what WebKit does and other browsers. I found a bug report <https://bugs.webkit.org/show_bug.cgi?id=27775> that seems to match what you are saying. -- Darin From mbensi at pleyo.com Mon Nov 30 11:38:07 2009 From: mbensi at pleyo.com (Mario Bensi) Date: Mon, 30 Nov 2009 20:38:07 +0100 Subject: [webkit-dev] display:none In-Reply-To: <48DE475C-CDFF-4CDB-BBC7-2BF2D1F935D5@apple.com> References: <200911301758.41083.mbensi@pleyo.com> <48DE475C-CDFF-4CDB-BBC7-2BF2D1F935D5@apple.com> Message-ID: <200911302038.08037.mbensi@pleyo.com> yes, it's the same problem. Are you an idea to fix this or a pointer to help me ? Mario Le lundi 30 novembre 2009 19:56:41, Darin Adler a ?crit : > You have sent your mail to the wrong mailing list. The right one is > webkit-help. See this page for details: > > http://webkit.org/contact.html > > > After read http://www.w3.org/TR/CSS21/visuren.html#display-prop for me > > the plugin must be instantiated > > What you describe seems to be a bug where HTML5 describes something > different from what WebKit does and other browsers. I found a bug report > <https://bugs.webkit.org/show_bug.cgi?id=27775> that seems to match what > you are saying. > > -- Darin > -- Mario Bensi Join OWB team on freenode IRC, channel #owb Web-enabler for CE devices www.pleyo.com Follow us on twitter : twitter.com/pleyo tel : +339 70 447 544 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091130/ef08b9b9/attachment.html> From darin at apple.com Mon Nov 30 11:44:40 2009 From: darin at apple.com (Darin Adler) Date: Mon, 30 Nov 2009 11:44:40 -0800 Subject: [webkit-dev] display:none In-Reply-To: <200911302038.08037.mbensi@pleyo.com> References: <200911301758.41083.mbensi@pleyo.com> <48DE475C-CDFF-4CDB-BBC7-2BF2D1F935D5@apple.com> <200911302038.08037.mbensi@pleyo.com> Message-ID: <87B29FEB-F313-405E-ACA5-09C07CBBC636@apple.com> On Nov 30, 2009, at 11:38 AM, Mario Bensi wrote: > Are you an idea to fix this or a pointer to help me ? I don?t know what you are doing, so not sure what kind of help you need. Please ask on webkit-help, though, lets end the discussion on the WebKit development mailing list. -- Darin From abarth at webkit.org Mon Nov 30 13:03:42 2009 From: abarth at webkit.org (Adam Barth) Date: Mon, 30 Nov 2009 13:03:42 -0800 Subject: [webkit-dev] style-queue entering beta In-Reply-To: <7789133a0911280221p48bd53cdk8e1d730160124936@mail.gmail.com> References: <7789133a0911280221p48bd53cdk8e1d730160124936@mail.gmail.com> Message-ID: <7789133a0911301303u67b07ec2lde953c114b252101@mail.gmail.com> The queue is now running and caught up to the top of the review queue. Please let me know if we should adjust anything. Thanks, Adam On Sat, Nov 28, 2009 at 2:21 AM, Adam Barth <abarth at webkit.org> wrote: > One of the bots that Eric and I have been working on is about to come > online. ?This bot is a "style bot" that runs check-webkit-style on > patches that have been nominated for review. ?I'd like to ask your > patience while we work out the kinks. > > You can skip the rest of this email if you're not interested in the > nitty gritty. > > == Summary == > > The primary goal of the style-queue is to reduce review latency by (1) > giving immediate feedback to contributors and (2) making human > reviewer more efficient by relieving them of mechanical tasks (like > asking for tabs to be replaced with spaces). > > The style-queue scans the set of patches that are pending-review for > new patches. ?When it finds a new patch, the bot runs > check-webkit-style on the patch. ?If check-webkit-style finds style > errors, the bot comments on the bug. > > == Social Contract == > > The style-queue is purely informative. ?You're free to ignore it's > comments. ?Ideally, the bot should be silent unless it has something > interesting to say. ?If we decide that style-queue is too chatty, we > can change check-webkit-style to report fewer errors. > > One corollary of this social contract is that the style-queue doesn't > inform you when your patch passes the style check (because most > patches should pass, right?). ?We can re-visit this design choice > later if it turns out we really want to know when the check succeeds. > > == Response to Previous Feedback == > > When I floated this idea on webkit-dev previously (in the "bot-filled > future" thread), I got a bunch of useful feedback. ?Here's how we > incorporated that feedback into the current design: > > 1) "Adding an extra flags is going to cause confusion." ?The > style-queue does not add any flags to Bugzilla. ?Instead of storing > it's state in Bugzilla flags (like commit-queue does), we built an > AppEngine web service to hold the queue's persistent state. ?Instead > of indicating style errors with a negative flag, the bot adds a > comment to the bug. > > 2) "What machines are going to be doing these tests, and on which > platforms?" ?The style-queue runs on a machine in my apartment that > runs Mac OS X. ?The style-queue is platform independent, so this is > less of an issue for style-queue than it is for a build-queue. > > 3) "Which patches would this test?" ?The style-queue tests any patch > marked "review?". ?This design avoids the need for additional flags or > indications that a patch should be run through the queue. > > 4) "Running tests on an arbitrary patches [opens a security hole]." > Instead of running check-webkit-style from it's own working copy, the > style-queue runs check-webkit-style from a separate working copy. > While it's true you could haxor my machine by committing an evil copy > of check-webkit-style, I'm already running that risk whenever I type > "svn up". > > == Frequently Asked Questions == > > Q1: If the style-queue doesn't complain, does that mean my patch has > correct style? > > A1: Unfortunately, no. ?First of all, check-webkit-style has false > negatives. ?Hopefully, the script will improve over time, but it will > never be perfect. ?Second, the style-queue is only able to check > patches that successfully download and apply to top-of-tree. ?If your > patch does not apply to top-of-tree (e.g., because it depends on > another patch), then style-queue won't say anything. > > Q2: How can I see whether style-queue processed my patch? > > A2: There isn't a great way to do this yet. ?The data is stored in the > webkit-commit-queue.appspot.com web service, but we haven't built a > front-end for it yet. ?If you have a strong stomach, you can look at > the endpoint the bot itself uses > > http://webkit-commit-queue.appspot.com/patch-status/style-queue/12345 > > where 12345 is the ID of your attachment. ?If you'd like to have a > better status display, feel free to hack on > WebKitTools/QueueStatusServer and send me or Eric patches to review. > In the long term, there's no reason we can't have an awesome UI. > > Q3: This bot is going to run amock! ?How can I keep track of all it's > evil deeds? > > A3: If you want to see what the bots are doing, you can subscribe to > the following email list: > > http://groups.google.com/group/webkit-bot-watchers > > Whenever the bots touch a bug, they're supposed to add this address to > the CC list. ?This functionality is very new, so we might not have > every case covered yet. ?If you see the bot misbehaving, let me or > Eric know. ?We'll correct the issue ASAP. > > Q4: Checking style is fine and dandy, but I was hoping for a build-queue! > > A4: My next project is to get a build-queue working for Qt. ?The > build-queue will share a lot of infrastructure with the style-queue, > but making the style-queue was easier because check-webkit-style is a > lot faster than build-webkit. ?:) > > Q5: When are you flipping the switch? > > A5: Either today or tomorrow, depending on when I find a stretch of > time to babysit the queue through whatever initial troubles it has. > My working copy of the style-queue is about five patches ahead of > trunk. ?It would be nice to have those patches committed before > flipping the switch, but it's not necessary. > > Thanks for reading to the end, and I hope you find the style-queue useful. > > Adam > From ap at webkit.org Mon Nov 30 13:12:28 2009 From: ap at webkit.org (Alexey Proskuryakov) Date: Mon, 30 Nov 2009 13:12:28 -0800 Subject: [webkit-dev] appendChild does not work for elements produced by DOMParser In-Reply-To: <43a7c3700911300720i562c9495yd9a380de675a98b1@mail.gmail.com> References: <43a7c3700911300317l7774b564sa4802cd46edbd206@mail.gmail.com> <4A6879C4-6073-4C5B-9BEA-2290C1456F1A@apple.com> <43a7c3700911300720i562c9495yd9a380de675a98b1@mail.gmail.com> Message-ID: <209007D3-8AF0-46F7-B6CE-976A4DD43EAB@webkit.org> On 30.11.2009, at 7:20, Alexander Shabanov wrote: > I believe that this is because I'm playing with DOMParser in the > wrong way. > Could you please clarify what is the error here? This is offtopic in webkit-dev mailing list. Please use webkit-help instead. I think that you may get better results if you parse full documents (with <html xmlns=...>, <body> and all) with DOMParser. Or just use parseContextualFragment, as Maciej suggested. - WBR, Alexey Proskuryakov From michaeln at google.com Mon Nov 30 13:15:57 2009 From: michaeln at google.com (Michael Nordman) Date: Mon, 30 Nov 2009 13:15:57 -0800 Subject: [webkit-dev] GlobalScript in WebKit In-Reply-To: <fbbf8c7c0911300955k4b0463afy59ab48fbb70feb3f@mail.gmail.com> References: <28040fc60911191935o7dc5c5edndd696ee6c31607ac@mail.gmail.com> <63a07bb10911252030g360f902fh81cc04734aa1f0b2@mail.gmail.com> <28040fc60911252141i6f1ff2c3o89dd9514699d14a7@mail.gmail.com> <d62cf1d10911252216m48d212c4i72e3d571e2a41018@mail.gmail.com> <28040fc60911260944h63f0cab0q52256439c11fc46a@mail.gmail.com> <fbbf8c7c0911300955k4b0463afy59ab48fbb70feb3f@mail.gmail.com> Message-ID: <fa2eab050911301315h20881073r8c00401e1b2cc3aa@mail.gmail.com> http://alex.dojotoolkit.org/2007/12/the-w3c-cannot-save-us/ What a great rant :) I'm also reminded of this quote... "The reasonable man adapts himself to the world. The unreasonable man persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -George Bernard Shaw<http://en.wikipedia.org/wiki/George_Bernard_Shaw> The Chrome team has come around to putting this particular feature into Chrome as an experiment. It's not clear that can be pulled off without actually putting some bits into WebKit, and I think we're of the opinion that the cleanest implementation is to have the code reside entirely in WebKit. (Personally, I think to do otherwise puts us into the realm of hackery to pull off the experiment.) Sam said "It adds extra complexity to WebKit". We can and should keep a careful eye to minimize that. On Mon, Nov 30, 2009 at 9:55 AM, Dimitri Glazkov <dglazkov at chromium.org>wrote: > Reading this, I am reminded of a great commentary by Alex Russell, > written nearly 3 years ago: > > http://alex.dojotoolkit.org/2007/12/the-w3c-cannot-save-us/ > > Despite of what I may think about SharedScript, I am certain that > waiting -- whether for standards community or Web developers to > embrace or reject our ideas -- is not the right answer. If we really > want to move the Web platform forward, we can't afford a feedback > cycle this long. Especially, when we have an opportunity for close > collaboration with Web developers of some of the most JS-intensive Web > properties. > > Experimenting is great. We should experiment. > > This doesn't mean we shouldn't discuss technical merits of the > proposed solution, including more efficient ways of accomplishing the > same thing. > > :DG< > > On Thu, Nov 26, 2009 at 9:44 AM, Dmitry Titov <dimich at chromium.org> wrote: > > What I meant was it would be nice, for the sake of discussion, to share > the > > experience of real life applications that used SharedWorkers or > inter-window > > communications for sharing of significant portions of code and data. > Google > > apps may be a partial example but it is a real life example of concrete > > issues with proposed solution that sounds pretty generic and useful for > > other web apps. It is only prudent to take their feedback rather then > > replace it with our own theories about future of the web. No doubt this > is a > > new mechanism and it's good to question it, since it has costs even as > > experimental API. Gut feelings vary, some app devs say they need it to > solve > > real issues, we dont hear from other app devs who were facing similar > issues > > and solved it differently. Seems there is no strong argument to kill it > nor > > bless it. Why don't make it experimental and see? If it was possible to > > implement it in extension or plugin, we would run it as another > Gears-like > > experiment, but it can not be done in a plugin... I believe there could > be > > good arguments that simply didn't surface yet, and hope to hear them. > > Dmitry. > > > > On Wed, Nov 25, 2009 at 10:16 PM, Peter Kasting <pkasting at google.com> > wrote: > >> > >> On Wed, Nov 25, 2009 at 9:41 PM, Dmitry Titov <dimich at chromium.org> > wrote: > >>> > >>> BTW, could you tell what's the 'course' that would be reverted? > >> > >> Meaning, "before we decide that SharedWorkers and inter-window > >> communication are insufficient, and a further proposal should be > entertained > >> by the standards community". > >> PK > > > > _______________________________________________ > > webkit-dev mailing list > > webkit-dev at lists.webkit.org > > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > > > > _______________________________________________ > webkit-dev mailing list > webkit-dev at lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091130/71673801/attachment.html> From ap at webkit.org Mon Nov 30 13:17:17 2009 From: ap at webkit.org (Alexey Proskuryakov) Date: Mon, 30 Nov 2009 13:17:17 -0800 Subject: [webkit-dev] GlobalScript in WebKit In-Reply-To: <fbbf8c7c0911300955k4b0463afy59ab48fbb70feb3f@mail.gmail.com> References: <28040fc60911191935o7dc5c5edndd696ee6c31607ac@mail.gmail.com> <63a07bb10911252030g360f902fh81cc04734aa1f0b2@mail.gmail.com> <28040fc60911252141i6f1ff2c3o89dd9514699d14a7@mail.gmail.com> <d62cf1d10911252216m48d212c4i72e3d571e2a41018@mail.gmail.com> <28040fc60911260944h63f0cab0q52256439c11fc46a@mail.gmail.com> <fbbf8c7c0911300955k4b0463afy59ab48fbb70feb3f@mail.gmail.com> Message-ID: <8421EA96-F80B-4CF2-8A68-A6823D510BEA@webkit.org> On 30.11.2009, at 9:55, Dimitri Glazkov wrote: > If we really want to move the Web platform forward, we can't afford > a feedback > cycle this long. Per <http://webkit.org/projects/goals.html>, it doesn't seem that we want this at all, much less "really want". - WBR, Alexey Proskuryakov From jorlow at chromium.org Mon Nov 30 13:31:52 2009 From: jorlow at chromium.org (Jeremy Orlow) Date: Mon, 30 Nov 2009 13:31:52 -0800 Subject: [webkit-dev] GlobalScript in WebKit In-Reply-To: <8421EA96-F80B-4CF2-8A68-A6823D510BEA@webkit.org> References: <28040fc60911191935o7dc5c5edndd696ee6c31607ac@mail.gmail.com> <63a07bb10911252030g360f902fh81cc04734aa1f0b2@mail.gmail.com> <28040fc60911252141i6f1ff2c3o89dd9514699d14a7@mail.gmail.com> <d62cf1d10911252216m48d212c4i72e3d571e2a41018@mail.gmail.com> <28040fc60911260944h63f0cab0q52256439c11fc46a@mail.gmail.com> <fbbf8c7c0911300955k4b0463afy59ab48fbb70feb3f@mail.gmail.com> <8421EA96-F80B-4CF2-8A68-A6823D510BEA@webkit.org> Message-ID: <5dd9e5c50911301331y5312f646q711e6314cf224a1@mail.gmail.com> On Mon, Nov 30, 2009 at 1:17 PM, Alexey Proskuryakov <ap at webkit.org> wrote: > > On 30.11.2009, at 9:55, Dimitri Glazkov wrote: > > If we really want to move the Web platform forward, we can't afford a >> feedback >> cycle this long. >> > > > Per <http://webkit.org/projects/goals.html>, it doesn't seem that we want > this at all, much less "really want". > You're twisting words. We (everyone working on WebKit) do "really want" to move the web platform forward, it's just that we don't always agree how best to do that. First of all, 2 major points: There are plenty of experiments that have been done in the WebKit code base that haven't been agreed upon in standards bodies or on webkit-dev before hand, and we should have a high standard for the experiments done and should only do them when we do think there's a strong possibility of a standardized future. In this case, the idea was floated around both standards bodies and webkit-dev. The response we got from the standards mailing list was some skepticism but a "someone should experiment with this and see how useful it is" type response. There are a lot of people inside Google that have a lot of experience with web standards, browsers, and web apps that seem to think this is useful and worth the effort to experiment with it. Some of these people are even WebKit reviewers and are volunteering to take on the burden of implementing the experiment. If that's not enough, then I'd say we need to come up with some formal criteria on what types of non-standard experiments are OK and what aren't. J -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091130/60cb12bf/attachment.html> From mjs at apple.com Mon Nov 30 13:33:11 2009 From: mjs at apple.com (Maciej Stachowiak) Date: Mon, 30 Nov 2009 13:33:11 -0800 Subject: [webkit-dev] GlobalScript in WebKit In-Reply-To: <63a07bb10911252030g360f902fh81cc04734aa1f0b2@mail.gmail.com> References: <28040fc60911191935o7dc5c5edndd696ee6c31607ac@mail.gmail.com> <63a07bb10911252030g360f902fh81cc04734aa1f0b2@mail.gmail.com> Message-ID: <ABC72D2B-04D2-43BC-8407-E5062BA1B0F3@apple.com> I'm somewhat concerned about GlobalScript too. I am pretty wary of putting complex features in WebKit if it seems like they will be rejected by the standards process and become orphan WebKit-only technologies. Perhaps I am somewhat sensitive about this because it looks like the SQL Database is heading down that road, but it's too late now for us to drop it. My impression from WHATWG and from TPAC is that the web standards community and other browser implementors don't really buy into the value of this feature, so I think there's good odds we would end up in the orphan situation. That's not to say GlobalScript is a bad feature on its own merits. In fact, a while back, in a meeting with some of the Gears folks before Chrome was publicly announced, I argued that we should have something like this (a shared object that all pages from a particular domain could access, where global state and code could live) *instead* of SharedWorker, because having a separate thread did not seem essential to the stated use cases. So I can see some plusses to the GlobalScript design. But now that SharedWorker is out there and has multiple implementations, it's much harder to make the case for GlobalScript. And it seems like people in the Web standards community, and in particular other browser vendors, are not sold. I'm worried in particular that we'll end up in a situation with WebKit of sort of throwing darts at the wall and seeing what sticks, feature- wise. A scatter-shot approach is not so great, because it can become very hard to phase out the features that don't get wide traction, if even only a few sites end up depending on them, and even if their use is conditional. Now, sometimes a new idea seems either so hugely valuable or so trivial and low-cost that we don't care if it ends up a WebKit-only feature. I'm not sure this is one of those cases. Based on this, I agree with Sam's opinion that we should wait and see how workers (and in particular SharedWorker) play out before we take up this feature. Regards, Maciej On Nov 25, 2009, at 8:30 PM, Sam Weinig wrote: > Hi Dmitry, > > As I have noted to others on the Chrome team, I do not think this is > good idea and I don't think we should have it in WebKit. It adds > extra complexity to WebKit and gives little beyond what is possible > using inter-window communication and SharedWorkers. I think we need > to give more time for large applications to adopt designs around > workers before we reverse course, at which point, we should again > discuss this in the standards community. > > -Sam > > On Thu, Nov 19, 2009 at 10:35 PM, Dmitry Titov <dimich at chromium.org> > wrote: > Hi webkit! > > I'm starting to work on actual implementation of GlobalScript > experimental API and started to post patches (hopefully in > reviewable portions). There is an uber-bug which has plan of > implementation. > > The current plan is to get it in under ENABLE_GLOBAL_SCRIPT, with > both JSC and v8 bindings (first with JSC because at the moment JSC > bindings are easier to work with and I'd wish WebKit not to have 1- > engine-only features ever). > > I'd be glad to know if there are suggestions, ideas or concerns of > any kind... For example, if there is no interest in JSC bindings, it > can be hard to get them reviewed by someone who knows them well. > It'd be better to know that earlier. > > Thanks! > Dmitry > > _______________________________________________ > webkit-dev mailing list > webkit-dev at lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > > _______________________________________________ > webkit-dev mailing list > webkit-dev at lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091130/93c91a21/attachment.html> From mjs at apple.com Mon Nov 30 13:45:10 2009 From: mjs at apple.com (Maciej Stachowiak) Date: Mon, 30 Nov 2009 13:45:10 -0800 Subject: [webkit-dev] GlobalScript in WebKit In-Reply-To: <fbbf8c7c0911300955k4b0463afy59ab48fbb70feb3f@mail.gmail.com> References: <28040fc60911191935o7dc5c5edndd696ee6c31607ac@mail.gmail.com> <63a07bb10911252030g360f902fh81cc04734aa1f0b2@mail.gmail.com> <28040fc60911252141i6f1ff2c3o89dd9514699d14a7@mail.gmail.com> <d62cf1d10911252216m48d212c4i72e3d571e2a41018@mail.gmail.com> <28040fc60911260944h63f0cab0q52256439c11fc46a@mail.gmail.com> <fbbf8c7c0911300955k4b0463afy59ab48fbb70feb3f@mail.gmail.com> Message-ID: <552A9728-511D-4260-8725-7D2ACE8724AC@apple.com> On Nov 30, 2009, at 9:55 AM, Dimitri Glazkov wrote: > Reading this, I am reminded of a great commentary by Alex Russell, > written nearly 3 years ago: > > http://alex.dojotoolkit.org/2007/12/the-w3c-cannot-save-us/ > > Despite of what I may think about SharedScript, I am certain that > waiting -- whether for standards community or Web developers to > embrace or reject our ideas -- is not the right answer. If we really > want to move the Web platform forward, we can't afford a feedback > cycle this long. Especially, when we have an opportunity for close > collaboration with Web developers of some of the most JS-intensive Web > properties. > > Experimenting is great. We should experiment. WebKit (or at least the mainline) is not necessarily a great place for experiments. As our Project Goals say: "WebKit is an engineering project, not a science project." <http://webkit.org/projects/ goals.html>. Of course, that's a pretty fuzzy line, because sometimes a use case is really well proven and we're not willing to wait for standards groups to get their butt in gear. But there are some potential bad scenarios with building features that don't have a clear path to standardization: 1) It will be rejected by other browser vendors and end up a WebKit- only (or nearly WebKit-only) feature, but enough WebKit-specific content depends on it that we can't drop it, even if we would like to. Then we are stuck maintaining a dead-end technology indefinitely. It seems like the SQL database may be on this path. 2) It will get adopted into standards, but with significant changes when other implementors and standards experts jump on the bandwagon. These changes can cause a very painful transition, since we need to remain compatible with legacy WebKit-specific content, yet at the same time we don't want to be in violation of the consensus spec. This actually happened with <canvas> - it changed incompatibly in ways that broke a bunch of WebKit-specific content (in particular Dashboard widgets), but we had to implement the standard to support content coded to Firefox. This really sucked and we have Dashboard-specific hacks still lying around in our code base as a result. So please realize, experimenting is not free. The cost can be much greater than the implementation cost, and may indeed last far beyond the experimental era. These kinds of bad scenarios are the reason that nowadays we try to get standards buy-in on new Web platform features *before* they get shipped in a mass-market product. And experience with these kinds of scenarios is what makes some of us very wary of going hog-wild with experiments in the WebKit code base. We take backwards compatibility for Web content very seriously, and so we hesitate to put anything in that we don't feel we can commit to. As I said in my other message, I actually think a global script with proper DOM access is a good idea in principle, and in my opinion would have been a better design than SharedWorkers (and indeed, given global script, you can implement shared workers yourself). But we have not done a great job of selling it. Can we make a good case for this feature that will get some buy-in from the broader Web standards community? Regards, Maciej From hyatt at apple.com Mon Nov 30 13:51:22 2009 From: hyatt at apple.com (David Hyatt) Date: Mon, 30 Nov 2009 15:51:22 -0600 Subject: [webkit-dev] GlobalScript in WebKit In-Reply-To: <ABC72D2B-04D2-43BC-8407-E5062BA1B0F3@apple.com> References: <28040fc60911191935o7dc5c5edndd696ee6c31607ac@mail.gmail.com> <63a07bb10911252030g360f902fh81cc04734aa1f0b2@mail.gmail.com> <ABC72D2B-04D2-43BC-8407-E5062BA1B0F3@apple.com> Message-ID: <D4D22106-D757-4FFD-A3D4-BAC3D19F0A1C@apple.com> On Nov 30, 2009, at 3:33 PM, Maciej Stachowiak wrote: > Based on this, I agree with Sam's opinion that we should wait and > see how workers (and in particular SharedWorker) play out before we > take up this feature. > > Regards, > Maciej While I share many of your concerns, I think it's worth doing GlobalScript as an experiment in WebKit if we think there are lessons that will be learned from the implementation. In general I think innovation in the engine should be encouraged. The bar for such experimentation should be low. The bar for enabling those experiments in shipping products, however, should be high. If the goal of the Chrome team is to provide an experimental implementation that will be used only in development builds to collect feedback on the feature, then it seems like a worthwhile goal to experiment. If the goal of the Chrome team is to actually just ship the feature, then it isn't really an experiment at all, and it's right for people to be concerned. dave (hyatt at apple.com) From jorlow at chromium.org Mon Nov 30 13:53:05 2009 From: jorlow at chromium.org (Jeremy Orlow) Date: Mon, 30 Nov 2009 13:53:05 -0800 Subject: [webkit-dev] GlobalScript in WebKit In-Reply-To: <552A9728-511D-4260-8725-7D2ACE8724AC@apple.com> References: <28040fc60911191935o7dc5c5edndd696ee6c31607ac@mail.gmail.com> <63a07bb10911252030g360f902fh81cc04734aa1f0b2@mail.gmail.com> <28040fc60911252141i6f1ff2c3o89dd9514699d14a7@mail.gmail.com> <d62cf1d10911252216m48d212c4i72e3d571e2a41018@mail.gmail.com> <28040fc60911260944h63f0cab0q52256439c11fc46a@mail.gmail.com> <fbbf8c7c0911300955k4b0463afy59ab48fbb70feb3f@mail.gmail.com> <552A9728-511D-4260-8725-7D2ACE8724AC@apple.com> Message-ID: <5dd9e5c50911301353x2283a61es77fb75cb74badda7@mail.gmail.com> On Mon, Nov 30, 2009 at 1:45 PM, Maciej Stachowiak <mjs at apple.com> wrote: > > On Nov 30, 2009, at 9:55 AM, Dimitri Glazkov wrote: > > Reading this, I am reminded of a great commentary by Alex Russell, >> written nearly 3 years ago: >> >> http://alex.dojotoolkit.org/2007/12/the-w3c-cannot-save-us/ >> >> Despite of what I may think about SharedScript, I am certain that >> waiting -- whether for standards community or Web developers to >> embrace or reject our ideas -- is not the right answer. If we really >> want to move the Web platform forward, we can't afford a feedback >> cycle this long. Especially, when we have an opportunity for close >> collaboration with Web developers of some of the most JS-intensive Web >> properties. >> >> Experimenting is great. We should experiment. >> > > WebKit (or at least the mainline) is not necessarily a great place for > experiments. As our Project Goals say: "WebKit is an engineering project, > not a science project." <http://webkit.org/projects/goals.html>. Of > course, that's a pretty fuzzy line, because sometimes a use case is really > well proven and we're not willing to wait for standards groups to get their > butt in gear. But there are some potential bad scenarios with building > features that don't have a clear path to standardization: > > 1) It will be rejected by other browser vendors and end up a WebKit-only > (or nearly WebKit-only) feature, but enough WebKit-specific content depends > on it that we can't drop it, even if we would like to. Then we are stuck > maintaining a dead-end technology indefinitely. It seems like the SQL > database may be on this path. > > 2) It will get adopted into standards, but with significant changes when > other implementors and standards experts jump on the bandwagon. These > changes can cause a very painful transition, since we need to remain > compatible with legacy WebKit-specific content, yet at the same time we > don't want to be in violation of the consensus spec. This actually happened > with <canvas> - it changed incompatibly in ways that broke a bunch of > WebKit-specific content (in particular Dashboard widgets), but we had to > implement the standard to support content coded to Firefox. This really > sucked and we have Dashboard-specific hacks still lying around in our code > base as a result. > > So please realize, experimenting is not free. The cost can be much greater > than the implementation cost, and may indeed last far beyond the > experimental era. These kinds of bad scenarios are the reason that nowadays > we try to get standards buy-in on new Web platform features *before* they > get shipped in a mass-market product. And experience with these kinds of > scenarios is what makes some of us very wary of going hog-wild with > experiments in the WebKit code base. We take backwards compatibility for Web > content very seriously, and so we hesitate to put anything in that we don't > feel we can commit to. > Isn't it being developed behind a flag? If not, couldn't it be? That would keep it from being inadvertently shipped with any platforms. If there is a compatibility breaking burden, it would be those who explicitly choose to ship it, and those alone. As far as I can tell, the only thing at issue here is the code maintenance burden. Other embedders of WebKit should be shielded from the other issues you cite. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091130/624674b1/attachment.html> From mjs at apple.com Mon Nov 30 13:54:03 2009 From: mjs at apple.com (Maciej Stachowiak) Date: Mon, 30 Nov 2009 13:54:03 -0800 Subject: [webkit-dev] GlobalScript in WebKit In-Reply-To: <D4D22106-D757-4FFD-A3D4-BAC3D19F0A1C@apple.com> References: <28040fc60911191935o7dc5c5edndd696ee6c31607ac@mail.gmail.com> <63a07bb10911252030g360f902fh81cc04734aa1f0b2@mail.gmail.com> <ABC72D2B-04D2-43BC-8407-E5062BA1B0F3@apple.com> <D4D22106-D757-4FFD-A3D4-BAC3D19F0A1C@apple.com> Message-ID: <6C21C44C-168D-4D87-977A-E36A21236A91@apple.com> On Nov 30, 2009, at 1:51 PM, David Hyatt wrote: > On Nov 30, 2009, at 3:33 PM, Maciej Stachowiak wrote: > >> Based on this, I agree with Sam's opinion that we should wait and >> see how workers (and in particular SharedWorker) play out before we >> take up this feature. >> >> Regards, >> Maciej > > While I share many of your concerns, I think it's worth doing > GlobalScript as an experiment in WebKit if we think there are > lessons that will be learned from the implementation. In general I > think innovation in the engine should be encouraged. The bar for > such experimentation should be low. The bar for enabling those > experiments in shipping products, however, should be high. > > If the goal of the Chrome team is to provide an experimental > implementation that will be used only in development builds to > collect feedback on the feature, then it seems like a worthwhile > goal to experiment. If the goal of the Chrome team is to actually > just ship the feature, then it isn't really an experiment at all, > and it's right for people to be concerned. I agree with the above distinction. Regards, Maciej From ggaren at apple.com Mon Nov 30 13:54:25 2009 From: ggaren at apple.com (Geoffrey Garen) Date: Mon, 30 Nov 2009 13:54:25 -0800 Subject: [webkit-dev] GlobalScript in WebKit In-Reply-To: <5dd9e5c50911301331y5312f646q711e6314cf224a1@mail.gmail.com> References: <28040fc60911191935o7dc5c5edndd696ee6c31607ac@mail.gmail.com> <63a07bb10911252030g360f902fh81cc04734aa1f0b2@mail.gmail.com> <28040fc60911252141i6f1ff2c3o89dd9514699d14a7@mail.gmail.com> <d62cf1d10911252216m48d212c4i72e3d571e2a41018@mail.gmail.com> <28040fc60911260944h63f0cab0q52256439c11fc46a@mail.gmail.com> <fbbf8c7c0911300955k4b0463afy59ab48fbb70feb3f@mail.gmail.com> <8421EA96-F80B-4CF2-8A68-A6823D510BEA@webkit.org> <5dd9e5c50911301331y5312f646q711e6314cf224a1@mail.gmail.com> Message-ID: <02AA91E5-5FFF-44F3-8E05-1DCC311E9D1A@apple.com> > There are a lot of people inside Google that have a lot of experience with web standards, browsers, and web apps that seem to think this is useful and worth the effort to experiment with it. Who exactly inside Google is waiting to build a new service, feature, or experiment using SharedScript? Geoff From pkasting at google.com Mon Nov 30 13:55:08 2009 From: pkasting at google.com (Peter Kasting) Date: Mon, 30 Nov 2009 13:55:08 -0800 Subject: [webkit-dev] GlobalScript in WebKit In-Reply-To: <ABC72D2B-04D2-43BC-8407-E5062BA1B0F3@apple.com> References: <28040fc60911191935o7dc5c5edndd696ee6c31607ac@mail.gmail.com> <63a07bb10911252030g360f902fh81cc04734aa1f0b2@mail.gmail.com> <ABC72D2B-04D2-43BC-8407-E5062BA1B0F3@apple.com> Message-ID: <d62cf1d10911301355v76b5c877k4c1bc2b0ea8809b5@mail.gmail.com> On Mon, Nov 30, 2009 at 1:33 PM, Maciej Stachowiak <mjs at apple.com> wrote: > My impression from WHATWG and from TPAC is that the web standards community > and other browser implementors don't really buy into the value of this > feature, so I think there's good odds we would end up in the orphan > situation. > It seems like the concern is not in trying the feature, but in being unable to remove it if it doesn't pan out. I too am concerned about this case. To me, the right response to this concern is not to ban implementation but to try and determine how we can guarantee removal/modification if this doesn't prove to be effective. And to do that it seems like we have to guarantee that we won't have consumers who depend on this feature that we're forced to support. I agree with Dave Hyatt that perhaps the best way of minimizing risk in these cases is to agree that this will not be enabled in stable releases of browsers until we have enough feedback for the broader community to make more final decisions. Hopefully this will prevent web authors from relying on the feature's availability and yet still allow interested parties to run what tests they need. PK -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091130/d941bf03/attachment.html> From hyatt at apple.com Mon Nov 30 13:58:45 2009 From: hyatt at apple.com (David Hyatt) Date: Mon, 30 Nov 2009 15:58:45 -0600 Subject: [webkit-dev] GlobalScript in WebKit In-Reply-To: <552A9728-511D-4260-8725-7D2ACE8724AC@apple.com> References: <28040fc60911191935o7dc5c5edndd696ee6c31607ac@mail.gmail.com> <63a07bb10911252030g360f902fh81cc04734aa1f0b2@mail.gmail.com> <28040fc60911252141i6f1ff2c3o89dd9514699d14a7@mail.gmail.com> <d62cf1d10911252216m48d212c4i72e3d571e2a41018@mail.gmail.com> <28040fc60911260944h63f0cab0q52256439c11fc46a@mail.gmail.com> <fbbf8c7c0911300955k4b0463afy59ab48fbb70feb3f@mail.gmail.com> <552A9728-511D-4260-8725-7D2ACE8724AC@apple.com> Message-ID: <87DB0D9D-E4E0-414D-9C10-ABCD5FBFE855@apple.com> On Nov 30, 2009, at 3:45 PM, Maciej Stachowiak wrote: > WebKit (or at least the mainline) is not necessarily a great place > for experiments. As our Project Goals say: "WebKit is an engineering > project, not a science project." <http://webkit.org/projects/goals.html > >. Of course, that's a pretty fuzzy line, because sometimes a use > case is really well proven and we're not willing to wait for > standards groups to get their butt in gear. But there are some > potential bad scenarios with building features that don't have a > clear path to standardization: > > 1) It will be rejected by other browser vendors and end up a WebKit- > only (or nearly WebKit-only) feature, but enough WebKit-specific > content depends on it that we can't drop it, even if we would like > to. Then we are stuck maintaining a dead-end technology > indefinitely. It seems like the SQL database may be on this path. > This is really the scenario to worry about the most. Having to support "failed" technologies is painful. > 2) It will get adopted into standards, but with significant changes > when other implementors and standards experts jump on the bandwagon. > These changes can cause a very painful transition, since we need to > remain compatible with legacy WebKit-specific content, yet at the > same time we don't want to be in violation of the consensus spec. > This actually happened with <canvas> - it changed incompatibly in > ways that broke a bunch of WebKit-specific content (in particular > Dashboard widgets), but we had to implement the standard to support > content coded to Firefox. This really sucked and we have Dashboard- > specific hacks still lying around in our code base as a result. > I don't really think it's fair to bring this up as a negative. Having the experiment adopted as a standard is a complete win. That the transition from experiment to reality can be painful is just an inevitable consequence of a maturing standard. CSS gradients are a good example. The new syntax coming out of the CSS WG is way better, but none of it would have happened without the initial WebKit experiment. Because of that experiment we're eventually going to have gradients in all browsers. Will the transition be a bit painful? Sure, but the end result is that we pushed the Web forward. Now I don't know if GlobalScript falls into this category or not. If no other browser vendors are interested in it, we should be pretty wary. If we think the implementation of the feature can change their minds, though, then I'd say it's worth at least experimenting with. What do other browser vendors think of this feature right now? dave From jorlow at chromium.org Mon Nov 30 13:58:42 2009 From: jorlow at chromium.org (Jeremy Orlow) Date: Mon, 30 Nov 2009 13:58:42 -0800 Subject: [webkit-dev] GlobalScript in WebKit In-Reply-To: <02AA91E5-5FFF-44F3-8E05-1DCC311E9D1A@apple.com> References: <28040fc60911191935o7dc5c5edndd696ee6c31607ac@mail.gmail.com> <63a07bb10911252030g360f902fh81cc04734aa1f0b2@mail.gmail.com> <28040fc60911252141i6f1ff2c3o89dd9514699d14a7@mail.gmail.com> <d62cf1d10911252216m48d212c4i72e3d571e2a41018@mail.gmail.com> <28040fc60911260944h63f0cab0q52256439c11fc46a@mail.gmail.com> <fbbf8c7c0911300955k4b0463afy59ab48fbb70feb3f@mail.gmail.com> <8421EA96-F80B-4CF2-8A68-A6823D510BEA@webkit.org> <5dd9e5c50911301331y5312f646q711e6314cf224a1@mail.gmail.com> <02AA91E5-5FFF-44F3-8E05-1DCC311E9D1A@apple.com> Message-ID: <5dd9e5c50911301358t5b35c30bh9bdc84c3ee095771@mail.gmail.com> On Mon, Nov 30, 2009 at 1:54 PM, Geoffrey Garen <ggaren at apple.com> wrote: > > There are a lot of people inside Google that have a lot of experience > with web standards, browsers, and web apps that seem to think this is useful > and worth the effort to experiment with it. > > Who exactly inside Google is waiting to build a new service, feature, or > experiment using SharedScript? > I don't think we can or should have to say specifically, but several major apps with millions of users. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091130/f801066d/attachment.html> From eric at webkit.org Mon Nov 30 14:00:00 2009 From: eric at webkit.org (Eric Seidel) Date: Mon, 30 Nov 2009 17:00:00 -0500 Subject: [webkit-dev] style-queue entering beta In-Reply-To: <7789133a0911301303u67b07ec2lde953c114b252101@mail.gmail.com> References: <7789133a0911280221p48bd53cdk8e1d730160124936@mail.gmail.com> <7789133a0911301303u67b07ec2lde953c114b252101@mail.gmail.com> Message-ID: <1448d9f30911301400g21b833ddo7b9fe674d255be96@mail.gmail.com> Wow. I have to admit I was skeptical. It's way too early to tell, but I *really* like the pass messages which make my job as a reviewer much easer: https://bugs.webkit.org/show_bug.cgi?id=31985#c3 Thank you very much for putting this together Adam! -eric On Mon, Nov 30, 2009 at 4:03 PM, Adam Barth <abarth at webkit.org> wrote: > The queue is now running and caught up to the top of the review queue. > Please let me know if we should adjust anything. > > Thanks, > Adam > > > On Sat, Nov 28, 2009 at 2:21 AM, Adam Barth <abarth at webkit.org> wrote: > > One of the bots that Eric and I have been working on is about to come > > online. This bot is a "style bot" that runs check-webkit-style on > > patches that have been nominated for review. I'd like to ask your > > patience while we work out the kinks. > > > > You can skip the rest of this email if you're not interested in the > > nitty gritty. > > > > == Summary == > > > > The primary goal of the style-queue is to reduce review latency by (1) > > giving immediate feedback to contributors and (2) making human > > reviewer more efficient by relieving them of mechanical tasks (like > > asking for tabs to be replaced with spaces). > > > > The style-queue scans the set of patches that are pending-review for > > new patches. When it finds a new patch, the bot runs > > check-webkit-style on the patch. If check-webkit-style finds style > > errors, the bot comments on the bug. > > > > == Social Contract == > > > > The style-queue is purely informative. You're free to ignore it's > > comments. Ideally, the bot should be silent unless it has something > > interesting to say. If we decide that style-queue is too chatty, we > > can change check-webkit-style to report fewer errors. > > > > One corollary of this social contract is that the style-queue doesn't > > inform you when your patch passes the style check (because most > > patches should pass, right?). We can re-visit this design choice > > later if it turns out we really want to know when the check succeeds. > > > > == Response to Previous Feedback == > > > > When I floated this idea on webkit-dev previously (in the "bot-filled > > future" thread), I got a bunch of useful feedback. Here's how we > > incorporated that feedback into the current design: > > > > 1) "Adding an extra flags is going to cause confusion." The > > style-queue does not add any flags to Bugzilla. Instead of storing > > it's state in Bugzilla flags (like commit-queue does), we built an > > AppEngine web service to hold the queue's persistent state. Instead > > of indicating style errors with a negative flag, the bot adds a > > comment to the bug. > > > > 2) "What machines are going to be doing these tests, and on which > > platforms?" The style-queue runs on a machine in my apartment that > > runs Mac OS X. The style-queue is platform independent, so this is > > less of an issue for style-queue than it is for a build-queue. > > > > 3) "Which patches would this test?" The style-queue tests any patch > > marked "review?". This design avoids the need for additional flags or > > indications that a patch should be run through the queue. > > > > 4) "Running tests on an arbitrary patches [opens a security hole]." > > Instead of running check-webkit-style from it's own working copy, the > > style-queue runs check-webkit-style from a separate working copy. > > While it's true you could haxor my machine by committing an evil copy > > of check-webkit-style, I'm already running that risk whenever I type > > "svn up". > > > > == Frequently Asked Questions == > > > > Q1: If the style-queue doesn't complain, does that mean my patch has > > correct style? > > > > A1: Unfortunately, no. First of all, check-webkit-style has false > > negatives. Hopefully, the script will improve over time, but it will > > never be perfect. Second, the style-queue is only able to check > > patches that successfully download and apply to top-of-tree. If your > > patch does not apply to top-of-tree (e.g., because it depends on > > another patch), then style-queue won't say anything. > > > > Q2: How can I see whether style-queue processed my patch? > > > > A2: There isn't a great way to do this yet. The data is stored in the > > webkit-commit-queue.appspot.com web service, but we haven't built a > > front-end for it yet. If you have a strong stomach, you can look at > > the endpoint the bot itself uses > > > > http://webkit-commit-queue.appspot.com/patch-status/style-queue/12345 > > > > where 12345 is the ID of your attachment. If you'd like to have a > > better status display, feel free to hack on > > WebKitTools/QueueStatusServer and send me or Eric patches to review. > > In the long term, there's no reason we can't have an awesome UI. > > > > Q3: This bot is going to run amock! How can I keep track of all it's > > evil deeds? > > > > A3: If you want to see what the bots are doing, you can subscribe to > > the following email list: > > > > http://groups.google.com/group/webkit-bot-watchers > > > > Whenever the bots touch a bug, they're supposed to add this address to > > the CC list. This functionality is very new, so we might not have > > every case covered yet. If you see the bot misbehaving, let me or > > Eric know. We'll correct the issue ASAP. > > > > Q4: Checking style is fine and dandy, but I was hoping for a build-queue! > > > > A4: My next project is to get a build-queue working for Qt. The > > build-queue will share a lot of infrastructure with the style-queue, > > but making the style-queue was easier because check-webkit-style is a > > lot faster than build-webkit. :) > > > > Q5: When are you flipping the switch? > > > > A5: Either today or tomorrow, depending on when I find a stretch of > > time to babysit the queue through whatever initial troubles it has. > > My working copy of the style-queue is about five patches ahead of > > trunk. It would be nice to have those patches committed before > > flipping the switch, but it's not necessary. > > > > Thanks for reading to the end, and I hope you find the style-queue > useful. > > > > Adam > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091130/7dc66e92/attachment.html> From hyatt at apple.com Mon Nov 30 14:01:52 2009 From: hyatt at apple.com (David Hyatt) Date: Mon, 30 Nov 2009 16:01:52 -0600 Subject: [webkit-dev] GlobalScript in WebKit In-Reply-To: <d62cf1d10911301355v76b5c877k4c1bc2b0ea8809b5@mail.gmail.com> References: <28040fc60911191935o7dc5c5edndd696ee6c31607ac@mail.gmail.com> <63a07bb10911252030g360f902fh81cc04734aa1f0b2@mail.gmail.com> <ABC72D2B-04D2-43BC-8407-E5062BA1B0F3@apple.com> <d62cf1d10911301355v76b5c877k4c1bc2b0ea8809b5@mail.gmail.com> Message-ID: <32A1B235-DB18-4ADB-845B-04AD94C3063D@apple.com> On Nov 30, 2009, at 3:55 PM, Peter Kasting wrote: > On Mon, Nov 30, 2009 at 1:33 PM, Maciej Stachowiak <mjs at apple.com> > wrote: > My impression from WHATWG and from TPAC is that the web standards > community and other browser implementors don't really buy into the > value of this feature, so I think there's good odds we would end up > in the orphan situation. > > It seems like the concern is not in trying the feature, but in being > unable to remove it if it doesn't pan out. I too am concerned about > this case. > > To me, the right response to this concern is not to ban > implementation but to try and determine how we can guarantee removal/ > modification if this doesn't prove to be effective. And to do that > it seems like we have to guarantee that we won't have consumers who > depend on this feature that we're forced to support. > > I agree with Dave Hyatt that perhaps the best way of minimizing risk > in these cases is to agree that this will not be enabled in stable > releases of browsers until we have enough feedback for the broader > community to make more final decisions. Hopefully this will prevent > web authors from relying on the feature's availability and yet still > allow interested parties to run what tests they need. > > CSS variables are a good example. It's very fortunate that this experiment was never shipped, and I was able to collect a lot of great feedback purely from development builds. dave -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091130/fbe4836b/attachment-0001.html> From mjs at apple.com Mon Nov 30 14:17:26 2009 From: mjs at apple.com (Maciej Stachowiak) Date: Mon, 30 Nov 2009 14:17:26 -0800 Subject: [webkit-dev] GlobalScript in WebKit In-Reply-To: <87DB0D9D-E4E0-414D-9C10-ABCD5FBFE855@apple.com> References: <28040fc60911191935o7dc5c5edndd696ee6c31607ac@mail.gmail.com> <63a07bb10911252030g360f902fh81cc04734aa1f0b2@mail.gmail.com> <28040fc60911252141i6f1ff2c3o89dd9514699d14a7@mail.gmail.com> <d62cf1d10911252216m48d212c4i72e3d571e2a41018@mail.gmail.com> <28040fc60911260944h63f0cab0q52256439c11fc46a@mail.gmail.com> <fbbf8c7c0911300955k4b0463afy59ab48fbb70feb3f@mail.gmail.com> <552A9728-511D-4260-8725-7D2ACE8724AC@apple.com> <87DB0D9D-E4E0-414D-9C10-ABCD5FBFE855@apple.com> Message-ID: <EB95E389-8902-4E04-A40C-0A0149D0DD1D@apple.com> On Nov 30, 2009, at 1:58 PM, David Hyatt wrote: > On Nov 30, 2009, at 3:45 PM, Maciej Stachowiak wrote: > >> WebKit (or at least the mainline) is not necessarily a great place >> for experiments. As our Project Goals say: "WebKit is an >> engineering project, not a science project." <http://webkit.org/projects/goals.html >> >. Of course, that's a pretty fuzzy line, because sometimes a use >> case is really well proven and we're not willing to wait for >> standards groups to get their butt in gear. But there are some >> potential bad scenarios with building features that don't have a >> clear path to standardization: >> >> 1) It will be rejected by other browser vendors and end up a WebKit- >> only (or nearly WebKit-only) feature, but enough WebKit-specific >> content depends on it that we can't drop it, even if we would like >> to. Then we are stuck maintaining a dead-end technology >> indefinitely. It seems like the SQL database may be on this path. >> > > This is really the scenario to worry about the most. Having to > support "failed" technologies is painful. > >> 2) It will get adopted into standards, but with significant changes >> when other implementors and standards experts jump on the >> bandwagon. These changes can cause a very painful transition, since >> we need to remain compatible with legacy WebKit-specific content, >> yet at the same time we don't want to be in violation of the >> consensus spec. This actually happened with <canvas> - it changed >> incompatibly in ways that broke a bunch of WebKit-specific content >> (in particular Dashboard widgets), but we had to implement the >> standard to support content coded to Firefox. This really sucked >> and we have Dashboard-specific hacks still lying around in our code >> base as a result. >> > > I don't really think it's fair to bring this up as a negative. > Having the experiment adopted as a standard is a complete win. That > the transition from experiment to reality can be painful is just an > inevitable consequence of a maturing standard. The transition could have been somewhat less painful if we'd gotten more review on <canvas> before shipping it in product. But I do agree that overall, <canvas> is a technology success story even if the path there was painful for us. > > CSS gradients are a good example. The new syntax coming out of the > CSS WG is way better, but none of it would have happened without the > initial WebKit experiment. Because of that experiment we're > eventually going to have gradients in all browsers. Will the > transition be a bit painful? Sure, but the end result is that we > pushed the Web forward. Probably much less pain than <canvas> for a couple of reasons: (a) We started getting outside review before shipping in product. (b) The CSS prefixing convention makes it easier to support preliminary syntax at relatively low cost. > Now I don't know if GlobalScript falls into this category or not. > If no other browser vendors are interested in it, we should be > pretty wary. If we think the implementation of the feature can > change their minds, though, then I'd say it's worth at least > experimenting with. > > What do other browser vendors think of this feature right now? My impression was they weren't really into it but we could always ask directly. Regards, Maciej From dimich at chromium.org Mon Nov 30 14:25:24 2009 From: dimich at chromium.org (Dmitry Titov) Date: Mon, 30 Nov 2009 14:25:24 -0800 Subject: [webkit-dev] GlobalScript in WebKit In-Reply-To: <5dd9e5c50911301358t5b35c30bh9bdc84c3ee095771@mail.gmail.com> References: <28040fc60911191935o7dc5c5edndd696ee6c31607ac@mail.gmail.com> <63a07bb10911252030g360f902fh81cc04734aa1f0b2@mail.gmail.com> <28040fc60911252141i6f1ff2c3o89dd9514699d14a7@mail.gmail.com> <d62cf1d10911252216m48d212c4i72e3d571e2a41018@mail.gmail.com> <28040fc60911260944h63f0cab0q52256439c11fc46a@mail.gmail.com> <fbbf8c7c0911300955k4b0463afy59ab48fbb70feb3f@mail.gmail.com> <8421EA96-F80B-4CF2-8A68-A6823D510BEA@webkit.org> <5dd9e5c50911301331y5312f646q711e6314cf224a1@mail.gmail.com> <02AA91E5-5FFF-44F3-8E05-1DCC311E9D1A@apple.com> <5dd9e5c50911301358t5b35c30bh9bdc84c3ee095771@mail.gmail.com> Message-ID: <28040fc60911301425g669b7ffeh713989e47a557d2@mail.gmail.com> We could name a couple of big ones (GMail was already mentioned before), they already have designs ready to go into test as soon as they get SharedScript in a dev build. If there was no desire from actual app developer teams for SharedScript, we would not have the reason to continue with it long time ago. That also pretty much means if we won't do SharedScript, we'll need to explore other opportunities toward efficient sharing of code and data which does not make people to write a multithreaded UI as SharedWorker solution would do. We have practically zero positive response to SharedWorkers being used this way. Granted, this is "just one company" but the limited unscientific poll kind of shows the direction... On Mon, Nov 30, 2009 at 1:58 PM, Jeremy Orlow <jorlow at chromium.org> wrote: > On Mon, Nov 30, 2009 at 1:54 PM, Geoffrey Garen <ggaren at apple.com> wrote: > >> > There are a lot of people inside Google that have a lot of experience >> with web standards, browsers, and web apps that seem to think this is useful >> and worth the effort to experiment with it. >> >> Who exactly inside Google is waiting to build a new service, feature, or >> experiment using SharedScript? >> > > I don't think we can or should have to say specifically, but several major > apps with millions of users. > > _______________________________________________ > webkit-dev mailing list > webkit-dev at lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091130/34af7e17/attachment.html> From ap at webkit.org Mon Nov 30 14:30:05 2009 From: ap at webkit.org (Alexey Proskuryakov) Date: Mon, 30 Nov 2009 14:30:05 -0800 Subject: [webkit-dev] GlobalScript in WebKit In-Reply-To: <28040fc60911301405gef7ab6cw4f032b4af37d7f2@mail.gmail.com> References: <28040fc60911191935o7dc5c5edndd696ee6c31607ac@mail.gmail.com> <63a07bb10911252030g360f902fh81cc04734aa1f0b2@mail.gmail.com> <28040fc60911252141i6f1ff2c3o89dd9514699d14a7@mail.gmail.com> <d62cf1d10911252216m48d212c4i72e3d571e2a41018@mail.gmail.com> <28040fc60911260944h63f0cab0q52256439c11fc46a@mail.gmail.com> <fbbf8c7c0911300955k4b0463afy59ab48fbb70feb3f@mail.gmail.com> <8421EA96-F80B-4CF2-8A68-A6823D510BEA@webkit.org> <5dd9e5c50911301331y5312f646q711e6314cf224a1@mail.gmail.com> <02AA91E5-5FFF-44F3-8E05-1DCC311E9D1A@apple.com> <28040fc60911301405gef7ab6cw4f032b4af37d7f2@mail.gmail.com> Message-ID: <A3C1B706-04F5-4604-B276-E62D76D506B3@webkit.org> On 30.11.2009, at 14:05, Dmitry Titov wrote: > That also pretty much means if we won't have SharedScript, we'll > need to explore other opportunities toward efficient sharing of code > and data which does not make people to write a multithreaded UI as > SharedWorker solution would do. We have practically zero positive > response to SharedWorkers being used this way. Granted, this is > "just one company" but the devs here are good and came from variosu > other companies so the limited unscientific poll kind of shows the > outcome... This makes me wonder if there is any positive experience using SharedWorkers for this elsewhere - or any better use cases for it. At the moment, it seems that technical issues around shared workers's implementation in WebKit haven't all been resolved yet, and that GlobalObject could be a better replacement for the same use case anyway. Dropping one for another is in the spirit of successful experimentation - what do you think? - WBR, Alexey Proskuryakov From darin at chromium.org Mon Nov 30 14:48:55 2009 From: darin at chromium.org (Darin Fisher) Date: Mon, 30 Nov 2009 14:48:55 -0800 Subject: [webkit-dev] GlobalScript in WebKit In-Reply-To: <A3C1B706-04F5-4604-B276-E62D76D506B3@webkit.org> References: <28040fc60911191935o7dc5c5edndd696ee6c31607ac@mail.gmail.com> <28040fc60911252141i6f1ff2c3o89dd9514699d14a7@mail.gmail.com> <d62cf1d10911252216m48d212c4i72e3d571e2a41018@mail.gmail.com> <28040fc60911260944h63f0cab0q52256439c11fc46a@mail.gmail.com> <fbbf8c7c0911300955k4b0463afy59ab48fbb70feb3f@mail.gmail.com> <8421EA96-F80B-4CF2-8A68-A6823D510BEA@webkit.org> <5dd9e5c50911301331y5312f646q711e6314cf224a1@mail.gmail.com> <02AA91E5-5FFF-44F3-8E05-1DCC311E9D1A@apple.com> <28040fc60911301405gef7ab6cw4f032b4af37d7f2@mail.gmail.com> <A3C1B706-04F5-4604-B276-E62D76D506B3@webkit.org> Message-ID: <bd8f24d20911301448o131fb481rb19982824b303232@mail.gmail.com> On Mon, Nov 30, 2009 at 2:30 PM, Alexey Proskuryakov <ap at webkit.org> wrote: > > On 30.11.2009, at 14:05, Dmitry Titov wrote: > > That also pretty much means if we won't have SharedScript, we'll need to >> explore other opportunities toward efficient sharing of code and data which >> does not make people to write a multithreaded UI as SharedWorker solution >> would do. We have practically zero positive response to SharedWorkers being >> used this way. Granted, this is "just one company" but the devs here are >> good and came from variosu other companies so the limited unscientific poll >> kind of shows the outcome... >> > > This makes me wonder if there is any positive experience using > SharedWorkers for this elsewhere - or any better use cases for it. > > At the moment, it seems that technical issues around shared workers's > implementation in WebKit haven't all been resolved yet, and that > GlobalObject could be a better replacement for the same use case anyway. > Dropping one for another is in the spirit of successful experimentation - > what do you think? > > - WBR, Alexey Proskuryakov > > 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. -Darin -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091130/4b382817/attachment.html> From oliver at apple.com Mon Nov 30 14:56:50 2009 From: oliver at apple.com (Oliver Hunt) Date: Mon, 30 Nov 2009 14:56:50 -0800 Subject: [webkit-dev] GlobalScript in WebKit In-Reply-To: <bd8f24d20911301448o131fb481rb19982824b303232@mail.gmail.com> References: <28040fc60911191935o7dc5c5edndd696ee6c31607ac@mail.gmail.com> <28040fc60911252141i6f1ff2c3o89dd9514699d14a7@mail.gmail.com> <d62cf1d10911252216m48d212c4i72e3d571e2a41018@mail.gmail.com> <28040fc60911260944h63f0cab0q52256439c11fc46a@mail.gmail.com> <fbbf8c7c0911300955k4b0463afy59ab48fbb70feb3f@mail.gmail.com> <8421EA96-F80B-4CF2-8A68-A6823D510BEA@webkit.org> <5dd9e5c50911301331y5312f646q711e6314cf224a1@mail.gmail.com> <02AA91E5-5FFF-44F3-8E05-1DCC311E9D1A@apple.com> <28040fc60911301405gef7ab6cw4f032b4af37d7f2@mail.gmail.com> <A3C1B706-04F5-4604-B276-E62D76D506B3@webkit.org> <bd8f24d20911301448o131fb481rb19982824b303232@mail.gmail.com> Message-ID: <CE009A6D-95AE-4CE6-AB9D-5AF9E97E2126@apple.com> > 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. What you seem to be implying is that a "SharedScript" would not actually achieve the one thing it is intended to gain -- a common context for all instances of a page. > > -Darin --Oliver > _______________________________________________ > webkit-dev mailing list > webkit-dev at lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev From darin at chromium.org Mon Nov 30 15:07:37 2009 From: darin at chromium.org (Darin Fisher) Date: Mon, 30 Nov 2009 15:07:37 -0800 Subject: [webkit-dev] GlobalScript in WebKit In-Reply-To: <CE009A6D-95AE-4CE6-AB9D-5AF9E97E2126@apple.com> References: <28040fc60911191935o7dc5c5edndd696ee6c31607ac@mail.gmail.com> <28040fc60911260944h63f0cab0q52256439c11fc46a@mail.gmail.com> <fbbf8c7c0911300955k4b0463afy59ab48fbb70feb3f@mail.gmail.com> <8421EA96-F80B-4CF2-8A68-A6823D510BEA@webkit.org> <5dd9e5c50911301331y5312f646q711e6314cf224a1@mail.gmail.com> <02AA91E5-5FFF-44F3-8E05-1DCC311E9D1A@apple.com> <28040fc60911301405gef7ab6cw4f032b4af37d7f2@mail.gmail.com> <A3C1B706-04F5-4604-B276-E62D76D506B3@webkit.org> <bd8f24d20911301448o131fb481rb19982824b303232@mail.gmail.com> <CE009A6D-95AE-4CE6-AB9D-5AF9E97E2126@apple.com> Message-ID: <bd8f24d20911301507l3b4b045fy90e9db42335e019c@mail.gmail.com> On Mon, Nov 30, 2009 at 2:56 PM, Oliver Hunt <oliver at apple.com> wrote: > > 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. > > What you seem to be implying is that a "SharedScript" would not actually > achieve the one thing it is intended to gain -- a common context for all > instances of a page. > No. I'm saying that SharedScript would be shared within a WebKit process, similar to the "sharing" that happens for DOM windows (reachable by name). That doesn't prevent it from being shared by multiple pages in an application. For any Window created by a web app, Chrome keeps the new window in the same process as the opener since they may script one another (i.e., they may be effectively part of the same web app). -Darin > > > > > -Darin > --Oliver > > > _______________________________________________ > > webkit-dev mailing list > > webkit-dev at lists.webkit.org > > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091130/7bc54833/attachment.html> From ggaren at apple.com Mon Nov 30 15:08:32 2009 From: ggaren at apple.com (Geoffrey Garen) Date: Mon, 30 Nov 2009 15:08:32 -0800 Subject: [webkit-dev] GlobalScript in WebKit In-Reply-To: <bd8f24d20911301448o131fb481rb19982824b303232@mail.gmail.com> References: <28040fc60911191935o7dc5c5edndd696ee6c31607ac@mail.gmail.com> <28040fc60911252141i6f1ff2c3o89dd9514699d14a7@mail.gmail.com> <d62cf1d10911252216m48d212c4i72e3d571e2a41018@mail.gmail.com> <28040fc60911260944h63f0cab0q52256439c11fc46a@mail.gmail.com> <fbbf8c7c0911300955k4b0463afy59ab48fbb70feb3f@mail.gmail.com> <8421EA96-F80B-4CF2-8A68-A6823D510BEA@webkit.org> <5dd9e5c50911301331y5312f646q711e6314cf224a1@mail.gmail.com> <02AA91E5-5FFF-44F3-8E05-1DCC311E9D1A@apple.com> <28040fc60911301405gef7ab6cw4f032b4af37d7f2@mail.gmail.com> <A3C1B706-04F5-4604-B276-E62D76D506B3@webkit.org> <bd8f24d20911301448o131fb481rb19982824b303232@mail.gmail.com> Message-ID: <A37C7280-DFA4-4A3F-8282-1A0002BAC54F@apple.com> > 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 From dimich at chromium.org Mon Nov 30 15:43:32 2009 From: dimich at chromium.org (Dmitry Titov) Date: Mon, 30 Nov 2009 15:43:32 -0800 Subject: [webkit-dev] GlobalScript in WebKit In-Reply-To: <A37C7280-DFA4-4A3F-8282-1A0002BAC54F@apple.com> References: <28040fc60911191935o7dc5c5edndd696ee6c31607ac@mail.gmail.com> <28040fc60911260944h63f0cab0q52256439c11fc46a@mail.gmail.com> <fbbf8c7c0911300955k4b0463afy59ab48fbb70feb3f@mail.gmail.com> <8421EA96-F80B-4CF2-8A68-A6823D510BEA@webkit.org> <5dd9e5c50911301331y5312f646q711e6314cf224a1@mail.gmail.com> <02AA91E5-5FFF-44F3-8E05-1DCC311E9D1A@apple.com> <28040fc60911301405gef7ab6cw4f032b4af37d7f2@mail.gmail.com> <A3C1B706-04F5-4604-B276-E62D76D506B3@webkit.org> <bd8f24d20911301448o131fb481rb19982824b303232@mail.gmail.com> <A37C7280-DFA4-4A3F-8282-1A0002BAC54F@apple.com> Message-ID: <28040fc60911301543h6868018at5b3dc3a867753647@mail.gmail.com> 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 issues <http://www.chromium.org/developers/design-documents/process-models>are 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 <ggaren at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091130/06175688/attachment.html> From darin at apple.com Mon Nov 30 15:44:16 2009 From: darin at apple.com (Darin Adler) Date: Mon, 30 Nov 2009 15:44:16 -0800 Subject: [webkit-dev] Webkit render tree dump In-Reply-To: <e9a2579e0911182055w20e39a09r122821944f4830c5@mail.gmail.com> References: <e9a2579e0911182055w20e39a09r122821944f4830c5@mail.gmail.com> Message-ID: <197CB871-EDF9-4858-89F5-649CCB3A03C4@apple.com> On Nov 18, 2009, at 8:55 PM, pundarik rajkhowa wrote: > I have a doubt regarding the content of webkit render tree dump. In this dump, do we only print the HTML node information(body, div etc) or we print the style information also(font-weight, text-decoration etc). From what I have seen, it looks like only node information is printed. In such a case how a bug is caught if it is related to style attributes ? Some bugs related to style attributes affect the layout of the web page, and so are detected by the change in size of the rendered elements. But other bugs related to style can only be caught by explicit queries of style by JavaScript code, or with the ?pixel tests?, test results that use a graphical dump of a fixed-size browser window. -- Darin From atwilson at google.com Mon Nov 30 16:05:25 2009 From: atwilson at google.com (Drew Wilson) Date: Mon, 30 Nov 2009 16:05:25 -0800 Subject: [webkit-dev] GlobalScript in WebKit In-Reply-To: <28040fc60911301543h6868018at5b3dc3a867753647@mail.gmail.com> References: <28040fc60911191935o7dc5c5edndd696ee6c31607ac@mail.gmail.com> <fbbf8c7c0911300955k4b0463afy59ab48fbb70feb3f@mail.gmail.com> <8421EA96-F80B-4CF2-8A68-A6823D510BEA@webkit.org> <5dd9e5c50911301331y5312f646q711e6314cf224a1@mail.gmail.com> <02AA91E5-5FFF-44F3-8E05-1DCC311E9D1A@apple.com> <28040fc60911301405gef7ab6cw4f032b4af37d7f2@mail.gmail.com> <A3C1B706-04F5-4604-B276-E62D76D506B3@webkit.org> <bd8f24d20911301448o131fb481rb19982824b303232@mail.gmail.com> <A37C7280-DFA4-4A3F-8282-1A0002BAC54F@apple.com> <28040fc60911301543h6868018at5b3dc3a867753647@mail.gmail.com> Message-ID: <f965ae410911301605p637a5c4bkd7eb8339a6e19fcc@mail.gmail.com> 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 <dimich at 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 issues<http://www.chromium.org/developers/design-documents/process-models>are 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 <ggaren at 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 at lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091130/622b1f33/attachment.html> From darin at chromium.org Mon Nov 30 16:05:50 2009 From: darin at chromium.org (Darin Fisher) Date: Mon, 30 Nov 2009 16:05:50 -0800 Subject: [webkit-dev] GlobalScript in WebKit In-Reply-To: <A37C7280-DFA4-4A3F-8282-1A0002BAC54F@apple.com> References: <28040fc60911191935o7dc5c5edndd696ee6c31607ac@mail.gmail.com> <28040fc60911260944h63f0cab0q52256439c11fc46a@mail.gmail.com> <fbbf8c7c0911300955k4b0463afy59ab48fbb70feb3f@mail.gmail.com> <8421EA96-F80B-4CF2-8A68-A6823D510BEA@webkit.org> <5dd9e5c50911301331y5312f646q711e6314cf224a1@mail.gmail.com> <02AA91E5-5FFF-44F3-8E05-1DCC311E9D1A@apple.com> <28040fc60911301405gef7ab6cw4f032b4af37d7f2@mail.gmail.com> <A3C1B706-04F5-4604-B276-E62D76D506B3@webkit.org> <bd8f24d20911301448o131fb481rb19982824b303232@mail.gmail.com> <A37C7280-DFA4-4A3F-8282-1A0002BAC54F@apple.com> Message-ID: <bd8f24d20911301605o7b28ec43x3ebe995e2ea9469d@mail.gmail.com> On Mon, Nov 30, 2009 at 3:08 PM, Geoffrey Garen <ggaren at 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. > > It is not clear to me what you are arguing for. Are you saying that Chrome is wrong to allow *unrelated* similar-origin-browsing-contexts to see the same SharedWorker instances? -Darin -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091130/03fcf149/attachment.html> From oliver at apple.com Mon Nov 30 16:07:21 2009 From: oliver at apple.com (Oliver Hunt) Date: Mon, 30 Nov 2009 16:07:21 -0800 Subject: [webkit-dev] GlobalScript in WebKit In-Reply-To: <28040fc60911301543h6868018at5b3dc3a867753647@mail.gmail.com> References: <28040fc60911191935o7dc5c5edndd696ee6c31607ac@mail.gmail.com> <28040fc60911260944h63f0cab0q52256439c11fc46a@mail.gmail.com> <fbbf8c7c0911300955k4b0463afy59ab48fbb70feb3f@mail.gmail.com> <8421EA96-F80B-4CF2-8A68-A6823D510BEA@webkit.org> <5dd9e5c50911301331y5312f646q711e6314cf224a1@mail.gmail.com> <02AA91E5-5FFF-44F3-8E05-1DCC311E9D1A@apple.com> <28040fc60911301405gef7ab6cw4f032b4af37d7f2@mail.gmail.com> <A3C1B706-04F5-4604-B276-E62D76D506B3@webkit.org> <bd8f24d20911301448o131fb481rb19982824b303232@mail.gmail.com> <A37C7280-DFA4-4A3F-8282-1A0002BAC54F@apple.com> <28040fc60911301543h6868018at5b3dc3a867753647@mail.gmail.com> Message-ID: <70C4D1CF-48F3-440B-960F-4A380BD4EC95@apple.com> 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. > > Multi-process browsers are bringing more complexity (and benefits). Not all technical issues are 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. The Worker implementation behaviour is not really relevant to this conversation. The issue is whether a browser implements a spec in a correct manner, that's why implementation is not described. A worker for instance may be per thread, per process, or may not even represent a separate machine thread and could be implemented by in software just running each task in sequence (assuming a sufficiently careful implementation, etc, etc). The issue we're discussing however was what Darin bought up -- should a multiprocess browser be allowed to have multiple distinct instances of the same Global/SharedScript? the answer is clearly no (and that concept has been removed from the spec); The issue being that in regular day to day use such a browser could end up producing behaviour inconsistent with behaviour that of browsers that actually did provide a single shared context -- in effect all users of Global/SharedScript would have to assume that their Global/SharedScript context was not in fact shared. The resultant implication is that a "Shared" or "Global" script would have not need to be shared at all and each page could have it's own copy -- effectively degenerating to a glorified iframe. I would consider it to be a warning sign of potential badness in a spec if behaviour was being defined by perceived difficulty in implementing a feature, rather than on the desired end user behaviour. In general I feel a spec should always favour complexity of implementation over complexity in use, after all if a feature is hard to implement it still only needs to be implemented a relatively small number of times (basically once per browser/engine) pushing the complexity on to end developers however then means thousands (millions?) of developers have to implement the same code and deal with the same complexity over and over again. Obviously if there's an option to avoid any complexity that would be best, but i suspect that's unlikely to exist :-D --Oliver > > Dmitry > > On Mon, Nov 30, 2009 at 3:08 PM, Geoffrey Garen <ggaren at 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 at lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091130/d1fffe2b/attachment.html> From ian at hixie.ch Mon Nov 30 16:15:44 2009 From: ian at hixie.ch (Ian Hickson) Date: Tue, 1 Dec 2009 00:15:44 +0000 (UTC) Subject: [webkit-dev] GlobalScript in WebKit In-Reply-To: <28040fc60911301425g669b7ffeh713989e47a557d2@mail.gmail.com> References: <28040fc60911191935o7dc5c5edndd696ee6c31607ac@mail.gmail.com> <63a07bb10911252030g360f902fh81cc04734aa1f0b2@mail.gmail.com> <28040fc60911252141i6f1ff2c3o89dd9514699d14a7@mail.gmail.com> <d62cf1d10911252216m48d212c4i72e3d571e2a41018@mail.gmail.com> <28040fc60911260944h63f0cab0q52256439c11fc46a@mail.gmail.com> <fbbf8c7c0911300955k4b0463afy59ab48fbb70feb3f@mail.gmail.com> <8421EA96-F80B-4CF2-8A68-A6823D510BEA@webkit.org> <5dd9e5c50911301331y5312f646q711e6314cf224a1@mail.gmail.com> <02AA91E5-5FFF-44F3-8E05-1DCC311E9D1A@apple.com> <5dd9e5c50911301358t5b35c30bh9bdc84c3ee095771@mail.gmail.com> <28040fc60911301425g669b7ffeh713989e47a557d2@mail.gmail.com> Message-ID: <Pine.LNX.4.62.0912010010350.2479@hixie.dreamhostps.com> On Mon, 30 Nov 2009, Dmitry Titov wrote: > > That also pretty much means if we won't do SharedScript, we'll need to > explore other opportunities toward efficient sharing of code and data > which does not make people to write a multithreaded UI as SharedWorker > solution would do. We have practically zero positive response to > SharedWorkers being used this way. Granted, this is "just one company" > but the limited unscientific poll kind of shows the direction... 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. However, we should not be basing the platform's progress on transition cost avoidance of one company. Google can afford to rewrite GMail if it comes down to that. It is not in the Web's long term interests for us to design features that are optimised for the transition phase at the cost of the long-term health of the Web. What we should be looking at is what API do teams prefer to work with when starting from scratch, because on the long term that will be the far more common case than transitioning from a legacy codebase. I don't think that our (Google's) response is representative here. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From jorlow at chromium.org Mon Nov 30 16:18:34 2009 From: jorlow at chromium.org (Jeremy Orlow) Date: Mon, 30 Nov 2009 16:18:34 -0800 Subject: [webkit-dev] GlobalScript in WebKit In-Reply-To: <70C4D1CF-48F3-440B-960F-4A380BD4EC95@apple.com> References: <28040fc60911191935o7dc5c5edndd696ee6c31607ac@mail.gmail.com> <8421EA96-F80B-4CF2-8A68-A6823D510BEA@webkit.org> <5dd9e5c50911301331y5312f646q711e6314cf224a1@mail.gmail.com> <02AA91E5-5FFF-44F3-8E05-1DCC311E9D1A@apple.com> <28040fc60911301405gef7ab6cw4f032b4af37d7f2@mail.gmail.com> <A3C1B706-04F5-4604-B276-E62D76D506B3@webkit.org> <bd8f24d20911301448o131fb481rb19982824b303232@mail.gmail.com> <A37C7280-DFA4-4A3F-8282-1A0002BAC54F@apple.com> <28040fc60911301543h6868018at5b3dc3a867753647@mail.gmail.com> <70C4D1CF-48F3-440B-960F-4A380BD4EC95@apple.com> Message-ID: <5dd9e5c50911301618m3645f7e6md3ee4352f44bf8@mail.gmail.com> Does anyone have a link to the spec? On Mon, Nov 30, 2009 at 4:07 PM, Oliver Hunt <oliver at 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. > > Multi-process browsers are bringing more complexity (and benefits). Not all > technical issues<http://www.chromium.org/developers/design-documents/process-models>are 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. > > > The Worker implementation behaviour is not really relevant to this > conversation. The issue is whether a browser implements a spec in a correct > manner, that's why implementation is not described. A worker for instance > may be per thread, per process, or may not even represent a separate machine > thread and could be implemented by in software just running each task in > sequence (assuming a sufficiently careful implementation, etc, etc). > > The issue we're discussing however was what Darin bought up -- should a > multiprocess browser be allowed to have multiple distinct instances of the > same Global/SharedScript? the answer is clearly no (and that concept has > been removed from the spec); > I don't agree that it's clearly no and I didn't have any clue that it had been removed from the spec. If multiple processes/event-loops would share the same SharedScript instance then we're either not going to be able to maintain run to completion semantics or its going to need to use the storage mutex (which would probably need to be renamed). That would be unfortunate to put it very...VERY lightly. > The issue being that in regular day to day use such a browser could end up > producing behaviour inconsistent with behaviour that of browsers that > actually did provide a single shared context -- in effect all users of > Global/SharedScript would have to assume that their Global/SharedScript > context was not in fact shared. > > The resultant implication is that a "Shared" or "Global" script would have > not need to be shared at all and each page could have it's own copy -- > effectively degenerating to a glorified iframe. > > I would consider it to be a warning sign of potential badness in a spec if > behaviour was being defined by perceived difficulty in implementing a > feature, rather than on the desired end user behaviour. In general I feel a > spec should always favour complexity of implementation over complexity in > use, after all if a feature is hard to implement it still only needs to be > implemented a relatively small number of times (basically once per > browser/engine) pushing the complexity on to end developers however then > means thousands (millions?) of developers have to implement the same code > and deal with the same complexity over and over again. Obviously if there's > an option to avoid any complexity that would be best, but i suspect that's > unlikely to exist :-D > > --Oliver > > > Dmitry > > On Mon, Nov 30, 2009 at 3:08 PM, Geoffrey Garen <ggaren at 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 at lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > > > _______________________________________________ > webkit-dev mailing list > webkit-dev at lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091130/b9553782/attachment.html> From oliver at apple.com Mon Nov 30 16:23:02 2009 From: oliver at apple.com (Oliver Hunt) Date: Mon, 30 Nov 2009 16:23:02 -0800 Subject: [webkit-dev] GlobalScript in WebKit In-Reply-To: <5dd9e5c50911301618m3645f7e6md3ee4352f44bf8@mail.gmail.com> References: <28040fc60911191935o7dc5c5edndd696ee6c31607ac@mail.gmail.com> <8421EA96-F80B-4CF2-8A68-A6823D510BEA@webkit.org> <5dd9e5c50911301331y5312f646q711e6314cf224a1@mail.gmail.com> <02AA91E5-5FFF-44F3-8E05-1DCC311E9D1A@apple.com> <28040fc60911301405gef7ab6cw4f032b4af37d7f2@mail.gmail.com> <A3C1B706-04F5-4604-B276-E62D76D506B3@webkit.org> <bd8f24d20911301448o131fb481rb19982824b303232@mail.gmail.com> <A37C7280-DFA4-4A3F-8282-1A0002BAC54F@apple.com> <28040fc60911301543h6868018at5b3dc3a867753647@mail.gmail.com> <70C4D1CF-48F3-440B-960F-4A380BD4EC95@apple.com> <5dd9e5c50911301618m3645f7e6md3ee4352f44bf8@mail.gmail.com> Message-ID: <C6537F0D-E46D-497B-8C4C-3025E877C270@apple.com> On Nov 30, 2009, at 4:18 PM, Jeremy Orlow wrote: > Does anyone have a link to the spec? > > On Mon, Nov 30, 2009 at 4:07 PM, Oliver Hunt <oliver at 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. >> >> Multi-process browsers are bringing more complexity (and benefits). Not all technical issues are 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. > > The Worker implementation behaviour is not really relevant to this conversation. The issue is whether a browser implements a spec in a correct manner, that's why implementation is not described. A worker for instance may be per thread, per process, or may not even represent a separate machine thread and could be implemented by in software just running each task in sequence (assuming a sufficiently careful implementation, etc, etc). > > The issue we're discussing however was what Darin bought up -- should a multiprocess browser be allowed to have multiple distinct instances of the same Global/SharedScript? the answer is clearly no (and that concept has been removed from the spec); > > I don't agree that it's clearly no and I didn't have any clue that it had been removed from the spec. If multiple processes/event-loops would share the same SharedScript instance then we're either not going to be able to maintain run to completion semantics or its going to need to use the storage mutex (which would probably need to be renamed). That would be unfortunate to put it very...VERY lightly. It would not need to reference a storage mutex in any way -- Global/SharedScript runs inline, it's deliberately intended to not be a separate thread, and therefore from the PoV of the spec there is no concurrency. Ensuring correct semantics is simply an implementation detail that is completely distinct from the main spec. --Oliver -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091130/1b21eeba/attachment.html> From levin at google.com Mon Nov 30 16:29:44 2009 From: levin at google.com (David Levin) Date: Mon, 30 Nov 2009 16:29:44 -0800 Subject: [webkit-dev] GlobalScript in WebKit In-Reply-To: <Pine.LNX.4.62.0912010010350.2479@hixie.dreamhostps.com> References: <28040fc60911191935o7dc5c5edndd696ee6c31607ac@mail.gmail.com> <d62cf1d10911252216m48d212c4i72e3d571e2a41018@mail.gmail.com> <28040fc60911260944h63f0cab0q52256439c11fc46a@mail.gmail.com> <fbbf8c7c0911300955k4b0463afy59ab48fbb70feb3f@mail.gmail.com> <8421EA96-F80B-4CF2-8A68-A6823D510BEA@webkit.org> <5dd9e5c50911301331y5312f646q711e6314cf224a1@mail.gmail.com> <02AA91E5-5FFF-44F3-8E05-1DCC311E9D1A@apple.com> <5dd9e5c50911301358t5b35c30bh9bdc84c3ee095771@mail.gmail.com> <28040fc60911301425g669b7ffeh713989e47a557d2@mail.gmail.com> <Pine.LNX.4.62.0912010010350.2479@hixie.dreamhostps.com> Message-ID: <b902e34a0911301629r3ddc91e3k624f037d86f2a62c@mail.gmail.com> On Mon, Nov 30, 2009 at 4:15 PM, Ian Hickson <ian at hixie.ch> wrote: > On Mon, 30 Nov 2009, Dmitry Titov wrote: > > > > That also pretty much means if we won't do SharedScript, we'll need to > > explore other opportunities toward efficient sharing of code and data > > which does not make people to write a multithreaded UI as SharedWorker > > solution would do. We have practically zero positive response to > > SharedWorkers being used this way. Granted, this is "just one company" > > but the limited unscientific poll kind of shows the direction... > > 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. > > Presenting this as a SharedWorker vs SharedScript thing is a false dichotomy. SharedWorkers and SharedScript serve different purposes for the people who want to use each. The majority of applications are not written to do *all* of their logic in a background thread, so it is odd to me that it is espoused as the right paradigm on web developers. There is a certain amount of logic that makes sense to happen on the main thread and be shared across windows. > However, we should not be basing the platform's progress on transition > cost avoidance of one company. Google can afford to rewrite GMail if it > comes down to that. It is not in the Web's long term interests for us to > design features that are optimised for the transition phase at the cost of > the long-term health of the Web. > On the other hand, just because there is a hammer, it doesn't mean that everything is a nail no matter how much we want it to be. > What we should be looking at is what API do teams prefer to work with when > starting from scratch, And it makes a lot of sense for new apps to do some logic that is quick on the main thread (and not proxy it off to another thread). > because on the long term that will be the far more > common case than transitioning from a legacy codebase. I don't think that > our (Google's) response is representative here. > > Based on my 10+ years of experience as an app developer, I think the response is very representative of what I'd want. dave -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091130/895ede22/attachment.html> From jorlow at chromium.org Mon Nov 30 16:30:49 2009 From: jorlow at chromium.org (Jeremy Orlow) Date: Mon, 30 Nov 2009 16:30:49 -0800 Subject: [webkit-dev] GlobalScript in WebKit In-Reply-To: <C6537F0D-E46D-497B-8C4C-3025E877C270@apple.com> References: <28040fc60911191935o7dc5c5edndd696ee6c31607ac@mail.gmail.com> <02AA91E5-5FFF-44F3-8E05-1DCC311E9D1A@apple.com> <28040fc60911301405gef7ab6cw4f032b4af37d7f2@mail.gmail.com> <A3C1B706-04F5-4604-B276-E62D76D506B3@webkit.org> <bd8f24d20911301448o131fb481rb19982824b303232@mail.gmail.com> <A37C7280-DFA4-4A3F-8282-1A0002BAC54F@apple.com> <28040fc60911301543h6868018at5b3dc3a867753647@mail.gmail.com> <70C4D1CF-48F3-440B-960F-4A380BD4EC95@apple.com> <5dd9e5c50911301618m3645f7e6md3ee4352f44bf8@mail.gmail.com> <C6537F0D-E46D-497B-8C4C-3025E877C270@apple.com> Message-ID: <5dd9e5c50911301630u4904d7e1l4644aeda092b9f6d@mail.gmail.com> On Mon, Nov 30, 2009 at 4:23 PM, Oliver Hunt <oliver at apple.com> wrote: > > On Nov 30, 2009, at 4:18 PM, Jeremy Orlow wrote: > > Does anyone have a link to the spec? > > On Mon, Nov 30, 2009 at 4:07 PM, Oliver Hunt <oliver at 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. >> >> Multi-process browsers are bringing more complexity (and benefits). Not >> all technical issues<http://www.chromium.org/developers/design-documents/process-models>are 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. >> >> >> The Worker implementation behaviour is not really relevant to this >> conversation. The issue is whether a browser implements a spec in a correct >> manner, that's why implementation is not described. A worker for instance >> may be per thread, per process, or may not even represent a separate machine >> thread and could be implemented by in software just running each task in >> sequence (assuming a sufficiently careful implementation, etc, etc). >> >> The issue we're discussing however was what Darin bought up -- should a >> multiprocess browser be allowed to have multiple distinct instances of the >> same Global/SharedScript? the answer is clearly no (and that concept has >> been removed from the spec); >> > > I don't agree that it's clearly no and I didn't have any clue that it had > been removed from the spec. If multiple processes/event-loops would share > the same SharedScript instance then we're either not going to be able to > maintain run to completion semantics or its going to need to use the storage > mutex (which would probably need to be renamed). That would > be unfortunate to put it very...VERY lightly. > > > It would not need to reference a storage mutex in any way -- > Global/SharedScript runs inline, it's deliberately intended to not be a > separate thread, and therefore from the PoV of the spec there is no > concurrency. Ensuring correct semantics is simply an implementation detail > that is completely distinct from the main spec. > What you're suggesting is even one step worse (performance wise) than the storage mutex: you're suggesting that entire event loops would need to block on each other. Of course maybe this is the correct solution to the whole storage mutex issue.... -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091130/1f122a83/attachment.html> From dglazkov at chromium.org Mon Nov 30 16:35:02 2009 From: dglazkov at chromium.org (Dimitri Glazkov) Date: Mon, 30 Nov 2009 16:35:02 -0800 Subject: [webkit-dev] GlobalScript in WebKit In-Reply-To: <5dd9e5c50911301630u4904d7e1l4644aeda092b9f6d@mail.gmail.com> References: <28040fc60911191935o7dc5c5edndd696ee6c31607ac@mail.gmail.com> <28040fc60911301405gef7ab6cw4f032b4af37d7f2@mail.gmail.com> <A3C1B706-04F5-4604-B276-E62D76D506B3@webkit.org> <bd8f24d20911301448o131fb481rb19982824b303232@mail.gmail.com> <A37C7280-DFA4-4A3F-8282-1A0002BAC54F@apple.com> <28040fc60911301543h6868018at5b3dc3a867753647@mail.gmail.com> <70C4D1CF-48F3-440B-960F-4A380BD4EC95@apple.com> <5dd9e5c50911301618m3645f7e6md3ee4352f44bf8@mail.gmail.com> <C6537F0D-E46D-497B-8C4C-3025E877C270@apple.com> <5dd9e5c50911301630u4904d7e1l4644aeda092b9f6d@mail.gmail.com> Message-ID: <fbbf8c7c0911301635s712ec650h90e0e409b571114d@mail.gmail.com> Guys, this thread is getting out of hand. I am waiting for Godwin's law to strike any second now. Can I make a gentle suggestion to perhaps break out new conversations into separate topics? :) Your friendly neighborhood mailing list maid, :DG< From jorlow at chromium.org Mon Nov 30 16:35:30 2009 From: jorlow at chromium.org (Jeremy Orlow) Date: Mon, 30 Nov 2009 16:35:30 -0800 Subject: [webkit-dev] GlobalScript in WebKit In-Reply-To: <b902e34a0911301629r3ddc91e3k624f037d86f2a62c@mail.gmail.com> References: <28040fc60911191935o7dc5c5edndd696ee6c31607ac@mail.gmail.com> <28040fc60911260944h63f0cab0q52256439c11fc46a@mail.gmail.com> <fbbf8c7c0911300955k4b0463afy59ab48fbb70feb3f@mail.gmail.com> <8421EA96-F80B-4CF2-8A68-A6823D510BEA@webkit.org> <5dd9e5c50911301331y5312f646q711e6314cf224a1@mail.gmail.com> <02AA91E5-5FFF-44F3-8E05-1DCC311E9D1A@apple.com> <5dd9e5c50911301358t5b35c30bh9bdc84c3ee095771@mail.gmail.com> <28040fc60911301425g669b7ffeh713989e47a557d2@mail.gmail.com> <Pine.LNX.4.62.0912010010350.2479@hixie.dreamhostps.com> <b902e34a0911301629r3ddc91e3k624f037d86f2a62c@mail.gmail.com> Message-ID: <5dd9e5c50911301635jcbfb430n445447afc87ae6ed@mail.gmail.com> On Mon, Nov 30, 2009 at 4:29 PM, David Levin <levin at google.com> wrote: > > > On Mon, Nov 30, 2009 at 4:15 PM, Ian Hickson <ian at hixie.ch> wrote: > >> On Mon, 30 Nov 2009, Dmitry Titov wrote: >> > >> > That also pretty much means if we won't do SharedScript, we'll need to >> > explore other opportunities toward efficient sharing of code and data >> > which does not make people to write a multithreaded UI as SharedWorker >> > solution would do. We have practically zero positive response to >> > SharedWorkers being used this way. Granted, this is "just one company" >> > but the limited unscientific poll kind of shows the direction... >> >> 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. >> >> > Presenting this as a SharedWorker vs SharedScript thing is a false > dichotomy. SharedWorkers and SharedScript serve different purposes for the > people who want to use each. > > The majority of applications are not written to do *all* of their logic in > a background thread, so it is odd to me that it is espoused as the right > paradigm on web developers. There is a certain amount of logic that makes > sense to happen on the main thread and be shared across windows. > > > >> However, we should not be basing the platform's progress on transition >> cost avoidance of one company. Google can afford to rewrite GMail if it >> comes down to that. It is not in the Web's long term interests for us to >> design features that are optimised for the transition phase at the cost of >> the long-term health of the Web. >> > > On the other hand, just because there is a hammer, it doesn't mean that > everything is a nail no matter how much we want it to be. > > > >> What we should be looking at is what API do teams prefer to work with when >> starting from scratch, > > > And it makes a lot of sense for new apps to do some logic that is quick on > the main thread (and not proxy it off to another thread). > > >> because on the long term that will be the far more >> common case than transitioning from a legacy codebase. I don't think that >> our (Google's) response is representative here. >> >> > Based on my 10+ years of experience as an app developer, I think the > response is very representative of what I'd want. > To be fair, app developers in general want to do everything synchronously but we (in standards land) have pushed back very hard because software research has shown that such interfaces are very difficult (if not impossible) to parallelize. That's why SharedScript sidesteps the issue by saying there should be no parallelism. Which really is a step backwards. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091130/ceb0c378/attachment.html> From dglazkov at chromium.org Mon Nov 30 16:42:42 2009 From: dglazkov at chromium.org (Dimitri Glazkov) Date: Mon, 30 Nov 2009 16:42:42 -0800 Subject: [webkit-dev] Bright Future Tomorrow vs. Boring Today, was: GlobalScript in WebKit Message-ID: <fbbf8c7c0911301642n55ee49b6yf61a65747459986e@mail.gmail.com> Indeed. I tend to think that designing specs to work in the future with future applications in a great leap of engineering faith is not the approach that's worked. The argument that we should design for new applications made from scratch smells very XHTMLey to me. Let's take realistic small steps instead. :DG< On Mon, Nov 30, 2009 at 4:29 PM, David Levin <levin at google.com> wrote: > > > On Mon, Nov 30, 2009 at 4:15 PM, Ian Hickson <ian at hixie.ch> wrote: >> >> On Mon, 30 Nov 2009, Dmitry Titov wrote: >> > >> > That also pretty much means if we won't do SharedScript, we'll need to >> > explore other opportunities toward efficient sharing of code and data >> > which does not make people to write a multithreaded UI as SharedWorker >> > solution would do. We have practically zero positive response to >> > SharedWorkers being used this way. Granted, this is "just one company" >> > but the limited unscientific poll kind of shows the direction... >> >> 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. >> > > Presenting this as a SharedWorker vs SharedScript thing?is a?false > dichotomy. SharedWorkers and SharedScript serve different purposes for the > people who want to use each. > The majority of applications are not written to do all of their logic in a > background thread, so it is?odd to me?that it is espoused as the right > paradigm on web developers. There is a certain amount of logic that makes > sense to happen on the main thread and be shared across windows. > >> >> However, we should not be basing the platform's progress on transition >> cost avoidance of one company. Google can afford to rewrite GMail if it >> comes down to that. It is not in the Web's long term interests for us to >> design features that are optimised for the transition phase at the cost of >> the long-term health of the Web. > > On the other hand, just because there is a hammer, it doesn't mean that > everything is a nail no matter how much we want it to be. > >> >> What we should be looking at is what API do teams prefer to work with when >> starting from scratch, > > And it makes a lot of sense for new apps to do some logic that is quick on > the main thread (and not proxy it off to another thread). > >> >> because on the long term that will be the far more >> common case than transitioning from a legacy codebase. I don't think that >> our (Google's) response is representative here. >> > > Based on my 10+ years of experience as an app developer, I think the > response is very representative of what I'd want. > > dave > _______________________________________________ > webkit-dev mailing list > webkit-dev at lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > From atwilson at google.com Mon Nov 30 16:46:49 2009 From: atwilson at google.com (Drew Wilson) Date: Mon, 30 Nov 2009 16:46:49 -0800 Subject: [webkit-dev] GlobalScript in WebKit In-Reply-To: <Pine.LNX.4.62.0912010010350.2479@hixie.dreamhostps.com> References: <28040fc60911191935o7dc5c5edndd696ee6c31607ac@mail.gmail.com> <d62cf1d10911252216m48d212c4i72e3d571e2a41018@mail.gmail.com> <28040fc60911260944h63f0cab0q52256439c11fc46a@mail.gmail.com> <fbbf8c7c0911300955k4b0463afy59ab48fbb70feb3f@mail.gmail.com> <8421EA96-F80B-4CF2-8A68-A6823D510BEA@webkit.org> <5dd9e5c50911301331y5312f646q711e6314cf224a1@mail.gmail.com> <02AA91E5-5FFF-44F3-8E05-1DCC311E9D1A@apple.com> <5dd9e5c50911301358t5b35c30bh9bdc84c3ee095771@mail.gmail.com> <28040fc60911301425g669b7ffeh713989e47a557d2@mail.gmail.com> <Pine.LNX.4.62.0912010010350.2479@hixie.dreamhostps.com> Message-ID: <f965ae410911301646w580505beufb00532b9344049f@mail.gmail.com> On Mon, Nov 30, 2009 at 4:15 PM, Ian Hickson <ian at 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 at lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091130/6bd2b856/attachment.html> From darin at chromium.org Mon Nov 30 16:58:01 2009 From: darin at chromium.org (Darin Fisher) Date: Mon, 30 Nov 2009 16:58:01 -0800 Subject: [webkit-dev] SharedScript/Worker and multiprocess browsers Message-ID: <bd8f24d20911301658n158c2d8em77aa5af765dbc70a@mail.gmail.com> On Mon, Nov 30, 2009 at 4:07 PM, Oliver Hunt <oliver at 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. > > Multi-process browsers are bringing more complexity (and benefits). Not all > technical issues<http://www.chromium.org/developers/design-documents/process-models>are 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. > > > The Worker implementation behaviour is not really relevant to this > conversation. The issue is whether a browser implements a spec in a correct > manner, that's why implementation is not described. A worker for instance > may be per thread, per process, or may not even represent a separate machine > thread and could be implemented by in software just running each task in > sequence (assuming a sufficiently careful implementation, etc, etc). > > The issue we're discussing however was what Darin bought up -- should a > multiprocess browser be allowed to have multiple distinct instances of the > same Global/SharedScript? the answer is clearly no (and that concept has > been removed from the spec); > Sorry, I think you misunderstand. The way Chrome processes are divided is an implementation detail, but it is an important one. I think it is folly to ignore it when designing web APIs. We'll likely *never* implement APIs that involve cross-process, synchronous script evaluation. We have some experience with that in supporting plugins, and I can tell you that I do not favor it: not just because of implementation complexity but also because of the performance impact it entails. > The issue being that in regular day to day use such a browser could end up > producing behaviour inconsistent with behaviour that of browsers that > actually did provide a single shared context -- in effect all users of > Global/SharedScript would have to assume that their Global/SharedScript > context was not in fact shared. > This is true, but I don't think it is a big deal. Processes are roughly divided up into browsing units. You start a new browsing unit by opening a new tab and navigating it. By doing so, you are creating a separate world that cannot see other worlds. SharedWorkers (as well as cookies and other storage mechanisms) provide a bridge between these worlds, but window.open and SharedScripts do not (b/c of the script connection they imply). Cheers, -Darin > > The resultant implication is that a "Shared" or "Global" script would have > not need to be shared at all and each page could have it's own copy -- > effectively degenerating to a glorified iframe. > > I would consider it to be a warning sign of potential badness in a spec if > behaviour was being defined by perceived difficulty in implementing a > feature, rather than on the desired end user behaviour. In general I feel a > spec should always favour complexity of implementation over complexity in > use, after all if a feature is hard to implement it still only needs to be > implemented a relatively small number of times (basically once per > browser/engine) pushing the complexity on to end developers however then > means thousands (millions?) of developers have to implement the same code > and deal with the same complexity over and over again. Obviously if there's > an option to avoid any complexity that would be best, but i suspect that's > unlikely to exist :-D > > --Oliver > > > Dmitry > > On Mon, Nov 30, 2009 at 3:08 PM, Geoffrey Garen <ggaren at 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 at lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > > > _______________________________________________ > webkit-dev mailing list > webkit-dev at lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091130/ef329ed2/attachment.html> From oliver at apple.com Mon Nov 30 17:05:55 2009 From: oliver at apple.com (Oliver Hunt) Date: Mon, 30 Nov 2009 17:05:55 -0800 Subject: [webkit-dev] SharedScript/Worker and multiprocess browsers In-Reply-To: <bd8f24d20911301658n158c2d8em77aa5af765dbc70a@mail.gmail.com> References: <bd8f24d20911301658n158c2d8em77aa5af765dbc70a@mail.gmail.com> Message-ID: <F1C8C8EE-1EC8-442C-B687-9118985763D1@apple.com> > Sorry, I think you misunderstand. The way Chrome processes are divided is an implementation detail, but it is an important one. I think it is folly to ignore it when designing web APIs. We'll likely *never* implement APIs that involve cross-process, synchronous script evaluation. We have some experience with that in supporting plugins, and I can tell you that I do not favor it: not just because of implementation complexity but also because of the performance impact it entails. It is wrong to design an API based on architectural decisions of your existing browser -- you should be making decisions based on what the developers actually need. Being hard for the browser to implement is a secondary concern next to being hard for the end developer to use. > The issue being that in regular day to day use such a browser could end up producing behaviour inconsistent with behaviour that of browsers that actually did provide a single shared context -- in effect all users of Global/SharedScript would have to assume that their Global/SharedScript context was not in fact shared. > > This is true, but I don't think it is a big deal. Processes are roughly divided up into browsing units. You start a new browsing unit by opening a new tab and navigating it. By doing so, you are creating a separate world that cannot see other worlds. SharedWorkers (as well as cookies and other storage mechanisms) provide a bridge between these worlds, but window.open and SharedScripts do not (b/c of the script connection they imply). I have a (simple) question: If Global/SharedScript is not guaranteed to be either Global or Shared, what is it trying to accomplish? It's not possible for any developer to use them for shared state as they can't guarantee that a normal user, doing normal things, is not going to end up with distinct instances of this "shared" state. --Oliver -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091130/5815dbbd/attachment.html> From mjs at apple.com Mon Nov 30 17:09:59 2009 From: mjs at apple.com (Maciej Stachowiak) Date: Mon, 30 Nov 2009 17:09:59 -0800 Subject: [webkit-dev] GlobalScript in WebKit In-Reply-To: <5dd9e5c50911301635jcbfb430n445447afc87ae6ed@mail.gmail.com> References: <28040fc60911191935o7dc5c5edndd696ee6c31607ac@mail.gmail.com> <28040fc60911260944h63f0cab0q52256439c11fc46a@mail.gmail.com> <fbbf8c7c0911300955k4b0463afy59ab48fbb70feb3f@mail.gmail.com> <8421EA96-F80B-4CF2-8A68-A6823D510BEA@webkit.org> <5dd9e5c50911301331y5312f646q711e6314cf224a1@mail.gmail.com> <02AA91E5-5FFF-44F3-8E05-1DCC311E9D1A@apple.com> <5dd9e5c50911301358t5b35c30bh9bdc84c3ee095771@mail.gmail.com> <28040fc60911301425g669b7ffeh713989e47a557d2@mail.gmail.com> <Pine.LNX.4.62.0912010010350.2479@hixie.dreamhostps.com> <b902e34a0911301629r3ddc91e3k624f037d86f2a62c@mail.gmail.com> <5dd9e5c50911301635jcbfb430n445447afc87ae6ed@mail.gmail.com> Message-ID: <DAC75C36-51DE-4A60-86D5-0E0F8CF89E56@apple.com> On Nov 30, 2009, at 4:35 PM, Jeremy Orlow wrote: > > To be fair, app developers in general want to do everything > synchronously but we (in standards land) have pushed back very hard > because software research has shown that such interfaces are very > difficult (if not impossible) to parallelize. That's why > SharedScript sidesteps the issue by saying there should be no > parallelism. Which really is a step backwards. Now that I've heard more about it, it seems like SharedScript gives the worst of both worlds by encouraging synchronous coding but potentially still resulting in unexpected parallelism. It seems like for correctness you'd have to write nearly the exact same multiple- instance anti-collision code in your SharedScript that you would in each main document if you didn't have SharedScript. Regards, Maciej From mjs at apple.com Mon Nov 30 17:21:34 2009 From: mjs at apple.com (Maciej Stachowiak) Date: Mon, 30 Nov 2009 17:21:34 -0800 Subject: [webkit-dev] GlobalScript in WebKit In-Reply-To: <DAC75C36-51DE-4A60-86D5-0E0F8CF89E56@apple.com> References: <28040fc60911191935o7dc5c5edndd696ee6c31607ac@mail.gmail.com> <28040fc60911260944h63f0cab0q52256439c11fc46a@mail.gmail.com> <fbbf8c7c0911300955k4b0463afy59ab48fbb70feb3f@mail.gmail.com> <8421EA96-F80B-4CF2-8A68-A6823D510BEA@webkit.org> <5dd9e5c50911301331y5312f646q711e6314cf224a1@mail.gmail.com> <02AA91E5-5FFF-44F3-8E05-1DCC311E9D1A@apple.com> <5dd9e5c50911301358t5b35c30bh9bdc84c3ee095771@mail.gmail.com> <28040fc60911301425g669b7ffeh713989e47a557d2@mail.gmail.com> <Pine.LNX.4.62.0912010010350.2479@hixie.dreamhostps.com> <b902e34a0911301629r3ddc91e3k624f037d86f2a62c@mail.gmail.com> <5dd9e5c50911301635jcbfb430n445447afc87ae6ed@mail.gmail.com> <DAC75C36-51DE-4A60-86D5-0E0F8CF89E56@apple.com> Message-ID: <D71AEEB6-B9B1-439D-A98E-4AFC1683E2CF@apple.com> On Nov 30, 2009, at 5:09 PM, Maciej Stachowiak wrote: > > On Nov 30, 2009, at 4:35 PM, Jeremy Orlow wrote: > >> >> To be fair, app developers in general want to do everything >> synchronously but we (in standards land) have pushed back very hard >> because software research has shown that such interfaces are very >> difficult (if not impossible) to parallelize. That's why >> SharedScript sidesteps the issue by saying there should be no >> parallelism. Which really is a step backwards. > > Now that I've heard more about it, it seems like SharedScript gives > the worst of both worlds by encouraging synchronous coding but > potentially still resulting in unexpected parallelism. It seems like > for correctness you'd have to write nearly the exact same multiple- > instance anti-collision code in your SharedScript that you would in > each main document if you didn't have SharedScript. By the way, we could enable the SharedScript programming model at much lower WebKit-level implementation cost and with much less API surface as follows: - Allow Window to be passed via the structured clone algorithm over a MessageChannel, but it throws on all access if the recipient is not same-origin, in the same thread, and eligible for synchronous calls (i.e. in the same process). I believe this would allow SharedScript to be implemented in JavaScript. Essentially you'd use a SharedWorker to coordinate and elect a leader Window within each same-process group, which could then create a JavaScript object which it vends to all other Windows. The object does not get GC'd until all the referencing windows go away. Regards, Maciej From dimich at chromium.org Mon Nov 30 17:37:06 2009 From: dimich at chromium.org (Dmitry Titov) Date: Mon, 30 Nov 2009 17:37:06 -0800 Subject: [webkit-dev] GlobalScript in WebKit In-Reply-To: <D71AEEB6-B9B1-439D-A98E-4AFC1683E2CF@apple.com> References: <28040fc60911191935o7dc5c5edndd696ee6c31607ac@mail.gmail.com> <5dd9e5c50911301331y5312f646q711e6314cf224a1@mail.gmail.com> <02AA91E5-5FFF-44F3-8E05-1DCC311E9D1A@apple.com> <5dd9e5c50911301358t5b35c30bh9bdc84c3ee095771@mail.gmail.com> <28040fc60911301425g669b7ffeh713989e47a557d2@mail.gmail.com> <Pine.LNX.4.62.0912010010350.2479@hixie.dreamhostps.com> <b902e34a0911301629r3ddc91e3k624f037d86f2a62c@mail.gmail.com> <5dd9e5c50911301635jcbfb430n445447afc87ae6ed@mail.gmail.com> <DAC75C36-51DE-4A60-86D5-0E0F8CF89E56@apple.com> <D71AEEB6-B9B1-439D-A98E-4AFC1683E2CF@apple.com> Message-ID: <28040fc60911301737s28f3f63cl9615267e761e6c7@mail.gmail.com> On Mon, Nov 30, 2009 at 5:21 PM, Maciej Stachowiak <mjs at apple.com> wrote: > By the way, we could enable the SharedScript programming model at much > lower WebKit-level implementation cost and with much less API surface as > follows: > > - Allow Window to be passed via the structured clone algorithm over a > MessageChannel, but it throws on all access if the recipient is not > same-origin, in the same thread, and eligible for synchronous calls (i.e. in > the same process). > > I believe this would allow SharedScript to be implemented in JavaScript. > Essentially you'd use a SharedWorker to coordinate and elect a leader Window > within each same-process group, which could then create a JavaScript object > which it vends to all other Windows. The object does not get GC'd until all > the referencing windows go away. Yep, a variants of this were proposed... One difficulty with this is that while JS object is kept alive, the interesting objects like timers, XHR, WebSockets die once leader Window is closed. Plus, the leader [re]election algorithm should be implemented. It is not impossible to keep track of enough things to fix up the context, but it is way too difficult and error-prone. It sounds like by making it easier with SharedScript we'd remove the burden of those implementations from many web developers. Just connect to it and it provides stable JS context for things to run in. If we go with this, I believe we'll need to follow up with things like making XHR work even if page created it was closed... It might end up being essentially the same as SharedScript itself. Dmitry -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091130/b3d3cb19/attachment.html> From jorlow at chromium.org Mon Nov 30 17:40:19 2009 From: jorlow at chromium.org (Jeremy Orlow) Date: Mon, 30 Nov 2009 17:40:19 -0800 Subject: [webkit-dev] SharedScript/Worker and multiprocess browsers In-Reply-To: <F1C8C8EE-1EC8-442C-B687-9118985763D1@apple.com> References: <bd8f24d20911301658n158c2d8em77aa5af765dbc70a@mail.gmail.com> <F1C8C8EE-1EC8-442C-B687-9118985763D1@apple.com> Message-ID: <5dd9e5c50911301740j56d8653chd3ce0eb143d4a1a1@mail.gmail.com> On Mon, Nov 30, 2009 at 5:05 PM, Oliver Hunt <oliver at apple.com> wrote: > > Sorry, I think you misunderstand. The way Chrome processes are divided is > an implementation detail, but it is an important one. I think it is folly > to ignore it when designing web APIs. We'll likely *never* implement APIs > that involve cross-process, synchronous script evaluation. We have some > experience with that in supporting plugins, and I can tell you that I do not > favor it: not just because of implementation complexity but also because of > the performance impact it entails. > > > It is wrong to design an API based on architectural decisions of your > existing browser -- you should be making decisions based on what the > developers actually need. Being hard for the browser to implement is a > secondary concern next to being hard for the end developer to use. > > The issue being that in regular day to day use such a browser could end >> up producing behaviour inconsistent with behaviour that of browsers that >> actually did provide a single shared context -- in effect all users of >> Global/SharedScript would have to assume that their Global/SharedScript >> context was not in fact shared. >> > > This is true, but I don't think it is a big deal. Processes are roughly > divided up into browsing units. You start a new browsing unit by opening a > new tab and navigating it. By doing so, you are creating a separate world > that cannot see other worlds. SharedWorkers (as well as cookies and other > storage mechanisms) provide a bridge between these worlds, but window.open > and SharedScripts do not (b/c of the script connection they imply). > > > > I have a (simple) question: If Global/SharedScript is not guaranteed to be > either Global or Shared, what is it trying to accomplish? It's not possible > for any developer to use them for shared state as they can't guarantee that > a normal user, doing normal things, is not going to end up with distinct > instances of this "shared" state. > Please look at the use cases in the spec. They're pretty much all an optimization to cut down on resource utilization and load times by sharing more state. As a side note, I would expect that many SharedScript users would also use SharedWorkers for a lot of the non-UI logic including storage and network. Also note that the possibility of having multiple SharedScript instances within one browser is pretty much the same as the possibility of the user having multiple browsers open on the same computer. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091130/fbddbeba/attachment.html> From jorlow at chromium.org Mon Nov 30 17:43:35 2009 From: jorlow at chromium.org (Jeremy Orlow) Date: Mon, 30 Nov 2009 17:43:35 -0800 Subject: [webkit-dev] GlobalScript in WebKit In-Reply-To: <28040fc60911301737s28f3f63cl9615267e761e6c7@mail.gmail.com> References: <28040fc60911191935o7dc5c5edndd696ee6c31607ac@mail.gmail.com> <02AA91E5-5FFF-44F3-8E05-1DCC311E9D1A@apple.com> <5dd9e5c50911301358t5b35c30bh9bdc84c3ee095771@mail.gmail.com> <28040fc60911301425g669b7ffeh713989e47a557d2@mail.gmail.com> <Pine.LNX.4.62.0912010010350.2479@hixie.dreamhostps.com> <b902e34a0911301629r3ddc91e3k624f037d86f2a62c@mail.gmail.com> <5dd9e5c50911301635jcbfb430n445447afc87ae6ed@mail.gmail.com> <DAC75C36-51DE-4A60-86D5-0E0F8CF89E56@apple.com> <D71AEEB6-B9B1-439D-A98E-4AFC1683E2CF@apple.com> <28040fc60911301737s28f3f63cl9615267e761e6c7@mail.gmail.com> Message-ID: <5dd9e5c50911301743s1f1cee98r3f5be3494c5e72e8@mail.gmail.com> On Mon, Nov 30, 2009 at 5:37 PM, Dmitry Titov <dimich at chromium.org> wrote: > On Mon, Nov 30, 2009 at 5:21 PM, Maciej Stachowiak <mjs at apple.com> wrote: > > >> By the way, we could enable the SharedScript programming model at much >> lower WebKit-level implementation cost and with much less API surface as >> follows: >> >> - Allow Window to be passed via the structured clone algorithm over a >> MessageChannel, but it throws on all access if the recipient is not >> same-origin, in the same thread, and eligible for synchronous calls (i.e. in >> the same process). >> >> I believe this would allow SharedScript to be implemented in JavaScript. >> Essentially you'd use a SharedWorker to coordinate and elect a leader Window >> within each same-process group, which could then create a JavaScript object >> which it vends to all other Windows. The object does not get GC'd until all >> the referencing windows go away. > > > Yep, a variants of this were proposed... One difficulty with this is that > while JS object is kept alive, the interesting objects like timers, XHR, > WebSockets die once leader Window is closed. > With the exception of timers, most of these things would also suffer from network errors. I wonder if the same code could be used to recover from them. In addition, everything you mentioned would be a good use case for a SharedWorker since it'd be fairly detached from UI and is async. > Plus, the leader [re]election algorithm should be implemented. It is not > impossible to keep track of enough things to fix up the context, but it is > way too difficult and error-prone. > > It sounds like by making it easier with SharedScript we'd remove the burden > of those implementations from many web developers. Just connect to it and it > provides stable JS context for things to run in. > > If we go with this, I believe we'll need to follow up with things like > making XHR work even if page created it was closed... It might end up being > essentially the same as SharedScript itself. > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091130/5a1839db/attachment.html> From pkasting at google.com Mon Nov 30 17:45:08 2009 From: pkasting at google.com (Peter Kasting) Date: Mon, 30 Nov 2009 17:45:08 -0800 Subject: [webkit-dev] SharedScript/Worker and multiprocess browsers In-Reply-To: <F1C8C8EE-1EC8-442C-B687-9118985763D1@apple.com> References: <bd8f24d20911301658n158c2d8em77aa5af765dbc70a@mail.gmail.com> <F1C8C8EE-1EC8-442C-B687-9118985763D1@apple.com> Message-ID: <d62cf1d10911301745g4a91b27fk9634f068d2533007@mail.gmail.com> On Mon, Nov 30, 2009 at 5:05 PM, Oliver Hunt <oliver at apple.com> wrote: > It is wrong to design an API based on architectural decisions of your > existing browser -- you should be making decisions based on what the > developers actually need. Being hard for the browser to implement is a > secondary concern next to being hard for the end developer to use. > This is an aside that concerns the general point above, not GlobalScript etc. specifically. I agree that in general we should push complexity towards the UA vendor and away from the web author, but your statement is too sweeping. It is certainly relevant to consider the concept of multiprocess browsers when designing APIs. Failing to take that into account at all can lead to APIs which make process separation outright impossible. It's one thing to make implementation somewhat trickier for UA vendors, it's another thing entirely to completely eliminate whole categories of browser architectures in the name of developer simplicity. To give an example of "poor foresight in a spec" from the past, synchronous XHR is convenient for developers in certain circumstances, but I think all implementors recognize that it was a mistake to specify and we'd be better off without it. For a ridiculous hypothetical example, we wouldn't spec an API that required UAs to solve the halting problem. Developer need and convenience should certainly be the prime motivator of APIs, but not the only motivator. PK -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091130/4a4ca088/attachment.html> From levin at chromium.org Mon Nov 30 17:49:17 2009 From: levin at chromium.org (David Levin) Date: Mon, 30 Nov 2009 17:49:17 -0800 Subject: [webkit-dev] GlobalScript in WebKit In-Reply-To: <5dd9e5c50911301743s1f1cee98r3f5be3494c5e72e8@mail.gmail.com> References: <28040fc60911191935o7dc5c5edndd696ee6c31607ac@mail.gmail.com> <5dd9e5c50911301358t5b35c30bh9bdc84c3ee095771@mail.gmail.com> <28040fc60911301425g669b7ffeh713989e47a557d2@mail.gmail.com> <Pine.LNX.4.62.0912010010350.2479@hixie.dreamhostps.com> <b902e34a0911301629r3ddc91e3k624f037d86f2a62c@mail.gmail.com> <5dd9e5c50911301635jcbfb430n445447afc87ae6ed@mail.gmail.com> <DAC75C36-51DE-4A60-86D5-0E0F8CF89E56@apple.com> <D71AEEB6-B9B1-439D-A98E-4AFC1683E2CF@apple.com> <28040fc60911301737s28f3f63cl9615267e761e6c7@mail.gmail.com> <5dd9e5c50911301743s1f1cee98r3f5be3494c5e72e8@mail.gmail.com> Message-ID: <b902e34a0911301749q1647d41cn50f991b105ffef1a@mail.gmail.com> On Mon, Nov 30, 2009 at 5:43 PM, Jeremy Orlow <jorlow at chromium.org> wrote: > In addition, everything you mentioned would be a good use case for a > SharedWorker since it'd be fairly detached from UI and is async. > Is it intentional or unintentional that this misses the point that some logic items is more natural (and doesn't interfere with perf) when done from the main thread? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091130/b4e547a5/attachment.html> From mjs at apple.com Mon Nov 30 17:56:45 2009 From: mjs at apple.com (Maciej Stachowiak) Date: Mon, 30 Nov 2009 17:56:45 -0800 Subject: [webkit-dev] GlobalScript in WebKit In-Reply-To: <28040fc60911301737s28f3f63cl9615267e761e6c7@mail.gmail.com> References: <28040fc60911191935o7dc5c5edndd696ee6c31607ac@mail.gmail.com> <5dd9e5c50911301331y5312f646q711e6314cf224a1@mail.gmail.com> <02AA91E5-5FFF-44F3-8E05-1DCC311E9D1A@apple.com> <5dd9e5c50911301358t5b35c30bh9bdc84c3ee095771@mail.gmail.com> <28040fc60911301425g669b7ffeh713989e47a557d2@mail.gmail.com> <Pine.LNX.4.62.0912010010350.2479@hixie.dreamhostps.com> <b902e34a0911301629r3ddc91e3k624f037d86f2a62c@mail.gmail.com> <5dd9e5c50911301635jcbfb430n445447afc87ae6ed@mail.gmail.com> <DAC75C36-51DE-4A60-86D5-0E0F8CF89E56@apple.com> <D71AEEB6-B9B1-439D-A98E-4AFC1683E2CF@apple.com> <28040fc60911301737s28f3f63cl9615267e761e6c7@mail.gmail.com> Message-ID: <72C59434-6A13-4822-953C-D84527C65F55@apple.com> On Nov 30, 2009, at 5:37 PM, Dmitry Titov wrote: > On Mon, Nov 30, 2009 at 5:21 PM, Maciej Stachowiak <mjs at apple.com> > wrote: > > By the way, we could enable the SharedScript programming model at > much lower WebKit-level implementation cost and with much less API > surface as follows: > > - Allow Window to be passed via the structured clone algorithm over > a MessageChannel, but it throws on all access if the recipient is > not same-origin, in the same thread, and eligible for synchronous > calls (i.e. in the same process). > > I believe this would allow SharedScript to be implemented in > JavaScript. Essentially you'd use a SharedWorker to coordinate and > elect a leader Window within each same-process group, which could > then create a JavaScript object which it vends to all other Windows. > The object does not get GC'd until all the referencing windows go > away. > > Yep, a variants of this were proposed... One difficulty with this is > that while JS object is kept alive, the interesting objects like > timers, XHR, WebSockets die once leader Window is closed. These could all be proxied to a SharedWorker (with callbacks possibly delivered to the current leader window). This would involve some extra cross-thread messaging overhead but would not require restarting when the leader Window is closed. Alternately, JS-level wrappers could be made in which handle changes in the leader window transparently. > Plus, the leader [re]election algorithm should be implemented. It is > not impossible to keep track of enough things to fix up the context, > but it is way too difficult and error-prone. > > It sounds like by making it easier with SharedScript we'd remove the > burden of those implementations from many web developers. Just > connect to it and it provides stable JS context for things to run in. > > If we go with this, I believe we'll need to follow up with things > like making XHR work even if page created it was closed... It might > end up being essentially the same as SharedScript itself. I agree that SharedScript would make things easier on content authors compared to my proposal, in particular, it would save the effort to implement a SharedScript-like environment via a JavaScript library. But for experimental features, prototyping mostly or entirely in JS is a lower-risk approach, since it allows issues to be discovered without risking premature lockin of a feature that doesn't work out. You can even try multiple different approaches at once via different JS libraries. Regards, Maciej P.S. I haven't seen an answer to Hyatt's question about whether SharedScript is intended as a purely experimental feature that doesn't ship enabled in release versions or if it's intended to ship in product. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091130/a2c885bb/attachment.html> From oliver at apple.com Mon Nov 30 17:58:37 2009 From: oliver at apple.com (Oliver Hunt) Date: Mon, 30 Nov 2009 17:58:37 -0800 Subject: [webkit-dev] SharedScript/Worker and multiprocess browsers In-Reply-To: <5dd9e5c50911301740j56d8653chd3ce0eb143d4a1a1@mail.gmail.com> References: <bd8f24d20911301658n158c2d8em77aa5af765dbc70a@mail.gmail.com> <F1C8C8EE-1EC8-442C-B687-9118985763D1@apple.com> <5dd9e5c50911301740j56d8653chd3ce0eb143d4a1a1@mail.gmail.com> Message-ID: <9E7E40CB-C2C8-49B9-8CCD-184169CB37E0@apple.com> On Nov 30, 2009, at 5:40 PM, Jeremy Orlow wrote: > On Mon, Nov 30, 2009 at 5:05 PM, Oliver Hunt <oliver at apple.com> wrote: > >> Sorry, I think you misunderstand. The way Chrome processes are divided is an implementation detail, but it is an important one. I think it is folly to ignore it when designing web APIs. We'll likely *never* implement APIs that involve cross-process, synchronous script evaluation. We have some experience with that in supporting plugins, and I can tell you that I do not favor it: not just because of implementation complexity but also because of the performance impact it entails. > > It is wrong to design an API based on architectural decisions of your existing browser -- you should be making decisions based on what the developers actually need. Being hard for the browser to implement is a secondary concern next to being hard for the end developer to use. > >> The issue being that in regular day to day use such a browser could end up producing behaviour inconsistent with behaviour that of browsers that actually did provide a single shared context -- in effect all users of Global/SharedScript would have to assume that their Global/SharedScript context was not in fact shared. >> >> This is true, but I don't think it is a big deal. Processes are roughly divided up into browsing units. You start a new browsing unit by opening a new tab and navigating it. By doing so, you are creating a separate world that cannot see other worlds. SharedWorkers (as well as cookies and other storage mechanisms) provide a bridge between these worlds, but window.open and SharedScripts do not (b/c of the script connection they imply). > > > I have a (simple) question: If Global/SharedScript is not guaranteed to be either Global or Shared, what is it trying to accomplish? It's not possible for any developer to use them for shared state as they can't guarantee that a normal user, doing normal things, is not going to end up with distinct instances of this "shared" state. > > Please look at the use cases in the spec. They're pretty much all an optimization to cut down on resource utilization and load times by sharing more state. > > As a side note, I would expect that many SharedScript users would also use SharedWorkers for a lot of the non-UI logic including storage and network. > > Also note that the possibility of having multiple SharedScript instances within one browser is pretty much the same as the possibility of the user having multiple browsers open on the same computer. The point i was getting at is that unlike the typical way to get this situation (running multiple browsers) is not a common end user behaviour, but Chrome's model makes it very easy -- as far as I am aware if I open two windows independently and navigate both to example.com i will end up with two processes, thus ending up with two instances of the same SharedScript. I actually just did a quick test, and I am unsure how I can actually open two windows in such a way that Chrome would end up using a single SharedScript instance -- both new window and new tab result in separate processes, the only logical case that would allow multiple windows to end up sharing an instance (and thus gaining any benefit at all from this feature) would be by opening a window from an original source page, in which case an invisible iframe could trivially be passed around, and has all of the advantages of SharedScript, none of the disadvantages, and works in all existing browsers. Has anyone really sat down and compared the use cases given in the spec to the behaviour of users? eg. to see if the model you're talking about would actually provide any real benefit in real world usage --Oliver -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091130/f8d846e6/attachment.html> From mjs at apple.com Mon Nov 30 18:08:11 2009 From: mjs at apple.com (Maciej Stachowiak) Date: Mon, 30 Nov 2009 18:08:11 -0800 Subject: [webkit-dev] GlobalScript in WebKit In-Reply-To: <28040fc60911301543h6868018at5b3dc3a867753647@mail.gmail.com> References: <28040fc60911191935o7dc5c5edndd696ee6c31607ac@mail.gmail.com> <28040fc60911260944h63f0cab0q52256439c11fc46a@mail.gmail.com> <fbbf8c7c0911300955k4b0463afy59ab48fbb70feb3f@mail.gmail.com> <8421EA96-F80B-4CF2-8A68-A6823D510BEA@webkit.org> <5dd9e5c50911301331y5312f646q711e6314cf224a1@mail.gmail.com> <02AA91E5-5FFF-44F3-8E05-1DCC311E9D1A@apple.com> <28040fc60911301405gef7ab6cw4f032b4af37d7f2@mail.gmail.com> <A3C1B706-04F5-4604-B276-E62D76D506B3@webkit.org> <bd8f24d20911301448o131fb481rb19982824b303232@mail.gmail.com> <A37C7280-DFA4-4A3F-8282-1A0002BAC54F@apple.com> <28040fc60911301543h6868018at5b3dc3a867753647@mail.gmail.com> Message-ID: <0D58A65F-5354-4252-806C-599D7F533B31@apple.com> 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 From atwilson at google.com Mon Nov 30 18:11:11 2009 From: atwilson at google.com (Drew Wilson) Date: Mon, 30 Nov 2009 18:11:11 -0800 Subject: [webkit-dev] GlobalScript in WebKit In-Reply-To: <0D58A65F-5354-4252-806C-599D7F533B31@apple.com> References: <28040fc60911191935o7dc5c5edndd696ee6c31607ac@mail.gmail.com> <8421EA96-F80B-4CF2-8A68-A6823D510BEA@webkit.org> <5dd9e5c50911301331y5312f646q711e6314cf224a1@mail.gmail.com> <02AA91E5-5FFF-44F3-8E05-1DCC311E9D1A@apple.com> <28040fc60911301405gef7ab6cw4f032b4af37d7f2@mail.gmail.com> <A3C1B706-04F5-4604-B276-E62D76D506B3@webkit.org> <bd8f24d20911301448o131fb481rb19982824b303232@mail.gmail.com> <A37C7280-DFA4-4A3F-8282-1A0002BAC54F@apple.com> <28040fc60911301543h6868018at5b3dc3a867753647@mail.gmail.com> <0D58A65F-5354-4252-806C-599D7F533B31@apple.com> Message-ID: <f965ae410911301811t60001ec7ia0099f746eb12ec9@mail.gmail.com> 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 <mjs at 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 at lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091130/43b125d6/attachment.html> From jorlow at chromium.org Mon Nov 30 18:16:08 2009 From: jorlow at chromium.org (Jeremy Orlow) Date: Mon, 30 Nov 2009 18:16:08 -0800 Subject: [webkit-dev] SharedScript/Worker and multiprocess browsers In-Reply-To: <9E7E40CB-C2C8-49B9-8CCD-184169CB37E0@apple.com> References: <bd8f24d20911301658n158c2d8em77aa5af765dbc70a@mail.gmail.com> <F1C8C8EE-1EC8-442C-B687-9118985763D1@apple.com> <5dd9e5c50911301740j56d8653chd3ce0eb143d4a1a1@mail.gmail.com> <9E7E40CB-C2C8-49B9-8CCD-184169CB37E0@apple.com> Message-ID: <5dd9e5c50911301816j438cfb71xa5968f86259bc009@mail.gmail.com> On Mon, Nov 30, 2009 at 5:58 PM, Oliver Hunt <oliver at apple.com> wrote: > > On Nov 30, 2009, at 5:40 PM, Jeremy Orlow wrote: > > On Mon, Nov 30, 2009 at 5:05 PM, Oliver Hunt <oliver at apple.com> wrote: > >> >> Sorry, I think you misunderstand. The way Chrome processes are divided is >> an implementation detail, but it is an important one. I think it is folly >> to ignore it when designing web APIs. We'll likely *never* implement APIs >> that involve cross-process, synchronous script evaluation. We have some >> experience with that in supporting plugins, and I can tell you that I do not >> favor it: not just because of implementation complexity but also because of >> the performance impact it entails. >> >> >> It is wrong to design an API based on architectural decisions of your >> existing browser -- you should be making decisions based on what the >> developers actually need. Being hard for the browser to implement is a >> secondary concern next to being hard for the end developer to use. >> >> The issue being that in regular day to day use such a browser could end >>> up producing behaviour inconsistent with behaviour that of browsers that >>> actually did provide a single shared context -- in effect all users of >>> Global/SharedScript would have to assume that their Global/SharedScript >>> context was not in fact shared. >>> >> >> This is true, but I don't think it is a big deal. Processes are roughly >> divided up into browsing units. You start a new browsing unit by opening a >> new tab and navigating it. By doing so, you are creating a separate world >> that cannot see other worlds. SharedWorkers (as well as cookies and other >> storage mechanisms) provide a bridge between these worlds, but window.open >> and SharedScripts do not (b/c of the script connection they imply). >> >> >> >> I have a (simple) question: If Global/SharedScript is not guaranteed to be >> either Global or Shared, what is it trying to accomplish? It's not possible >> for any developer to use them for shared state as they can't guarantee that >> a normal user, doing normal things, is not going to end up with distinct >> instances of this "shared" state. >> > > Please look at the use cases in the spec. They're pretty much all an > optimization to cut down on resource utilization and load times by sharing > more state. > > As a side note, I would expect that many SharedScript users would also > use SharedWorkers for a lot of the non-UI logic including storage and > network. > > Also note that the possibility of having multiple SharedScript instances > within one browser is pretty much the same as the possibility of the user > having multiple browsers open on the same computer. > > The point i was getting at is that unlike the typical way to get this > situation (running multiple browsers) is not a common end user behaviour, > but Chrome's model makes it very easy -- as far as I am aware if I open two > windows independently and navigate both to example.com i will end up with > two processes, thus ending up with two instances of the same SharedScript. > > I actually just did a quick test, and I am unsure how I can actually open > two windows in such a way that Chrome would end up using a single > SharedScript instance -- both new window and new tab result in separate > processes, the only logical case that would allow multiple windows to end up > sharing an instance (and thus gaining any benefit at all from this > feature) would be by opening a window from an original source page, in which > case an invisible iframe could trivially be passed around, and has all of > the advantages of SharedScript, none of the disadvantages, and works in all > existing browsers. > The usage of SharedScript is a strong hint to the browser that future tabs for that origin should be opened in the same process. With such a heuristic, you only run into trouble when a particular origin doesn't immediately use the SharedScript and a user opens up another tab in the mean time. This could be mitigated by the browser saving which origins use SharedScript somewhere. Has anyone really sat down and compared the use cases given in the spec to > the behaviour of users? eg. to see if the model you're talking about would > actually provide any real benefit in real world usage > The spec was co-written by real world users (gmail engineers). -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091130/9b6b4175/attachment.html> From atwilson at google.com Mon Nov 30 18:16:48 2009 From: atwilson at google.com (Drew Wilson) Date: Mon, 30 Nov 2009 18:16:48 -0800 Subject: [webkit-dev] GlobalScript in WebKit In-Reply-To: <f965ae410911301811t60001ec7ia0099f746eb12ec9@mail.gmail.com> References: <28040fc60911191935o7dc5c5edndd696ee6c31607ac@mail.gmail.com> <5dd9e5c50911301331y5312f646q711e6314cf224a1@mail.gmail.com> <02AA91E5-5FFF-44F3-8E05-1DCC311E9D1A@apple.com> <28040fc60911301405gef7ab6cw4f032b4af37d7f2@mail.gmail.com> <A3C1B706-04F5-4604-B276-E62D76D506B3@webkit.org> <bd8f24d20911301448o131fb481rb19982824b303232@mail.gmail.com> <A37C7280-DFA4-4A3F-8282-1A0002BAC54F@apple.com> <28040fc60911301543h6868018at5b3dc3a867753647@mail.gmail.com> <0D58A65F-5354-4252-806C-599D7F533B31@apple.com> <f965ae410911301811t60001ec7ia0099f746eb12ec9@mail.gmail.com> Message-ID: <f965ae410911301816reb7f483j8cee358caffdf69d@mail.gmail.com> 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 <atwilson at 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 <mjs at 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 at lists.webkit.org >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091130/cee19e31/attachment-0001.html> From oliver at apple.com Mon Nov 30 18:31:43 2009 From: oliver at apple.com (Oliver Hunt) Date: Mon, 30 Nov 2009 18:31:43 -0800 Subject: [webkit-dev] SharedScript/Worker and multiprocess browsers In-Reply-To: <5dd9e5c50911301816j438cfb71xa5968f86259bc009@mail.gmail.com> References: <bd8f24d20911301658n158c2d8em77aa5af765dbc70a@mail.gmail.com> <F1C8C8EE-1EC8-442C-B687-9118985763D1@apple.com> <5dd9e5c50911301740j56d8653chd3ce0eb143d4a1a1@mail.gmail.com> <9E7E40CB-C2C8-49B9-8CCD-184169CB37E0@apple.com> <5dd9e5c50911301816j438cfb71xa5968f86259bc009@mail.gmail.com> Message-ID: <79D3D430-4E33-4F39-9E1B-164CB7D22586@apple.com> > I actually just did a quick test, and I am unsure how I can actually open two windows in such a way that Chrome would end up using a single SharedScript instance -- both new window and new tab result in separate processes, the only logical case that would allow multiple windows to end up sharing an instance (and thus gaining any benefit at all from this feature) would be by opening a window from an original source page, in which case an invisible iframe could trivially be passed around, and has all of the advantages of SharedScript, none of the disadvantages, and works in all existing browsers. > > The usage of SharedScript is a strong hint to the browser that future tabs for that origin should be opened in the same process. With such a heuristic, you only run into trouble when a particular origin doesn't immediately use the SharedScript and a user opens up another tab in the mean time. This could be mitigated by the browser saving which origins use SharedScript somewhere. > > Has anyone really sat down and compared the use cases given in the spec to the behaviour of users? eg. to see if the model you're talking about would actually provide any real benefit in real world usage > > The spec was co-written by real world users (gmail engineers). Engineers are not everyday users -- I am not referring to developers (i've been fairly careful in this discussion to not conflate developers with end users), I am referring to actual end users and their interaction with the browser. If a SharedScript is meant to indicate that a new process shouldn't been spawned it seems reasonable to require SharedScripts actually be shared. --Oliver -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091130/787974ad/attachment.html> From creis at chromium.org Mon Nov 30 18:34:38 2009 From: creis at chromium.org (Charles Reis) Date: Mon, 30 Nov 2009 18:34:38 -0800 Subject: [webkit-dev] SharedScript/Worker and multiprocess browsers In-Reply-To: <5dd9e5c50911301816j438cfb71xa5968f86259bc009@mail.gmail.com> References: <bd8f24d20911301658n158c2d8em77aa5af765dbc70a@mail.gmail.com> <F1C8C8EE-1EC8-442C-B687-9118985763D1@apple.com> <5dd9e5c50911301740j56d8653chd3ce0eb143d4a1a1@mail.gmail.com> <9E7E40CB-C2C8-49B9-8CCD-184169CB37E0@apple.com> <5dd9e5c50911301816j438cfb71xa5968f86259bc009@mail.gmail.com> Message-ID: <81c4530c0911301834p5930bbc5me850a7886698c982@mail.gmail.com> On Mon, Nov 30, 2009 at 6:16 PM, Jeremy Orlow <jorlow at chromium.org> wrote: > On Mon, Nov 30, 2009 at 5:58 PM, Oliver Hunt <oliver at apple.com> wrote: > >> >> On Nov 30, 2009, at 5:40 PM, Jeremy Orlow wrote: >> >> On Mon, Nov 30, 2009 at 5:05 PM, Oliver Hunt <oliver at apple.com> wrote: >> >>> >>> Sorry, I think you misunderstand. The way Chrome processes are divided >>> is an implementation detail, but it is an important one. I think it is >>> folly to ignore it when designing web APIs. We'll likely *never* implement >>> APIs that involve cross-process, synchronous script evaluation. We have >>> some experience with that in supporting plugins, and I can tell you that I >>> do not favor it: not just because of implementation complexity but also >>> because of the performance impact it entails. >>> >>> >>> It is wrong to design an API based on architectural decisions of your >>> existing browser -- you should be making decisions based on what the >>> developers actually need. Being hard for the browser to implement is a >>> secondary concern next to being hard for the end developer to use. >>> >>> The issue being that in regular day to day use such a browser could end >>>> up producing behaviour inconsistent with behaviour that of browsers that >>>> actually did provide a single shared context -- in effect all users of >>>> Global/SharedScript would have to assume that their Global/SharedScript >>>> context was not in fact shared. >>>> >>> >>> This is true, but I don't think it is a big deal. Processes are roughly >>> divided up into browsing units. You start a new browsing unit by opening a >>> new tab and navigating it. By doing so, you are creating a separate world >>> that cannot see other worlds. SharedWorkers (as well as cookies and other >>> storage mechanisms) provide a bridge between these worlds, but window.open >>> and SharedScripts do not (b/c of the script connection they imply). >>> >>> >>> >>> I have a (simple) question: If Global/SharedScript is not guaranteed to >>> be either Global or Shared, what is it trying to accomplish? It's not >>> possible for any developer to use them for shared state as they can't >>> guarantee that a normal user, doing normal things, is not going to end up >>> with distinct instances of this "shared" state. >>> >> >> Please look at the use cases in the spec. They're pretty much all an >> optimization to cut down on resource utilization and load times by sharing >> more state. >> >> As a side note, I would expect that many SharedScript users would also >> use SharedWorkers for a lot of the non-UI logic including storage and >> network. >> >> Also note that the possibility of having multiple SharedScript instances >> within one browser is pretty much the same as the possibility of the user >> having multiple browsers open on the same computer. >> >> The point i was getting at is that unlike the typical way to get this >> situation (running multiple browsers) is not a common end user behaviour, >> but Chrome's model makes it very easy -- as far as I am aware if I open two >> windows independently and navigate both to example.com i will end up with >> two processes, thus ending up with two instances of the same SharedScript. >> >> I actually just did a quick test, and I am unsure how I can actually open >> two windows in such a way that Chrome would end up using a single >> SharedScript instance -- both new window and new tab result in separate >> processes, the only logical case that would allow multiple windows to end up >> sharing an instance (and thus gaining any benefit at all from this >> feature) would be by opening a window from an original source page, in which >> case an invisible iframe could trivially be passed around, and has all of >> the advantages of SharedScript, none of the disadvantages, and works in all >> existing browsers. >> > > The usage of SharedScript is a strong hint to the browser that future tabs > for that origin should be opened in the same process. With such a > heuristic, you only run into trouble when a particular origin doesn't > immediately use the SharedScript and a user opens up another tab in the mean > time. This could be mitigated by the browser saving which origins use > SharedScript somewhere. > [from the right email address] Just my two cents, but I don't think the browser's process model should change based on a web site's use of SharedScript. This would end up causing all of the instances of a given web site to share a process, which can have bad implications for responsiveness. (Basically, it eliminates most of the benefits of having a multi-process browser if the user visits a lot of pages from the same site.) I haven't been following the SharedScript discussion closely enough, but I was under the impression that it was mainly targeted at pages opened directly from existing pages. If the user creates separate windows and navigates them to the same site independently, I would argue that those should not share the same SharedScript. Charlie > Has anyone really sat down and compared the use cases given in the spec to >> the behaviour of users? eg. to see if the model you're talking about would >> actually provide any real benefit in real world usage >> > > The spec was co-written by real world users (gmail engineers). > > _______________________________________________ > webkit-dev mailing list > webkit-dev at lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091130/3c4c021f/attachment.html> From jorlow at chromium.org Mon Nov 30 18:47:33 2009 From: jorlow at chromium.org (Jeremy Orlow) Date: Mon, 30 Nov 2009 18:47:33 -0800 Subject: [webkit-dev] SharedScript/Worker and multiprocess browsers In-Reply-To: <79D3D430-4E33-4F39-9E1B-164CB7D22586@apple.com> References: <bd8f24d20911301658n158c2d8em77aa5af765dbc70a@mail.gmail.com> <F1C8C8EE-1EC8-442C-B687-9118985763D1@apple.com> <5dd9e5c50911301740j56d8653chd3ce0eb143d4a1a1@mail.gmail.com> <9E7E40CB-C2C8-49B9-8CCD-184169CB37E0@apple.com> <5dd9e5c50911301816j438cfb71xa5968f86259bc009@mail.gmail.com> <79D3D430-4E33-4F39-9E1B-164CB7D22586@apple.com> Message-ID: <5dd9e5c50911301847v383881dfs747e1a033cc86159@mail.gmail.com> On Mon, Nov 30, 2009 at 6:31 PM, Oliver Hunt <oliver at apple.com> wrote: > > Has anyone really sat down and compared the use cases given in the spec >> to the behaviour of users? eg. to see if the model you're talking about >> would actually provide any real benefit in real world usage >> > > The spec was co-written by real world users (gmail engineers). > > > Engineers are not everyday users -- I am not referring to developers (i've > been fairly careful in this discussion to not conflate developers with end > users), I am referring to actual end users and their interaction with the > browser. If a SharedScript is meant to indicate that a new process > shouldn't been spawned it seems reasonable to require SharedScripts actually > be shared. > The end user benefit is lower latency and resource usage. If you click the link in gmail to tear off a chat window or compose email window there's (very) user noticeable latency. Some of this we can continue to improve with browsers, but it's not easy and it will definitely be a while before an app like gmail can be loaded in 100ish ms (so it's not perceivable). And some (resource sharing) is nearly impossible without help from the app. On Mon, Nov 30, 2009 at 6:34 PM, Charles Reis <creis at chromium.org> wrote: > > The usage of SharedScript is a strong hint to the browser that future >> tabs for that origin should be opened in the same process. With such a >> heuristic, you only run into trouble when a particular origin doesn't >> immediately use the SharedScript and a user opens up another tab in the mean >> time. This could be mitigated by the browser saving which origins use >> SharedScript somewhere. >> > > [from the right email address] > > Just my two cents, but I don't think the browser's process model should > change based on a web site's use of SharedScript. This would end up causing > all of the instances of a given web site to share a process, which can have > bad implications for responsiveness. (Basically, it eliminates most of the > benefits of having a multi-process browser if the user visits a lot of pages > from the same site.) > > I haven't been following the SharedScript discussion closely enough, but I > was under the impression that it was mainly targeted at pages opened > directly from existing pages. If the user creates separate windows and > navigates them to the same site independently, I would argue that those > should not share the same SharedScript. > The main purpose of SharedScript is to make web apps more single threaded (and thus able to share more state). Besides the whole site crashing when one tab of it crashes, I don't really see any problem with having the whole app in the same process....that's essentially what's being asked of us. If we're only targeting opening new windows via script, then there's really no reason to do SharedScript since the windows can already access each other. You can even do clever things so that children of children still can communicate even if one of the middle nodes gets closed. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091130/02fc3811/attachment.html> From mpd at google.com Mon Nov 30 19:13:24 2009 From: mpd at google.com (Michael Davidson) Date: Mon, 30 Nov 2009 19:13:24 -0800 Subject: [webkit-dev] GlobalScript in WebKit In-Reply-To: <f965ae410911301816reb7f483j8cee358caffdf69d@mail.gmail.com> References: <28040fc60911191935o7dc5c5edndd696ee6c31607ac@mail.gmail.com> <02AA91E5-5FFF-44F3-8E05-1DCC311E9D1A@apple.com> <28040fc60911301405gef7ab6cw4f032b4af37d7f2@mail.gmail.com> <A3C1B706-04F5-4604-B276-E62D76D506B3@webkit.org> <bd8f24d20911301448o131fb481rb19982824b303232@mail.gmail.com> <A37C7280-DFA4-4A3F-8282-1A0002BAC54F@apple.com> <28040fc60911301543h6868018at5b3dc3a867753647@mail.gmail.com> <0D58A65F-5354-4252-806C-599D7F533B31@apple.com> <f965ae410911301811t60001ec7ia0099f746eb12ec9@mail.gmail.com> <f965ae410911301816reb7f483j8cee358caffdf69d@mail.gmail.com> Message-ID: <63c0fecb0911301913y4b17bbedv7f433ce498520a82@mail.gmail.com> Hi folks - I'm one of the Gmail engineers who worked on the SharedScript proposal. I thought I'd jump in and give my perspective as a developer. The thread has gotten a little broad, so apologies if I miss something. It seems to me there are a few separate questions being discussed: 1) In isolation, is SharedScript a good idea? People seem neutral-to-positive, so I won't spend time addressing this. It's clearly something that would be useful. There are open questions about how it works with Chrome's process model, but I think that's mostly just implementation details. In a world where SharedWorkers never existed, I think people would be jumping on this. 2) Given that WebKit has committed to supporting SharedWorkers, is SharedScript a good idea? I think so. Background processing and sharing are orthogonal. It seems odd to me to require the former to get the latter. The problems that Drew pointed out upthread are real. Putting UI code in a SharedWorker is not feasible. Web apps are event driven. The user does something, the app responds by looking at its data and updating the UI. Introducing an async seam in between those operations is extremely difficult. I'm unaware of a UI framework that forces that programming model on developers. (I believe that Cocoa is the same - one UI thread that pumps messages, and new threads are only spawned at the developer's request. All we want is to have multiple windows that can work like that!) It's not that the cost of migrating Gmail to such a model would be high (although it would). The amount of code that we have that deals with the UI and needs to look at our shared state is huge. Sharing that code *and* the data model across windows would be a big win for Gmail latency. 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 <atwilson at 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 <atwilson at 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 <mjs at 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 at lists.webkit.org >>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >>> >> >> > > _______________________________________________ > webkit-dev mailing list > webkit-dev at lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091130/924471ee/attachment.html> From mjs at apple.com Mon Nov 30 19:55:53 2009 From: mjs at apple.com (Maciej Stachowiak) Date: Mon, 30 Nov 2009 19:55:53 -0800 Subject: [webkit-dev] GlobalScript in WebKit In-Reply-To: <f965ae410911301816reb7f483j8cee358caffdf69d@mail.gmail.com> References: <28040fc60911191935o7dc5c5edndd696ee6c31607ac@mail.gmail.com> <5dd9e5c50911301331y5312f646q711e6314cf224a1@mail.gmail.com> <02AA91E5-5FFF-44F3-8E05-1DCC311E9D1A@apple.com> <28040fc60911301405gef7ab6cw4f032b4af37d7f2@mail.gmail.com> <A3C1B706-04F5-4604-B276-E62D76D506B3@webkit.org> <bd8f24d20911301448o131fb481rb19982824b303232@mail.gmail.com> <A37C7280-DFA4-4A3F-8282-1A0002BAC54F@apple.com> <28040fc60911301543h6868018at5b3dc3a867753647@mail.gmail.com> <0D58A65F-5354-4252-806C-599D7F533B31@apple.com> <f965ae410911301811t60001ec7ia0099f746eb12ec9@mail.gmail.com> <f965ae410911301816reb7f483j8cee358caffdf69d@mail.gmail.com> Message-ID: <47AD6703-CF30-45C3-B0D8-E37871CD20CD@apple.com> On Nov 30, 2009, at 6:16 PM, Drew Wilson 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. Would it be fair to say the goal for SharedScript is just to share code and data (to reduce memory use of multiple instances of GMail), and not network connections, timers, or other APIs based on async callbacks (assuming those either remain per-Window or are in the SharedWorker)? If so, then it would pretty much completely be handled by sharing of some arbitrary JavaScript object, possibly arranged by SharedWorker. Sharing an out-of-document HTMLIFrameElement would almost even account for timers and the like, except that currently in WebKit a frame's Window does not exist and its contents are not loaded if the frame is not rendered. - Maciej > > -atw > > On Mon, Nov 30, 2009 at 6:11 PM, Drew Wilson <atwilson at 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 <mjs at 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 at lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091130/2ff1ee24/attachment.html> From mjs at apple.com Mon Nov 30 20:08:18 2009 From: mjs at apple.com (Maciej Stachowiak) Date: Mon, 30 Nov 2009 20:08:18 -0800 Subject: [webkit-dev] GlobalScript in WebKit In-Reply-To: <63c0fecb0911301913y4b17bbedv7f433ce498520a82@mail.gmail.com> References: <28040fc60911191935o7dc5c5edndd696ee6c31607ac@mail.gmail.com> <02AA91E5-5FFF-44F3-8E05-1DCC311E9D1A@apple.com> <28040fc60911301405gef7ab6cw4f032b4af37d7f2@mail.gmail.com> <A3C1B706-04F5-4604-B276-E62D76D506B3@webkit.org> <bd8f24d20911301448o131fb481rb19982824b303232@mail.gmail.com> <A37C7280-DFA4-4A3F-8282-1A0002BAC54F@apple.com> <28040fc60911301543h6868018at5b3dc3a867753647@mail.gmail.com> <0D58A65F-5354-4252-806C-599D7F533B31@apple.com> <f965ae410911301811t60001ec7ia0099f746eb12ec9@mail.gmail.com> <f965ae410911301816reb7f483j8cee358caffdf69d@mail.gmail.com> <63c0fecb0911301913y4b17bbedv7f433ce498520a82@mail.gmail.com> Message-ID: <68CBBA20-D07D-47A3-BF2E-5D60DBD89684@apple.com> Hi Michael, On Nov 30, 2009, at 7:13 PM, Michael Davidson wrote: > Hi folks - > > I'm one of the Gmail engineers who worked on the SharedScript > proposal. I thought I'd jump in and give my perspective as a > developer. Thanks a lot for sharing your perspective. Hearing it directly is helpful. Would you be willing to share your thoughts with one of the standards mailing lists? One of our concerns is the apparent skepticism of other browser implementors towards this idea. > > The thread has gotten a little broad, so apologies if I miss > something. It seems to me there are a few separate questions being > discussed: > > 1) In isolation, is SharedScript a good idea? > > People seem neutral-to-positive, so I won't spend time addressing > this. It's clearly something that would be useful. There are open > questions about how it works with Chrome's process model, but I > think that's mostly just implementation details. In a world where > SharedWorkers never existed, I think people would be jumping on this. Always-shared vs. opportunistically-sometimes-shared seems like a big difference, more than just implementation details. It has a direct impact on how to correctly author content using this mechanism. > > 2) Given that WebKit has committed to supporting SharedWorkers, is > SharedScript a good idea? > > I think so. Background processing and sharing are orthogonal. It > seems odd to me to require the former to get the latter. > > The problems that Drew pointed out upthread are real. Putting UI > code in a SharedWorker is not feasible. Web apps are event driven. > The user does something, the app responds by looking at its data and > updating the UI. Introducing an async seam in between those > operations is extremely difficult. I'm unaware of a UI framework > that forces that programming model on developers. (I believe that > Cocoa is the same - one UI thread that pumps messages, and new > threads are only spawned at the developer's request. All we want is > to have multiple windows that can work like that!) It's not that the > cost of migrating Gmail to such a model would be high (although it > would). The amount of code that we have that deals with the UI and > needs to look at our shared state is huge. Sharing that code *and* > the data model across windows would be a big win for Gmail latency. Are you concerned mainly about users opening a brand new additional GMail window with some already open, or cases of windows created by an original GMail window, like the tear-off chat window? (I ask because windows with a pre-existing relationship like parent/opener could already share code and data if they chose to, without any new browser features. Just pass the functions or objects of your choice to the newly opened window. Even if this is only part of what you are interested in, it could be an easy way to prototype this programming model and quantify the benefits in terms of speed and memory use. Or if you've tried that experiment already, it would be useful to hear the results. I'm guessing it's not in production GMail since tearing off a chat window is fairly slow and shows a progress bar.) - 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 <atwilson at 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 <atwilson at 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 <mjs at 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 at lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > > > _______________________________________________ > webkit-dev mailing list > webkit-dev at lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > > _______________________________________________ > webkit-dev mailing list > webkit-dev at lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091130/ab336360/attachment.html> From darin at chromium.org Mon Nov 30 20:23:51 2009 From: darin at chromium.org (Darin Fisher) Date: Mon, 30 Nov 2009 20:23:51 -0800 Subject: [webkit-dev] SharedScript/Worker and multiprocess browsers In-Reply-To: <81c4530c0911301834p5930bbc5me850a7886698c982@mail.gmail.com> References: <bd8f24d20911301658n158c2d8em77aa5af765dbc70a@mail.gmail.com> <F1C8C8EE-1EC8-442C-B687-9118985763D1@apple.com> <5dd9e5c50911301740j56d8653chd3ce0eb143d4a1a1@mail.gmail.com> <9E7E40CB-C2C8-49B9-8CCD-184169CB37E0@apple.com> <5dd9e5c50911301816j438cfb71xa5968f86259bc009@mail.gmail.com> <81c4530c0911301834p5930bbc5me850a7886698c982@mail.gmail.com> Message-ID: <bd8f24d20911302023g47505704mf180a48157b4c533@mail.gmail.com> On Mon, Nov 30, 2009 at 6:34 PM, Charles Reis <creis at chromium.org> wrote: > > > On Mon, Nov 30, 2009 at 6:16 PM, Jeremy Orlow <jorlow at chromium.org> wrote: > >> On Mon, Nov 30, 2009 at 5:58 PM, Oliver Hunt <oliver at apple.com> wrote: >> >>> >>> On Nov 30, 2009, at 5:40 PM, Jeremy Orlow wrote: >>> >>> On Mon, Nov 30, 2009 at 5:05 PM, Oliver Hunt <oliver at apple.com> wrote: >>> >>>> >>>> Sorry, I think you misunderstand. The way Chrome processes are divided >>>> is an implementation detail, but it is an important one. I think it is >>>> folly to ignore it when designing web APIs. We'll likely *never* implement >>>> APIs that involve cross-process, synchronous script evaluation. We have >>>> some experience with that in supporting plugins, and I can tell you that I >>>> do not favor it: not just because of implementation complexity but also >>>> because of the performance impact it entails. >>>> >>>> >>>> It is wrong to design an API based on architectural decisions of your >>>> existing browser -- you should be making decisions based on what the >>>> developers actually need. Being hard for the browser to implement is a >>>> secondary concern next to being hard for the end developer to use. >>>> >>>> The issue being that in regular day to day use such a browser could >>>>> end up producing behaviour inconsistent with behaviour that of browsers that >>>>> actually did provide a single shared context -- in effect all users of >>>>> Global/SharedScript would have to assume that their Global/SharedScript >>>>> context was not in fact shared. >>>>> >>>> >>>> This is true, but I don't think it is a big deal. Processes are roughly >>>> divided up into browsing units. You start a new browsing unit by opening a >>>> new tab and navigating it. By doing so, you are creating a separate world >>>> that cannot see other worlds. SharedWorkers (as well as cookies and other >>>> storage mechanisms) provide a bridge between these worlds, but window.open >>>> and SharedScripts do not (b/c of the script connection they imply). >>>> >>>> >>>> >>>> I have a (simple) question: If Global/SharedScript is not guaranteed to >>>> be either Global or Shared, what is it trying to accomplish? It's not >>>> possible for any developer to use them for shared state as they can't >>>> guarantee that a normal user, doing normal things, is not going to end up >>>> with distinct instances of this "shared" state. >>>> >>> >>> Please look at the use cases in the spec. They're pretty much all an >>> optimization to cut down on resource utilization and load times by sharing >>> more state. >>> >>> As a side note, I would expect that many SharedScript users would also >>> use SharedWorkers for a lot of the non-UI logic including storage and >>> network. >>> >>> Also note that the possibility of having multiple SharedScript instances >>> within one browser is pretty much the same as the possibility of the user >>> having multiple browsers open on the same computer. >>> >>> The point i was getting at is that unlike the typical way to get this >>> situation (running multiple browsers) is not a common end user behaviour, >>> but Chrome's model makes it very easy -- as far as I am aware if I open two >>> windows independently and navigate both to example.com i will end up >>> with two processes, thus ending up with two instances of the same >>> SharedScript. >>> >>> I actually just did a quick test, and I am unsure how I can actually open >>> two windows in such a way that Chrome would end up using a single >>> SharedScript instance -- both new window and new tab result in separate >>> processes, the only logical case that would allow multiple windows to end up >>> sharing an instance (and thus gaining any benefit at all from this >>> feature) would be by opening a window from an original source page, in which >>> case an invisible iframe could trivially be passed around, and has all of >>> the advantages of SharedScript, none of the disadvantages, and works in all >>> existing browsers. >>> >> >> The usage of SharedScript is a strong hint to the browser that future tabs >> for that origin should be opened in the same process. With such a >> heuristic, you only run into trouble when a particular origin doesn't >> immediately use the SharedScript and a user opens up another tab in the mean >> time. This could be mitigated by the browser saving which origins use >> SharedScript somewhere. >> > > [from the right email address] > > Just my two cents, but I don't think the browser's process model should > change based on a web site's use of SharedScript. This would end up causing > all of the instances of a given web site to share a process, which can have > bad implications for responsiveness. (Basically, it eliminates most of the > benefits of having a multi-process browser if the user visits a lot of pages > from the same site.) > > I haven't been following the SharedScript discussion closely enough, but I > was under the impression that it was mainly targeted at pages opened > directly from existing pages. If the user creates separate windows and > navigates them to the same site independently, I would argue that those > should not share the same SharedScript. > > Charlie > +1 Oliver, please re-review the use cases in the document. You'll see that they are primarily concerned with apps that spawn a window from an existing window. I believe it is desirable to support allowing spawned windows to out-live the original window, which is why a hidden iframe doesn't work. The unit-of-related-browsing-contexts scoping seems plenty useful to me. I don't think it is necessary for SharedScript to solve all of the use cases of SharedWorker. (I think the names of these things are confusing matters.) Finally, the scoping being promoting here for SharedScript matches the scoping Chrome implements for window.open(name...) / window.name. That is similarly restricted to a WebKit process because we do not want to support synchronous scripting across processes. Regards, -Darin > > >> Has anyone really sat down and compared the use cases given in the spec to >>> the behaviour of users? eg. to see if the model you're talking about would >>> actually provide any real benefit in real world usage >>> >> >> The spec was co-written by real world users (gmail engineers). >> >> _______________________________________________ >> webkit-dev mailing list >> webkit-dev at lists.webkit.org >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >> >> > > _______________________________________________ > webkit-dev mailing list > webkit-dev at lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091130/5611ed31/attachment.html> From jorlow at chromium.org Mon Nov 30 20:26:36 2009 From: jorlow at chromium.org (Jeremy Orlow) Date: Mon, 30 Nov 2009 20:26:36 -0800 Subject: [webkit-dev] GlobalScript in WebKit In-Reply-To: <47AD6703-CF30-45C3-B0D8-E37871CD20CD@apple.com> References: <28040fc60911191935o7dc5c5edndd696ee6c31607ac@mail.gmail.com> <28040fc60911301405gef7ab6cw4f032b4af37d7f2@mail.gmail.com> <A3C1B706-04F5-4604-B276-E62D76D506B3@webkit.org> <bd8f24d20911301448o131fb481rb19982824b303232@mail.gmail.com> <A37C7280-DFA4-4A3F-8282-1A0002BAC54F@apple.com> <28040fc60911301543h6868018at5b3dc3a867753647@mail.gmail.com> <0D58A65F-5354-4252-806C-599D7F533B31@apple.com> <f965ae410911301811t60001ec7ia0099f746eb12ec9@mail.gmail.com> <f965ae410911301816reb7f483j8cee358caffdf69d@mail.gmail.com> <47AD6703-CF30-45C3-B0D8-E37871CD20CD@apple.com> Message-ID: <5dd9e5c50911302026x4696dacj98d4564399e5fb2f@mail.gmail.com> On Mon, Nov 30, 2009 at 7:55 PM, Maciej Stachowiak <mjs at apple.com> wrote: > > On Nov 30, 2009, at 6:16 PM, Drew Wilson 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. > > > Would it be fair to say the goal for SharedScript is just to share code and > data (to reduce memory use of multiple instances of GMail), and not network > connections, timers, or other APIs based on async callbacks (assuming those > either remain per-Window or are in the SharedWorker)? > I believe this is one of the main points we're not all agreeing about (even within Google). I believe Dave Levin and Michael Davidson are saying that network connections, timers, etc would be useful within a global context that's not shared among multiple pages (like SharedScript). I've argued that it's not that big of a leap to do storage and network access from a shared worker since it's async anyway, but I've never worked on a web app of GMail's scope.... But even if you subscribe to the idea that network connections, storage, etc should be done in shared workers because they're async anyway, it seems as though there might be use cases for timers being shared between pages since they often drive things that are directly related to the UI. A (weak) example would be blinking chat windows that are on multiple pages. If so, then it would pretty much completely be handled by sharing of some > arbitrary JavaScript object, possibly arranged by SharedWorker. > > Sharing an out-of-document HTMLIFrameElement would almost even account for > timers and the like, except that currently in WebKit a frame's Window does > not exist and its contents are not loaded if the frame is not rendered. > > - Maciej > > > -atw > > On Mon, Nov 30, 2009 at 6:11 PM, Drew Wilson <atwilson at 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 <mjs at 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 at lists.webkit.org >>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >>> >> >> > > > _______________________________________________ > webkit-dev mailing list > webkit-dev at lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091130/82c6d986/attachment.html> From darin at chromium.org Mon Nov 30 20:28:12 2009 From: darin at chromium.org (Darin Fisher) Date: Mon, 30 Nov 2009 20:28:12 -0800 Subject: [webkit-dev] SharedScript/Worker and multiprocess browsers In-Reply-To: <d62cf1d10911301745g4a91b27fk9634f068d2533007@mail.gmail.com> References: <bd8f24d20911301658n158c2d8em77aa5af765dbc70a@mail.gmail.com> <F1C8C8EE-1EC8-442C-B687-9118985763D1@apple.com> <d62cf1d10911301745g4a91b27fk9634f068d2533007@mail.gmail.com> Message-ID: <bd8f24d20911302028v6de21a0ck2c8175583cd4644a@mail.gmail.com> On Mon, Nov 30, 2009 at 5:45 PM, Peter Kasting <pkasting at google.com> wrote: > On Mon, Nov 30, 2009 at 5:05 PM, Oliver Hunt <oliver at apple.com> wrote: > >> It is wrong to design an API based on architectural decisions of your >> existing browser -- you should be making decisions based on what the >> developers actually need. Being hard for the browser to implement is a >> secondary concern next to being hard for the end developer to use. >> > > This is an aside that concerns the general point above, not GlobalScript > etc. specifically. > > I agree that in general we should push complexity towards the UA vendor and > away from the web author, but your statement is too sweeping. It is > certainly relevant to consider the concept of multiprocess browsers when > designing APIs. Failing to take that into account at all can lead to APIs > which make process separation outright impossible. It's one thing to make > implementation somewhat trickier for UA vendors, it's another thing entirely > to completely eliminate whole categories of browser architectures in the > name of developer simplicity. > > To give an example of "poor foresight in a spec" from the past, synchronous > XHR is convenient for developers in certain circumstances, but I think all > implementors recognize that it was a mistake to specify and we'd be better > off without it. For a ridiculous hypothetical example, we wouldn't spec an > API that required UAs to solve the halting problem. Developer need and > convenience should certainly be the prime motivator of APIs, but not the > only motivator. > > PK > +1 "Being hard for the browser to implement is a secondary concern" ^^^ Oliver, you are ignoring my assertion that it is not just about simplicity of implementation but also about the poor performance of the result. You negate much of the performance benefits of a multi-threaded architecture if you force the threads to run interlocked (required to enforce run-to-completion semantics). -Darin -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091130/c7d7ced6/attachment.html> From darin at chromium.org Mon Nov 30 20:31:28 2009 From: darin at chromium.org (Darin Fisher) Date: Mon, 30 Nov 2009 20:31:28 -0800 Subject: [webkit-dev] GlobalScript in WebKit In-Reply-To: <47AD6703-CF30-45C3-B0D8-E37871CD20CD@apple.com> References: <28040fc60911191935o7dc5c5edndd696ee6c31607ac@mail.gmail.com> <28040fc60911301405gef7ab6cw4f032b4af37d7f2@mail.gmail.com> <A3C1B706-04F5-4604-B276-E62D76D506B3@webkit.org> <bd8f24d20911301448o131fb481rb19982824b303232@mail.gmail.com> <A37C7280-DFA4-4A3F-8282-1A0002BAC54F@apple.com> <28040fc60911301543h6868018at5b3dc3a867753647@mail.gmail.com> <0D58A65F-5354-4252-806C-599D7F533B31@apple.com> <f965ae410911301811t60001ec7ia0099f746eb12ec9@mail.gmail.com> <f965ae410911301816reb7f483j8cee358caffdf69d@mail.gmail.com> <47AD6703-CF30-45C3-B0D8-E37871CD20CD@apple.com> Message-ID: <bd8f24d20911302031r302d2b11s95533ee9de9db499@mail.gmail.com> On Mon, Nov 30, 2009 at 7:55 PM, Maciej Stachowiak <mjs at apple.com> wrote: > > On Nov 30, 2009, at 6:16 PM, Drew Wilson 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. > > > Would it be fair to say the goal for SharedScript is just to share code and > data (to reduce memory use of multiple instances of GMail), and not network > connections, timers, or other APIs based on async callbacks (assuming those > either remain per-Window or are in the SharedWorker)? If so, then it would > pretty much completely be handled by sharing of some arbitrary JavaScript > object, possibly arranged by SharedWorker. > > Sharing an out-of-document HTMLIFrameElement would almost even account for > timers and the like, except that currently in WebKit a frame's Window does > not exist and its contents are not loaded if the frame is not rendered. > XHRs also don't work after the frame has been unloaded. -Darin > > - Maciej > > > -atw > > On Mon, Nov 30, 2009 at 6:11 PM, Drew Wilson <atwilson at 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 <mjs at 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 at lists.webkit.org >>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >>> >> >> > > > _______________________________________________ > webkit-dev mailing list > webkit-dev at lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091130/ba9dc8a4/attachment.html> From oliver at apple.com Mon Nov 30 20:52:38 2009 From: oliver at apple.com (Oliver Hunt) Date: Mon, 30 Nov 2009 20:52:38 -0800 Subject: [webkit-dev] GlobalScript in WebKit In-Reply-To: <bd8f24d20911302031r302d2b11s95533ee9de9db499@mail.gmail.com> References: <28040fc60911191935o7dc5c5edndd696ee6c31607ac@mail.gmail.com> <28040fc60911301405gef7ab6cw4f032b4af37d7f2@mail.gmail.com> <A3C1B706-04F5-4604-B276-E62D76D506B3@webkit.org> <bd8f24d20911301448o131fb481rb19982824b303232@mail.gmail.com> <A37C7280-DFA4-4A3F-8282-1A0002BAC54F@apple.com> <28040fc60911301543h6868018at5b3dc3a867753647@mail.gmail.com> <0D58A65F-5354-4252-806C-599D7F533B31@apple.com> <f965ae410911301811t60001ec7ia0099f746eb12ec9@mail.gmail.com> <f965ae410911301816reb7f483j8cee358caffdf69d@mail.gmail.com> <47AD6703-CF30-45C3-B0D8-E37871CD20CD@apple.com> <bd8f24d20911302031r302d2b11s95533ee9de9db499@mail.gmail.com> Message-ID: <8148A44B-6DBC-4CDD-BBA3-74D38E033D01@apple.com> On Nov 30, 2009, at 8:31 PM, Darin Fisher wrote: > > > On Mon, Nov 30, 2009 at 7:55 PM, Maciej Stachowiak <mjs at apple.com> wrote: > > On Nov 30, 2009, at 6:16 PM, Drew Wilson 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. > > Would it be fair to say the goal for SharedScript is just to share code and data (to reduce memory use of multiple instances of GMail), and not network connections, timers, or other APIs based on async callbacks (assuming those either remain per-Window or are in the SharedWorker)? If so, then it would pretty much completely be handled by sharing of some arbitrary JavaScript object, possibly arranged by SharedWorker. > > Sharing an out-of-document HTMLIFrameElement would almost even account for timers and the like, except that currently in WebKit a frame's Window does not exist and its contents are not loaded if the frame is not rendered. > > XHRs also don't work after the frame has been unloaded. I think my primary concern is that the use of _Shared_ or _Global_ in the name implies behaviour similar to that of SharedWorker, which is not guaranteed, likewise origin based object lifetime can trivially result in differences in behaviour between browser (which when coupled with the naming issue) could easily become a headache for developers. It seems that what is really wanted is a Worker context that isn't actually a separate thread, so avoiding the need for postMessage, and have it be explicitly instantiated so as to avoid any browser-architecture derived behavioural differences. eg. var mySharedContext = new SharableScriptContext("script to load here?"); mySharedContext.onload = function() { doStuff(); } // or should it be // mySharedContext.src = "script to load here?" Later on: function doSomethingCoolThatNeedsANewWindow() { var win = window.open(...); win.onload = function() { win.functionThatTakesScriptContext(mySharedContext); } } // Note handling the passing of the shared context is entirely developer defined -- eg. the only spec behaviour is the 'new SharableScriptContext' everything else is whatever the developers wants // Note 2: I am truly awful at naming things so these names are mostly chosen to clarify unambiguously-ish what i believe the goal is The downside is that it requires manually passing the context to new windows, the plus side is that it doesn't provide (or imply) behaviour that may be ('necessarily') different between UAs. --Oliver > > -Darin -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091130/7f79e7cf/attachment-0001.html> From darin at chromium.org Mon Nov 30 21:07:11 2009 From: darin at chromium.org (Darin Fisher) Date: Mon, 30 Nov 2009 21:07:11 -0800 Subject: [webkit-dev] SharableScriptContext [was: GlobalScript in WebKit] Message-ID: <bd8f24d20911302107v50c04915h428c2c52de900c@mail.gmail.com> On Mon, Nov 30, 2009 at 8:52 PM, Oliver Hunt <oliver at apple.com> wrote: > > On Nov 30, 2009, at 8:31 PM, Darin Fisher wrote: > > > > On Mon, Nov 30, 2009 at 7:55 PM, Maciej Stachowiak <mjs at apple.com> wrote: > >> >> On Nov 30, 2009, at 6:16 PM, Drew Wilson 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. >> >> >> Would it be fair to say the goal for SharedScript is just to share code >> and data (to reduce memory use of multiple instances of GMail), and not >> network connections, timers, or other APIs based on async callbacks >> (assuming those either remain per-Window or are in the SharedWorker)? If so, >> then it would pretty much completely be handled by sharing of some arbitrary >> JavaScript object, possibly arranged by SharedWorker. >> >> Sharing an out-of-document HTMLIFrameElement would almost even account for >> timers and the like, except that currently in WebKit a frame's Window does >> not exist and its contents are not loaded if the frame is not rendered. >> > > XHRs also don't work after the frame has been unloaded. > > > I think my primary concern is that the use of _Shared_ or _Global_ in the > name implies behaviour similar to that of SharedWorker, which is not > guaranteed, likewise origin based object lifetime can trivially result in > differences in behaviour between browser (which when coupled with the naming > issue) could easily become a headache for developers. > > It seems that what is really wanted is a Worker context that isn't actually > a separate thread, so avoiding the need for postMessage, and have it be > explicitly instantiated so as to avoid any browser-architecture derived > behavioural differences. eg. > > var mySharedContext = new SharableScriptContext("script to load here?"); > mySharedContext.onload = function() { > doStuff(); > } > // or should it be > // mySharedContext.src = "script to load here?" > > Later on: > function doSomethingCoolThatNeedsANewWindow() { > var win = window.open(...); > win.onload = function() { > win.functionThatTakesScriptContext(mySharedContext); > } > } > > // Note handling the passing of the shared context is entirely developer > defined -- eg. the only spec behaviour is the 'new SharableScriptContext' > everything else is whatever the developers wants > // Note 2: I am truly awful at naming things so these names are mostly > chosen to clarify unambiguously-ish what i believe the goal is > > The downside is that it requires manually passing the context to new > windows, the plus side is that it doesn't provide (or imply) behaviour that > may be ('necessarily') different between UAs. > > --Oliver > > This seems pretty compelling to me. I think if we also had a function like window.getWindowByName(name), then we could support the use case of a newly opened window connecting to an existing window to get access to an existing SharableScriptContext. (To further support sharing from a newly opened window, perhaps it would be interesting if application manifests could be leveraged to identify URLs that should be loaded in the same browsing context.) -Darin -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091130/30464bdc/attachment.html> From darin at chromium.org Mon Nov 30 22:23:43 2009 From: darin at chromium.org (Darin Fisher) Date: Mon, 30 Nov 2009 22:23:43 -0800 Subject: [webkit-dev] SharableScriptContext [was: GlobalScript in WebKit] In-Reply-To: <28040fc60911302212w7a3e784uaaccbee18076cf54@mail.gmail.com> References: <bd8f24d20911302107v50c04915h428c2c52de900c@mail.gmail.com> <28040fc60911302212w7a3e784uaaccbee18076cf54@mail.gmail.com> Message-ID: <bd8f24d20911302223h20b4b107gc4be90e4c2185ef1@mail.gmail.com> On Mon, Nov 30, 2009 at 10:12 PM, Dmitry Titov <dimich at google.com> wrote: > At first look, this would solve same use cases as SharedScript. The > difference is that it has to be passed to participating windows > explicitly. Summing up, just for reference: > > var mySharedScriptContext = new SharedScriptContext("foo.js"); > mySharedScriptContext.onload = ...; > > later: > var win = window.open(...); > win.functionThatTakesSharedScriptContext(mySharedScriptContext); > > alternatively, later: > var win = window.getWindowByName("foo"); // does not create a window if > there is no "foo", searches in same process > if (win) > win.functionThatTakesSharedScriptContext(mySharedScriptContext); > actually, you'd use this like so: var mySharedScriptContext; var win = window.getWindowByName("foo"); // does not create a window if there is no "foo", searches in same process if (win) mySharedScriptContext = win.functionThatReturnsSharedScriptContext(); if (!mySharedScriptContext) { mySharedScriptContext = new SharedScriptContext("foo.js"); ... } In other words, getWindowByName becomes a tool that you can use to locate existing windows in your application so that you can get access to the already constructed shared script context. > > and, possibly: add a list (regexp?) to App Cache manifest to describe the > set of URLs loaded into the same process to make them able to find each > other without relying on window.open(). > Yes. -Darin > > Dmitry > > On Mon, Nov 30, 2009 at 9:07 PM, Darin Fisher <darin at chromium.org> wrote: > >> On Mon, Nov 30, 2009 at 8:52 PM, Oliver Hunt <oliver at apple.com> wrote: >> >>> >>> On Nov 30, 2009, at 8:31 PM, Darin Fisher wrote: >>> >>> >>> >>> On Mon, Nov 30, 2009 at 7:55 PM, Maciej Stachowiak <mjs at apple.com>wrote: >>> >>>> >>>> On Nov 30, 2009, at 6:16 PM, Drew Wilson 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. >>>> >>>> >>>> Would it be fair to say the goal for SharedScript is just to share code >>>> and data (to reduce memory use of multiple instances of GMail), and not >>>> network connections, timers, or other APIs based on async callbacks >>>> (assuming those either remain per-Window or are in the SharedWorker)? If so, >>>> then it would pretty much completely be handled by sharing of some arbitrary >>>> JavaScript object, possibly arranged by SharedWorker. >>>> >>>> Sharing an out-of-document HTMLIFrameElement would almost even account >>>> for timers and the like, except that currently in WebKit a frame's Window >>>> does not exist and its contents are not loaded if the frame is not rendered. >>>> >>> >>> XHRs also don't work after the frame has been unloaded. >>> >>> >>> I think my primary concern is that the use of _Shared_ or _Global_ in the >>> name implies behaviour similar to that of SharedWorker, which is not >>> guaranteed, likewise origin based object lifetime can trivially result in >>> differences in behaviour between browser (which when coupled with the naming >>> issue) could easily become a headache for developers. >>> >>> It seems that what is really wanted is a Worker context that isn't >>> actually a separate thread, so avoiding the need for postMessage, and have >>> it be explicitly instantiated so as to avoid any browser-architecture >>> derived behavioural differences. eg. >>> >>> var mySharedContext = new SharableScriptContext("script to load here?"); >>> mySharedContext.onload = function() { >>> doStuff(); >>> } >>> // or should it be >>> // mySharedContext.src = "script to load here?" >>> >>> Later on: >>> function doSomethingCoolThatNeedsANewWindow() { >>> var win = window.open(...); >>> win.onload = function() { >>> win.functionThatTakesScriptContext(mySharedContext); >>> } >>> } >>> >>> // Note handling the passing of the shared context is entirely developer >>> defined -- eg. the only spec behaviour is the 'new SharableScriptContext' >>> everything else is whatever the developers wants >>> // Note 2: I am truly awful at naming things so these names are mostly >>> chosen to clarify unambiguously-ish what i believe the goal is >>> >>> The downside is that it requires manually passing the context to new >>> windows, the plus side is that it doesn't provide (or imply) behaviour that >>> may be ('necessarily') different between UAs. >>> >>> --Oliver >>> >>> >> >> This seems pretty compelling to me. >> >> I think if we also had a function like window.getWindowByName(name), then >> we could support the use case of a newly opened window connecting to an >> existing window to get access to an existing SharableScriptContext. >> >> (To further support sharing from a newly opened window, perhaps it would >> be interesting if application manifests could be leveraged to identify URLs >> that should be loaded in the same browsing context.) >> >> -Darin >> >> _______________________________________________ >> webkit-dev mailing list >> webkit-dev at lists.webkit.org >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091130/cef7a707/attachment.html> From oliver at apple.com Mon Nov 30 22:24:59 2009 From: oliver at apple.com (Oliver Hunt) Date: Mon, 30 Nov 2009 22:24:59 -0800 Subject: [webkit-dev] SharableScriptContext [was: GlobalScript in WebKit] In-Reply-To: <28040fc60911302212w7a3e784uaaccbee18076cf54@mail.gmail.com> References: <bd8f24d20911302107v50c04915h428c2c52de900c@mail.gmail.com> <28040fc60911302212w7a3e784uaaccbee18076cf54@mail.gmail.com> Message-ID: <B8F8FA0B-F894-4060-8912-E326FA64C6E1@apple.com> On Nov 30, 2009, at 10:12 PM, Dmitry Titov wrote: > At first look, this would solve same use cases as SharedScript. The difference is that it has to be passed to participating windows explicitly. Summing up, just for reference: > > var mySharedScriptContext = new SharedScriptContext("foo.js"); > mySharedScriptContext.onload = ...; > > later: > var win = window.open(...); > win.functionThatTakesSharedScriptContext(mySharedScriptContext); > > alternatively, later: > var win = window.getWindowByName("foo"); // does not create a window if there is no "foo", searches in same process > if (win) > win.functionThatTakesSharedScriptContext(mySharedScriptContext); > > and, possibly: add a list (regexp?) to App Cache manifest to describe the set of URLs loaded into the same process to make them able to find each other without relying on window.open(). The idea behind SharedScriptContext+getWindowByName was that it would be possible to do (in your new window) if (sharedWin = getWindowByName("OriginWindow")) sharedContext = sharedWin.sharedContext; else { name = "OriginWindow"; sharedContext = new SharedScriptContext("foo.js"); } At least that was my understanding. What is your application cache suggestion attempting to do? The whole point of getWindowByName is that it doesn't need window.open All that said, Darin, Maciej and I were discussing this on IRC earlier and it would seem that simply adding getWindowByName (or some such) would gain a very large amount of the behaviour desired in the {Shared, Global}Script[Context] concept. --Oliver > > Dmitry > > On Mon, Nov 30, 2009 at 9:07 PM, Darin Fisher <darin at chromium.org> wrote: > On Mon, Nov 30, 2009 at 8:52 PM, Oliver Hunt <oliver at apple.com> wrote: > > On Nov 30, 2009, at 8:31 PM, Darin Fisher wrote: > >> >> >> On Mon, Nov 30, 2009 at 7:55 PM, Maciej Stachowiak <mjs at apple.com> wrote: >> >> On Nov 30, 2009, at 6:16 PM, Drew Wilson 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. >> >> Would it be fair to say the goal for SharedScript is just to share code and data (to reduce memory use of multiple instances of GMail), and not network connections, timers, or other APIs based on async callbacks (assuming those either remain per-Window or are in the SharedWorker)? If so, then it would pretty much completely be handled by sharing of some arbitrary JavaScript object, possibly arranged by SharedWorker. >> >> Sharing an out-of-document HTMLIFrameElement would almost even account for timers and the like, except that currently in WebKit a frame's Window does not exist and its contents are not loaded if the frame is not rendered. >> >> XHRs also don't work after the frame has been unloaded. > > I think my primary concern is that the use of _Shared_ or _Global_ in the name implies behaviour similar to that of SharedWorker, which is not guaranteed, likewise origin based object lifetime can trivially result in differences in behaviour between browser (which when coupled with the naming issue) could easily become a headache for developers. > > It seems that what is really wanted is a Worker context that isn't actually a separate thread, so avoiding the need for postMessage, and have it be explicitly instantiated so as to avoid any browser-architecture derived behavioural differences. eg. > > var mySharedContext = new SharableScriptContext("script to load here?"); > mySharedContext.onload = function() { > doStuff(); > } > // or should it be > // mySharedContext.src = "script to load here?" > > Later on: > function doSomethingCoolThatNeedsANewWindow() { > var win = window.open(...); > win.onload = function() { > win.functionThatTakesScriptContext(mySharedContext); > } > } > > // Note handling the passing of the shared context is entirely developer defined -- eg. the only spec behaviour is the 'new SharableScriptContext' everything else is whatever the developers wants > // Note 2: I am truly awful at naming things so these names are mostly chosen to clarify unambiguously-ish what i believe the goal is > > The downside is that it requires manually passing the context to new windows, the plus side is that it doesn't provide (or imply) behaviour that may be ('necessarily') different between UAs. > > --Oliver > > > > This seems pretty compelling to me. > > I think if we also had a function like window.getWindowByName(name), then we could support the use case of a newly opened window connecting to an existing window to get access to an existing SharableScriptContext. > > (To further support sharing from a newly opened window, perhaps it would be interesting if application manifests could be leveraged to identify URLs that should be loaded in the same browsing context.) > > -Darin > > _______________________________________________ > webkit-dev mailing list > webkit-dev at lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091130/af1447da/attachment.html> From eric at webkit.org Mon Nov 30 22:31:44 2009 From: eric at webkit.org (Eric Seidel) Date: Tue, 1 Dec 2009 01:31:44 -0500 Subject: [webkit-dev] lxr.webkit.org Message-ID: <1448d9f30911302231y2a8babc6rfbfd7bd97d6050bc@mail.gmail.com> Curious if we've ever tossed around the idea of setting up an lxr for webkit? Maybe the functionality of being able to click on a function name and have it jump to the definition already exists somewhere on the web for WebKit and I just am not aware of it. -eric -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091201/285c8a4f/attachment.html> From mrowe at apple.com Mon Nov 30 22:34:17 2009 From: mrowe at apple.com (Mark Rowe) Date: Mon, 30 Nov 2009 22:34:17 -0800 Subject: [webkit-dev] lxr.webkit.org In-Reply-To: <1448d9f30911302231y2a8babc6rfbfd7bd97d6050bc@mail.gmail.com> References: <1448d9f30911302231y2a8babc6rfbfd7bd97d6050bc@mail.gmail.com> Message-ID: <09A693A6-7C97-4B71-BC18-0E949B7A027E@apple.com> On 2009-11-30, at 22:31, Eric Seidel wrote: > Curious if we've ever tossed around the idea of setting up an lxr for webkit? > > Maybe the functionality of being able to click on a function name and have it jump to the definition already exists somewhere on the web for WebKit and I just am not aware of it. Mac OS Forge is looking in to something along these lines. - Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3166 bytes Desc: not available URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091130/a29e72f5/attachment.bin> From eric at webkit.org Mon Nov 30 22:36:07 2009 From: eric at webkit.org (Eric Seidel) Date: Tue, 1 Dec 2009 01:36:07 -0500 Subject: [webkit-dev] trac.webkit.org links via Google.com Message-ID: <1448d9f30911302236v74ef7f23k81a44f0900f19c22@mail.gmail.com> It's bothered me for a while that I can't just type "trac webkit Document.cpp" into Google and have it give me a trac link to our Document.cpp page. http://trac.webkit.org/browser/trunk/WebCore/dom/Document.cpp I checked http://trac.macosforge.org/robots.txt tonight and low and behold we disallow "browser/" (which is where all these links live). Curious if this is intentional, and if we should change this setting? -eric -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091201/e6b16d43/attachment.html> From darin at chromium.org Mon Nov 30 22:39:11 2009 From: darin at chromium.org (Darin Fisher) Date: Mon, 30 Nov 2009 22:39:11 -0800 Subject: [webkit-dev] trac.webkit.org links via Google.com In-Reply-To: <1448d9f30911302236v74ef7f23k81a44f0900f19c22@mail.gmail.com> References: <1448d9f30911302236v74ef7f23k81a44f0900f19c22@mail.gmail.com> Message-ID: <bd8f24d20911302239y504cf271g62c127baca1a3436@mail.gmail.com> perhaps the crawlers put too much load on trac? -darin On Mon, Nov 30, 2009 at 10:36 PM, Eric Seidel <eric at webkit.org> wrote: > It's bothered me for a while that I can't just type "trac webkit > Document.cpp" into Google and have it give me a trac link to our > Document.cpp page. > http://trac.webkit.org/browser/trunk/WebCore/dom/Document.cpp > > I checked http://trac.macosforge.org/robots.txt tonight and low and behold > we disallow "browser/" (which is where all these links live). Curious if > this is intentional, and if we should change this setting? > > -eric > > _______________________________________________ > webkit-dev mailing list > webkit-dev at lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091130/0234a13a/attachment.html> From mrowe at apple.com Mon Nov 30 22:41:44 2009 From: mrowe at apple.com (Mark Rowe) Date: Mon, 30 Nov 2009 22:41:44 -0800 Subject: [webkit-dev] trac.webkit.org links via Google.com In-Reply-To: <1448d9f30911302236v74ef7f23k81a44f0900f19c22@mail.gmail.com> References: <1448d9f30911302236v74ef7f23k81a44f0900f19c22@mail.gmail.com> Message-ID: <9BD40582-6492-47C9-9A59-4C8DEB1D688D@apple.com> On 2009-11-30, at 22:36, Eric Seidel wrote: > It's bothered me for a while that I can't just type "trac webkit Document.cpp" into Google and have it give me a trac link to our Document.cpp page. > http://trac.webkit.org/browser/trunk/WebCore/dom/Document.cpp > > I checked http://trac.macosforge.org/robots.txt tonight and low and behold we disallow "browser/" (which is where all these links live). Curious if this is intentional, and if we should change this setting? Web crawler indexing of Trac is seriously painful for the servers involved. The entire SVN history of the repository is accessible. File content. Changes. Annotations. Everything. That's not cheap to compute and serve up. - Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091130/2a273118/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3166 bytes Desc: not available URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091130/2a273118/attachment.bin> From eric at webkit.org Mon Nov 30 22:49:47 2009 From: eric at webkit.org (Eric Seidel) Date: Tue, 1 Dec 2009 01:49:47 -0500 Subject: [webkit-dev] trac.webkit.org links via Google.com In-Reply-To: <9BD40582-6492-47C9-9A59-4C8DEB1D688D@apple.com> References: <1448d9f30911302236v74ef7f23k81a44f0900f19c22@mail.gmail.com> <9BD40582-6492-47C9-9A59-4C8DEB1D688D@apple.com> Message-ID: <1448d9f30911302249y68d24362u2ab661361ff753f3@mail.gmail.com> Yeah, I could see how that would be the case. I expect it would be possible to set it up to NOFOLLOW all the expensive links, but I doubt trac does that out of the box, and it's probably not worth the effort. I need to find a better solution for web-based search of our code. Maybe the magical LXR stuff in the works at Mac OS Forge (mentioned in the other thread) will be the solution. Thanks for your quick response. -eric On Tue, Dec 1, 2009 at 1:41 AM, Mark Rowe <mrowe at apple.com> wrote: > > On 2009-11-30, at 22:36, Eric Seidel wrote: > > It's bothered me for a while that I can't just type "trac webkit > Document.cpp" into Google and have it give me a trac link to our > Document.cpp page. > http://trac.webkit.org/browser/trunk/WebCore/dom/Document.cpp > > I checked http://trac.macosforge.org/robots.txt tonight and low and behold > we disallow "browser/" (which is where all these links live). Curious if > this is intentional, and if we should change this setting? > > > Web crawler indexing of Trac is seriously painful for the servers involved. > The entire SVN history of the repository is accessible. File content. > Changes. Annotations. Everything. That's not cheap to compute and serve > up. > > - Mark > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091201/99be6f11/attachment.html> From wsiegrist at apple.com Mon Nov 30 22:51:16 2009 From: wsiegrist at apple.com (William Siegrist) Date: Mon, 30 Nov 2009 22:51:16 -0800 Subject: [webkit-dev] lxr.webkit.org In-Reply-To: <09A693A6-7C97-4B71-BC18-0E949B7A027E@apple.com> References: <1448d9f30911302231y2a8babc6rfbfd7bd97d6050bc@mail.gmail.com> <09A693A6-7C97-4B71-BC18-0E949B7A027E@apple.com> Message-ID: <E69DB55A-6D53-42A3-BACA-6534862A4274@apple.com> On Nov 30, 2009, at 10:34 PM, Mark Rowe wrote: > > On 2009-11-30, at 22:31, Eric Seidel wrote: > >> Curious if we've ever tossed around the idea of setting up an lxr for webkit? >> >> Maybe the functionality of being able to click on a function name and have it jump to the definition already exists somewhere on the web for WebKit and I just am not aware of it. > > Mac OS Forge is looking in to something along these lines. > Yes, we would like to provide such a feature. Unfortunately I have no ETA to give you. -Bill From mrowe at apple.com Mon Nov 30 22:52:41 2009 From: mrowe at apple.com (Mark Rowe) Date: Mon, 30 Nov 2009 22:52:41 -0800 Subject: [webkit-dev] trac.webkit.org links via Google.com In-Reply-To: <1448d9f30911302249y68d24362u2ab661361ff753f3@mail.gmail.com> References: <1448d9f30911302236v74ef7f23k81a44f0900f19c22@mail.gmail.com> <9BD40582-6492-47C9-9A59-4C8DEB1D688D@apple.com> <1448d9f30911302249y68d24362u2ab661361ff753f3@mail.gmail.com> Message-ID: <BFD4CFFC-0DB4-4259-AAE0-87F99CEF3063@apple.com> On 2009-11-30, at 22:49, Eric Seidel wrote: > Yeah, I could see how that would be the case. I expect it would be possible to set it up to NOFOLLOW all the expensive links, but I doubt trac does that out of the box, and it's probably not worth the effort. rel=nofollow doesn't do what you think it does. It prevents a link from implying influence. It doesn't prevent the link from being followed and the destination content from being indexed. > I need to find a better solution for web-based search of our code. Maybe the magical LXR stuff in the works at Mac OS Forge (mentioned in the other thread) will be the solution. "git grep" is hard to beat. - Mark > > On Tue, Dec 1, 2009 at 1:41 AM, Mark Rowe <mrowe at apple.com> wrote: > > On 2009-11-30, at 22:36, Eric Seidel wrote: > >> It's bothered me for a while that I can't just type "trac webkit Document.cpp" into Google and have it give me a trac link to our Document.cpp page. >> http://trac.webkit.org/browser/trunk/WebCore/dom/Document.cpp >> >> I checked http://trac.macosforge.org/robots.txt tonight and low and behold we disallow "browser/" (which is where all these links live). Curious if this is intentional, and if we should change this setting? > > Web crawler indexing of Trac is seriously painful for the servers involved. The entire SVN history of the repository is accessible. File content. Changes. Annotations. Everything. That's not cheap to compute and serve up. > > - Mark > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091130/2a58e1dd/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3166 bytes Desc: not available URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091130/2a58e1dd/attachment.bin> From darin at chromium.org Mon Nov 30 22:53:28 2009 From: darin at chromium.org (Darin Fisher) Date: Mon, 30 Nov 2009 22:53:28 -0800 Subject: [webkit-dev] lxr.webkit.org In-Reply-To: <1448d9f30911302231y2a8babc6rfbfd7bd97d6050bc@mail.gmail.com> References: <1448d9f30911302231y2a8babc6rfbfd7bd97d6050bc@mail.gmail.com> Message-ID: <bd8f24d20911302253v7e800c00i12e0db6366ea3b87@mail.gmail.com> +1 On Mon, Nov 30, 2009 at 10:31 PM, Eric Seidel <eric at webkit.org> wrote: > Curious if we've ever tossed around the idea of setting up an lxr for > webkit? > > Maybe the functionality of being able to click on a function name and have > it jump to the definition already exists somewhere on the web for WebKit and > I just am not aware of it. > > -eric > > _______________________________________________ > webkit-dev mailing list > webkit-dev at lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091130/851740a0/attachment.html> From wsiegrist at apple.com Mon Nov 30 22:57:26 2009 From: wsiegrist at apple.com (William Siegrist) Date: Mon, 30 Nov 2009 22:57:26 -0800 Subject: [webkit-dev] trac.webkit.org links via Google.com In-Reply-To: <1448d9f30911302249y68d24362u2ab661361ff753f3@mail.gmail.com> References: <1448d9f30911302236v74ef7f23k81a44f0900f19c22@mail.gmail.com> <9BD40582-6492-47C9-9A59-4C8DEB1D688D@apple.com> <1448d9f30911302249y68d24362u2ab661361ff753f3@mail.gmail.com> Message-ID: <21EA76B6-B52A-4032-93B1-8B27FD8764C1@apple.com> On Nov 30, 2009, at 10:49 PM, Eric Seidel wrote: > Yeah, I could see how that would be the case. I expect it would be possible to set it up to NOFOLLOW all the expensive links, but I doubt trac does that out of the box, and it's probably not worth the effort. > > I need to find a better solution for web-based search of our code. Maybe the magical LXR stuff in the works at Mac OS Forge (mentioned in the other thread) will be the solution. > > Thanks for your quick response. > Yes, a few parts of Trac account for most of the server load (annotate/blame and changesets). We'd rather provide our own source indexing, I just have not had a chance to implement it. I'll take this as a vote to make it a higher priority, and see what I can do. -Bill From eric at webkit.org Mon Nov 30 23:00:43 2009 From: eric at webkit.org (Eric Seidel) Date: Tue, 1 Dec 2009 02:00:43 -0500 Subject: [webkit-dev] trac.webkit.org links via Google.com In-Reply-To: <BFD4CFFC-0DB4-4259-AAE0-87F99CEF3063@apple.com> References: <1448d9f30911302236v74ef7f23k81a44f0900f19c22@mail.gmail.com> <9BD40582-6492-47C9-9A59-4C8DEB1D688D@apple.com> <1448d9f30911302249y68d24362u2ab661361ff753f3@mail.gmail.com> <BFD4CFFC-0DB4-4259-AAE0-87F99CEF3063@apple.com> Message-ID: <1448d9f30911302300v5c8c0d48u5088c9bb89739e05@mail.gmail.com> On Tue, Dec 1, 2009 at 1:52 AM, Mark Rowe <mrowe at apple.com> wrote: > > rel=nofollow doesn't do what you think it does<http://en.wikipedia.org/wiki/Nofollow#What_nofollow_is_not_for>. > It prevents a link from implying influence. It doesn't prevent the link > from being followed and the destination content from being indexed. > Good to know. "git grep" is hard to beat. > I totally agree! I just often want trac urls for sharing with others, and assembling them from file paths is annoying sometimes. :) I looked briefly at google.com/codesearch but it doesn't seem to have found svn.webkit.org yet. It claims we should ideally have a "codesearch sitemap" http://www.google.com/support/webmasters/bin/topic.py?topic=12640but I don't really know much about sitemaps or if that would even be a good idea. I don't see a sitemap listed in robots.txt ( http://www.sitemaps.org/protocol.php#submit_robots), but maybe there is one tucked away somewhere, but I'm pretty clueless on the whole "hosting a website" thing. :) Thanks again. -eric > On Tue, Dec 1, 2009 at 1:41 AM, Mark Rowe <mrowe at apple.com> wrote: > >> >> On 2009-11-30, at 22:36, Eric Seidel wrote: >> >> It's bothered me for a while that I can't just type "trac webkit >> Document.cpp" into Google and have it give me a trac link to our >> Document.cpp page. >> http://trac.webkit.org/browser/trunk/WebCore/dom/Document.cpp >> >> I checked http://trac.macosforge.org/robots.txt tonight and low and >> behold we disallow "browser/" (which is where all these links live). >> Curious if this is intentional, and if we should change this setting? >> >> >> Web crawler indexing of Trac is seriously painful for the servers >> involved. The entire SVN history of the repository is accessible. File >> content. Changes. Annotations. Everything. That's not cheap to compute >> and serve up. >> >> - Mark >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091201/fe19b7be/attachment.html> From yaar at chromium.org Mon Nov 30 23:38:45 2009 From: yaar at chromium.org (Yaar Schnitman) Date: Mon, 30 Nov 2009 23:38:45 -0800 Subject: [webkit-dev] trac.webkit.org links via Google.com In-Reply-To: <1448d9f30911302300v5c8c0d48u5088c9bb89739e05@mail.gmail.com> References: <1448d9f30911302236v74ef7f23k81a44f0900f19c22@mail.gmail.com> <9BD40582-6492-47C9-9A59-4C8DEB1D688D@apple.com> <1448d9f30911302249y68d24362u2ab661361ff753f3@mail.gmail.com> <BFD4CFFC-0DB4-4259-AAE0-87F99CEF3063@apple.com> <1448d9f30911302300v5c8c0d48u5088c9bb89739e05@mail.gmail.com> Message-ID: <b81a6db30911302338n3f00b58bj908082bbcd45002e@mail.gmail.com> A sitemap.xml file is a more modern way of telling Google how to crawl a site and the traffic can be throttled in Google's webmaster tools ( http://www.google.com/webmasters/tools/). Creating a daily script that generates sitemap.xml for webkit's SVN repo should trivial. There are probably trac plugins that do that already. If done right, google crawler shouldn't produce much more load than an average developer doing a daily svn sync. On Mon, Nov 30, 2009 at 11:00 PM, Eric Seidel <eric at webkit.org> wrote: > > > On Tue, Dec 1, 2009 at 1:52 AM, Mark Rowe <mrowe at apple.com> wrote: >> >> rel=nofollow doesn't do what you think it does<http://en.wikipedia.org/wiki/Nofollow#What_nofollow_is_not_for>. >> It prevents a link from implying influence. It doesn't prevent the link >> from being followed and the destination content from being indexed. >> > > Good to know. > > "git grep" is hard to beat. >> > > I totally agree! I just often want trac urls for sharing with others, and > assembling them from file paths is annoying sometimes. :) > > > I looked briefly at google.com/codesearch but it doesn't seem to have > found svn.webkit.org yet. It claims we should ideally have a "codesearch > sitemap" http://www.google.com/support/webmasters/bin/topic.py?topic=12640but I don't really know much about sitemaps or if that would even be a good > idea. > > I don't see a sitemap listed in robots.txt ( > http://www.sitemaps.org/protocol.php#submit_robots), but maybe there is > one tucked away somewhere, but I'm pretty clueless on the whole "hosting a > website" thing. :) > > Thanks again. > > -eric > > >> On Tue, Dec 1, 2009 at 1:41 AM, Mark Rowe <mrowe at apple.com> wrote: >> >>> >>> On 2009-11-30, at 22:36, Eric Seidel wrote: >>> >>> It's bothered me for a while that I can't just type "trac webkit >>> Document.cpp" into Google and have it give me a trac link to our >>> Document.cpp page. >>> http://trac.webkit.org/browser/trunk/WebCore/dom/Document.cpp >>> >>> I checked http://trac.macosforge.org/robots.txt tonight and low and >>> behold we disallow "browser/" (which is where all these links live). >>> Curious if this is intentional, and if we should change this setting? >>> >>> >>> Web crawler indexing of Trac is seriously painful for the servers >>> involved. The entire SVN history of the repository is accessible. File >>> content. Changes. Annotations. Everything. That's not cheap to compute >>> and serve up. >>> >>> - Mark >>> >>> >> >> > > _______________________________________________ > webkit-dev mailing list > webkit-dev at lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091130/24d22f1b/attachment.html> From adeboor at google.com Mon Nov 30 23:47:52 2009 From: adeboor at google.com (Adam de Boor) Date: Mon, 30 Nov 2009 23:47:52 -0800 Subject: [webkit-dev] SharableScriptContext [was: GlobalScript in WebKit] In-Reply-To: <B8F8FA0B-F894-4060-8912-E326FA64C6E1@apple.com> References: <bd8f24d20911302107v50c04915h428c2c52de900c@mail.gmail.com> <28040fc60911302212w7a3e784uaaccbee18076cf54@mail.gmail.com> <B8F8FA0B-F894-4060-8912-E326FA64C6E1@apple.com> Message-ID: <6dd32ba0911302347x141cae5ar578902386d10f56@mail.gmail.com> A worker context without the thread is close to what we're after, except for the bit about how it doesn't do network stuff or timeouts. Fundamentally what we need is, a place for centralizing network access and significant amounts of application state, and sharing large amounts of code, that is independent of any single window, and can manipulate the DOM of an arbitrary number of application windows that are either created by code in this independent context, or created by the user through navigation. We'd like to be able to create this context from an extension, so if a user wishes to have instant access to their gmail, or facebook, or whatever, they could choose to install an extension that would create this context when the browser starts. Shared workers fundamentally don't do the trick because (a) most of the code in the application has nothing to do with accessing the server, and everything to do with presenting the UI, so shared workers don't help with sharing the code among multiple windows, and (b) we want the UI to be immediately responsive, which means not waiting for a worker thread to get back to the UI thread with data, so we'd be caching the data both in the UI context and in the worker thread context, in which case we might as well just go to the server. When using a named window, there are interesting race conditions (unless you do something like the appcache suggestion to ensure the windows are in the same process) when one is restoring the browser state on startup. The significant challenge for the app developer is to deal with, when the named window closes, in-flight non-idempotent XHRs and registered timeouts that ought to be independent of any window, but that are tied to the named window. Timeouts are easier to deal with (centralized timer manager that remembers the deadline for each and reschedules in the context of the new named window). Being able to reparent an XHR in flight would make handling the transition easier.... a On Mon, Nov 30, 2009 at 10:24 PM, Oliver Hunt <oliver at apple.com> wrote: > > On Nov 30, 2009, at 10:12 PM, Dmitry Titov wrote: > > At first look, this would solve same use cases as SharedScript. The > difference is that it has to be passed to participating windows > explicitly. Summing up, just for reference: > > var mySharedScriptContext = new SharedScriptContext("foo.js"); > mySharedScriptContext.onload = ...; > > later: > var win = window.open(...); > win.functionThatTakesSharedScriptContext(mySharedScriptContext); > > alternatively, later: > var win = window.getWindowByName("foo"); // does not create a window if > there is no "foo", searches in same process > if (win) > win.functionThatTakesSharedScriptContext(mySharedScriptContext); > > and, possibly: add a list (regexp?) to App Cache manifest to describe the > set of URLs loaded into the same process to make them able to find each > other without relying on window.open(). > > The idea behind SharedScriptContext+getWindowByName was that it would be > possible to do (in your new window) > if (sharedWin = getWindowByName("OriginWindow")) > sharedContext = sharedWin.sharedContext; > else { > name = "OriginWindow"; > sharedContext = new SharedScriptContext("foo.js"); > } > > At least that was my understanding. > > What is your application cache suggestion attempting to do? The whole > point of getWindowByName is that it doesn't need window.open > > All that said, Darin, Maciej and I were discussing this on IRC earlier and > it would seem that simply adding getWindowByName (or some such) would gain a > very large amount of the behaviour desired in the {Shared, > Global}Script[Context] concept. > > --Oliver > > > Dmitry > > On Mon, Nov 30, 2009 at 9:07 PM, Darin Fisher <darin at chromium.org> wrote: > >> On Mon, Nov 30, 2009 at 8:52 PM, Oliver Hunt <oliver at apple.com> wrote: >> >>> >>> On Nov 30, 2009, at 8:31 PM, Darin Fisher wrote: >>> >>> >>> >>> On Mon, Nov 30, 2009 at 7:55 PM, Maciej Stachowiak <mjs at apple.com>wrote: >>> >>>> >>>> On Nov 30, 2009, at 6:16 PM, Drew Wilson 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. >>>> >>>> >>>> Would it be fair to say the goal for SharedScript is just to share code >>>> and data (to reduce memory use of multiple instances of GMail), and not >>>> network connections, timers, or other APIs based on async callbacks >>>> (assuming those either remain per-Window or are in the SharedWorker)? If so, >>>> then it would pretty much completely be handled by sharing of some arbitrary >>>> JavaScript object, possibly arranged by SharedWorker. >>>> >>>> Sharing an out-of-document HTMLIFrameElement would almost even account >>>> for timers and the like, except that currently in WebKit a frame's Window >>>> does not exist and its contents are not loaded if the frame is not rendered. >>>> >>> >>> XHRs also don't work after the frame has been unloaded. >>> >>> >>> I think my primary concern is that the use of _Shared_ or _Global_ in the >>> name implies behaviour similar to that of SharedWorker, which is not >>> guaranteed, likewise origin based object lifetime can trivially result in >>> differences in behaviour between browser (which when coupled with the naming >>> issue) could easily become a headache for developers. >>> >>> It seems that what is really wanted is a Worker context that isn't >>> actually a separate thread, so avoiding the need for postMessage, and have >>> it be explicitly instantiated so as to avoid any browser-architecture >>> derived behavioural differences. eg. >>> >>> var mySharedContext = new SharableScriptContext("script to load here?"); >>> mySharedContext.onload = function() { >>> doStuff(); >>> } >>> // or should it be >>> // mySharedContext.src = "script to load here?" >>> >>> Later on: >>> function doSomethingCoolThatNeedsANewWindow() { >>> var win = window.open(...); >>> win.onload = function() { >>> win.functionThatTakesScriptContext(mySharedContext); >>> } >>> } >>> >>> // Note handling the passing of the shared context is entirely developer >>> defined -- eg. the only spec behaviour is the 'new SharableScriptContext' >>> everything else is whatever the developers wants >>> // Note 2: I am truly awful at naming things so these names are mostly >>> chosen to clarify unambiguously-ish what i believe the goal is >>> >>> The downside is that it requires manually passing the context to new >>> windows, the plus side is that it doesn't provide (or imply) behaviour that >>> may be ('necessarily') different between UAs. >>> >>> --Oliver >>> >>> >> >> This seems pretty compelling to me. >> >> I think if we also had a function like window.getWindowByName(name), then >> we could support the use case of a newly opened window connecting to an >> existing window to get access to an existing SharableScriptContext. >> >> (To further support sharing from a newly opened window, perhaps it would >> be interesting if application manifests could be leveraged to identify URLs >> that should be loaded in the same browsing context.) >> >> -Darin >> >> _______________________________________________ >> webkit-dev mailing list >> webkit-dev at lists.webkit.org >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >> >> > > > _______________________________________________ > webkit-dev mailing list > webkit-dev at lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091130/5a933c68/attachment.html>