[webkit-dev] On Safari 5.1.8 for Snow Leopard....
To the Apple people on this list: What exactly does Safari 5.1.8 for Snow Leopard contain? Does it contain security updates? Yuhong Bao ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] FrameLoader::stopAllLoaders and sync XHR
I'm trying to debug a deadlock on exit in a BlackBerry app that uses webkit (which is pretty hard to reproduce, so I don't have a cut-down test case yet). Right now my suspicions are on this behaviour: a synchronous XMLHttpRequest starts loading (from a script running in the main frame) ResourceHandle::platformLoadResourceSynchronously gets called On BlackBerry, this is implemented by creating a nested EventLoop and calling loop.cycle() While in the nested event loop, BlackBerry::WebPage::stopLoading is called This is implemented by calling m_mainFrame-loader()-stopAllLoaders() As far as I can see, FrameLoader::stopAllLoaders does NOT stop any XMLHttpRequest started from this frame - it just stops the provisionalDocumentLoader and documentLoader for the frame itself, and recursively does the same for all subframes. Is that correct? Is there a way to find and stop all synchronous requests associated with a frame? (There should be only one...) Thanks, Joe - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] FrameLoader::stopAllLoaders and sync XHR
Hi Joe, From what I remembered and understood, actions like FrameLoader::stopAllLoaders is not safe to be executed in a nested event loop. I would try to find a way to exit all nested event loops first and then close the page if it has to be done gracefully. In EventLoopBlackBerry.cpp, the loop’s end flag is set when the thread’s isRunning() method returns false. m_ended = !BlackBerry::Platform::webKitThreadMessageClient()-isRunning(); It could be something like: m_ended = !BlackBerry::Platform::webKitThreadMessageClient()-isRunning() || ...-shouldExitNestedEventLoop(); -yong From: Joe Mason Sent: Monday, April 22, 2013 11:37 AM To: webkit-dev@lists.webkit.org Cc: Mike Lattanzio, Mike Fenton I'm trying to debug a deadlock on exit in a BlackBerry app that uses webkit (which is pretty hard to reproduce, so I don't have a cut-down test case yet). Right now my suspicions are on this behaviour: a synchronous XMLHttpRequest starts loading (from a script running in the main frame) ResourceHandle::platformLoadResourceSynchronously gets called On BlackBerry, this is implemented by creating a nested EventLoop and calling loop.cycle() While in the nested event loop, BlackBerry::WebPage::stopLoading is called This is implemented by calling m_mainFrame-loader()-stopAllLoaders() As far as I can see, FrameLoader::stopAllLoaders does NOT stop any XMLHttpRequest started from this frame - it just stops the provisionalDocumentLoader and documentLoader for the frame itself, and recursively does the same for all subframes. Is that correct? Is there a way to find and stop all synchronous requests associated with a frame? (There should be only one...) Thanks, Joe - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Enabling Experimental Features
On Apr 20, 2013, at 10:03 AM, Maciej Stachowiak m...@apple.com wrote: On Apr 19, 2013, at 3:50 PM, Timothy Hatcher timo...@apple.com wrote: On Apr 19, 2013, at 6:15 PM, Bear Travis betra...@adobe.com wrote: What do folks think about adding a mechanism for users to toggle features like this on in WebKit nightlies? I don't have a definite approach yet, but wanted to float the idea for feedback. I like the idea. Having things off for everyone but the engineers is a bad approach and misses out on testing. We could have WebKit modify Safari's Develop menu to provide additional items to toggle. Safari provides an Enable WebGL item, we could inject more items next to it. On Mac, we could at the very last use 'defaults write' to toggle experimental runtime-enabled features. One problem is that most CSS-exposed experimental features are not runtime-switchable. We'd have to do a bunch of work in the parser and style resolver to make this possible. Simon ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Enabling Experimental Features
On Apr 22, 2013, at 9:32 AM, Simon Fraser simon.fra...@apple.com wrote: On Apr 20, 2013, at 10:03 AM, Maciej Stachowiak m...@apple.com wrote: On Apr 19, 2013, at 3:50 PM, Timothy Hatcher timo...@apple.com wrote: On Apr 19, 2013, at 6:15 PM, Bear Travis betra...@adobe.com wrote: What do folks think about adding a mechanism for users to toggle features like this on in WebKit nightlies? I don't have a definite approach yet, but wanted to float the idea for feedback. I like the idea. Having things off for everyone but the engineers is a bad approach and misses out on testing. We could have WebKit modify Safari's Develop menu to provide additional items to toggle. Safari provides an Enable WebGL item, we could inject more items next to it. On Mac, we could at the very last use 'defaults write' to toggle experimental runtime-enabled features. One problem is that most CSS-exposed experimental features are not runtime-switchable. We'd have to do a bunch of work in the parser and style resolver to make this possible. I think it is worth it to do that. Not just because of CSS Exclusions, but for future properties as well. Greetings, Dirk Simon ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] FrameLoader::stopAllLoaders and sync XHR
On Apr 22, 2013, at 8:37 AM, Joe Mason jma...@blackberry.com wrote: I'm trying to debug a deadlock on exit in a BlackBerry app that uses webkit (which is pretty hard to reproduce, so I don't have a cut-down test case yet). Right now my suspicions are on this behaviour: a synchronous XMLHttpRequest starts loading (from a script running in the main frame) ResourceHandle::platformLoadResourceSynchronously gets called On BlackBerry, this is implemented by creating a nested EventLoop and calling loop.cycle() While in the nested event loop, BlackBerry::WebPage::stopLoading is called There's your problem - loadResourceSynchronously is supposed to guarantee that - from WebCore's perspective - the main web thread is waiting on the resource load. The nested event loop needs to be configured to *not* call back in to WebCore and *only* to service the load. Note that this expectation re: sync XHR is why single-process, Web-thread-is-UI-thread browsers are expected to become completely non responsive during the sync XHR. The proper way to allowing such an app to exit while a sync XHR is outstanding would be to cause the sync XHR load to fail at the networking layer *then* exit. ~Brady This is implemented by calling m_mainFrame-loader()-stopAllLoaders() As far as I can see, FrameLoader::stopAllLoaders does NOT stop any XMLHttpRequest started from this frame - it just stops the provisionalDocumentLoader and documentLoader for the frame itself, and recursively does the same for all subframes. Is that correct? Is there a way to find and stop all synchronous requests associated with a frame? (There should be only one...) Thanks, Joe - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Enabling Experimental Features
FWIW, Blink is going through this right now too. We're attempting to move completely away from prefixed development: http://www.chromium.org/blink#vendor-prefixes To do that, that requires making it possible enable/disable CSS properties at runtime: https://code.google.com/p/chromium/issues/detail?id=232181 https://code.google.com/p/chromium/issues/detail?id=234270 Perhaps this is another opportunity for the two code bases to learn from one another as we both implement solutions to this. On Mon, Apr 22, 2013 at 9:32 AM, Simon Fraser simon.fra...@apple.com wrote: On Apr 20, 2013, at 10:03 AM, Maciej Stachowiak m...@apple.com wrote: On Apr 19, 2013, at 3:50 PM, Timothy Hatcher timo...@apple.com wrote: On Apr 19, 2013, at 6:15 PM, Bear Travis betra...@adobe.com wrote: What do folks think about adding a mechanism for users to toggle features like this on in WebKit nightlies? I don't have a definite approach yet, but wanted to float the idea for feedback. I like the idea. Having things off for everyone but the engineers is a bad approach and misses out on testing. We could have WebKit modify Safari's Develop menu to provide additional items to toggle. Safari provides an Enable WebGL item, we could inject more items next to it. On Mac, we could at the very last use 'defaults write' to toggle experimental runtime-enabled features. One problem is that most CSS-exposed experimental features are not runtime-switchable. We'd have to do a bunch of work in the parser and style resolver to make this possible. Simon ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] mouseenter and mouseleave events
On Wednesday 17 April 2013, Maciej Stachowiak wrote: Seems like a reasonable feature to add. Would you mind also reviewing the patch in question then or help me find a reviewer with the right knowledge? Most of the patch is boiler plate work. The central part is how and when the events are dispatched and confined to additional responsibility of updateHoverActiveState. Regards `Allan ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
