Re: [webkit-dev] JavaScriptCore Debugger - Non-Browser
Hi, could you please elaborate a bit more on this? Are there any definite plans and timelines already defined? What is the new direction for the JS debugger evolution? Thanks in advance, -Sergiy Temnikov Wakanda Server architect Message: 5 Date: Mon, 13 Feb 2012 11:46:10 -0800 From: Oliver Hunt oli...@apple.com To: Maciej Stachowiak m...@apple.com Cc: WebKit Development webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] JavaScriptCore Debugger - Non-Browser Implementation Message-ID: d67ef71c-9f30-4cc3-b9fd-a8c95391f...@apple.com Content-Type: text/plain; CHARSET=US-ASCII We actually want to kill the current debugging mechanisms as they're somewhat archaic in their current form (they require substantial [and fragile] work on the debugger side, and have a significant runtime cost). I'd be hesistant to start building anything new on top of what's currently there, but we do want to improve the dev support in JSC itself so we wouldn't say no to any patches in that direction. --Oliver Sergiy Temnikov Architecte Logiciel 4D SAS 60, rue d'Alsace 92110 Clichy France Standard : +33 1 40 87 92 00 Email :sergiy.temni...@4d.com Web : www.4D.com ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] JavaScriptCore Debugger - Non-Browser Implementation
Hi, The APIs exist, so it should be possible to make one, but no one has done so at this time, so far as I know. We did implement a remote debugger in JSC in Wakanda Server. It will be open-sourced very soon. For a quick demo please take a look at this video: http://www.wakanda.org/blog?page=2 -Sergiy Temnikov Wakanda Server architect Message: 4 Date: Mon, 13 Feb 2012 11:39:52 -0800 From: Maciej Stachowiak m...@apple.com To: Matt Veenstra matts_li...@tribalmedia.com Cc: WebKit Development webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] JavaScriptCore Debugger - Non-Browser Implementation Message-ID: f2261cff-e25e-41cd-8f71-c001c4db6...@apple.com Content-Type: text/plain; CHARSET=US-ASCII On Feb 7, 2012, at 10:18 PM, Matt Veenstra wrote: Hello, I am looking for a tool to help debug JavaScript code for JavaScriptCore when NOT using a browser? I did a bit of research and did not find anything that seems to attach and debug at a code level and ignore the DOM. Is there something simple I missed? Drosera seemed to exist in the past. Is this the proper list for this question? I don't believe there is a pre-made tool for debugging JavaScript code in JSC outside of WebKit. The APIs exist, so it should be possible to make one, but no one has done so at this time, so far as I know. Regards, Maciej Sergiy Temnikov Architecte Logiciel 4D SAS 60, rue d'Alsace 92110 Clichy France Standard : +33 1 40 87 92 00 Email :sergiy.temni...@4d.com Web : www.4D.com ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Qt Snow Leopard buildbot.
Hi all, Qt Snow Leopard build bot is experiencing some hardware issues. It seems like the MacBook Pro it was running on died, the machine doesn't even want to switch on. I'll try to bring it back to life today. Sorry for the inconvenience. Thanks. -- Alexis Menard (darktears) Software Engineer INdT Recife Brazil ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Is the style bot OK?
I've been trying to send a patch to bug 78600 for a few hours, but the style bot is always rejecting [1] it when trying to apply a separate patch. Does the bot need some love? [1] https://bugs.webkit.org/show_bug.cgi?id=78600#c2 -- Raphael Kubo da Costa ProFUSION embedded systems http://profusion.mobi ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Is the style bot OK?
It does seem wedged. However it will reset itself every 20 patches or so: http://trac.webkit.org/browser/trunk/Tools/EWSTools/start-queue.sh On Tue, Feb 14, 2012 at 8:44 AM, Raphael Kubo da Costa k...@profusion.mobi wrote: I've been trying to send a patch to bug 78600 for a few hours, but the style bot is always rejecting [1] it when trying to apply a separate patch. Does the bot need some love? [1] https://bugs.webkit.org/show_bug.cgi?id=78600#c2 -- Raphael Kubo da Costa ProFUSION embedded systems http://profusion.mobi ___ 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] Is the style bot OK?
Sorry about that. I tried to fix it last night but apparently was unsuccessful. I'll try again. Adam On Feb 14, 2012 8:43 AM, Raphael Kubo da Costa k...@profusion.mobi wrote: I've been trying to send a patch to bug 78600 for a few hours, but the style bot is always rejecting [1] it when trying to apply a separate patch. Does the bot need some love? [1] https://bugs.webkit.org/show_bug.cgi?id=78600#c2 -- Raphael Kubo da Costa ProFUSION embedded systems http://profusion.mobi ___ 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] optimizing browser handling of Facebook Timeline scrolling
If anyone needs a test page, you can log in as my test user styoung.tra...@gmail.com (pwd:browsertest). Then go to https://www.facebook.com/styoung. you could maintain a separate document for measuring items, so you could measure without reflowing the main document. We are actually already doing that. Kelly Norton suggested offline to me that the problem could be layout thrash caused by us doing interleaved dom reads/writes (one for each story) as opposed to a series of reads followed by a series of writes. That sounds right to me. (2) 50% of time spent painting images... This is a simple speed vs quality tradeoff. If you down-sampled the images on the server, they'd download and paint much faster. Thanks. Downsampling sounds like a straightforward solution. We can show the higher quality image if they open the photo. Btw, what tool are you using that tells you what item is being repainted when the cpu is pegged? ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] optimizing browser handling of Facebook Timeline scrolling
On Feb 14, 2012, at 10:25 AM, Steven Young wrote: (2) 50% of time spent painting images... This is a simple speed vs quality tradeoff. If you down-sampled the images on the server, they'd download and paint much faster. Thanks. Downsampling sounds like a straightforward solution. We can show the higher quality image if they open the photo. The significant time spent painting images could simply be a sign that too much of the page is being repainted when scrolling, which could be a side effect of unnecessary re-layouts. So this could just another symptom of the layout thrash problem. Thus, I would suggest fixing the other issues and retesting before you move to downsample images. Btw, what tool are you using that tells you what item is being repainted when the cpu is pegged? I would guess that Geoff is using the Instruments tool on Mac OS X, but it likely takes some expert knowledge to interpret the profile. You can tell by looking at the profile what kind of things are getting painted, but not necessarily the specific item. REgards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] optimizing browser handling of Facebook Timeline scrolling
If anyone needs a test page, you can log in as my test user styoung.tra...@gmail.com (pwd:browsertest). Then go to https://www.facebook.com/styoung. Nice! I took a trace of this timeline and saw similar results as before (lots of time computing .offsetHeight and .scrollLeft), but with less time spent in image drawing. (Perhaps I have higher resolution photos in my timeline.) Btw, what tool are you using that tells you what item is being repainted when the cpu is pegged? Mac OS X ships with a performance analysis tool called Instruments. Documentation overview: https://developer.apple.com/library/wwdc/ios/#documentation/DeveloperTools/Conceptual/InstrumentsUserGuide/Introduction/Introduction.html#//apple_ref/doc/uid/TP40004652 Recent WWDC presentation: https://developer.apple.com/wwdc/schedule/details.php?id=310 Instruments analysis doesn't work very well with the current shipping version of WebKit, but it works great with WebKit nightly builds (nightly.webkit.org). Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Web Notifications API
Both GMail and Google Calendar are using text based notification, not html notification. What kind of notifications do IRCCloud, New York Timers skimmer view, and TweetDeck use, text based or html? Are notifications trigger from the web site or Chrome App extension? On Mon, Feb 13, 2012 at 6:05 PM, Adam Barth aba...@webkit.org wrote: On Mon, Feb 13, 2012 at 5:31 PM, David Levin le...@chromium.org wrote: On Mon, Feb 13, 2012 at 5:29 PM, Adam Barth aba...@webkit.org wrote: On Mon, Feb 13, 2012 at 5:23 PM, Jon Lee jon...@apple.com wrote: I also have concerns about backwards compatibility support. Aside from Gmail, what other web sites have integrated the notifications feature? I could only find example pages, one of which was using already an outdated API. IRCCloud is an example of a site that I use every day that uses notifications. Google Calendar fwiw ( http://www.howtogeek.com/howto/28573/how-to-enable-desktop-notifications-for-google-calendar-in-chrome/ ) They're also used by the New York Times skimmer view as well as TweetDeck. (These are just web sites I happened to use personally, not any sort of exhaustive list.) Adam ___ 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] Web Notifications API
On Tue, Feb 14, 2012 at 2:07 PM, Jian Li jia...@chromium.org wrote: Both GMail and Google Calendar are using text based notification, not html notification. What kind of notifications do IRCCloud, New York Timers skimmer view, and TweetDeck use, text based or html? I believe they use text-based notifications, but I haven't debugged them. I just noticed the notifications being used. Are notifications trigger from the web site or Chrome App extension? These are web sites, not Chrome apps/extensions. Adam On Mon, Feb 13, 2012 at 6:05 PM, Adam Barth aba...@webkit.org wrote: On Mon, Feb 13, 2012 at 5:31 PM, David Levin le...@chromium.org wrote: On Mon, Feb 13, 2012 at 5:29 PM, Adam Barth aba...@webkit.org wrote: On Mon, Feb 13, 2012 at 5:23 PM, Jon Lee jon...@apple.com wrote: I also have concerns about backwards compatibility support. Aside from Gmail, what other web sites have integrated the notifications feature? I could only find example pages, one of which was using already an outdated API. IRCCloud is an example of a site that I use every day that uses notifications. Google Calendar fwiw (http://www.howtogeek.com/howto/28573/how-to-enable-desktop-notifications-for-google-calendar-in-chrome/) They're also used by the New York Times skimmer view as well as TweetDeck. (These are just web sites I happened to use personally, not any sort of exhaustive list.) Adam ___ 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] Web Notifications API
I think TweetDeck actually uses HTML notifications. Daniel On Tue, Feb 14, 2012 at 14:14, Adam Barth aba...@webkit.org wrote: On Tue, Feb 14, 2012 at 2:07 PM, Jian Li jia...@chromium.org wrote: Both GMail and Google Calendar are using text based notification, not html notification. What kind of notifications do IRCCloud, New York Timers skimmer view, and TweetDeck use, text based or html? I believe they use text-based notifications, but I haven't debugged them. I just noticed the notifications being used. Are notifications trigger from the web site or Chrome App extension? These are web sites, not Chrome apps/extensions. Adam On Mon, Feb 13, 2012 at 6:05 PM, Adam Barth aba...@webkit.org wrote: On Mon, Feb 13, 2012 at 5:31 PM, David Levin le...@chromium.org wrote: On Mon, Feb 13, 2012 at 5:29 PM, Adam Barth aba...@webkit.org wrote: On Mon, Feb 13, 2012 at 5:23 PM, Jon Lee jon...@apple.com wrote: I also have concerns about backwards compatibility support. Aside from Gmail, what other web sites have integrated the notifications feature? I could only find example pages, one of which was using already an outdated API. IRCCloud is an example of a site that I use every day that uses notifications. Google Calendar fwiw ( http://www.howtogeek.com/howto/28573/how-to-enable-desktop-notifications-for-google-calendar-in-chrome/ ) They're also used by the New York Times skimmer view as well as TweetDeck. (These are just web sites I happened to use personally, not any sort of exhaustive list.) Adam ___ 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 mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Including new IETestCenter tests in the LayoutTests
Greetings, I am currently looking at the WebKit CSS3 failures on IETestCenter (http://samples.msdn.microsoft.com/ietestcenter/ ). I'm making some progress, and getting ready to submit a patch. I've contacted Beth Dakin about my approach on the first patch, and she says I should proceed. As part of the patch, of course I need to submit a passing layout test. This is where a question for the community arises: Presuming it is legal (I have my legal department looking at it), I think it makes sense to bring in the tests verbatim from the IETestCenter site. I do understand that there will likely be some overlap (thus, inefficiency) in coverage, but I think having a complete, identical set of tests will make it easier to verify WebKit's performance in this test suite. There is a precedent for this: the IETestCenter javascript tests are already present in the LayoutTests tree. The alternative is to write new tests or enhance existing tests in the current LayoutTests tree. I'm open to either approach, just need some direction from the team. -Dave Tharp ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Can you help me with a problem obtaining the size of content after a WebView has been resized?
Hi. I'm trying to use WebKit WebView inside a view-based NSTableView (OSX 10.7.2) and it works fairly well except for one (for me) show-stopper problem. My table is using a custom NSView (XKMessageView) that contains two subviews. The first is an NSView with a button, the second is a WebKit WebView. Because the web content can be of variable length (and because I do not want to use scrollbars in the web content) I am using a variable row-height table to show the selected row tall enough to fit the whole of the web content. I do this by implementing the NSTableView delegate method: - (CGFloat)tableView:(NSTableView *)tableView heightOfRow:(NSInteger)row To implement this method I need to answer the question What height is the web content? Looking around I found that one approach was to use: webFrame.frameView.documentView.frame.height and, on the face of it, this seemed to work pretty well. Now the selected row could be expanded to show the full web content for that row. Now when the table view is resized the web content may end up taller or shorter and depending on the new size of the view. So I had my delegate implement the notification: - (void)windowResized:(NSNotification *)notification In response to the window being resized the delegate asks the WebView for it's new desired size and then invalidates the row height for the selected row. I tested making the window very narrow and, just like magic, the WebView grew taller and taller in response. Then I made my window very wide again and this is where I hit my problem. The WebView did not get shorter as it had gotten taller. Or, rather, it did but only very slowly and by repeatedly resizing the window. If you want to see what I mean this 30s screen capture highlights the effect: http://f.cl.ly/items/1h1s2W05133m3d3t2v2J/ScreenFlow.mov What you can see is several rows in a table, each containing a view with a button and then a WebView. I shrink the width of the window and the WebView for the selected row gets taller in response. But when I drag the window wide again it doesn't immediate shrink back to it's original height. The content shrinks but the view remains large and leaves a big white gap behind it. However if I keep resizing the window by waggling the window edge (forcing repeated calls to frame.height) then the view does, gradually, shrink back to fit the content. In the console I can by logging the value of documentView.frame.height that, in successive notification cycles, it gradually decreases until it stablises at the value that fits the content. So, when the view gets narrower the height snaps to the right value. When the view gets wider the height decays to the right value. I have also tried, as an alternative to documentView.frame.height, using the DOM API to access clientHeight, scrollHeight and offsetHeight properties of the body element of the WebView document. In the case of clientHeight it does not vary at all, and the scrollHeight and offsetHeight show this same curious property of decreasing only over time. So I am stuck very close to my goal. The WebViews in the table work, they grow taller to accommodate the containing view being made narrower. But they do not grow shorter in the same way leaving a big unsightly gap. Here is my test code: https://gist.github.com/7aba5c24046462284c95 If anyone can help me understand how to achieve my goal or offer me any further pointers in how to explore the problem I would be most grateful. Kind regards, Matt -- http://mattmower.com/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Including new IETestCenter tests in the LayoutTests
On Tue, Feb 14, 2012 at 3:03 PM, Dave Tharp dth...@codeaurora.org wrote: I am currently looking at the WebKit CSS3 failures on IETestCenter (http://samples.msdn.microsoft.com/ietestcenter/ ). I’m making some progress, and getting ready to submit a patch. I’ve contacted Beth Dakin about my approach on the first patch, and she says I should proceed. As part of the patch, of course I need to submit a passing layout test. This is where a question for the community arises: Presuming it is legal (I have my legal department looking at it), I think it makes sense to bring in the tests verbatim from the IETestCenter site. I do understand that there will likely be some overlap (thus, inefficiency) in coverage, but I think having a complete, identical set of tests will make it easier to verify WebKit’s performance in this test suite. There is a precedent for this: the IETestCenter javascript tests are already present in the LayoutTests tree. Assuming there are no legal barriers, importing the whole test suite would be valuable. The LayoutTests contain a number of test suites developed externally (e.g., acid3, W3C conformance tests). Some of these tests are redundant with other tests, but having the whole test suite as a unit is valuable itself. The alternative is to write new tests or enhance existing tests in the current LayoutTests tree. I’m open to either approach, just need some direction from the team. That path is also fine. I would encourage you to import all of the IE test center CSS tests (assuming it passes legal muster). Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Propose adding button support to text based notifications (Was: Removing HTML notifications from WebKit)
One of the reasons for using html notifications is to allow direct interaction with the notifications. Here're some scenarios from our customers that want to use html notifications purely for this purpose: 1) In calendar notifications, the user might want to snooze the reminder for some time. 2) In email notifications, it might be very convenient if the user can archive/delete directly from the notification, since often the snippet will provide enough context to do this. 3) In voice/video chat notifications, the user could click on Answer or Accept button directly, instead of clicking on the notification message and then being presented with another UI where Answer or Accept is there. It seems to be very useful if we could enhance the text notifications by adding optional button support. If the underlying system does not support showing extra buttons, it will get handled in the traditional way. Thanks, Jian On Mon, Feb 13, 2012 at 11:23 AM, Maciej Stachowiak m...@apple.com wrote: This plan sounds reasonable to me. No disruption of Chrome extensions in the short term, but we would better align with each other and with standards in the longer term. Jon? Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Propose adding button support to text based notifications (Was: Removing HTML notifications from WebKit)
On Tue, Feb 14, 2012 at 5:59 PM, Jian Li jia...@chromium.org wrote: One of the reasons for using html notifications is to allow direct interaction with the notifications. Here're some scenarios from our customers that want to use html notifications purely for this purpose: Does any platform provide this kind action in their native notification? If not, aren't you just repeating the same mistake as HTML notifications? Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Propose adding button support to text based notifications (Was: Removing HTML notifications from WebKit)
On Tue, Feb 14, 2012 at 6:13 PM, Benjamin Poulain benja...@webkit.orgwrote: On Tue, Feb 14, 2012 at 5:59 PM, Jian Li jia...@chromium.org wrote: One of the reasons for using html notifications is to allow direct interaction with the notifications. Here're some scenarios from our customers that want to use html notifications purely for this purpose: Does any platform provide this kind action in their native notification? If not, aren't you just repeating the same mistake as HTML notifications? I hate to reopen this particular point of discussion again (because many many words have already been exchanged about this on the WebApps mailing list), but are you maintaining that we should only expose functionality in our notification APIs that can be supported by native notification platforms? Because that path leads to a lowest-common-denominator API that doesn't support things like onclick events (since NotifyOSD doesn't support clicks on notifications). I know that some people feel that compatibility with Growl should be one of our prime concerns when crafting this API, but keep in mind that there is disagreement on that point, the standard body explicitly made this a non-goal, and so I think we ought to consider API suggestions on their merits rather than in light of whether they can be mapped to any specific native notification framework. Anyhow, Jian, if you think this is a valuable addition, you might want to bring it up on the standards list. I know it's come up before, but we've always pointed to HTML notifications to address those use cases, so it might bear reconsidering if nobody is going to support HTML notifications. Benjamin ___ 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] Layout issue with fieldset legend element
Hi, While working on webkit bug#:50287 ( https://bugs.webkit.org/show_bug.cgi?id=50287), i found another issue related to legend element of fieldset form-property as described below. On applying padding style information to fieldset legend element, the bottom border gets clipped-off in Safari and Chrome. (Padding more than 8px). There is no such issue on FF IE with any value or percentage of Padding. Following is the simple test case to reproduce the issue on Safari and Chrome.(Also attached as test.html) html head style type=text/css fieldset legend{ padding: 20px; } /style /head formfieldsetlegendHAPPY/legend/fieldset/form /html On analyzing further, I found that clipping of legend element is buggy in WebKit, and i may have the fix for it. I intend to submit this as a new bug, and submit the patch for it. Please let me know if any one think otherwise. -Sravan. HAPPY ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev