Re: [webkit-dev] build.webkit.org problem
Hi, Sure, I filed a bug for the sick(dying) build.webkit.org: https://bugs.webkit.org/show_bug.cgi?id=79474 I hope it will be recovered once from this long and serious sickness. ;) br, Ossy On 02/22/2012 11:12 PM, Lucas Forschler wrote: Can you open a bugzilla bug, and we can use that to keep any investigations documented? Thanks, Lucas ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] How to specify the window size in DumpRenderTree?
Hi, I want to specify the window size/view size in DumpRenderTree, so that rendertree, can reflect the structure according to the new window size. Is there an existing option/method to do so? Thanks in advance. --Mayur Kankanwadi. -- Symbiangeek,Codekata Webkitwiki all in one - http://flaminghorns.com ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] build.webkit.org is very sick
I restarted the master so it's back for now. -Bill On Feb 23, 2012, at 11:05 PM, Osztrogonac Csaba wrote: Hi again, Now the things are going from bad to worse: Service Temporarily Unavailable The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later. :(( Are you planning to fix http://build.webkit.org in the near future? br, Ossy Osztrogonac Csaba írta: it seems build.webkit.org is very very sick. Almost all builds are broken with a strange exception and there are zillion strange stucked builds: building 1 min 1 min 1 min 1 min 1 min 1 min 1 min Could you check what happened? ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] build.webkit.org is very sick
It's not responding now. This system is mission-critical to the webkit project. What do we need to do to improve the uptime and performance? Simon On Feb 24, 2012, at 6:55 AM, William Siegrist wrote: I restarted the master so it's back for now. -Bill On Feb 23, 2012, at 11:05 PM, Osztrogonac Csaba wrote: Hi again, Now the things are going from bad to worse: Service Temporarily Unavailable The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later. :(( Are you planning to fix http://build.webkit.org in the near future? br, Ossy Osztrogonac Csaba írta: it seems build.webkit.org is very very sick. Almost all builds are broken with a strange exception and there are zillion strange stucked builds: building 1 min 1 min 1 min 1 min 1 min 1 min 1 min Could you check what happened? ___ 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] build.webkit.org is very sick
Lucas will be looking into it. -Bill On Feb 24, 2012, at 9:16 AM, Simon Fraser simon.fra...@apple.com wrote: It's not responding now. This system is mission-critical to the webkit project. What do we need to do to improve the uptime and performance? Simon On Feb 24, 2012, at 6:55 AM, William Siegrist wrote: I restarted the master so it's back for now. -Bill On Feb 23, 2012, at 11:05 PM, Osztrogonac Csaba wrote: Hi again, Now the things are going from bad to worse: Service Temporarily Unavailable The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later. :(( Are you planning to fix http://build.webkit.org in the near future? br, Ossy Osztrogonac Csaba írta: it seems build.webkit.org is very very sick. Almost all builds are broken with a strange exception and there are zillion strange stucked builds: building 1 min 1 min 1 min 1 min 1 min 1 min 1 min Could you check what happened? ___ 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] build.webkit.org is very sick
32$ $ time curl http://build.webkit.org !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN http://www.w3.org/TR/html4/loose.dtd; html head meta http-equiv=Content-Type content=text/html; charset=iso-8859-15 titleWelcome to the Buildbot/title /head body h1Welcome to the Buildbot!/h1 ul lia href=consoleConsole/a - a href=console?category=AppleMacApple Mac/a, a href=console?category=AppleWinApple Windows/a, a href=console?category=GTKGTK+/a, a href=console?category=QtQt/a, a href=console?category=ChromiumChromium/a, and a href=console?category=miscmiscellaneous/a/li lia href=waterfallWaterfall Display/a, a time-oriented summary of recent buildbot activity - a href=waterfall?category=AppleMacApple Mac/a, a href=waterfall?category=AppleWinApple Windows/a, a href=waterfall?category=GTKGTK+/a, a href=waterfall?category=QtQt/a, a href=waterfall?category=ChromiumChromium/a, and a href=waterfall?category=miscmiscellaneous/a/li lia href=one_box_per_builderLatest Build/a for each builder is here./li lia href=one_line_per_buildRecent Builds/a are summarized here, one per line./li lia href=buildslavesBuildslave/a information/li lia href=http://webkit-commit-queue.appspot.com/;Commit Queue Status/a information./li lia href=changesChangeSource/a information./li lia href=resultsTest Results/a/li lia href=LeaksViewerLeaks Viewer/a/li lia href=TestFailuresTest Failures/a/li /ul /body /html real2m28.272s user0m0.007s sys 0m0.009s On Feb 24, 2012, at 9:16 AM, Simon Fraser wrote: It's not responding now. This system is mission-critical to the webkit project. What do we need to do to improve the uptime and performance? Simon On Feb 24, 2012, at 6:55 AM, William Siegrist wrote: I restarted the master so it's back for now. -Bill On Feb 23, 2012, at 11:05 PM, Osztrogonac Csaba wrote: Hi again, Now the things are going from bad to worse: Service Temporarily Unavailable The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later. :(( Are you planning to fix http://build.webkit.org in the near future? br, Ossy Osztrogonac Csaba írta: it seems build.webkit.org is very very sick. Almost all builds are broken with a strange exception and there are zillion strange stucked builds: building 1 min 1 min 1 min 1 min 1 min 1 min 1 min Could you check what happened? ___ 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
Re: [webkit-dev] WebKit modularization
22.02.2012, в 22:08, Kentaro Hara написал(а): TL;DR: We are starting WebKit modularization. Self-contained features like WebAudio, WebSocket, IndexedDB, File APIs ...etc will be moved from WebCore/ to WebCore/Modules/. Looking at patches that are actually getting landed, they go far beyond this idea. See e.g. bug 79436 - Move HTML-related APIs from DOMWindow.idl to DOMWindowHTML.idl. How is HTML a self-contained feature? I see a lot of downside in such refactoring, and don't really see any benefit: 1) It gets very hard to navigate source code, as you never know where a given function is. You can't find it, you can't see if it's even there without a full code search. 2) The division lines are very arbitrary. For example, bug 79434 moved XML-related APIs to a separate file, including window.XMLDocument, which is as core to DOM as it gets. 3) The moves don't respect original licenses - e.g. DOMWindowXML.idl is LGPL, while DOMWindow.idl is BSD. 4) More files means longer build times. I think that most of the patches landed under this umbrella should be reconsidered, and most immediately those that had license wrong. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit modularization
2012/2/24 Alexey Proskuryakov a...@webkit.org: 22.02.2012, в 22:08, Kentaro Hara написал(а): TL;DR: We are starting WebKit modularization. Self-contained features like WebAudio, WebSocket, IndexedDB, File APIs ...etc will be moved from WebCore/ to WebCore/Modules/. Looking at patches that are actually getting landed, they go far beyond this idea. See e.g. bug 79436 - Move HTML-related APIs from DOMWindow.idl to DOMWindowHTML.idl. How is HTML a self-contained feature? I see a lot of downside in such refactoring, and don't really see any benefit: 1) It gets very hard to navigate source code, as you never know where a given function is. You can't find it, you can't see if it's even there without a full code search. 2) The division lines are very arbitrary. For example, bug 79434 moved XML-related APIs to a separate file, including window.XMLDocument, which is as core to DOM as it gets. 3) The moves don't respect original licenses - e.g. DOMWindowXML.idl is LGPL, while DOMWindow.idl is BSD. 4) More files means longer build times. I think that most of the patches landed under this umbrella should be reconsidered, and most immediately those that had license wrong. I'm happy to re-check them for license errors. If you can send me a list of the license errors you've noticed, I'll make sure they get addressed. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit modularization
On Feb 24, 2012, at 9:57 AM, Alexey Proskuryakov wrote: 22.02.2012, в 22:08, Kentaro Hara написал(а): TL;DR: We are starting WebKit modularization. Self-contained features like WebAudio, WebSocket, IndexedDB, File APIs ...etc will be moved from WebCore/ to WebCore/Modules/. Looking at patches that are actually getting landed, they go far beyond this idea. See e.g. bug 79436 - Move HTML-related APIs from DOMWindow.idl to DOMWindowHTML.idl. How is HTML a self-contained feature? I see a lot of downside in such refactoring, and don't really see any benefit: 1) It gets very hard to navigate source code, as you never know where a given function is. You can't find it, you can't see if it's even there without a full code search. 2) The division lines are very arbitrary. For example, bug 79434 moved XML-related APIs to a separate file, including window.XMLDocument, which is as core to DOM as it gets. 3) The moves don't respect original licenses - e.g. DOMWindowXML.idl is LGPL, while DOMWindow.idl is BSD. 4) More files means longer build times. I think that most of the patches landed under this umbrella should be reconsidered, and most immediately those that had license wrong. I too am surprised that HTML-related APIs would be refactored as a result of modularization. This change may be justifiable on its own merits, but it doesn't seem like a logical part of a project to make self-contained features more modular. At the very least, to avoid confusion, changes like that should be kept clearly separate from the modularization effort, or else, someone could explain the relationship if there is one and its not obvious. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Making DOMWindow less epic (was Re: WebKit modularization)
2012/2/24 Maciej Stachowiak m...@apple.com: I too am surprised that HTML-related APIs would be refactored as a result of modularization. This change may be justifiable on its own merits, but it doesn't seem like a logical part of a project to make self-contained features more modular. At the very least, to avoid confusion, changes like that should be kept clearly separate from the modularization effort, or else, someone could explain the relationship if there is one and its not obvious. Fair enough. I've detached those bugs from the larger meta bug. These patches have a different goal than the other patches attached to that meta bug. Much in the same way that we've moved code out of Frame.h over time, these patches are intended to make DOMWindow.idl more readable. The net result will (hopefully!) be a file that's more focused on concerns that actually relate to DOMWindow (e.g., name/closed/opener/parent/top) rather than a dumping ground for every random thing that needs to be in the global scope. In retrospect, we should have presented this work separately so folks could have discussed its merits separately. I think we got tied up in the implementation detail that the same mechanism makes both projects possible. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] How to specify the window size in DumpRenderTree?
In your test case, you should be able to use window.resizeTo to change the size of the window. On Fri, Feb 24, 2012 at 5:01 AM, Mayur K emineme...@gmail.com wrote: Hi, I want to specify the window size/view size in DumpRenderTree, so that rendertree, can reflect the structure according to the new window size. Is there an existing option/method to do so? Thanks in advance. --Mayur Kankanwadi. -- Symbiangeek,Codekata Webkitwiki all in one - http://flaminghorns.com ___ 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 to specify the window size in DumpRenderTree?
Well, that would be too limiting.Passing the window size as a command line option would be better, to get know the content behavior and would avoid adding the resizeTo to every content. Also adding resizeTo would not be an option to live content. I tried playing around with the windows port of DumpRenderTree. But could not figure out the way to provide the window size to affect the rendertree, it was taking the default values of 800 X 600 always. --Mayur. On Sat, Feb 25, 2012 at 12:06 AM, Tony Chang t...@chromium.org wrote: In your test case, you should be able to use window.resizeTo to change the size of the window. On Fri, Feb 24, 2012 at 5:01 AM, Mayur K emineme...@gmail.com wrote: Hi, I want to specify the window size/view size in DumpRenderTree, so that rendertree, can reflect the structure according to the new window size. Is there an existing option/method to do so? Thanks in advance. --Mayur Kankanwadi. -- Symbiangeek,Codekata Webkitwiki all in one - http://flaminghorns.com ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- Symbiangeek,Codekata Webkitwiki all in one - http://flaminghorns.com ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Bash scripts should support LF endings only
Webkit, Bash scripts with CRLF are failing on some versions of bash. I've filed this issue under bug 78953 in a wider context but decided it's best to have its own bug: 79509. In short, the issue is that some bash scripts have their svn:eol-style set to native, which is CRLF on Windows. This is causing build failures on some version of cygwin-bash that don't like CR in the scripts. I'm looking for someone who has commit rights and is willing to volunteer to set svn:eol-style to LF on all .sh scripts and commit. AFAIK changing properties aren't well supported in diff so I can't submit a patch for review and commit-queue (please correct me if that's not the case, I'll take it from there). Any help is highly appreciated. Thanks in advance. -Ash___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Bash scripts should support LF endings only
On Fri, Feb 24, 2012 at 11:13 AM, Ashod Nakashian ashodnakash...@yahoo.comwrote: In short, the issue is that some bash scripts have their svn:eol-style set to native, which is CRLF on Windows. This is causing build failures on some version of cygwin-bash that don't like CR in the scripts. I fixed a number of these cases in the past by doing precisely what you suggested, and got r+ from aroben IIRC. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Web Inspector tests for DOM node highlights
(CC-ing webkit-dev) I would not do that. We should not add methods for testing into the inspector protocol. Also, having the highlight figures right does not guarantee proper rendering (scrollbars, etc. might affect things). Ok. That makes sense. A lot can go wrong between having the correct quad values and getting them on the screen. I'll keep going with the pixel tests approach. Thanks for feedback, Max On 2/24/12 12:10 AM, Pavel Feldman pfeld...@chromium.org wrote: On Fri, Feb 24, 2012 at 2:00 AM, Max Vujovic mvujo...@adobe.com wrote: Hi Pavel, I'd like your opinion on another approach to enable highlight tests without using pixel tests. We could expose the highlight data to the inspector via a new method in InspectorDOMAgent.h called getHighlight. This would enable us to test the position and size of highlight quadrants programmatically, like the other inspector tests. I would not do that. We should not add methods for testing into the inspector protocol. Also, having the highlight figures right does not guarantee proper rendering (scrollbars, etc. might affect things). I would define getHighlight next to InspectorDOMAgent.h's other highlight-related methods (hideHighlight, highlightRect, highlightNode, and highlightFrame). A variant to this approach is that instead of defining a new method, the highlightNode method could return the highlight data. However, this approach is perhaps not as flexible or elegant in case the highlight changes (e.g. page zoom changes, the node changes). I'm bringing all of this up because I usually try to avoid pixel tests because of the associated platform maintenance, and the PNGs that make WebKit bigger. In this case, you are validating the result of the paint, so I think pixel tests are appropriate. What are your thoughts? Do you think we should expose the highlight information or create pixel tests? (Also, do you mind if we re-CC webkit-dev on this? I noticed we start emailing each other directly, and I have some colleagues at work who have become interested in this discussion.) Sure I don't mind. Regards Pavel Thanks, Max On 2/23/12 11:21 AM, Max Vujovic mvujo...@adobe.com wrote: Hi Pavel, Thanks for the guidance. I'll try the approach you described for grabbing pixels. I've been digging into the inspector harness lately (inspector-test.js), and it's making sense so far, but I'll inevitably have some questions for you when I hit a snag :). Thanks, Max On 2/23/12 11:05 AM, Pavel Feldman pfeld...@chromium.org wrote: Hi Max, Got it. I hate to say it, but implementing a harness for this case is likely to be more expensive than the fix itself. In your case, DOMNodeHighlighter::drawHighlight receives proper data (the node), but converts it into the graphics context poorly. As you suggested, I would probably go for a pixel test. Inspector's harness is fairly complex: our tests live under LayoutTests/inspector and LayoutTests/http/tests/inspector. I'd create a page like in your use case, pass node's handle to the front-end (as in many tests under inspector/elements), issue a DOMAgent.highlightNode(nodeId) followed by a RuntimeAgent.evaluate that would call a method on a page that tells layoutTestController to grab pixels. We don't have pixel tests for inspector, so I'd expect this last step to be challenging. If you are willing to give it a try, please go ahead. If you hit an issue, I'll be happy to help you out. Otherwise, I am now feeling bad for the lack of the highlight tests, so I'll probably put an effort into doing it myself. Regards Pavel On Thu, Feb 23, 2012 at 10:53 PM, Max Vujovic mvujo...@adobe.com wrote: Hi Pavel, I'm trying to test the position and size of the highlight quadrants (not the node). This screenshot of the bug I'm working on might make it more clear: https://bug-78037-attachments.webkit.org/attachment.cgi?id=128501 Here's direct link to the bug: https://bugs.webkit.org/show_bug.cgi?id=78037 In the screenshot, the blue, green, yellow, and orange quadrants should line up with the SVG element when the bug is fixed, and I'd like to create a test for that. Thanks, Max On 2/23/12 4:00 AM, Pavel Feldman pfeld...@chromium.org wrote: There are no tests covering the DOM Node highlight. It just paints quadrants for a given node. What are you trying to test, the highlight or the node position? Is there a bug you are fixing? Regards Pavel On Wed, Feb 22, 2012 at 11:10 PM, Max Vujovic mvujo...@adobe.com wrote: Hello, I was wondering if there are any Web Inspector tests that check the appearance, size, or position of a DOM node highlight. By DOM node highlight, I mean the translucent margin box, border box, padding box, and content box combination that WebKit draws over a DOM node when you inspect it. I need to write a test for a bug to check the size and position of the DOM node highlight for an SVG root element, and I've been searching for a similar test to imitate. I'd like to query the size and position
Re: [webkit-dev] Making DOMWindow less epic (was Re: WebKit modularization)
On Feb 24, 2012, at 10:27 AM, Adam Barth wrote: 2012/2/24 Maciej Stachowiak m...@apple.com: I too am surprised that HTML-related APIs would be refactored as a result of modularization. This change may be justifiable on its own merits, but it doesn't seem like a logical part of a project to make self-contained features more modular. At the very least, to avoid confusion, changes like that should be kept clearly separate from the modularization effort, or else, someone could explain the relationship if there is one and its not obvious. Fair enough. I've detached those bugs from the larger meta bug. These patches have a different goal than the other patches attached to that meta bug. Much in the same way that we've moved code out of Frame.h over time, these patches are intended to make DOMWindow.idl more readable. The net result will (hopefully!) be a file that's more focused on concerns that actually relate to DOMWindow (e.g., name/closed/opener/parent/top) rather than a dumping ground for every random thing that needs to be in the global scope. In retrospect, we should have presented this work separately so folks could have discussed its merits separately. I think we got tied up in the implementation detail that the same mechanism makes both projects possible. I think this case is a little different than Frame.h, because with Frame, we can actually move related methods to separate objects, thus actually splitting up the interface. This creates an actual separation of concerns in the code if done right, not just a file split. I'm not sure that having multiple files which actually all form a single interface is equally beneficial. It doesn't seem hugely worse, but it does not seem obviously better to me either. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Removing obsolete File attributes
As I mentioned in the bug, it is encouraging news that Mozilla has already removed these attributes (for a couple releases now). I would like to see them go away too. There's unfortunately, the real possibility that there may be some existing webkit-specific or chrome-specific (extensions) content out there that is expecting these properties to exist. I think we need to be a bit cautious since we've included these properties in webkit for such a long time (since 2008!). Here's the revision that added them: http://trac.webkit.org/changeset/34702 -Darin On Fri, Feb 24, 2012 at 9:36 AM, Alexey Proskuryakov a...@webkit.org wrote: I'd like to remove old File object properties that are superseded in current spec versions, and have been already removed from Firefox: https://bugs.webkit.org/show_bug.cgi?id=79383. Would any ports want to keep these under a feature flag, or to have some time to investigate possible consequences of the removal for port specific content? - WBR, Alexey Proskuryakov ___ 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] Making DOMWindow less epic (was Re: WebKit modularization)
On Fri, Feb 24, 2012 at 11:50 AM, Maciej Stachowiak m...@apple.com wrote: On Feb 24, 2012, at 10:27 AM, Adam Barth wrote: 2012/2/24 Maciej Stachowiak m...@apple.com: I too am surprised that HTML-related APIs would be refactored as a result of modularization. This change may be justifiable on its own merits, but it doesn't seem like a logical part of a project to make self-contained features more modular. At the very least, to avoid confusion, changes like that should be kept clearly separate from the modularization effort, or else, someone could explain the relationship if there is one and its not obvious. Fair enough. I've detached those bugs from the larger meta bug. These patches have a different goal than the other patches attached to that meta bug. Much in the same way that we've moved code out of Frame.h over time, these patches are intended to make DOMWindow.idl more readable. The net result will (hopefully!) be a file that's more focused on concerns that actually relate to DOMWindow (e.g., name/closed/opener/parent/top) rather than a dumping ground for every random thing that needs to be in the global scope. In retrospect, we should have presented this work separately so folks could have discussed its merits separately. I think we got tied up in the implementation detail that the same mechanism makes both projects possible. I think this case is a little different than Frame.h, because with Frame, we can actually move related methods to separate objects, thus actually splitting up the interface. This creates an actual separation of concerns in the code if done right, not just a file split. I'm not sure that having multiple files which actually all form a single interface is equally beneficial. It doesn't seem hugely worse, but it does not seem obviously better to me either. It's quite analogous to Frame.h in the sense that this mechanism also lets us move related methods to a separate object. Consider a case such as http://trac.webkit.org/browser/trunk/Source/WebCore/fileapi/DOMWindowFileSystem.idl. When we moved webkitRequestFileSystem from DOMWindow.idl to DOMWindowFileSystem.idl, the code for webkitRequestFileSystem moved from DOMWindow.cpp to http://trac.webkit.org/browser/trunk/Source/WebCore/fileapi/DOMWindowFileSystem.cpp#L53, separating these concerns from DOMWindow. In the case of http://trac.webkit.org/browser/trunk/Source/WebCore/html/DOMWindowHTML.idl, the C++ code that backs those interfaces is already in Source/WebCore/html. The net result is 100 less lines of noise in DOMWindow.idl. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Removing obsolete File attributes
On Feb 24, 2012, at 11:52 AM, Darin Fisher wrote: As I mentioned in the bug, it is encouraging news that Mozilla has already removed these attributes (for a couple releases now). I would like to see them go away too. There's unfortunately, the real possibility that there may be some existing webkit-specific or chrome-specific (extensions) content out there that is expecting these properties to exist. I think we need to be a bit cautious since we've included these properties in webkit for such a long time (since 2008!). Here's the revision that added them: http://trac.webkit.org/changeset/34702 Is there a good way to quantify and/or mitigate this risk? Regards, Maciej -Darin On Fri, Feb 24, 2012 at 9:36 AM, Alexey Proskuryakov a...@webkit.org wrote: I'd like to remove old File object properties that are superseded in current spec versions, and have been already removed from Firefox: https://bugs.webkit.org/show_bug.cgi?id=79383. Would any ports want to keep these under a feature flag, or to have some time to investigate possible consequences of the removal for port specific content? - WBR, Alexey Proskuryakov ___ 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
Re: [webkit-dev] Removing obsolete File attributes
On Fri, Feb 24, 2012 at 12:00 PM, Maciej Stachowiak m...@apple.com wrote: On Feb 24, 2012, at 11:52 AM, Darin Fisher wrote: As I mentioned in the bug, it is encouraging news that Mozilla has already removed these attributes (for a couple releases now). I would like to see them go away too. There's unfortunately, the real possibility that there may be some existing webkit-specific or chrome-specific (extensions) content out there that is expecting these properties to exist. I think we need to be a bit cautious since we've included these properties in webkit for such a long time (since 2008!). Here's the revision that added them: http://trac.webkit.org/changeset/34702 Is there a good way to quantify and/or mitigate this risk? Well, we could certainly instrument a Chrome nightly build to measure accesses made on these attributes, and see what that turns up. I haven't thought about it enough to decide what a good metric would be. You probably want to know the percentage of unique pages that depend on these features. It is probably easier to measure percentage of navigations that resulted in a document that depended on these features. That would over-estimate usage if a page that needs these features is navigated to frequently. I'm concerned that it may be tricky to grep the repository of Chrome extensions (or Google's index of the web) since fileName and fileSize are likely to be very common terms. -Darin Regards, Maciej -Darin On Fri, Feb 24, 2012 at 9:36 AM, Alexey Proskuryakov a...@webkit.orgwrote: I'd like to remove old File object properties that are superseded in current spec versions, and have been already removed from Firefox: https://bugs.webkit.org/show_bug.cgi?id=79383. Would any ports want to keep these under a feature flag, or to have some time to investigate possible consequences of the removal for port specific content? - WBR, Alexey Proskuryakov ___ 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
Re: [webkit-dev] Making DOMWindow less epic (was Re: WebKit modularization)
On Feb 24, 2012, at 11:58 AM, Adam Barth wrote: On Fri, Feb 24, 2012 at 11:50 AM, Maciej Stachowiak m...@apple.com wrote: On Feb 24, 2012, at 10:27 AM, Adam Barth wrote: 2012/2/24 Maciej Stachowiak m...@apple.com: I too am surprised that HTML-related APIs would be refactored as a result of modularization. This change may be justifiable on its own merits, but it doesn't seem like a logical part of a project to make self-contained features more modular. At the very least, to avoid confusion, changes like that should be kept clearly separate from the modularization effort, or else, someone could explain the relationship if there is one and its not obvious. Fair enough. I've detached those bugs from the larger meta bug. These patches have a different goal than the other patches attached to that meta bug. Much in the same way that we've moved code out of Frame.h over time, these patches are intended to make DOMWindow.idl more readable. The net result will (hopefully!) be a file that's more focused on concerns that actually relate to DOMWindow (e.g., name/closed/opener/parent/top) rather than a dumping ground for every random thing that needs to be in the global scope. In retrospect, we should have presented this work separately so folks could have discussed its merits separately. I think we got tied up in the implementation detail that the same mechanism makes both projects possible. I think this case is a little different than Frame.h, because with Frame, we can actually move related methods to separate objects, thus actually splitting up the interface. This creates an actual separation of concerns in the code if done right, not just a file split. I'm not sure that having multiple files which actually all form a single interface is equally beneficial. It doesn't seem hugely worse, but it does not seem obviously better to me either. It's quite analogous to Frame.h in the sense that this mechanism also lets us move related methods to a separate object. Consider a case such as http://trac.webkit.org/browser/trunk/Source/WebCore/fileapi/DOMWindowFileSystem.idl. When we moved webkitRequestFileSystem from DOMWindow.idl to DOMWindowFileSystem.idl, the code for webkitRequestFileSystem moved from DOMWindow.cpp to http://trac.webkit.org/browser/trunk/Source/WebCore/fileapi/DOMWindowFileSystem.cpp#L53, separating these concerns from DOMWindow. Splitting out the file-related stuff from DOMWindow seems justified based on modularity grounds, presuming we see File API as a self-contained feature. So no objection there. In the case of http://trac.webkit.org/browser/trunk/Source/WebCore/html/DOMWindowHTML.idl, the C++ code that backs those interfaces is already in Source/WebCore/html. The net result is 100 less lines of noise in DOMWindow.idl. It seems to me like the practical difference of the IDL move in this case is changing the IDL file where you need to add HTML elements, and adding an extra place you need to look to see what's in the global scope. It's not obvious to me that this is an improvement, but like I said, it doesn't seem terrible. I think there is a potentially even better approach here though. HTMLTagNames.in is already used to autogenerate most of the things that need to mention every HTML element. If it was used to avoid the need to explicitly mention all HTML element constructors in any IDL file at all, for instance by autogenerating one, then it would reduce the number of places that have to mention every HTML element by 1, and eliminate one of the possible mistakes when adding a new HTML element. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Removing obsolete File attributes
On Feb 24, 2012, at 12:06 PM, Darin Fisher wrote: On Fri, Feb 24, 2012 at 12:00 PM, Maciej Stachowiak m...@apple.com wrote: On Feb 24, 2012, at 11:52 AM, Darin Fisher wrote: As I mentioned in the bug, it is encouraging news that Mozilla has already removed these attributes (for a couple releases now). I would like to see them go away too. There's unfortunately, the real possibility that there may be some existing webkit-specific or chrome-specific (extensions) content out there that is expecting these properties to exist. I think we need to be a bit cautious since we've included these properties in webkit for such a long time (since 2008!). Here's the revision that added them: http://trac.webkit.org/changeset/34702 Is there a good way to quantify and/or mitigate this risk? Well, we could certainly instrument a Chrome nightly build to measure accesses made on these attributes, and see what that turns up. I haven't thought about it enough to decide what a good metric would be. You probably want to know the percentage of unique pages that depend on these features. It is probably easier to measure percentage of navigations that resulted in a document that depended on these features. That would over-estimate usage if a page that needs these features is navigated to frequently. I'm concerned that it may be tricky to grep the repository of Chrome extensions (or Google's index of the web) since fileName and fileSize are likely to be very common terms. Though you did not say so explicitly, it sounded to me like your suggested approach to this issue was let's remove these eventually, but maybe not right now. That sounds like a reasonable approach. But then we'll need to figure out if it's actually too costly to remove them right now, and if so, figure out how to get to the point that we feel comfortable removing them. I don't really have a specific kind of idea of what data would tell us these things. Your suggestions above seem ok. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] 48459: Glyphs in vertical text tests are rotated 90 degrees clockwise on Windows
Hi webkit-dev, I was looking into bug 48459: Glyphs in vertical text tests are rotated 90 degrees clockwise on Windows https://bugs.webkit.org/show_bug.cgi?id=48459 and found that it has two issues: 1. It does not support text-orientation[1] property as OS X does. 2. It uses @-font, which lets Windows do a magic to rotate some code points and apply 'vert' automatically. But that means WebKit has no control over the glyph orientations, and therefore orientation of some code points don't match to the one on OS X. I think the correct fix for the bug is to port showGlyphsWithAdvances from FontMac.mm to FontCGWin.cpp. But I then encounter an issue that WebKitLibraries does not support CTFontGetVerticalTranslationsForGlyphs API. Since Windows doesn't have such API, possible options I can think of are: 1. Bring the CTFontGetVerticalTranslationsForGlyphs API to WebKitLibraries. 2. Use other libraries such as FreeType[2] to read related OpenType tables. 3. Read raw tables using GetFontData Win32 API and parse vhea/vorg/vmtx tables etc. I have no idea how I can make option 1 happen. Any suggestions? [1] http://dev.w3.org/csswg/css3-writing-modes/#text-orientation [2] http://freetype.sourceforge.net/license.html Regards, Koji ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] 48459: Glyphs in vertical text tests are rotated 90 degrees clockwise on Windows
Thank you Ryosuke for the prompt reply. 1. Bring the CTFontGetVerticalTranslationsForGlyphs API to WebKitLibraries. 2. Use other libraries such as FreeType[2] to read related OpenType tables. 3. Read raw tables using GetFontData Win32 API and parse vhea/vorg/vmtx tables etc. Option 3 seems most desirable since it doesn't introduce new dependencies. Okay...I was afraid of that, because then the patch becomes larger and it might make review harder. But if that's preferable than introducing new dependencies, I can look into that. I checked other platforms quickly. Without knowing much of them, from the submitted patches, APIs of Qt[1] and Gtk[2] look like similar to the one on OS X, but it wasn't clear to me if the patches support upright for non-CJK letters properly. Chromium Linux[3] doesn't have a patch yet, and Chromium Windows[4] patch has the same issue (uses @-font API.) So guess is that if I were to write a function that calculates vertical translations from OpenType tables, it could be shared among some platforms. I was thinking to put it into platform/graphics/win/OpenTypeUtilities.cpp, but should I put it into somewhere else? [1] https://bugs.webkit.org/show_bug.cgi?id=51584 [2] https://bugs.webkit.org/show_bug.cgi?id=50619 [3] https://bugs.webkit.org/show_bug.cgi?id=69282 [4] https://bugs.webkit.org/show_bug.cgi?id=51450 - From: ryosuke.n...@gmail.com [mailto:ryosuke.n...@gmail.com] On Behalf Of Ryosuke Niwa Sent: Saturday, February 25, 2012 5:20 AM To: Koji Ishii Cc: webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] 48459: Glyphs in vertical text tests are rotated 90 degrees clockwise on Windows On Fri, Feb 24, 2012 at 12:14 PM, Koji Ishii kojii...@gluesoft.co.jp wrote: I was looking into bug 48459: Glyphs in vertical text tests are rotated 90 degrees clockwise on Windows https://bugs.webkit.org/show_bug.cgi?id=48459 and found that it has two issues: 1. It does not support text-orientation[1] property as OS X does. 2. It uses @-font, which lets Windows do a magic to rotate some code points and apply 'vert' automatically. But that means WebKit has no control over the glyph orientations, and therefore orientation of some code points don't match to the one on OS X. I think the correct fix for the bug is to port showGlyphsWithAdvances from FontMac.mm to FontCGWin.cpp. But I then encounter an issue that WebKitLibraries does not support CTFontGetVerticalTranslationsForGlyphs API. Since Windows doesn't have such API, possible options I can think of are: 1. Bring the CTFontGetVerticalTranslationsForGlyphs API to WebKitLibraries. 2. Use other libraries such as FreeType[2] to read related OpenType tables. 3. Read raw tables using GetFontData Win32 API and parse vhea/vorg/vmtx tables etc. Option 3 seems most desirable since it doesn't introduce new dependencies. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Making DOMWindow less epic (was Re: WebKit modularization)
On Fri, Feb 24, 2012 at 12:07 PM, Maciej Stachowiak m...@apple.com wrote: On Feb 24, 2012, at 11:58 AM, Adam Barth wrote: On Fri, Feb 24, 2012 at 11:50 AM, Maciej Stachowiak m...@apple.com wrote: On Feb 24, 2012, at 10:27 AM, Adam Barth wrote: 2012/2/24 Maciej Stachowiak m...@apple.com: I too am surprised that HTML-related APIs would be refactored as a result of modularization. This change may be justifiable on its own merits, but it doesn't seem like a logical part of a project to make self-contained features more modular. At the very least, to avoid confusion, changes like that should be kept clearly separate from the modularization effort, or else, someone could explain the relationship if there is one and its not obvious. Fair enough. I've detached those bugs from the larger meta bug. These patches have a different goal than the other patches attached to that meta bug. Much in the same way that we've moved code out of Frame.h over time, these patches are intended to make DOMWindow.idl more readable. The net result will (hopefully!) be a file that's more focused on concerns that actually relate to DOMWindow (e.g., name/closed/opener/parent/top) rather than a dumping ground for every random thing that needs to be in the global scope. In retrospect, we should have presented this work separately so folks could have discussed its merits separately. I think we got tied up in the implementation detail that the same mechanism makes both projects possible. I think this case is a little different than Frame.h, because with Frame, we can actually move related methods to separate objects, thus actually splitting up the interface. This creates an actual separation of concerns in the code if done right, not just a file split. I'm not sure that having multiple files which actually all form a single interface is equally beneficial. It doesn't seem hugely worse, but it does not seem obviously better to me either. It's quite analogous to Frame.h in the sense that this mechanism also lets us move related methods to a separate object. Consider a case such as http://trac.webkit.org/browser/trunk/Source/WebCore/fileapi/DOMWindowFileSystem.idl. When we moved webkitRequestFileSystem from DOMWindow.idl to DOMWindowFileSystem.idl, the code for webkitRequestFileSystem moved from DOMWindow.cpp to http://trac.webkit.org/browser/trunk/Source/WebCore/fileapi/DOMWindowFileSystem.cpp#L53, separating these concerns from DOMWindow. Splitting out the file-related stuff from DOMWindow seems justified based on modularity grounds, presuming we see File API as a self-contained feature. So no objection there. In the case of http://trac.webkit.org/browser/trunk/Source/WebCore/html/DOMWindowHTML.idl, the C++ code that backs those interfaces is already in Source/WebCore/html. The net result is 100 less lines of noise in DOMWindow.idl. It seems to me like the practical difference of the IDL move in this case is changing the IDL file where you need to add HTML elements, and adding an extra place you need to look to see what's in the global scope. It's not obvious to me that this is an improvement, but like I said, it doesn't seem terrible. I think there is a potentially even better approach here though. HTMLTagNames.in is already used to autogenerate most of the things that need to mention every HTML element. If it was used to avoid the need to explicitly mention all HTML element constructors in any IDL file at all, for instance by autogenerating one, then it would reduce the number of places that have to mention every HTML element by 1, and eliminate one of the possible mistakes when adding a new HTML element. Yeah, autogenerating this code from HTMLTagNames.in would be a better solution. I look forward to your patch. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Removing obsolete File attributes
My 2¢: - I'm glad to see these properties go. - I think Darin is correct to be concerned about a potential web-compat risk. (But, I suspect grepping extensions for .fileSize and .fileName might actually turn up useful data. Assuming that's easy to do?) - I agree with ap that warnings are mostly useless. Firefox has a zillion such warnings, and most page authors seem to ignore them. - I agree with Jian Li, that if/when we add warnings (or any other form of deprecation) notating such in the IDL and autogenerating is a Good Idea™. How much work is it to collect how many unique pages grab these numbers from nightlies? Have we done such in the past? (Do we have other studies to compare against?) It feels a bit odd for WebKit to depend on Chromium to collect such numbers, but Chromium does seem well suited to the task. -eric On Fri, Feb 24, 2012 at 1:30 PM, Alexey Proskuryakov a...@webkit.org wrote: 24.02.2012, в 12:20, Darin Fisher написал(а): Perhaps a concrete good first step is to log a console warning when they are used? Warning, blahBlah is a deprecated attribute. Use fluxCapacitor instead. I'm not much in favor of such warnings - from all I heard (second or third hand, without hard data), they are not effective. FWIW, this is what I'd expect - developers don't check console logs for sites they've delivered and were paid for long ago. I should point out that replacement standard attributes have been implemented in WebKit for a long time. - WBR, Alexey Proskuryakov ___ 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] Removing obsolete File attributes
On Fri, Feb 24, 2012 at 1:47 PM, Jochen Eisinger joc...@chromium.orgwrote: On Fri, Feb 24, 2012 at 10:38 PM, Eric Seidel e...@webkit.org wrote: My 2¢: - I'm glad to see these properties go. - I think Darin is correct to be concerned about a potential web-compat risk. (But, I suspect grepping extensions for .fileSize and .fileName might actually turn up useful data. Assuming that's easy to do?) - I agree with ap that warnings are mostly useless. Firefox has a zillion such warnings, and most page authors seem to ignore them. Is it really useless, or does it help to decrease the number of new pages using the feature? At the very least, it would make it seem more fair if the feature is eventually removed to give some warning. Exactly! For a point of reference, the bug to remove these properties caught the attention of a developer at Google just yesterday. He was really worried that we were taking away the ability to get the name and size from a File. He just wasn't aware of the fact that the same data was still available, but just under a different name on the Blob interface. He was writing new code. I'm certain a warning in the console would have been helpful in this case. - I agree with Jian Li, that if/when we add warnings (or any other form of deprecation) notating such in the IDL and autogenerating is a Good Idea™. I agree that this would be useful. Great idea! -Darin -jochen How much work is it to collect how many unique pages grab these numbers from nightlies? Have we done such in the past? (Do we have other studies to compare against?) It feels a bit odd for WebKit to depend on Chromium to collect such numbers, but Chromium does seem well suited to the task. -eric On Fri, Feb 24, 2012 at 1:30 PM, Alexey Proskuryakov a...@webkit.org wrote: 24.02.2012, в 12:20, Darin Fisher написал(а): Perhaps a concrete good first step is to log a console warning when they are used? Warning, blahBlah is a deprecated attribute. Use fluxCapacitor instead. I'm not much in favor of such warnings - from all I heard (second or third hand, without hard data), they are not effective. FWIW, this is what I'd expect - developers don't check console logs for sites they've delivered and were paid for long ago. I should point out that replacement standard attributes have been implemented in WebKit for a long time. - WBR, Alexey Proskuryakov ___ 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 mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Bash scripts should support LF endings only
Thanks Peter, just submitted the patch[1] although I still don't see any property change related lines. I also added aroben to the cc list. Hope somebody will take it from here. [1]: https://bugs.webkit.org/attachment.cgi?id=128849action=diffcontext=patchcollapsed=headers=1format=raw -Ash From: Peter Kasting pkast...@chromium.org To: Ashod Nakashian ashodnakash...@yahoo.com Cc: WebKit Development webkit-dev@lists.webkit.org Sent: Friday, February 24, 2012 11:20 PM Subject: Re: [webkit-dev] Bash scripts should support LF endings only On Fri, Feb 24, 2012 at 11:13 AM, Ashod Nakashian ashodnakash...@yahoo.com wrote: In short, the issue is that some bash scripts have their svn:eol-style set to native, which is CRLF on Windows. This is causing build failures on some version of cygwin-bash that don't like CR in the scripts. I fixed a number of these cases in the past by doing precisely what you suggested, and got r+ from aroben IIRC. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
