[webkit-dev] WebKit2GTK+ breakage due to removal of WKPageResourceLoadClient
Hi, So it seems WebKit2GTK+ builds are broken since yesterday due to this commit (as it was already predicted by EWS in [1]): http://trac.webkit.org/changeset/140285 ... and it seems to me it's not something easily fixable since it will certainly require a certain amount of work (and maybe a certain amount of re-design too) to get it back, as the WebKitWebResource API (as well as certain parts in WebKitWebView API) did benefit of both WKResourceLoadClient and WebResourceLoadClient. I've checked the related bug [1], but still haven't been able to properly understand what's exactly the reason of this change and, more importantly, what could be the best way to sort this out in the GTK port (an alternative implementation using the Injected Bundle perhaps?). If anyone could drop some light on this issue or provide some pointers to better understand the motivation of this change, I'd really appreciate that. I understand rolling r140285 might be not the best option at this point, yet I'd personally rather not keep the WebKit2GTK+ broken for too long. Thanks, Mario [1] https://bugs.webkit.org/show_bug.cgi?id=107405 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebKit2GTK+ breakage due to removal of WKPageResourceLoadClient
On Mon, Jan 21, 2013 at 2:53 PM, Mario Sanchez Prada mario.pr...@samsung.com wrote: Hi, (...) If anyone could drop some light on this issue or provide some pointers to better understand the motivation of this change, I’d really appreciate that. I understand rolling r140285 might be not the best option at this point, yet I’d personally rather not keep the WebKit2GTK+ broken for too long. As has been discussed in the list (see http://lists.webkit.org/pipermail/webkit-dev/2013-January/023255.html) the new development model for WebKit2 basically means this can happen at any time, and the broken pieces are for each port to keep and put back together. So I doubt reverting the patch is an option (in fact this is essentially the intended result of the new policy), we just need to figure out how to deal with this as fast as we can (which I think will be too long by any reasonably standard, but such is life). Xan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebKit2GTK+ breakage due to removal of WKPageResourceLoadClient
On Mon, 2013-01-21 at 15:27 +0100, Xan Lopez wrote: On Mon, Jan 21, 2013 at 2:53 PM, Mario Sanchez Prada mario.pr...@samsung.com wrote: Hi, (...) If anyone could drop some light on this issue or provide some pointers to better understand the motivation of this change, I’d really appreciate that. I understand rolling r140285 might be not the best option at this point, yet I’d personally rather not keep the WebKit2GTK+ broken for too long. As has been discussed in the list (see http://lists.webkit.org/pipermail/webkit-dev/2013-January/023255.html) the new development model for WebKit2 basically means this can happen at any time, and the broken pieces are for each port to keep and put back together. So I doubt reverting the patch is an option (in fact this is essentially the intended result of the new policy), we just need to figure out how to deal with this as fast as we can (which I think will be too long by any reasonably standard, but such is life). For the time being it looks to me that the only sensible thing to do is to just remove the WK2 API so that the port builds and then find a way to provide a replacement. Not an elegant solution but this is the brave new world we live in! Claudio ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] RGBA8 and BGRA8 formats in WebKit
Hi, In WebKit both RGBA and BGRA formats are used for different purposes and different platforms in WebKit. Do we have a policy which one we prefer? It would be nice to reduce conversions between them in the future as it seems costly on embedded systems. Regards, Zoltan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] distributed build for WebKit on Mac OS 10.8
Hi Building WebKit on a MacPro 5,1 (mid 2010 - 2.8GHz quad core Xeon with SSD, 20 gb of ram, gigabit LAN) with Mac OS 10.8 takes 30 minutes and it really slows down the daily work. Buying new Macs is just too expensive and the current ones have plenty of computing power if we use them to the full extent. Back in the 10.6 days, distcc did a great job at speeding up the builds. How can the build of WebKit be distributed on all the Macs in the LAN to fully utilize the computing power? Mihai ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] distributed build for WebKit on Mac OS 10.8
On Mon, Jan 21, 2013 at 1:41 PM, Mihai Maerean mmaer...@adobe.com wrote: Hi Hi, Building WebKit on a MacPro 5,1 (mid 2010 - 2.8GHz quad core Xeon with SSD, 20 gb of ram, gigabit LAN) with Mac OS 10.8 takes 30 minutes and it really slows down the daily work. Buying new Macs is just too expensive and the current ones have plenty of computing power if we use them to the full extent. Back in the 10.6 days, distcc did a great job at speeding up the builds. How can the build of WebKit be distributed on all the Macs in the LAN to fully utilize the computing power? Good question. You could try : https://github.com/icecc/icecream I know for fact that it works fine on linux but it claims to to work on Mac OS too and according to git log it seems that clang support is possible. Let me know if it works for you, I haven't had time to try yet. Mihai ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev -- Software Engineer @ Intel Open Source Technology Center ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] distributed build for WebKit on Mac OS 10.8
Hi, On Mon, Jan 21, 2013 at 5:53 PM, Alexis Menard ale...@webkit.org wrote: On Mon, Jan 21, 2013 at 1:41 PM, Mihai Maerean mmaer...@adobe.com wrote: How can the build of WebKit be distributed on all the Macs in the LAN to fully utilize the computing power? https://github.com/icecc/icecream I've been experimenting with icecream and distcc. Icecream is super powerful on Linux. Especially because it has a central scheduler that distributes the jobs according to available resources. But unfortunately I did not have any luck with it on Mac, due to the packaging of the compiler. Icecream actually ships the compiler in an archive to all the clients participating in a compile job. I was more successful using distcc from: http://www.opensource.apple.com/source/distcc/ This one seemed to work fairly well. The only problem I had was that Qt is not actually using xcodebuild. Therefore I could not make use of any bonjour service to update my hosts list and had to do that manually. But if you know the machines in your network and can rely on them being available, keeping a static list might be an option. - Zeno I know for fact that it works fine on linux but it claims to to work on Mac OS too and according to git log it seems that clang support is possible. Let me know if it works for you, I haven't had time to try yet. Mihai ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev -- Software Engineer @ Intel Open Source Technology Center ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Out-of-process networking and potential for sharing memory cache (was Re: Feature Announcement: Moving HTML Parser off the Main Thread)
Some folks have pointed out to me off thread that I'm coming off as angry and harsh. I would like to apologize for my tone. My goal here is not to obstruct or block your progress on the NetworkProcess. My goal is to end up with a common design that we can share between WebKit2 and Chromium or at least have a common way of interfacing with WebCore. My concern is that I don't believe that the current path the NetworkProcess is taking leads to a common design or interface. Anyway, it's probably best to continue this conversation another time. We can certainly iterate on the approach once you all are feeling less schedule pressure. Adam On Sun, Jan 20, 2013 at 11:44 PM, Adam Barth aba...@webkit.org wrote: On Sun, Jan 20, 2013 at 1:54 PM, Maciej Stachowiak m...@apple.com wrote: On Jan 20, 2013, at 1:44 PM, Adam Barth aba...@webkit.org wrote: On Sun, Jan 20, 2013 at 1:30 PM, Oliver Hunt oli...@apple.com wrote: I take your word for it that it's not possible on Windows. Given that Chromium has many users on Windows (and other non-Mac platforms), you should now understand why this design does not fit well with Chromium's design constraints. But chromium doesn't use webkit or webkit2, so i'm not entirely sure why webkit2 design decisions should consider chromium's (pre-wk2) design decisions. The reason discussed earlier in this thread is because they have implications for how the loader works in WebCore. In particular, folks working on the NetworkProcess have been shoehorning it into WebCore by adding numerous #ifdefs throughout WebCore. Are you offerring to implement the NetworkProcess without adding a bunch of WebKit2-specific #ifdefs to WebCore? The choice of load interception point is completely orthogonal to the decision to make the network process is a process or a thread. I'm not sure that's the case. The choices are coupled because the choice of interception point determines what code is in the web process and what code is outside the web process. The more loader code that's outside the web process, the more desirable it is to sandbox that code, which pushes the design towards running the code in a sandboxable environment, like a process. One thing that I'm unclear on is how having a distinct network process can possibly be less secure than a single thread in _any_ circumstance. Fundamentally any sandbox model that allows a single thread to be sandboxed, can just sandbox the main appropriate threads in the separate networking process, vice versa is not true however. According to Maciej, one of the motivations for having a NetworkProcess is that it can be sandboxed more tightly on Mac OS X. Unfortunately, the NetworkProcess, as currently designed, cannot be sandboxed on other platforms, such as Windows. That's why the current design is not a good fit for other platforms. To be clear, I think it's fine if you want to use a Mac OS X-centric design for WebKit2. However, you shouldn't be surprised later when other ports that run on more platforms don't want to adopt your designs. Moreover, if sometime in the future, I want to implement a Chromium-centric design that involves adding a bunch of #ifdefs to WebCore, I expect that you won't mind not having input either. As I understand it, here's the payoff matrix for how much sandboxing of networking code you get, if you take the process vs thread decision in isolation: | Mac | Windows -- Networking in dedicated process| fs can be sandboxed | no meaningful sandbox -- Networking in thread in UI process | no meaningful sandbox | no meaningful sandbox Just to be absolutely clear, are you saying that the Chromium project sees the second row as a better payoff? As I wrote before, you're drawing a false dichotomy. Networking is not a monolithic blob of code. The question isn't how best to sandbox a particular blob of code you've chosen to put in the NetworkProcess. The question is how best to factor the loader across multiple processes so that the risky parts of the code can be sandboxed well on various platforms. You've chosen a Mac OS X centric design that lets you sandbox that code but that ignores the constraints that other platforms face in sandboxing. Since you asked for clarity, my answer to your specific question is that I reject it's premise. In other words, you'd consider it bad to make Mac security better in a way that can't be applied to Windows, even if it makes Windows security no worse? Again, you've returned to your false dichotomy. Instead of assuming that we've already chosen a Mac OS X centric design that screws Windows, I think we should choose a design that balances the contraints of all the platforms we care
Re: [webkit-dev] Please do not enable ENABLE_INPUT_TYPE_DATETIME
On Sun, Jan 20, 2013 at 9:55 PM, TAMURA, Kent tk...@chromium.org wrote: Please do not enable ENABLE_INPUT_TYPE_DATETIME to ship input type=datetimeimplementation in your products. We had some discussion in WHATWG [1] [2] and realized input type=datetime UIs in iOS Safari and Android Chrome are wrong and harmful. The current code for input type=datetime in WebCore can't make a reasonable UI and should not be shipped in products. The two mail threads bounce back and forth between Hixie's opinion and yours. Was there a conclusion reached anywhere on what to do with datetime and datetime-local? I don't think just asking people to disable ENABLE_INPUT_TYPE_DATETIME will get us far (why risk breaking existing websites without a minimum of data?). Can you share the plan going forward? Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Please do not enable ENABLE_INPUT_TYPE_DATETIME
On Jan 20, 2013, at 9:55 PM, TAMURA, Kent tk...@chromium.org wrote: Please do not enable ENABLE_INPUT_TYPE_DATETIME to ship input type=datetimeimplementation in your products. What do you recommend for products that have shipped it already? - Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] RGBA8 and BGRA8 formats in WebKit
On Mon, Jan 21, 2013 at 7:00 AM, Zoltan Herczeg zherc...@webkit.org wrote: In WebKit both RGBA and BGRA formats are used for different purposes and different platforms in WebKit. Do we have a policy which one we prefer? It would be nice to reduce conversions between them in the future as it seems costly on embedded systems. The Web APIs use RGBA (E.g. http://www.w3.org/html/wg/drafts/2dcontext/html5_canvas/#canvas-pixel-arraybuffer ) Using that internally will prevent conversion at the boundaries JS-WebCore. Internally, each port should be able to use any format. On some embedded systems, it can be advantageous to use 24 bits colors (or even 16 bits sometimes). Where in WebKit do you experience problems with color conversion? Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Out-of-process networking and potential for sharing memory cache (was Re: Feature Announcement: Moving HTML Parser off the Main Thread)
On Jan 21, 2013, at 11:23 AM, Adam Barth aba...@webkit.org wrote: Some folks have pointed out to me off thread that I'm coming off as angry and harsh. I would like to apologize for my tone. My goal here is not to obstruct or block your progress on the NetworkProcess. My goal is to end up with a common design that we can share between WebKit2 and Chromium or at least have a common way of interfacing with WebCore. My concern is that I don't believe that the current path the NetworkProcess is taking leads to a common design or interface. Anyway, it's probably best to continue this conversation another time. We can certainly iterate on the approach once you all are feeling less schedule pressure. Thanks, Adam. It's fine to pick up the conversation later, and we're certainly open to iterating beyond what we do first. We're also happy to meet with anyone interested in this topic to discuss in person, or to document more of our design decisions in writing if the community would find that helpful. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Proposal: Make Ninja the default build-system for build-webkit --chromium
On Sat, Jan 12, 2013 at 9:49 PM, Nico Weber tha...@chromium.org wrote: On Tue, Dec 11, 2012 at 3:43 PM, Eric Seidel e...@webkit.org wrote: Nevermind. After further discussion with Nico, this can't work yet. Ninja is currently configured to use a non-webkitty out build directory, which is undoubtably going to confus some scripts/bots. We'll try this again at a later time. Apologies for the noise. If you build WebKit/chromium on Linux (i.e. Chromium/Linux and Chromium/Android), you're now using ninja. The Chromium Linux Release and Chromium Android Release build bots seem to be working fine. Admire the exciting build output: http://build.webkit.org/builders/Chromium%20Linux%20Release/builds/65467/steps/compile-webkit/logs/stdio Let us know if anything is not working for you. (If you must use make, you can pass --no-ninja to update-webkit, and build-webkit will use make again. If you do this, please let me know why.) Chromium/Mac webkit builds now uses ninja by default too. The bot's build output is now a little more concise: http://build.webkit.org/builders/Chromium%20Mac%20Release/builds/53889/steps/compile-webkit/logs/stdio On my laptop, full builds are 10% faster and empty builds (the minimum time you need to wait for a build) are 30x as fast. If you still need xcodebuild, you can pass --no-ninja to update-webkit. Please let us know if and why you do this. Nico ps: Switching Chromium/Windows is blocked on http://crbug.com/169945, so it probably won't happen soon. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] I try to fix bug 105694
Thank you Alexis-san, Dominic-san, Ryosuke-san for guiding me gently. I learned the custom and what this list is used for. And, thank you Kent-san for assigning to me. I'll do my best. Many thanks, 高尾 将康 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebKit2GTK+ breakage due to removal of WKPageResourceLoadClient
Hi Mario, The motivation of the change was to reduce the chatter between the WebProcess and UIProcess and reduce the amount of knowledge the UIProcess has about the internals of the WebProcess. We will also be removing the UIProcess' notion of the frame tree, for the same reason. Going forward, if you need that kind of detailed knowledge, you should use the WebInspector or the protocol it is based on. -Sam On Jan 21, 2013, at 5:53 AM, Mario Sanchez Prada mario.pr...@samsung.com wrote: Hi, So it seems WebKit2GTK+ builds are broken since yesterday due to this commit (as it was already predicted by EWS in [1]): http://trac.webkit.org/changeset/140285 ... and it seems to me it’s not something easily fixable since it will certainly require a certain amount of work (and maybe a certain amount of re-design too) to get it back, as the WebKitWebResource API (as well as certain parts in WebKitWebView API) did benefit of both WKResourceLoadClient and WebResourceLoadClient. I’ve checked the related bug [1], but still haven’t been able to properly understand what’s exactly the reason of this change and, more importantly, what could be the best way to sort this out in the GTK port (an alternative implementation using the Injected Bundle perhaps?). If anyone could drop some light on this issue or provide some pointers to better understand the motivation of this change, I’d really appreciate that. I understand rolling r140285 might be not the best option at this point, yet I’d personally rather not keep the WebKit2GTK+ broken for too long. Thanks, Mario [1] https://bugs.webkit.org/show_bug.cgi?id=107405 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Please do not enable ENABLE_INPUT_TYPE_DATETIME
Please do not enable ENABLE_INPUT_TYPE_DATETIME to ship input type=datetimeimplementation in your products. What do you recommend for products that have shipped it already? I recommend to disable it in the next release of the products. I'll disable it for Android Chrome. It's an incompatible change. However I think it won't have large impact because the number of input[type=datetime] in the web is only 0.08% of the number of input[type=date] -- TAMURA Kent Software Engineer, Google ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
