Re: [webkit-dev] Ports not building as C++11?
On 07/29/2013 04:38 AM, Brianceau, Julien wrote: Hi all, I’m afraid that our sh4 bot won’t handle C++11 properly : http://build.webkit.org/builders/Qt%20Linux%20SH4%20Release $ sh4-linux-g++ --version sh4-linux-g++ (GCC) 4.6.3 20120613 (STMicroelectronics/Linux Base 4.6.3-111) Copyright (C) 2011 Free Software Foundation, Inc. For most of the thing this wont be a problem. http://gcc.gnu.org/gcc-4.6/cxx0x_status.html Julien *De :*webkit-dev-boun...@lists.webkit.org [mailto:webkit-dev-boun...@lists.webkit.org] *De la part de* Geoffrey Garen *Envoyé :* lundi 29 juillet 2013 09:19 *À :* Brent Fulgham *Cc :* WebKit Development *Objet :* Re: [webkit-dev] Ports not building as C++11? I’d really like to use atomic, which isn’t supported until VS2012. When will we VS2012? Geoff On Jul 28, 2013, at 9:10 PM, Brent Fulgham bfulg...@gmail.com mailto:bfulg...@gmail.com wrote: We can support auto and move semantics. We cannot support ranged iterators until VS2012. But at least it's a step in the right direction... Sent from my iPad On Jul 28, 2013, at 2:36 PM, Oliver Hunt oli...@apple.com mailto:oli...@apple.com wrote: So wait, is everyone using C++11 now? I dream of using auto… :-D On Jul 28, 2013, at 12:47 PM, Gergely Kis gerg...@homejinni.com mailto:gerg...@homejinni.com wrote: Hi, On Sun, Jul 28, 2013 at 7:30 PM, Allan Sandfeld Jensen k...@carewolf.com mailto:k...@carewolf.com wrote: became required in WebKit2. The only fallout will likely be the loss of the Qt MIPS bot which is maintained by a third party and is too old. The MIPS bot was updated to Debian Wheezy and GCC 4.7.2 a few weeks ago, I just forgot to update the buildbot slave info file, did it now. Best Regards, Gergely the 3rd party maintaining the MIPS bot :) ___ webkit-dev mailing list webkit-dev@lists.webkit.org mailto:webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org mailto:webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org mailto:webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev This message is confidential and intended only for the addressee. If you have received this message in error, please immediately notify the postmas...@nds.com and delete it from your system as well as any copies. The content of e-mails as well as traffic data may be monitored by NDS for employment and security purposes. To protect the environment please do not print this e-mail unless necessary. An NDS Group Limited company. www.nds.com ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Cleaning House
On Friday, April 05, 2013 09:24:59 AM Geoffrey Garen wrote: Hi Mario. First of all, let me say upfront that I see all the potential advantages of sticking to just one JS engine, and also perfectly understand the points that most of the people here have made on favour of not supporting multiple engines. Also, my mail was not really a formal request to keep the V8 bits around in the long term, but just a quick reply to the following comment from Maciej: Geoff posted the list in part because we'd like to know If any of the things above are used by other ports. We're not planning to remove things still in use. So, my position with regard to this is pretty much the same as Per's one, so I'll just quote him too: I'm not asking you to support an alternative JavaScript engine where it complicates the code. Just please keep in mind there are people who use WebKit *without* JSC. Thanks for clarifying. It sounds like you're not asking us to maintain the v8 bindings. Who do you envision maintaining the v8 bindings going forward? In an ideal world, I would see the people interested in using those bindings doing it. And as per the feedback received so far, I understand it's just us for the V8 bindings, and maybe Oracle for the more generic bits about supporting multiple JS engines. However, that depends on whether those who were interested in WebKit + !JSC keep their interest on that for the long term, and I don't think this is a question that can be answered right now, as it probably depends on some other decisions. I apologize if this question was a little to Socratic. The point of the question was to identify real world challenges and solutions, not an ideal world. My understanding is that, in the real world, nobody is maintaining the v8 bindings. As of today, there are no v8 ports in WebKit trunk that build successfully. What do you see as their value to the WebKit project? I'm not an expert on JS engines at all, so I just see the obvious short term benefit of not breaking right now WebKit+V8 configurations that might be in use, and a more long-term benefit of having the needed bits in place to support other JS engines different than V8. Now, whether those are good enough benefits to keep this part of the code around in the future or not is something I can't answer either. Do you see any cost to the WebKit project in maintaining the v8 bindings? Yes. I obviously see the cost and limitations imposed by having to maintain code to support more than one JS engine when, in most of the cases, only one (JSC) will be used. Also, considering that JSC will be the only one supported in WebKit2 suggests that whoever who try to use WebKit with other engine is going to have a hard time maintaining downstream patches that will probably be harder and harder to deal with over time. So yes, I'm not blind on this topic. I clearly see the drawbacks :) Does the benefit outweigh the cost? As I said, I'm not an expert on the matter, but after reading the comments here, I feel like benefit probably won't outweight the cost in the long run. What would it take for WebKitGTK+ to adopt the JSC bindings? Martin already kindly answered this. To finish this mail, I'd just like to stress again that I was not requesting to keep this code forever in my previous mail. My point was more about keeping those bits for a while, or that just giving a smaller priority to the removal, since that would probably be appreciated in the short term by those that are currently using engines other than JSC. I'm not clear on what you're proposing here. How long should we wait to remove the v8 bindings? The uses of the v8 bindings I've heard of -- Oracle's Java project, a GTK project, and a Qt project -- are downstream adopters that don't work in WebKit trunk, and that can adjust to this change at their leisure. Qt doesn't use it at all, Oracle use just the structure used to support multiple JS engines (that will probably vanish after v8 removal), not the v8 bindings. Since I haven't heard of a specific disruption that will happen to a WebKit trunk contributor, I'm planning to remove the v8 bindings today. Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev signature.asc Description: This is a digitally signed message part. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Compiling WebKit up to 25% faster in Windows?
On Tuesday, March 26, 2013 01:40:56 PM Dirk Pranke wrote: On Tue, Mar 26, 2013 at 1:29 PM, Benjamin Poulain benja...@webkit.orgwrote: On Tue, Mar 26, 2013 at 1:20 PM, Dirk Pranke dpra...@chromium.org wrote If we have consensus that we should just switch to paths relative to Source (or maybe a couple different options), that would be (IMO) a big win. It sounds like Daniel co. have already done the big bang conversion. I think using full path would be a serious hit regarding hackability. I would rather spend some time tweaking my compiler to cache each directory content than waste time finding where is every single header I need to include. Interesting. I have the exact opposite experience, having to paw around to figure out where Font.h actually lives rather than just seeing WebCore/platform/graphics/Font.h. At any rate, to be clear, I would be in favor of that change but I'm not expecting it to happen :). I would be in favor of that change but I'm not expecting it to happen :) This summarizes my feel on any attempt to do a relative big change on WebKit project. -- Dirk signature.asc Description: This is a digitally signed message part. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Compiling WebKit up to 25% faster in Windows?
On Tuesday, March 26, 2013 01:47:26 PM James Robinson wrote: Also keep in mind that currently different build systems hack the include path up to have the same #include point to different headers depending on the build configuration, so the path expansion for a given #include will not be the same for all ports. It's basically a very non-obvious way to do #if PLATFORM() guards at include sites without looking like it. For instance there are 7 different versions of AuthenticationChallenge.h but only one #include statement in ResourceLoader.cpp. I think this is another issue, but for sure a blocking issue for the one being discussed. Consider: $ find Source/WebCore -name *.h -printf %f\n | wc -l 3383 $ find Source/WebCore -name *.h -printf %f\n | sort | uniq | wc -l 3288 - James On Tue, Mar 26, 2013 at 1:40 PM, Dirk Pranke dpra...@chromium.org wrote: On Tue, Mar 26, 2013 at 1:29 PM, Benjamin Poulain benja...@webkit.orgwrote: On Tue, Mar 26, 2013 at 1:20 PM, Dirk Pranke dpra...@chromium.org wrote If we have consensus that we should just switch to paths relative to Source (or maybe a couple different options), that would be (IMO) a big win. It sounds like Daniel co. have already done the big bang conversion. I think using full path would be a serious hit regarding hackability. I would rather spend some time tweaking my compiler to cache each directory content than waste time finding where is every single header I need to include. Interesting. I have the exact opposite experience, having to paw around to figure out where Font.h actually lives rather than just seeing WebCore/platform/graphics/Font.h. At any rate, to be clear, I would be in favor of that change but I'm not expecting it to happen :). -- Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev signature.asc Description: This is a digitally signed message part. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Common build system (was Re: WebKit Wishes)
On Wednesday, January 30, 2013 04:15:48 PM Maciej Stachowiak wrote: On Jan 30, 2013, at 3:24 PM, Dirk Pranke dpra...@chromium.org wrote: On Wed, Jan 30, 2013 at 1:50 PM, Filip Pizlo fpi...@apple.com wrote: Thanks for sharing this. On Jan 30, 2013, at 1:28 PM, Eric Seidel e...@webkit.org wrote: I wish we only had one build system (it were easy to add/remove/move files). I believe changes like http://trac.webkit.org/changeset/74849 are an unhealthy sign for the project. Adam is not the only person who has chosen to empty files instead of removing them. The pain of updating 8 build system is so great, we jump through hoops to avoid it. Which means it took us months to move JavaScriptCore/wtf to WTF, and will take us years to kill WebCore/platform. +1 This is a hard problem. It is a problem worth solving. Do you have more thoughts on this, particularly since you know quite well how both Xcode and gyp work? I suspect this is one of those things that it would be hard to achieve consensus on since there are so many stakeholders. But it may be fruitful to have a what if discussion about what this might look like. I think we can solve this problem if we agree that we want to. I think we haven't in the past mostly because we couldn't reach a consensus that it was worth solving enough to really try. I would love to see this fixed and would be glad to work on it. I think we should at least pursue this far enough to fully understand what our options are and what the costs and tradeoffs might be; does anyone disagree, and is anyone else willing to help pitch in? I think there are several possible ways we could solve this. One would be to switch to a common meta-build system. My understanding is that Apple's internal production build processes impose certain constraints here that I don't fully understand, but I know we've discussed the possibility of checking in generated project files as a workaround. Maybe there are other options as well to those constraints? I would love to discuss this further w/ someone from Apple ... It's far simplest for us if: (a) There is an Xcode project (or a Makefile) that builds the Mac port checked in to source control. (b) The generated project invokes only tools that are part of the default Mac OS X install. It may not be completely impossible to violate these requirements but it will require a lot of bureaucracy. (Also, just to get this out of the way, I don't think gyp needs to be the solution). Another alternative would be to write a script that did support at least the common use cases (add/move/delete files). There have been attempts in the past, but they have foundered on at least some perceived skepticism over how well this would work w/ XCode. That said, I don't think we've really pushed this to see. At some point this script might turn into a meta-meta-build system, which might be silly but also be the shortest path to the finish line. I suggest if there is interest in this we can start a new thread to discuss further ... My preference would be to use a common meta-build system with a comfortably human-readable and human-editable syntax, and checked in generated project files for those ports that need them. I think a key to making this work is to get Chromium and the Apple Mac port onto a common build system, which will probably require both Google and Apple ponying up at least one person to work on this project for a reasonable period of time. I think the plausible meta-build-systems to use would be CMake and Gyp, but in both cases it may be necessary to modify them to work well for everyone. I'd also like to add that I think a key related issue to common build system is common feature configuration. The many different ways ports control their feature flags is super confusing. I've long wanted to implement common configuration management, but have not had time. I have a patch trying to solve this issue for CMake based ports[1], the patch still on going, but even a change affecting just 2-3 ports using the same build system is a bit hard to get a consensus, so you can imagine how hard will be to get a consensus over all WebKit ports. [1] https://bugs.webkit.org/show_bug.cgi?id=103162 Cheers, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev signature.asc Description: This is a digitally signed message part. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Common build system (was Re: WebKit Wishes)
On Thursday, January 31, 2013 06:14:20 PM Patrick Gansterer wrote: Am 31.01.2013 um 17:17 schrieb Maciej Stachowiak: On Jan 31, 2013, at 1:56 AM, Patrick Gansterer par...@paroga.com wrote: Am 31.01.2013 um 10:37 schrieb Ryosuke Niwa: On Thu, Jan 31, 2013 at 1:17 AM, Jochen Eisinger joc...@chromium.org wrote: Another option is to add a webkit-patch command for modifying the build files. That way, the syntax doesn't need to be overly human friendly. There was also some attempt to write a tool to add files automatically: https://bugs.webkit.org/show_bug.cgi?ida772 I would expect that such a tool becomes easier if it would only modify one source of truth and generates all other artifacts such as Xcode projects from it. I don't want build file's syntax to be so human unfriendly that I need a tool for it. Often times, these syntax problems can be improved dramatically by simple changes. e.g. we had a similar discussion about TestExpectation syntax, and I'm much happier with the new syntax even though the new syntax is functionally equivalent to the old one, and two syntaxes are very similar. On Thu, Jan 31, 2013 at 1:17 AM, Mark Rowe mr...@apple.com wrote: Iâve experimented with this in the past and youâre right that it shouldnât be particularly difficult to do. However, I suspect that the task would be similar in scope to defining an improved syntax for gyp. And if the syntax is the primary sticking point with gyp then itâd seem preferable to tackle initially. Yeah. In fact, we can just come up with whatever syntax we like and convert it to the existing gyp format if the syntax was the biggest issue. Do we want to define the whole build system (including inform tion how to invoke the generators) with the new system, or is a simple list for the input files sufficient? IMHO adding a new generator build step happens very rarely. So maybe we can spit the input file list (mainly *.cpp and *.idl) into new files. Then GYP and CMake can read them and generate the build system out of them directly (like they to already today) instead of listing the files in the *.gpyi and *.cmake. This might work for other systems like qmake too. For XCode we can maybe have a template XCode project and generate the work XCode project with a script. This script then only need to fill in the files from the input file list into the template XCode project. Defining the feature flags can be done like Maciej suggested with Port.h files. I think it would be better to adapt an existing meta build system to our needs than to make one from scratch, unless we find that completely impractical. I particular, gyp and cmake both know how to handle generated sources, and while it may not be super common to make a new type of generated source, it's bad for hackability of the project of doing so is super hard. We get a lot of hackability benefits from using various kinds of generated sources, many first introduced in the days when we had a lot fewer build systems. So in my mind, they are already ahead of a hypothetical simple system. Do you want to kick the requirements of the smaller ports from trunk or do you think that e.g. a qmake generate for GYP makes sense? AFAIK e.g. QtWebKit is shipped with Qt, which uses qmake as build system, where CMake/GYP is not an option. I completely agree that creating a new meta meta build system isn't a good idea, but sharing the common parts (which reduce the daily productivity) might be a step in the right direction. Using simple text files which contain the list of files (like the gpyi files already do tod y) isn't a new build system. It only offers the existing meta build systems (CMake, GYP, autotools, qmake) to use a common base. I agree, common build system on WebKit is an utopia, create a new meta build system isn't a good idea, so the only plausible option is to unify way we add/remove/modify files from the build. Create a script to do this on all build system is yet another utopia, so again, the only option is to have plain text files. Going a bit further on this idea, would be nice to also have conditionals on these plain text files to cover the use case of e.g. add foo.cpp to the build when ENABLE_FOO or WTF_USE_FOO is on would be even better, a script would be called passing all ENABLE, USE, HAVE, etc.. flags and returning a list of files, the only question is if all current build system would support such dynamic source file list, CMake does :-) The remaining build systems can be ported to one of these systems or be adopted to use this file lists too. -- Patrick pgpVpcWAo2RvL.pgp Description: This is a digitally signed message part. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Please include function-level comments in change log entries
On Friday, July 06, 2012 11:34:01 AM Per Bothner wrote: On 07/06/2012 10:05 AM, Dan Bernstein wrote: It appears that lately most WebCore change log entires donât include any comments on individual functions. An overall description of the change at the top of the change log entry is valuable, but it is no substitute for describing the changes to each function. Good function-level comments are useful both while reviewing a patch and while revisiting existing code. Personally, I find that writing the function-level comments helps me a lot in reviewing my own patches before I post them. You forget there is a WebKit policy of not writing comments or otherwise documenting the code. I think he meant function level comments on ChangeLogs, not on the code itself. Or at least that's what it looks like. :-(-BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iEYEABECAAYFAk/3MI8ACgkQ+tuOMzntPWmSvwCfZX7mSpblM8xqtVYfMagmkS1V 6U4AoJOVtSW5QtfGk0C10boluUg+jzoe vPjB -END PGP SIGNATURE- ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] scrollInToView(true) have different behavior on WebKit and Firefox
Hi, While taking a look into bug 83419 (about fast/transforms/scrollIntoView- transformed.html) I faced with the following render issue: When using Element::scrollInToView(true) on blocking elements that have bigger child elements with margins webkit and Firefox show different results. I attached the html file [1] and the render results on Firefox[2] and WebKit[3] into the bug, so what's the correct result? IMO the Firefox behavior seems right, but before trying to fix anything better to know if a consensus on what is right exists. The scrollInToView spec[4] says: If the align to top flag is set align the top of the border box of the element to be scrolled into view with the top of the scrolling box. [1] https://bug-83419-attachments.webkit.org/attachment.cgi?id=143619 [2] https://bug-83419-attachments.webkit.org/attachment.cgi?id=143620 [3] https://bug-83419-attachments.webkit.org/attachment.cgi?id=143621 [4] http://dev.w3.org/csswg/cssom-view/ Regards, Hugo Parente Lima signature.asc Description: This is a digitally signed message part. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Default viewport value on WAP DTDs
to turn on Tier 1 content for us, and serves us the XHTML-MP (Tier 3?) content instead. As far as I understand, the decision comes from that team not wanting to dedicate resources to make sure the Tier 1 content keeps working on our device. I totally understand their reasoning and decision, but it is a saddens me given the promise of the open web and HTML5. It is even more sad that this is not a unique case and it will only be solved the day content providers stop looking at the user agent strings. Kenneth On Fri, May 4, 2012 at 11:32 PM, Ojan Vafai o...@chromium.org wrote: Instead of UA faking, is it possible for you to pick an actual UA string that is more compatible with the web at large? For Chromium we experimented with making the most minimal UA string possible without a big loss in web compatibility. To our disappointment, we found we had to match the Safari UA string almost exactly. Our current UA string is Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/536.6 (KHTML, like Gecko) Chrome/20.0.1096.1 Safari/536.6. The parts that we found to be safe to change are the platform names in the first sent of parenthesis. The version number after AppleWebKit. And the Chrome/versionNumber section. Even getting rid of the Safari/versionNumber caused us significant web compatibility problems. That said, we did all this testing in 2008. The web may have changed considerably since then. In either case, if your UA string diverges too much, I expect this problem will just be the tip of the iceberg of compatibility problems you'll encounter. So it might be worth considering changing your UA string before trying to add new DocType switching behavior. Ojan On Fri, May 4, 2012 at 10:53 AM, Hugo Parente Lima hugo.l...@openbossa.org wrote: On Friday, May 04, 2012 10:11:07 AM Ryosuke Niwa wrote: On Fri, May 4, 2012 at 9:39 AM, Kenneth Rohde Christiansen kenneth.christian...@gmail.com wrote: This is not supporting XHTML-MP, as we are not implementing anything special to support it. We are basically showing the content as it was HTML5 and that solves most real use-cases. Injecting a proper viewport configuration makes it also layout properly. Okay. Is this change observable by the page? Or more specifically, can a web page currently feature-detect whether a given browser support XHTML-MP by checking the size of the viewport? The page knows nothing, just as it knows nothing about the ~980 pixels used for the canvas width, it's a matter of change a magic value to the device- width to get websites better looking. I attached screenshots of MiniBrowser runnin with and without the patch using: MiniBrowser --window-size 480x720 http://m.yahoo.com Without patch (viewport of 980 pixels): https://bug 85425-attachments.webkit.org/attachment.cgi?id0272 Patched (viewport of 880 pixels) https://bug-85425-attachments.webkit.org/attachment.cgi?id0273 If the answer is yes, then we'll be breaking the feature detection. Unfortunately most unknown mobile browsers tend to get lots of XHTML-MP. Heck, we even get that for google.com on the Nokia N9 : :-( : as well as other high profile sites. Yeah, it's very unfortunate. This makes the sites render acceptable, until we can advocate the sites to accept our user agent, something which we haven't always had luck with. Google for one didn't want to provide us the Tier 1 site of google.com on the N9, even though it works a lot better t an the XHTML-MP version we are being served. I don't see this situation change any time soon. Can we work-around this issue by faking the user agent string? If you are working on your own browser you wont be telling every website that you are a iPhone forever, at least you will not be happy doing that. Regards. Hugo Parente Lima ___ 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 -- Kenneth Rohde Christiansen Senior Engineer Nokia Mobile Phones, Browser / WebKit eam Phone +45 4093 0598 / E-mail kenneth at webkit.org http://codeposts.blogspot.com ï¹ï¹ï¹ -- Kenneth Rohde Christiansen Senior Engineer Nokia Mobile Phones, Browser / WebKit team Phone +45 4093 0598 / E-mail kenneth at webkit.org http
Re: [webkit-dev] Default viewport value on WAP DTDs
On Friday, May 04, 2012 10:11:07 AM Ryosuke Niwa wrote: On Fri, May 4, 2012 at 9:39 AM, Kenneth Rohde Christiansen kenneth.christian...@gmail.com wrote: This is not supporting XHTML-MP, as we are not implementing anything special to support it. We are basically showing the content as it was HTML5 and that solves most real use-cases. Injecting a proper viewport configuration makes it also layout properly. Okay. Is this change observable by the page? Or more specifically, can a web page currently feature-detect whether a given browser support XHTML-MP by checking the size of the viewport? The page knows nothing, just as it knows nothing about the ~980 pixels used for the canvas width, it's a matter of change a magic value to the device- width to get websites better looking. I attached screenshots of MiniBrowser runnin with and without the patch using: MiniBrowser --window-size 480x720 http://m.yahoo.com Without patch (viewport of 980 pixels): https://bug-85425-attachments.webkit.org/attachment.cgi?id=140272 Patched (viewport of 880 pixels) https://bug-85425-attachments.webkit.org/attachment.cgi?id=140273 If the answer is yes, then we'll be breaking the feature detection. Unfortunately most unknown mobile browsers tend to get lots of XHTML-MP. Heck, we even get that for google.com on the Nokia N9 :-( as well as other high profile sites. Yeah, it's very unfortunate. This makes the sites render acceptable, until we can advocate the sites to accept our user agent, something which we haven't always had luck with. Google for one didn't want to provide us the Tier 1 site of google.com on the N9, even though it works a lot better than the XHTML-MP version we are being served. I don't see this situation change any time soon. Can we work-around this issue by faking the user agent string? If you are working on your own browser you wont be telling every website that you are a iPhone forever, at least you will not be happy doing that. Regards. Hugo Parente Lima signature.asc Description: This is a digitally signed message part. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Default viewport value on WAP DTDs
Hi, I was pointed to trigger a discussion here about the patch: https://bugs.webkit.org/show_bug.cgi?id=85425 I'll try to resume to issue: If no viewport is specified webkit uses the magic and well know value of 980 pixels for the canvas width, this value is very good for most websites developed for desktop usage, on the other side there are the websites[1] developed for small screen mobile devices. Those websites will look pretty ugly on a 980 pixels canvas, many of those websites uses a different DTD like: !DOCTYPE html PUBLIC -//WAPFORUM//DTD XHTML Mobile 1.0//EN http://www.wapforum.org/DTD/xhtml-mobile10.dtd; The proposed patch changes the magic value of 980 pixels to device-width when this doctype is found causing the website to render nicely if the device screen is small, i.e. don't show the website in a 980 pixels canvas zoomed out to fit the 980 pixels screen. Some webkit browsers already use this hack, like the N9 browser and if I understood correctly by the Zalan comments on the bug, the iOS Safari too. Comments about why the viewport width should or shouldn't be changed by the doc type is appreciated. Thanks! Regards Hugo Parente Lima [1] http://m.yahoo.com; http://www.google.com (using a user agent like: Nokia 7110/1.0) signature.asc Description: This is a digitally signed message part. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Moving to Git?
On Thursday 08 March 2012 17:12:47 Ryosuke Niwa wrote: On Thu, Mar 8, 2012 at 12:04 PM, Adam Treat atr...@rim.com wrote: There is nothing about git that forces you to have multiple branches locally. Good practice, yes, but nothing forcing it. As for the difficulty of resolving conflicts between patches you've made locally and changes made on the shared repository since you started making your local patches... nothing about git makes this any harder. Unless you have a lock based source control system you'll have to resolve conflicts. On Thu, Mar 8, 2012 at 12:05 PM, Joe Mason jma...@rim.com wrote: It seems to me that there's no need to use multiple local branches in git if you find it confusing - it's an additional feature, but I don't see anything that requires it. What workflow do you have that requires you to have multiple branches locally in git, and how do you solve it in svn without using branches? What precisely do you find difficult about merging remote changes, and how is the svn equivalent easier? The simplicity. In git, I have to worry about things like committing local changes before rebasing to master, or stashing, etc... In svn, all I have to do is to run svn up. git pull does the same (if no conflicts were found, but the same pain will happen on svn in case of conflicts) or git fetch origin; git rebase origin/master I remember the days were I switched from svn to git, blaming git for force me to type additional commands, today I'm just regrets for the blames and can't think in another VCS than git :-). - Ryosuke -- Hugo Parente Lima INdT - Instituto Nokia de Tecnologia signature.asc Description: This is a digitally signed message part. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
