[webkit-dev] [webkit-help] [squirrelfish-dev] How to debug the JIT when it crash
Hi All, apologies for the spam. right now I am trying to fix the jit crash bug, but I don't know how to start it, can anyone give me some suggestion? when javascript engine run some special test case, it will run crash. I have print all the emited instructions, but the instructions will be repatch or relink after it run, so is exist an way or steps for debugging it? Thanks in advance! -- BGs/Felix Shi ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] [MIPS] buildslave expectations in qt-linux env.
Dear WebKit Developers, We would like to set up a tester buildbot slave for MIPS and we are using a qt-linux system. It seems we have to add some MIPS related expectations. Please give us some advice how to do that. 1. qt-arm is using old-run-webkit-tests. Should we use that too? 2. In new-run-webkit-tests modules in the qt port the x86 architecture is built-in so we can't specify expectations by the 'mipsel' arch. name: configurations.append(TestConfiguration(version=version, architecture='x86', build_type=build_type)) But if we define qt-mipsel platform name then the version tag will be mipsel and we loose qt-linux expectations. The current qt expectation tree: # qt-5.0-mac-wk2 #/ # qt-5.0-wk1qt-5.0-wk2 #\/ # qt-5.0qt-4.8 #\/ #(qt-linux|qt-mac|qt-win) #| # qt 2.a, Should we modify the Tools/Scripts/webkitpy/layout_tests/port/qt.py's QtPort class or 2.b, should we add a MipselQtPort class to extend the existing QtPort. 3., Something else Thank you for your help. Best Regards, Balazs ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Can the Windows WebKit nightly build be removed?
http://nightly.webkit.org The Windows build is currently over 13,158 revisions behind. I recently received a Chromium bug that are actually a WebKit bug because the user was using the Windows nightly build to confirm. Philip ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] New web-facing CSS feature: -webkit-cursor-visibility: auto-hide
In an effort to improve the user-experience of watching videos in full screen mode, I have created a patch which adds a new CSS style attribute: -webkit-cursor-visibility. When set to auto-hide, this rule would change the cursor type to none after a few seconds of inactivity. UAs could then add this rule to their UA full screen style sheets for full screened video elements, but this rule can be overridden by site authors to handle hiding the cursor (or not) themselves. Sites which do not hide the cursor during playback in full screen mode (e.g. YouTube) would get this behavior for free, and sites which do (e.g. vimeo) can continue to explicitly hide the mouse cursor when hiding their custom controls. This new attribute is not currently hidden behind a feature flag. We are at the very initial stages of proposing this attribute to the CSSWG, but have already incorporated feedback from some of the WG members. Please take a look at the associated bug, if you're interested: https://bugs.webkit.org/show_bug.cgi?id=107601 Default mouse cursor behavior should be auto-hide for full screen video with custom controls -Jer ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] New web-facing CSS feature: -webkit-cursor-visibility: auto-hide
On Mon, Mar 4, 2013 at 4:37 PM, Jer Noble jer.no...@apple.com wrote: In an effort to improve the user-experience of watching videos in full screen mode, I have created a patch which adds a new CSS style attribute: -webkit-cursor-visibility. When set to auto-hide, this rule would change the cursor type to none after a few seconds of inactivity. UAs could then add this rule to their UA full screen style sheets for full screened video elements, but this rule can be overridden by site authors to handle hiding the cursor (or not) themselves. Sites which do not hide the cursor during playback in full screen mode (e.g. YouTube) would get this behavior for free, and sites which do (e.g. vimeo) can continue to explicitly hide the mouse cursor when hiding their custom controls. This new attribute is not currently hidden behind a feature flag. Could you add either build or runtime flag? - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] New web-facing CSS feature: -webkit-cursor-visibility: auto-hide
On Mar 4, 2013, at 4:46 PM, Ryosuke Niwa rn...@webkit.org wrote: Could you add either build or runtime flag? I most definitely could. But are there any ports who would disable the flag? (Honestly asking, here.) If not, adding a feature flag may be more trouble than its worth. -Jer ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] New web-facing CSS feature: -webkit-cursor-visibility: auto-hide
On Mon, Mar 4, 2013 at 4:52 PM, Jer Noble jer.no...@apple.com wrote: On Mar 4, 2013, at 4:46 PM, Ryosuke Niwa rn...@webkit.org wrote: Could you add either build or runtime flag? I most definitely could. But are there any ports who would disable the flag? (Honestly asking, here.) If not, adding a feature flag may be more trouble than its worth. In chromium we would like the ability to monitor and, when appropriate, disable vendor-prefixed non-standard CSS properties. I think it's a bad idea to assume that by default all ports will want to expose non-standard API to the web platform without at least considering the situation and having a plan to remove at least the prefixed version. Please add a flag and, for bonus points, hook up FeatureObserver so we can monitor usage of this property. - James -Jer ___ 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] New web-facing CSS feature: -webkit-cursor-visibility: auto-hide
Have you proposed this feature to the relevant standards working group? Adam On Mon, Mar 4, 2013 at 4:37 PM, Jer Noble jer.no...@apple.com wrote: In an effort to improve the user-experience of watching videos in full screen mode, I have created a patch which adds a new CSS style attribute: -webkit-cursor-visibility. When set to auto-hide, this rule would change the cursor type to none after a few seconds of inactivity. UAs could then add this rule to their UA full screen style sheets for full screened video elements, but this rule can be overridden by site authors to handle hiding the cursor (or not) themselves. Sites which do not hide the cursor during playback in full screen mode (e.g. YouTube) would get this behavior for free, and sites which do (e.g. vimeo) can continue to explicitly hide the mouse cursor when hiding their custom controls. This new attribute is not currently hidden behind a feature flag. We are at the very initial stages of proposing this attribute to the CSSWG, but have already incorporated feedback from some of the WG members. Please take a look at the associated bug, if you're interested: https://bugs.webkit.org/show_bug.cgi?id=107601 Default mouse cursor behavior should be auto-hide for full screen video with custom controls -Jer ___ 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] New web-facing CSS feature: -webkit-cursor-visibility: auto-hide
On Mar 4, 2013, at 5:00 PM, James Robinson jam...@google.com wrote: On Mon, Mar 4, 2013 at 4:52 PM, Jer Noble jer.no...@apple.com wrote: On Mar 4, 2013, at 4:46 PM, Ryosuke Niwa rn...@webkit.org wrote: Could you add either build or runtime flag? I most definitely could. But are there any ports who would disable the flag? (Honestly asking, here.) If not, adding a feature flag may be more trouble than its worth. In chromium we would like the ability to monitor and, when appropriate, disable vendor-prefixed non-standard CSS properties. I think it's a bad idea to assume that by default all ports will want to expose non-standard API to the web platform without at least considering the situation and having a plan to remove at least the prefixed version. Please add a flag and, for bonus points, hook up FeatureObserver so we can monitor usage of this property. Sure thing. I'll ask around on IRC about FeatureObserver. -Jer ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] New web-facing CSS feature: -webkit-cursor-visibility: auto-hide
On Mon, Mar 4, 2013 at 4:52 PM, Jer Noble jer.no...@apple.com wrote: On Mar 4, 2013, at 4:46 PM, Ryosuke Niwa rn...@webkit.org wrote: Could you add either build or runtime flag? I most definitely could. But are there any ports who would disable the flag? (Honestly asking, here.) If not, adding a feature flag may be more trouble than its worth. In my opinion, it is a good practice to have build flag until a feature is ready for prime time. In WebKit, we make no assumption on when anyone ship anything. Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] New web-facing CSS feature: -webkit-cursor-visibility: auto-hide
On Mon, Mar 4, 2013 at 5:01 PM, Jer Noble jer.no...@apple.com wrote: On Mar 4, 2013, at 5:00 PM, James Robinson jam...@google.com wrote: On Mon, Mar 4, 2013 at 4:52 PM, Jer Noble jer.no...@apple.com wrote: On Mar 4, 2013, at 4:46 PM, Ryosuke Niwa rn...@webkit.org wrote: Could you add either build or runtime flag? I most definitely could. But are there any ports who would disable the flag? (Honestly asking, here.) If not, adding a feature flag may be more trouble than its worth. As everyone else has already stated, it's a good practice to wrap new features behind a build flag so that we may disable the feature as needed. e.g. your proposal needs to be modified significantly before it can be standardized. It'll be bad if browsers with a faster release cycle (e.g. Chrome) ended up shipping this property while such a discussion is taking place. The general rule of thumb is to have a build flag at least until the specification reaches CR. In chromium we would like the ability to monitor and, when appropriate, disable vendor-prefixed non-standard CSS properties. I think it's a bad idea to assume that by default all ports will want to expose non-standard API to the web platform without at least considering the situation and having a plan to remove at least the prefixed version. Please add a flag and, for bonus points, hook up FeatureObserver so we can monitor usage of this property. Sure thing. Thanks! - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] New web-facing CSS feature: -webkit-cursor-visibility: auto-hide
On Mon, Mar 4, 2013 at 5:07 PM, Ryosuke Niwa rn...@webkit.org wrote: On Mon, Mar 4, 2013 at 5:01 PM, Jer Noble jer.no...@apple.com wrote: On Mar 4, 2013, at 5:00 PM, James Robinson jam...@google.com wrote: On Mon, Mar 4, 2013 at 4:52 PM, Jer Noble jer.no...@apple.com wrote: On Mar 4, 2013, at 4:46 PM, Ryosuke Niwa rn...@webkit.org wrote: Could you add either build or runtime flag? I most definitely could. But are there any ports who would disable the flag? (Honestly asking, here.) If not, adding a feature flag may be more trouble than its worth. As everyone else has already stated, it's a good practice to wrap new features behind a build flag so that we may disable the feature as needed. e.g. your proposal needs to be modified MAY need to be modified significantly. significantly before it can be standardized. It'll be bad if browsers with a faster release cycle (e.g. Chrome) ended up shipping this property while such a discussion is taking place. The general rule of thumb is to have a build flag at least until the specification reaches CR. In chromium we would like the ability to monitor and, when appropriate, disable vendor-prefixed non-standard CSS properties. I think it's a bad idea to assume that by default all ports will want to expose non-standard API to the web platform without at least considering the situation and having a plan to remove at least the prefixed version. Please add a flag and, for bonus points, hook up FeatureObserver so we can monitor usage of this property. Sure thing. Thanks! - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] New web-facing CSS feature: -webkit-cursor-visibility: auto-hide
Is -webkit-cursor-visibility just for video ? If so, I am personally very much in favor of such a selector. It's a common feature of full-screen video players, see e.g. http://www.longtailvideo.com/support/forums/jw-player/bug-reports/31053/mouse-cursor-does-not-disappear-in-fullscreen-mode/or http://forum.brightcove.com/t5/General-Development/Hide-Mouse-Pointer-in-Fullscreen/td-p/7128 . Here's a discussion by Chrome users: http://productforums.google.com/forum/#!topic/chrome/Hd7AZRWejpk . It would be nice to get this through the CSS group quickly and implement without the prefix. Silvia. On Tue, Mar 5, 2013 at 11:37 AM, Jer Noble jer.no...@apple.com wrote: In an effort to improve the user-experience of watching videos in full screen mode, I have created a patch which adds a new CSS style attribute: -webkit-cursor-visibility. When set to auto-hide, this rule would change the cursor type to none after a few seconds of inactivity. UAs could then add this rule to their UA full screen style sheets for full screened video elements, but this rule can be overridden by site authors to handle hiding the cursor (or not) themselves. Sites which do not hide the cursor during playback in full screen mode (e.g. YouTube) would get this behavior for free, and sites which do (e.g. vimeo) can continue to explicitly hide the mouse cursor when hiding their custom controls. This new attribute is not currently hidden behind a feature flag. We are at the very initial stages of proposing this attribute to the CSSWG, but have already incorporated feedback from some of the WG members. Please take a look at the associated bug, if you're interested: https://bugs.webkit.org/show_bug.cgi?id=107601 Default mouse cursor behavior should be auto-hide for full screen video with custom controls -Jer ___ 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] New web-facing CSS feature: -webkit-cursor-visibility: auto-hide
On Mar 4, 2013, at 5:17 PM, Silvia Pfeiffer silvi...@chromium.org wrote: Is -webkit-cursor-visibility just for video ? If so, I am personally very much in favor of such a selector. It's a common feature of full-screen video players, see e.g. http://www.longtailvideo.com/support/forums/jw-player/bug-reports/31053/mouse-cursor-does-not-disappear-in-fullscreen-mode/ orhttp://forum.brightcove.com/t5/General-Development/Hide-Mouse-Pointer-in-Fullscreen/td-p/7128 . Not necessarily, though it's first use case is for the video element in full screen mode. I can imagine that full screen canvas apps could use it as well. Here's a discussion by Chrome users: http://productforums.google.com/forum/#!topic/chrome/Hd7AZRWejpk . It would be nice to get this through the CSS group quickly and implement without the prefix. Agreed! -Jer ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] [webkit-help] [squirrelfish-dev] How to debug the JIT when it crash
Hi Arunprasad, Thanks for your tips. My environment as following: CPU: SH4; SVN revision: 65000 OS: WINCE Tool Chain: MSVS+PB JS test case: I cann’t get the single js test case. But I can reproduce it as this steps[First access the http://image.baidu.com/, then access http://maps.google.de, wait 2-5 minitues, it will crash. The crash type is “access violation”]. I have try to debug it, find that the crash was caused by the jit, if we disable the JIT feature, the browser will not crash. As the test case is very complex and it is hard to be simplify, so I don’t know how to debug it. I try to print all the emitted instructions, but it is too many for me to analyze, after the instructions were emitted, the instruction will be repatch or relink, so anybody can give me some suggestion for how to debug it. Thanks. From: talking1239+caf_=talking1239=126@gmail.com [mailto:talking1239+caf_=talking1239=126@gmail.com] On Behalf Of Arunprasad Rajkumar Sent: 2013年3月4日 20:28 To: talking1...@gmail.com Cc: webkit-h...@lists.webkit.org; squirrelfish-...@lists.webkit.org; webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] [webkit-help] [squirrelfish-dev] How to debug the JIT when it crash It will be good to mention CPU, WebKit SVN revision, OS, Tool Chain, JS test case name(Sun Spider,..?)..etc so that people can give more suggestions. On 4 March 2013 16:11, talking1...@gmail.com wrote: Hi All, apologies for the spam. right now I am trying to fix the jit crash bug, but I don't know how to start it, can anyone give me some suggestion? when javascript engine run some special test case, it will run crash. I have print all the emited instructions, but the instructions will be repatch or relink after it run, so is exist an way or steps for debugging it? Thanks in advance! -- BGs/Felix Shi ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev -- Arunprasad Rajkumar http://in.linkedin.com/in/ararunprasad http://in.linkedin.com/in/ararunprasad ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
