Re: [webkit-dev] The JSC Garbage Collector
Hi! Once that patch is in the tree, perhaps you can transform the code that iterates objects in the heap to iterate based on this per-object size information, instead of constant size classes. Can you please give me an example in the source tree where such a transformation can be done? It seems most of traversing is done by the relevant method table. Thank you for your time! -- Sanjoy Das http://playingwithpointers.com ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] [webkit-gtk] Porting V8 to WebKit
Sorry to open up this discussion again, :) Based on the recent developments in bug https://bugs.webkit.org/show_bug.cgi?id=32452 and https://bugs.webkit.org/show_bug.cgi?id=69469, it seems like some are keen on having V8 as an configurable build option in WebKit-GTK. One obvious advantage of using V8 in WebKit-GTK is faster JS engine (at this point of time!). Moreover, it will be provided as separate build option and SFX will continue to be the default JS engine. If we ever in future wish to shift completely to V8, such transition would be smoother. On the down-side, I understand the concern about code maintainability and we are ready to maintain any code changes that are added for V8. Please let me know your suggestions, concerns, comments and feedback, we will try to address them and conclude on whether to push this patch or not. Thanks, On Wed, Sep 7, 2011 at 7:48 PM, Nayan Kumar K naya...@motorola.com wrote: As promised earlier, here is the blog post with the performance results of V8 and JSC on an embedded target http://xc0ffee.wordpress.com/2011/09/07/webkit-gtk-jsc-vs-v8-performance-on-arm/. These results seem to favor V8, both in x86-64 bit machine and in an ARM target. Given this, please let us know your opinions in pushing these changes to webkit. Based on it, I will start re-factoring the patch to ease code-maintainability and code review. Thanks, On Sun, Aug 28, 2011 at 1:22 AM, Nayan Kumar K naya...@motorola.comwrote: Here is the performance analysis between JSC and V8 on an x86 reference machine - http://xc0ffee.wordpress.com/2011/08/27/webkit-gtk-jsc-vs-v8/. I am also planning to benchmark the results on an arm reference board, will publish the results soon. On Wed, Aug 3, 2011 at 10:53 PM, Nayan Kumar K naya...@motorola.comwrote: We have discussed about this in the past, the conclusion was that adding all this code without a good reason is not that interesting, our understanding is that in big projects with long story you have to care about the code maintainability not just adding features. It will add more work to maintain the port and more complexity when trying to do some things. And basically performance tests were showing we have both engines in the same ballpark so choosing one or the other will not give any benefit to the user. I agree about your concerns on code maintainability. Please note that the patch was uploaded just for feedbacks/questions/concerns (like this. :)). I believe that this patch can be further re-factored (especially the code in WeCore/GNUmakefile.am and WebCore/GNUmakefile.list.am files) so that it eases the code maintenance (which I am willing to do anyways). We could aim to push this patch with at-most isolation as possible. Anyway if you want to push this patch I would say the best option is that you try to show how this is a big improvement or that it will be a separate part of the code that will not cause any issue. But this is just my understanding of what was the situation. Below are the result based on a quick performance benchmarking, with 91387 of WebKit and 8745 revision of V8 Benchmarking Suite : V8 benchmark suite by Google URL : http://v8.googlecode.com/svn/data/benchmarks/v6/run.html Host machine: x86-64 Score with SFX: 3454 Score with V8: 8366 Of-course, judgment on performance benefit cannot be based only on V8 bench-marking suite. I will provide the results with Sunspider and Dromaeo suite soon. Btw, usually in this kind of patches the best idea before starting to work is asking to the people that was already checking it why it was stopped. Hope it helps. -- Cheers, *Nayan* -- Cheers, *Nayan* -- Cheers, *Nayan* -- Cheers, *Nayan* ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Adding Scroll Padding to allow scroll beyond the edge of the page (within some bounds)
On Thu, Oct 6, 2011 at 2:02 PM, Antonio Gomes toniki...@gmail.com wrote: From what I tested on iOS5 Mobo Safari, it also overscroll's the overflow:scroll case (generally div's). On Thu, Oct 6, 2011 at 1:47 PM, Fady Samuel fsam...@chromium.org wrote: Hi Anders, At this point in time, we see no reason to allow for non-zero padding in overflow:scroll regions because you can always just move the page into a unobstructed area and then scroll through that overflow region. I agree with Fady that the feature he describes only requires scroll padding on the page. But would it be better from a code structure viewpoint to actually add this functionality to ScrollableArea? Rob. Thanks, Fady On Thu, Oct 6, 2011 at 1:43 PM, Anders Carlsson ander...@apple.com wrote: Do you envision this being useful on overflow:scroll regions as well or is it just frames? If it's just frames, then it seems like something we could keep in ScrollView? (I haven't looked at the patch yet). - Anders On Oct 6, 2011, at 10:41 AM, Fady Samuel wrote: Hi Anders, Thanks for your reply. Yes, you are correct. This padding would be between the content and the overhang area. Thanks, Fady On Thu, Oct 6, 2011 at 1:32 PM, Anders Carlsson ander...@apple.com wrote: Hi Fady, so if I'm understanding correctly, in the context of rubber-band scrolling, this padding would be between the content and the overhang area? As far as constrainsScrollingToContentEdge goes, I'd like to get rid of it and just have two scroll functions, one that constrains to the content edge and one that doesn't. - Anders On Oct 6, 2011, at 10:03 AM, Fady Samuel wrote: Hi all, We'd like to provide a general mechanism in WebKit for embedders to scroll page content so that it is not hidden by embedder-provided UI elements that overlap the page. In some cases, if a floating UI element overlaps the edge of the page, we'd like to allow the embedder to scroll beyond the edge of the page to allow the hidden content to move to an area that isn't overlapped by UI elements. This feature is orthogonal to rubber band scrolling. One approach we considered taking is to allow the platform to set scroll padding to a FrameView/ScrollableArea to allow scrolling beyond the edge of the page. As a more concrete example, one can imagine a persistent Chromium extension that floats above the edge of the page. A link may lie behind the floating window. That link would be inaccessible unless the page is allowed to scroll beyond its edge. An experimental and incomplete implementation of this idea can be found here: https://bugs.webkit.org/show_bug.cgi?id=68184 After some additional consideration since this patch was posted, I don't believe scroll padding should interact with ScrollView::constrainsScrollingToContentEdge the way it does in the patch. Instead, I feel that scroll padding should be ignored if constrainsScrollingToContentEdge is false. That way rubber band scrolling is not affected at all by this. What are your thoughts and suggestions? Is this feature sufficiently general to be implemented in WebCore? What are your thoughts about its interaction with ScrollView::constrainsScrollingToContentEdge? Thanks, Fady ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- --Antonio Gomes ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Adding Scroll Padding to allow scroll beyond the edge of the page (within some bounds)
The way I currently have it implemented, scroll padding affects the maximumScrollPosition and the minimumScrollPosition. Those two methods are virtual. If scroll padding was placed in FrameView, then it could also override maximumScrollPosition and minimumScrollPosition to take padding into account. I believe it's reasonable to do this in FrameView, but I'm open to suggestions. The one issue is ensuring that the scroll bounds are always checked through maximumScrollPosition and minimumScrollPosition rather than scrollSize (which is determined by the content only). Fady On Fri, Oct 7, 2011 at 11:27 AM, Robert Kroeger rjkro...@chromium.orgwrote: On Thu, Oct 6, 2011 at 2:02 PM, Antonio Gomes toniki...@gmail.com wrote: From what I tested on iOS5 Mobo Safari, it also overscroll's the overflow:scroll case (generally div's). On Thu, Oct 6, 2011 at 1:47 PM, Fady Samuel fsam...@chromium.org wrote: Hi Anders, At this point in time, we see no reason to allow for non-zero padding in overflow:scroll regions because you can always just move the page into a unobstructed area and then scroll through that overflow region. I agree with Fady that the feature he describes only requires scroll padding on the page. But would it be better from a code structure viewpoint to actually add this functionality to ScrollableArea? Rob. Thanks, Fady On Thu, Oct 6, 2011 at 1:43 PM, Anders Carlsson ander...@apple.com wrote: Do you envision this being useful on overflow:scroll regions as well or is it just frames? If it's just frames, then it seems like something we could keep in ScrollView? (I haven't looked at the patch yet). - Anders On Oct 6, 2011, at 10:41 AM, Fady Samuel wrote: Hi Anders, Thanks for your reply. Yes, you are correct. This padding would be between the content and the overhang area. Thanks, Fady On Thu, Oct 6, 2011 at 1:32 PM, Anders Carlsson ander...@apple.com wrote: Hi Fady, so if I'm understanding correctly, in the context of rubber-band scrolling, this padding would be between the content and the overhang area? As far as constrainsScrollingToContentEdge goes, I'd like to get rid of it and just have two scroll functions, one that constrains to the content edge and one that doesn't. - Anders On Oct 6, 2011, at 10:03 AM, Fady Samuel wrote: Hi all, We'd like to provide a general mechanism in WebKit for embedders to scroll page content so that it is not hidden by embedder-provided UI elements that overlap the page. In some cases, if a floating UI element overlaps the edge of the page, we'd like to allow the embedder to scroll beyond the edge of the page to allow the hidden content to move to an area that isn't overlapped by UI elements. This feature is orthogonal to rubber band scrolling. One approach we considered taking is to allow the platform to set scroll padding to a FrameView/ScrollableArea to allow scrolling beyond the edge of the page. As a more concrete example, one can imagine a persistent Chromium extension that floats above the edge of the page. A link may lie behind the floating window. That link would be inaccessible unless the page is allowed to scroll beyond its edge. An experimental and incomplete implementation of this idea can be found here: https://bugs.webkit.org/show_bug.cgi?id=68184 After some additional consideration since this patch was posted, I don't believe scroll padding should interact with ScrollView::constrainsScrollingToContentEdge the way it does in the patch. Instead, I feel that scroll padding should be ignored if constrainsScrollingToContentEdge is false. That way rubber band scrolling is not affected at all by this. What are your thoughts and suggestions? Is this feature sufficiently general to be implemented in WebCore? What are your thoughts about its interaction with ScrollView::constrainsScrollingToContentEdge? Thanks, Fady ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- --Antonio Gomes ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Making PopupMenuClient testable
Hi all, I've just uploaded a patch https://bugs.webkit.org/show_bug.cgi?id=69631 that's intended to make PopupMenuClient testable. On certain Chromium platforms, the position of the select element's popup is incorrect if the page's scale factor is not 1.0. The fix to the problem is simple, see https://bugs.webkit.org/show_bug.cgi?id=66062 , but since popups are external to WebKit on most platforms, this is difficult to test. The patch above in bug 69631 attempts to addresses this, albeit in a less than ideal way. I'm not sure what's the best way to test this, but this is my stab at it. I'd really appreciate any comments or suggestions you can provide on my patch for bug 69631. Thanks, Fady ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] layout tests cannot set Generic RGB Color Profile on headless MacPro?
I was having problems with lots of image mismatches running WebKit layout tests on a headless MacPro (10.6.8). (The image diffs were very minor adjustments in scroll bar shading.) Eventually, out of frustration, I tried running the same test on that headless MacPro as well as my desktop MacPro (also 10.6.8). The test succeeded on my desktop MacPro but not the headless MacPro. One difference I have noticed is that the Display Profile (under System Preferences Displays Color) is set to sRGB IEC61966-2.1 (my desktop was set to Generic RGB Profile). I tried setting it to Generic RGB Profile on the headless machine, but when I closed and reopened System Preferences it had reverted to sRGB IEC61966-2.1. I tried setting the Display Profile on my desktop to sRGB IEC61966-2.1, and the color scheme was noticeably brighter... but when I ran layout tests afterwards, I saw that layout tests automatically set the profile back to Generic RGB Profile temporarily for the test. When I run layout tests on the headless MacPro, it seems that it fails to change the color profile (and I don't see any error in the output of layout tests). I tried it on a headless Mac Mini (10.6.8) and there layout tests was able to change to Generic RGB Profile (and thus the tests passed). For now, my fix is going to be: don't run layout tests on headless MacPros; use headless MacMinis instead. Is this a Known Issue? Any suggestions? Thanks -Elliot ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] layout tests cannot set Generic RGB Color Profile on headless MacPro?
On Oct 7, 2011, at 11:45 AM, Elliot Poger wrote: I was having problems with lots of image mismatches running WebKit layout tests on a headless MacPro (10.6.8). (The image diffs were very minor adjustments in scroll bar shading.) Eventually, out of frustration, I tried running the same test on that headless MacPro as well as my desktop MacPro (also 10.6.8). The test succeeded on my desktop MacPro but not the headless MacPro. One difference I have noticed is that the Display Profile (under System Preferences Displays Color) is set to sRGB IEC61966-2.1 (my desktop was set to Generic RGB Profile). I tried setting it to Generic RGB Profile on the headless machine, but when I closed and reopened System Preferences it had reverted to sRGB IEC61966-2.1. I tried setting the Display Profile on my desktop to sRGB IEC61966-2.1, and the color scheme was noticeably brighter... but when I ran layout tests afterwards, I saw that layout tests automatically set the profile back to Generic RGB Profile temporarily for the test. When I run layout tests on the headless MacPro, it seems that it fails to change the color profile (and I don't see any error in the output of layout tests). I tried it on a headless Mac Mini (10.6.8) and there layout tests was able to change to Generic RGB Profile (and thus the tests passed). For now, my fix is going to be: don't run layout tests on headless MacPros; use headless MacMinis instead. Is this a Known Issue? Any suggestions? I'm aware that there are color profile issues when running pixel tests, but I was not aware of differences between hardware. We may be able to fix DumpRenderTree/WebKitTestRunner to change the color profile just for the test window, and not globally. I haven't tried that yet. Finally, I've noticed some changes in color profile behavior on Lion, so if you try running tests there, you may see a new set of problems. Simon ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] layout tests cannot set Generic RGB Color Profile on headless MacPro?
Yeah, layout tests fail on Mac without a screen connected to it. Chromium buildbots use Mac minis connected to KVMs for that reason. I'm actually surprised to learn that tests passed on a headless Mac mini. - Ryosuke On Fri, Oct 7, 2011 at 11:53 AM, Simon Fraser simon.fra...@apple.comwrote: On Oct 7, 2011, at 11:45 AM, Elliot Poger wrote: I was having problems with lots of image mismatches running WebKit layout tests on a headless MacPro (10.6.8). (The image diffs were very minor adjustments in scroll bar shading.) Eventually, out of frustration, I tried running the same test on that headless MacPro as well as my desktop MacPro (also 10.6.8). The test succeeded on my desktop MacPro but not the headless MacPro. One difference I have noticed is that the Display Profile (under System Preferences Displays Color) is set to sRGB IEC61966-2.1 (my desktop was set to Generic RGB Profile). I tried setting it to Generic RGB Profile on the headless machine, but when I closed and reopened System Preferences it had reverted to sRGB IEC61966-2.1. I tried setting the Display Profile on my desktop to sRGB IEC61966-2.1, and the color scheme was noticeably brighter... but when I ran layout tests afterwards, I saw that layout tests automatically set the profile back to Generic RGB Profile temporarily for the test. When I run layout tests on the headless MacPro, it seems that it fails to change the color profile (and I don't see any error in the output of layout tests). I tried it on a headless Mac Mini (10.6.8) and there layout tests was able to change to Generic RGB Profile (and thus the tests passed). For now, my fix is going to be: don't run layout tests on headless MacPros; use headless MacMinis instead. Is this a Known Issue? Any suggestions? I'm aware that there are color profile issues when running pixel tests, but I was not aware of differences between hardware. We may be able to fix DumpRenderTree/WebKitTestRunner to change the color profile just for the test window, and not globally. I haven't tried that yet. Finally, I've noticed some changes in color profile behavior on Lion, so if you try running tests there, you may see a new set of problems. Simon ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] layout tests cannot set Generic RGB Color Profile on headless MacPro?
At least as of Snow Leopard, it was impossible to run the layout tests, without a login-session/security context. You would need to be physically logged into the machine, and then run the tests from VNC/Remote Desktop for them to work. In snow leopard SSHing to a machine (without being physically logged in) did not create the right kind of session to support DumpRenderTree (which needs to talk to the pasteboard and window servers among other things). It may be possible to run the tests from SSH if you are also logged via the console. It used to be the case that you could run a Mac headless, but you need to boot them with a monitor attached if you wanted things like the layout tests and performance tests (like the PLT) to run correctly. (You could disconnect the monitor after initial boot and the mac would behave as though it was connected.) -eric On Fri, Oct 7, 2011 at 1:53 PM, Simon Fraser simon.fra...@apple.com wrote: On Oct 7, 2011, at 11:45 AM, Elliot Poger wrote: I was having problems with lots of image mismatches running WebKit layout tests on a headless MacPro (10.6.8). (The image diffs were very minor adjustments in scroll bar shading.) Eventually, out of frustration, I tried running the same test on that headless MacPro as well as my desktop MacPro (also 10.6.8). The test succeeded on my desktop MacPro but not the headless MacPro. One difference I have noticed is that the Display Profile (under System Preferences Displays Color) is set to sRGB IEC61966-2.1 (my desktop was set to Generic RGB Profile). I tried setting it to Generic RGB Profile on the headless machine, but when I closed and reopened System Preferences it had reverted to sRGB IEC61966-2.1. I tried setting the Display Profile on my desktop to sRGB IEC61966-2.1, and the color scheme was noticeably brighter... but when I ran layout tests afterwards, I saw that layout tests automatically set the profile back to Generic RGB Profile temporarily for the test. When I run layout tests on the headless MacPro, it seems that it fails to change the color profile (and I don't see any error in the output of layout tests). I tried it on a headless Mac Mini (10.6.8) and there layout tests was able to change to Generic RGB Profile (and thus the tests passed). For now, my fix is going to be: don't run layout tests on headless MacPros; use headless MacMinis instead. Is this a Known Issue? Any suggestions? I'm aware that there are color profile issues when running pixel tests, but I was not aware of differences between hardware. We may be able to fix DumpRenderTree/WebKitTestRunner to change the color profile just for the test window, and not globally. I haven't tried that yet. Finally, I've noticed some changes in color profile behavior on Lion, so if you try running tests there, you may see a new set of problems. Simon ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] layout tests cannot set Generic RGB Color Profile on headless MacPro?
On Fri, Oct 7, 2011 at 3:06 PM, Ryosuke Niwa rn...@webkit.org wrote: Yeah, layout tests fail on Mac without a screen connected to it. Chromium buildbots use Mac minis connected to KVMs for that reason. I'm actually surprised to learn that tests passed on a headless Mac mini. Ah, then you will perhaps NOT be surprised to learn: that MacMini actually WAS plugged into a monitor (but the monitor was far away and hadn't been turned on for months--thus I forgot about it). I plugged a monitor into the MacPro, and unplugged the monitor from the MacMini, and established the following for both MacPro and MacMini (restarting the computer each time): - monitor plugged in and turned on: layout tests work fine - monitor plugged in and turned off: layout tests work fine - no monitor plugged in: layout tests break I also tried plugging various adapters (Mini DisplayPort to DVI, Mini DisplayPort to VGA, HDMI to DVI) into the computer but *not* connecting a monitor to them; in all cases, it was the same as plugging in no monitor cable at all (layout tests break). Presumably connecting to a KVM or other fake monitor, as Ryosuke mentions, would work. Thanks all for the information. - Ryosuke On Fri, Oct 7, 2011 at 11:53 AM, Simon Fraser simon.fra...@apple.comwrote: On Oct 7, 2011, at 11:45 AM, Elliot Poger wrote: I was having problems with lots of image mismatches running WebKit layout tests on a headless MacPro (10.6.8). (The image diffs were very minor adjustments in scroll bar shading.) Eventually, out of frustration, I tried running the same test on that headless MacPro as well as my desktop MacPro (also 10.6.8). The test succeeded on my desktop MacPro but not the headless MacPro. One difference I have noticed is that the Display Profile (under System Preferences Displays Color) is set to sRGB IEC61966-2.1 (my desktop was set to Generic RGB Profile). I tried setting it to Generic RGB Profile on the headless machine, but when I closed and reopened System Preferences it had reverted to sRGB IEC61966-2.1. I tried setting the Display Profile on my desktop to sRGB IEC61966-2.1, and the color scheme was noticeably brighter... but when I ran layout tests afterwards, I saw that layout tests automatically set the profile back to Generic RGB Profile temporarily for the test. When I run layout tests on the headless MacPro, it seems that it fails to change the color profile (and I don't see any error in the output of layout tests). I tried it on a headless Mac Mini (10.6.8) and there layout tests was able to change to Generic RGB Profile (and thus the tests passed). For now, my fix is going to be: don't run layout tests on headless MacPros; use headless MacMinis instead. Is this a Known Issue? Any suggestions? I'm aware that there are color profile issues when running pixel tests, but I was not aware of differences between hardware. We may be able to fix DumpRenderTree/WebKitTestRunner to change the color profile just for the test window, and not globally. I haven't tried that yet. Finally, I've noticed some changes in color profile behavior on Lion, so if you try running tests there, you may see a new set of problems. Simon ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] layout tests cannot set Generic RGB Color Profile on headless MacPro?
Elliot, On 10/07/2011 05:05 PM, Elliot Poger wrote: Presumably connecting to a KVM or other fake monitor, as Ryosuke mentions, would work. You could try connecting VGA pins 4 (id2) and 11 (id0) to pin 5 (ground). This will signal the video controller that there's a monitor which supports 1024x768 resolution; could also work if only pin 11 is grounded as well. Can be done with a paper clip. Leandro ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] How do I turn off timeout for unresponsive plug-ins, to allow long debug sessions
Is there a way to have Safari (or webkit) have an infinite timeout waiting for the plugin process? I need this for effective debugging. Since Safari creates the plugin process, loads my plugin and starts it up when I click on a link, I can't pre-attach or pre-launch the plugin process. So I go through the following: * Have a sleep loop in NP_GetEntryPoints in my plugin * Launch Safari * Click on a link to a file that will invoke my plugin (Safari will create PluginProcess) * In Xcode, attach to my plugin * Manually jump past the sleep-loop ...so far, so good. Now my plug-in loads a very substantial framework where I have some breakpoints set, so I want Xcode to load the symbols. The problem is that it takes so long for Xcode to load the framework and process the symbols, that Safari appears to time out and kill the plugin process so I can't debug. So is there a way to keep Safari from doing this? Thanks, Rudi smime.p7s Description: S/MIME cryptographic signature ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] How do I turn off timeout for unresponsive plug-ins, to allow long debug sessions
Hi Rudi, in if you're running Safari with a WebKit nightly, you can disable the timeout using defaults write com.apple.Safari WebKitDisablePluginProcessMessageTimeout YES Hope this helps, Anders On Oct 7, 2011, at 2:59 PM, Rudi Sherry wrote: Is there a way to have Safari (or webkit) have an infinite timeout waiting for the plugin process? I need this for effective debugging. Since Safari creates the plugin process, loads my plugin and starts it up when I click on a link, I can't pre-attach or pre-launch the plugin process. So I go through the following: * Have a sleep loop in NP_GetEntryPoints in my plugin * Launch Safari * Click on a link to a file that will invoke my plugin (Safari will create PluginProcess) * In Xcode, attach to my plugin * Manually jump past the sleep-loop ...so far, so good. Now my plug-in loads a very substantial framework where I have some breakpoints set, so I want Xcode to load the symbols. The problem is that it takes so long for Xcode to load the framework and process the symbols, that Safari appears to time out and kill the plugin process so I can't debug. So is there a way to keep Safari from doing this? Thanks, Rudi ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] How do I turn off timeout for unresponsive plug-ins, to allow long debug sessions
Thanks! I'll try it as soon as I'm back in the office. Connected by DROID on Verizon Wireless -Original message- From: Anders Carlsson ander...@apple.com To: Rudi Sherry rshe...@adobe.com Cc: Webkit Development webkit-dev@lists.webkit.org Sent: Fri, Oct 7, 2011 22:12:03 GMT+00:00 Subject: Re: [webkit-dev] How do I turn off timeout for unresponsive plug-ins, to allow long debug sessions Hi Rudi, in if you're running Safari with a WebKit nightly, you can disable the timeout using defaults write com.apple.Safari WebKitDisablePluginProcessMessageTimeout YES Hope this helps, Anders On Oct 7, 2011, at 2:59 PM, Rudi Sherry wrote: Is there a way to have Safari (or webkit) have an infinite timeout waiting for the plugin process? I need this for effective debugging. Since Safari creates the plugin process, loads my plugin and starts it up when I click on a link, I can't pre-attach or pre-launch the plugin process. So I go through the following: * Have a sleep loop in NP_GetEntryPoints in my plugin * Launch Safari * Click on a link to a file that will invoke my plugin (Safari will create PluginProcess) * In Xcode, attach to my plugin * Manually jump past the sleep-loop ...so far, so good. Now my plug-in loads a very substantial framework where I have some breakpoints set, so I want Xcode to load the symbols. The problem is that it takes so long for Xcode to load the framework and process the symbols, that Safari appears to time out and kill the plugin process so I can't debug. So is there a way to keep Safari from doing this? Thanks, Rudi ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] How do I turn off timeout for unresponsive plug-ins, to allow long debug sessions
Hi Anders, Thanks, it does work, with one caveat, can you confirm: For Safari 5.1 it appears that it should be: defaults write com.apple.Safari DisablePluginProcessMessageTimeout YES ...no WebKit prefix. Some searching shows the WebKit prefix was added after 5.1, Aug 9 in changeset 92716, eight days after my Safari 5.1 is dated (Aug 1). Thanks, Rudi On Oct 7, 2011, at 3:33 PM, Rudi Sherry wrote: Thanks! I'll try it as soon as I'm back in the office. Connected by DROID on Verizon Wireless -Original message- From: Anders Carlsson ander...@apple.com To: Rudi Sherry rshe...@adobe.com Cc: Webkit Development webkit-dev@lists.webkit.org Sent: Fri, Oct 7, 2011 22:12:03 GMT+00:00 Subject: Re: [webkit-dev] How do I turn off timeout for unresponsive plug-ins, to allow long debug sessions Hi Rudi, in if you're running Safari with a WebKit nightly, you can disable the timeout using defaults write com.apple.Safari WebKitDisablePluginProcessMessageTimeout YES Hope this helps, Anders On Oct 7, 2011, at 2:59 PM, Rudi Sherry wrote: Is there a way to have Safari (or webkit) have an infinite timeout waiting for the plugin process? I need this for effective debugging. Since Safari creates the plugin process, loads my plugin and starts it up when I click on a link, I can't pre-attach or pre-launch the plugin process. So I go through the following: * Have a sleep loop in NP_GetEntryPoints in my plugin * Launch Safari * Click on a link to a file that will invoke my plugin (Safari will create PluginProcess) * In Xcode, attach to my plugin * Manually jump past the sleep-loop ...so far, so good. Now my plug-in loads a very substantial framework where I have some breakpoints set, so I want Xcode to load the symbols. The problem is that it takes so long for Xcode to load the framework and process the symbols, that Safari appears to time out and kill the plugin process so I can't debug. So is there a way to keep Safari from doing this? Thanks, Rudi ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev smime.p7s Description: S/MIME cryptographic signature ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
