Re: [webkit-dev] Remove HAVE_ACCESSIBILITY
> On Nov 16, 2018, at 10:44 AM, Ryosuke Niwa wrote: > > If a stub implementation is ok for ports without an actual accessibility > implementation then I’d say remove both flags. Then downstream users would > never have to worry about breaking due to AX signatures changing. > > > I don't think a stub implementation is okay. Removing ENABLE(ACCESSIBILITY) would be fine. Either way, I do think we need a better way to maintain !HAVE(ACCESSIBILITY). There have been at least ~38 build fixes for !HAVE(ACCESSIBILITY) over the years — one every 2-3 months on average. It was one of the pain points I remember in maintaining an outside port. https://trac.webkit.org/search?q=%21HAVE%28ACCESSIBILITY%29 — Timothy Hatcher ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Remove HAVE_ACCESSIBILITY
It wasn’t added for Tesla. But they did build with it disabled at the time I lasted worked on it. It was a frequent pain point to keep the build working when AX changes happened. — Timothy Hatcher > On Nov 14, 2018, at 5:29 PM, Ryosuke Niwa wrote: > > I think it was added for Telsa's private port. Probably not worth maintaining > the flag if the maintenance cost is high but is it? > > - R. Niwa > >> On Wed, Nov 14, 2018 at 5:19 PM Fujii Hironori >> wrote: >> Hi webkit-dev, >> >> It seems that all port defines HAVE_ACCESSIBILITY=1. Can I remove all code >> for !HAVE(ACCESSIBILITY)? >> >> https://trac.webkit.org/browser/webkit/trunk/Source/WTF/wtf/Platform.h?rev=237992#L648 >> >> #if PLATFORM(COCOA) || PLATFORM(WIN) || PLATFORM(GTK) || PLATFORM(WPE) >> #define HAVE_ACCESSIBILITY 1 >> #endif >> >> Bug 21802 – Rename HAVE_ACCESSIBILITY to ENABLE_ACCESSIBILITY >> https://bugs.webkit.org/show_bug.cgi?id=21802 >> >> -- Fujii >> >> ___ >> 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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Matt Baker is now a WebKit Reviewer
I want to announce that Matt Baker <mattba...@apple.com> is now a WebKit Reviewer. His expertise is in the Web Inspector codebase. Congratulations, Matt! — Timothy Hatcher smime.p7s Description: S/MIME cryptographic signature ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Proposal: Adopt Web Inspector coding style for all WebKit JS/CSS source code
> On Jul 9, 2016, at 3:22 PM, Sam Weinig <wei...@apple.com> wrote: > > It should probably get a parallel page to > https://webkit.org/code-style-guidelines/ > <https://webkit.org/code-style-guidelines/> and be updated with the same type > of right / wrong examples. Yes, I agree it should be a separate document. We can work on putting that together. > Our of curiosity, other than for features that simply aren’t available in C++ > / Objective-C (or vice-versa), are there places where the inspector JS > guideline deviates from what we do in the rest of WebKit? We pretty much follow the C++ WebKit style for things that overlap in the syntax. — Timothy Hatcher smime.p7s Description: S/MIME cryptographic signature ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebKit project repo size
Also, removing files from the repo does not save anything with a Git checkout since they are still there in the history. — Timothy Hatcher > On Mar 31, 2016, at 12:50 PM, Brian Burg <bb...@apple.com> wrote: > > Hi Marcus, > > It’s unclear what your actual problem is. > > If you have trouble downloading 7GB at once due to a slow or flaky > connection, you can fetch earlier git commits to finish the initial > repository checkout, and then fetch more commits in batches. > If you just want a subset of the repository, I recommend you use SVN instead > of Git. (Maybe git supports sparse checkouts these days, i dunno). > If you simply don’t like the repository layout or size, I don’t know how to > put it politely, but it’s unlikely to change due to the low payoff and huge > amount of work involved. > > -Brian > >> On Mar 31, 2016, at 12:42 PM, Marcus Johnson <bumblebritche...@gmail.com >> <mailto:bumblebritche...@gmail.com>> wrote: >> >> I use the git mirror, so I'm not sure how large the main SVN repo is, but >> the git one is huge at like 7 GB. >> >> I think the best way to reduce that amount of space, is by splitting out the >> websites into their own repos, and possibly even the unit tests into their >> own repo as well. >> >> Also, I've had pretty good luck reducing various repo's size running git gc >> --aggressive (it's re-compacts the .pack file) making it 5GB, so obviously >> some more work needs to be done. >> >> I mean, it's just ridiculous trying to download a 7 GB project just to >> submit a few patches for memory related issues. >> ___ >> 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 > https://lists.webkit.org/mailman/listinfo/webkit-dev smime.p7s Description: S/MIME cryptographic signature ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Suggestion: runtime disable Fetch API until it's complete enough for real web-apps
> On Mar 31, 2016, at 10:02 AM, Maciej Stachowiak <m...@apple.com> wrote: > > The recently released Safari Technology Preview has gotten more people living > on builds close to trunk, which is cool. Some people pointing out that the > current state of Fetch API causes problems - it's not quite complete enough > for real web apps that want to use it, but its presence breaks the detection > that would substitute a polypill. > > I'd like to suggest that it should be disabled until it's complete enough to > work. I would propose a runtime flag instead of compile-time so it can > continue to be tested by our regression tests while it's getting finished up. It is is way better shape in trunk. It really just missed the Safari Technology Preview build by a couple days. A fetch example I have now works in a trunk Safari build for example. I think we can keep it enabled and have it be in the next Safari Technology Preview release. We do need to be careful with things like this in the future though. — Timothy Hatcher smime.p7s Description: S/MIME cryptographic signature ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] [Block Pointer] Deterministic Region Based Memory Manager
> On Mar 13, 2016, at 10:06 AM, Phil Bouchard <philipp...@gmail.com> wrote: > > I just thought you might be interested in this benchmark. Please stop email this list until you provide benchmark results replacing JavaScriptCore’s GC. The benchmarks you are providing are irrelevant to JavaScriptCore’s needs. We are not interested. — Timothy Hatcher smime.p7s Description: S/MIME cryptographic signature ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Web inspector images
Hi Michael, I am looking into our options for the license of the images. Stay tuned. — Timothy Hatcher > On Feb 6, 2016, at 8:23 PM, Michael Catanzaro <mcatanz...@igalia.com> wrote: > > Hi, > > I'd like to address the problem with the license for the web inspector > images. The background on this is that a WebKitGTK+ release was > rejected by the legal department of one of our distributors after it > discovered the file Source/WebInspectorUI/APPLE_IMAGES_LICENSE.rtf, > which covers the images under > Source/WebInspectorUI/UserInterface/Images. From a cursory glance at > the license, it's clear that not only is this license not open source > compatible (and therefore not compatible with the acceptable content > policies of major WebKitGTK+ distributors), the images are also not > distributable. I don't believe this is consistent with the values of > the WebKit open source project. > > In response to this issue, we created similar but freely-licensed > replacement images under > Source/WebInspectorUI/UserInterface/Images/gtk, took down our hosted > tarballs for several previous WebKitGTK+ releases, reissued those > tarballs with the images replaced, and posted a notice to alert some of > our distributors to the issue. This was sufficient for our port, so we > just... stopped at that. But it would be good if other ports did not > have to address this problem individually, especially since there is no > obvious warning when downloading WebKit as to the legal status of this > content. > > Since the images are not usable except by Apple, it would be nice to > remove these images from the public repository to reduce the risk of > other ports accidentally including these image files. Therefore, I > propose to simply overwrite the images under Images with the images > under Images/gtk. As part of this, we would need to create a few new > images that do not currently exist under Images/gtk. Also, Apple's > internal build process would need to be modified to include the Apple > images from elsewhere. > > If I am remembering correctly, I spoke to Joe Pecoraro about this at > the WebKit Contributors Meeting, and he liked this idea. Would anyone > object to this change? > > A couple alternative solutions: > > * Apple could relicense its images. I suspect the set of similar but > freely-licensed gtk images defeats the purpose of using a restrictive > license for the Apple images. This would be the best solution. > Possible? > > * We could move the license file up from WebInspectorImages to the > toplevel project directory. This would make it very difficult to > accidentally distribute the Apple images without knowing the license. > > Michael > ___ > 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] Some text about the B3 compiler
Markdown is pretty similar to the wiki formatting and very simple. You can look at a cheatsheet if you login to the blog: https://webkit.org/wp/wp-admin/post.php?post=4300=edit I have also used this HTML to Markdown converter before: http://domchristie.github.io/to-markdown/ The pages are created: https://webkit.org/documentation/b3/ loads /docs/b3/bare-bones-backend.md https://webkit.org/documentation/b3/intermediate-representation/ loads /docs/b3/intermediate-representation.md Once those files are added to SVN, they will get picked up by the site. I can change those to point to other names if you want something different. — Timothy Hatcher > On Jan 29, 2016, at 9:34 AM, saam barati <saambara...@gmail.com> wrote: > > I'm happy to convert the document to markdown. Can you send me your latest > revision or post it to the website? > > I usually look at: > http://daringfireball.net/projects/markdown/syntax > <http://daringfireball.net/projects/markdown/syntax> > For a refresher on the syntax. > > Tim, could you create a page that loads the markdown file? > > Thanks, > Saam > > On Jan 29, 2016, at 12:06 AM, Filip Pizło <fpi...@apple.com > <mailto:fpi...@apple.com>> wrote: > >> I'm all for this but I don't know anything about markdown. >> >> What's the best way to proceed? >> >> -Filip >> >> On Jan 28, 2016, at 9:24 PM, Timothy Hatcher <timo...@apple.com >> <mailto:timo...@apple.com>> wrote: >> >>> They should be markdown files like we do for the code style and policy >>> documents. >>> >>> https://trac.webkit.org/browser/trunk/Websites/webkit.org/code-style.md >>> <https://trac.webkit.org/browser/trunk/Websites/webkit.org/code-style.md> >>> >>> We can then make Wordpress pages on the site that load the markdown. >>> >>> Maybe put them in a /docs/b3/ directory? >>> >>> — Timothy Hatcher >>> >>> On Jan 28, 2016, at 4:48 PM, Filip Pizlo <fpi...@apple.com >>> <mailto:fpi...@apple.com>> wrote: >>> >>>> I guess we could put it in Websites/webkit.org/b3 <http://webkit.org/b3>. >>>> Then patches could edit both B3 and the documentation in one go, and the >>>> documentation would go live when it’s committed. >>>> >>>> Does anyone object to this? >>>> >>>> -Filip >>>> >>>> >>>>> On Jan 28, 2016, at 4:39 PM, Saam barati <sbar...@apple.com >>>>> <mailto:sbar...@apple.com>> wrote: >>>>> >>>>> Yeah. That’d be the easiest way to keep it up IMO. >>>>> >>>>> Saam >>>>> >>>>>> On Jan 28, 2016, at 4:37 PM, Filip Pizło <fpi...@apple.com >>>>>> <mailto:fpi...@apple.com>> wrote: >>>>>> >>>>>> +1 >>>>>> >>>>>> Do you think we should move the documentation to a file in svn so that >>>>>> it can be reviewed as part of patch review? >>>>>> >>>>>> -Filip >>>>>> >>>>>> On Jan 28, 2016, at 4:32 PM, Saam barati <sbar...@apple.com >>>>>> <mailto:sbar...@apple.com>> wrote: >>>>>> >>>>>>> This is great. Thanks Fil. >>>>>>> >>>>>>> I propose that we do all that we can to keep this updated. >>>>>>> I suggest that all patches that change to the IR should also include >>>>>>> with it >>>>>>> a change to the documentation, and that reviewers should require this. >>>>>>> >>>>>>> It’d also be great if other significant changes that seem like the >>>>>>> deserve >>>>>>> a mention in the documentation also get added as part of patches. >>>>>>> >>>>>>> Saam >>>>>>> >>>>>>>> On Jan 28, 2016, at 4:23 PM, Filip Pizlo <fpi...@apple.com >>>>>>>> <mailto:fpi...@apple.com>> wrote: >>>>>>>> >>>>>>>> Hi everyone, >>>>>>>> >>>>>>>> We’ve been working on a new compiler backend for the FTL JIT, which we >>>>>>>> call B3. It stands for “Bare Bones Backend”. We recently enabled it >>>>>>>> on X86/Mac, and we’re working hard to enable it on other platforms. &g
Re: [webkit-dev] Some text about the B3 compiler
I also added: https://webkit.org/documentation/b3/air/ loads /docs/b3/assembly-intermediate-representation.md > On Jan 29, 2016, at 10:05 AM, Filip Pizło <fpi...@apple.com> wrote: > > Thank you! I'll convert them today. > > -Filip > > On Jan 29, 2016, at 10:02 AM, Timothy Hatcher <timo...@apple.com > <mailto:timo...@apple.com>> wrote: > >> Markdown is pretty similar to the wiki formatting and very simple. >> >> You can look at a cheatsheet if you login to the blog: >> https://webkit.org/wp/wp-admin/post.php?post=4300=edit >> <https://webkit.org/wp/wp-admin/post.php?post=4300=edit> >> >> I have also used this HTML to Markdown converter before: >> http://domchristie.github.io/to-markdown/ >> <http://domchristie.github.io/to-markdown/> >> >> The pages are created: >> >> https://webkit.org/documentation/b3/ <https://webkit.org/documentation/b3/> >> loads /docs/b3/bare-bones-backend.md >> https://webkit.org/documentation/b3/intermediate-representation/ >> <https://webkit.org/documentation/b3/intermediate-representation/> loads >> /docs/b3/intermediate-representation.md >> >> Once those files are added to SVN, they will get picked up by the site. I >> can change those to point to other names if you want something different. >> >> — Timothy Hatcher >> >>> On Jan 29, 2016, at 9:34 AM, saam barati <saambara...@gmail.com >>> <mailto:saambara...@gmail.com>> wrote: >>> >>> I'm happy to convert the document to markdown. Can you send me your latest >>> revision or post it to the website? >>> >>> I usually look at: >>> http://daringfireball.net/projects/markdown/syntax >>> <http://daringfireball.net/projects/markdown/syntax> >>> For a refresher on the syntax. >>> >>> Tim, could you create a page that loads the markdown file? >>> >>> Thanks, >>> Saam >>> >>> On Jan 29, 2016, at 12:06 AM, Filip Pizło <fpi...@apple.com >>> <mailto:fpi...@apple.com>> wrote: >>> >>>> I'm all for this but I don't know anything about markdown. >>>> >>>> What's the best way to proceed? >>>> >>>> -Filip >>>> >>>> On Jan 28, 2016, at 9:24 PM, Timothy Hatcher <timo...@apple.com >>>> <mailto:timo...@apple.com>> wrote: >>>> >>>>> They should be markdown files like we do for the code style and policy >>>>> documents. >>>>> >>>>> https://trac.webkit.org/browser/trunk/Websites/webkit.org/code-style.md >>>>> <https://trac.webkit.org/browser/trunk/Websites/webkit.org/code-style.md> >>>>> >>>>> We can then make Wordpress pages on the site that load the markdown. >>>>> >>>>> Maybe put them in a /docs/b3/ directory? >>>>> >>>>> — Timothy Hatcher >>>>> >>>>> On Jan 28, 2016, at 4:48 PM, Filip Pizlo <fpi...@apple.com >>>>> <mailto:fpi...@apple.com>> wrote: >>>>> >>>>>> I guess we could put it in Websites/webkit.org/b3 >>>>>> <http://webkit.org/b3>. Then patches could edit both B3 and the >>>>>> documentation in one go, and the documentation would go live when it’s >>>>>> committed. >>>>>> >>>>>> Does anyone object to this? >>>>>> >>>>>> -Filip >>>>>> >>>>>> >>>>>>> On Jan 28, 2016, at 4:39 PM, Saam barati <sbar...@apple.com >>>>>>> <mailto:sbar...@apple.com>> wrote: >>>>>>> >>>>>>> Yeah. That’d be the easiest way to keep it up IMO. >>>>>>> >>>>>>> Saam >>>>>>> >>>>>>>> On Jan 28, 2016, at 4:37 PM, Filip Pizło <fpi...@apple.com >>>>>>>> <mailto:fpi...@apple.com>> wrote: >>>>>>>> >>>>>>>> +1 >>>>>>>> >>>>>>>> Do you think we should move the documentation to a file in svn so that >>>>>>>> it can be reviewed as part of patch review? >>>>>>>> >>>>>>>> -Filip >>>>>>>> >>>>>>>> On Jan 28, 2016, at 4:32 PM,
Re: [webkit-dev] Some text about the B3 compiler
They should be markdown files like we do for the code style and policy documents. https://trac.webkit.org/browser/trunk/Websites/webkit.org/code-style.md We can then make Wordpress pages on the site that load the markdown. Maybe put them in a /docs/b3/ directory? — Timothy Hatcher > On Jan 28, 2016, at 4:48 PM, Filip Pizlo <fpi...@apple.com> wrote: > > I guess we could put it in Websites/webkit.org/b3. Then patches could edit > both B3 and the documentation in one go, and the documentation would go live > when it’s committed. > > Does anyone object to this? > > -Filip > > >> On Jan 28, 2016, at 4:39 PM, Saam barati <sbar...@apple.com> wrote: >> >> Yeah. That’d be the easiest way to keep it up IMO. >> >> Saam >> >>> On Jan 28, 2016, at 4:37 PM, Filip Pizło <fpi...@apple.com> wrote: >>> >>> +1 >>> >>> Do you think we should move the documentation to a file in svn so that it >>> can be reviewed as part of patch review? >>> >>> -Filip >>> >>>> On Jan 28, 2016, at 4:32 PM, Saam barati <sbar...@apple.com> wrote: >>>> >>>> This is great. Thanks Fil. >>>> >>>> I propose that we do all that we can to keep this updated. >>>> I suggest that all patches that change to the IR should also include with >>>> it >>>> a change to the documentation, and that reviewers should require this. >>>> >>>> It’d also be great if other significant changes that seem like the deserve >>>> a mention in the documentation also get added as part of patches. >>>> >>>> Saam >>>> >>>>> On Jan 28, 2016, at 4:23 PM, Filip Pizlo <fpi...@apple.com> wrote: >>>>> >>>>> Hi everyone, >>>>> >>>>> We’ve been working on a new compiler backend for the FTL JIT, which we >>>>> call B3. It stands for “Bare Bones Backend”. We recently enabled it on >>>>> X86/Mac, and we’re working hard to enable it on other platforms. >>>>> >>>>> If you’re interested in how it works, I’ve started writing documentation. >>>>> I’ll be adding more to it soon! >>>>> https://trac.webkit.org/wiki/BareBonesBackend >>>>> https://trac.webkit.org/wiki/B3IntermediateRepresentation >>>>> >>>>> -Filip >>>>> >>>>> ___ >>>>> 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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Updated WebKit Project Logo
On Aug 1, 2015, at 12:11 AM, Chris Aljoudi ch...@chrismatic.io wrote: Now that you mention the WebKit nightly builds on OS X, though, it seems like that icon could use an update, too. We were in the process of getting an updated nightly icon from Apple’s design team. I posted a patch to swap-in what they created. https://bugs.webkit.org/show_bug.cgi?id=147684 I put together an idea (see attached image) for one possible design. Thanks for showing what you designed. The blueprint look is something Jon has been exploring for parts of the redesigned website. — Timothy Hatcher ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Pattern for singleton classes instance getters
Yeah, that is exactly what I was thinking. Instance does not imply only one like singleton does. Call a singleton a singleton, we have a word for it. — Timothy Hatcher On Jan 28, 2015, at 9:19 PM, Maciej Stachowiak m...@apple.com wrote: This may be a question of what jargon we’ve encountered, but to me, “singleton clearly means the one unique instance of this class while “instance means any instance of this class. If I hadn’t seen this thread, I would interpret Class::instance() to mean “create a brand new instance of this class” rather than “return the unique singleton instance of this class, creating if necessary. Regards, Maciej On Jan 28, 2015, at 8:54 PM, Chris Dumez cdu...@apple.com wrote: Yes, instance() is what I’ve seen mostly outside WebKit as well. This would be my preference. Kr, -- Chris Dumez - Apple Inc. Cupertino, CA On Jan 28, 2015, at 8:44 PM, Michael Catanzaro mcatanz...@igalia.com wrote: On Wed, Jan 28, 2015 at 8:11 PM, Maciej Stachowiak m...@apple.com wrote: Yet another possibility is finding a better name than ‘shared’ for the singleton pattern function, but I don’t have any better ideas. Class::getSingleton() is more explicit but the extra verbosity doesn’t seem helpful to me. I recommend Class::instance(), which is what I've seen used almost exclusively outside of WebKit. It's what Scott Meyers used, and it's very similar to the Gang of Four's choice of Class::Instance() and the Java pattern Class.INSTANCE. That said, Class::singleton() is very attractive too. I've never seen Class::shared() used anywhere except WebKit. The first time I saw this I had no clue what it was until I looked up the implementation. All of these can get quite annoying to type, especially when the name of the class is long. (Sometimes I will keep a reference to the instance in a local variable with a shorter name.) But I think they're easier to read than free functions, and we should optimize for reading code, not writing it. Not a big deal either way. ___ 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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Proposal: Removing ENABLE(INSPECTOR) guards
I agree. Lets remove it. — Timothy Hatcher On Jan 19, 2015, at 9:44 AM, Osztrogonác Csaba o...@inf.u-szeged.hu wrote: Hi All, Inspector is enabled by default on all major WebKit port and the build without inspector isn't really maintained by anyone. Building without inspector can be useful on an embedded system where you don't need it, but it only reduces the binary code size with ~3%. It isn't so much, but the maintenance cost can be much more bigger. I propose removing ENABLE(INSPECTOR) guards to reduce maintenance cost. br, Ossy ___ 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
[webkit-dev] Brian Burg is now a WebKit reviewer
Howdy folks! I’m happy to announce that Brian is now a WebKit reviewer. Brian has been working on Web Inspector for a while now — covering both the frontend and the backend. His primary focus is integrating his deterministic replay research into WebKit and Web Inspector. More on his work can be found at http://brrian.org/ http://brrian.org/. Lets hope he has enough time to review all of our patches now that he is a new father. Congratulations on WebKit reviewer and fatherhood, Brian! — Timothy Hatcher ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebGL on by default?
On Apr 6, 2014, at 8:38 AM, Anatoly Ropotov anat...@innowate.com wrote: Is there a hope that either the next minor release will have WebGL turned on by default or we'll have to wait for the next OS X to have WebGL enabled by default (due to system-level security/sandboxing/energy consumption concerns?). I've seen some recent commits on utilizing ANGLE here and there, is there any ETA on rolling these things live and having WebGL turned on by default? WWDC is still months away, so I hope we could get some ETA/roadmap hints to make a promise to our users and properly convey information on Apple stance for this tech. These questions are not appropriate for webkit-dev — they are more about Safari than WebKit. Apple does not comment on future product releases. — Timothy Hatcher ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Heap snapshot/profiling support in Web inspector
Yes, the feature was V8 specific. It is a feature we would like to eventually have in JSC. — Timothy Hatcher On Mar 5, 2014, at 8:59 AM, dipak kumar mail.di...@gmail.com wrote: Do we currently support heap profiling/snapshot with JSC engine? What I have concluded is this feature is chrome/V8 specific. If yes, then any plan to support this feature with JSC? ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Feature Announcement: URL API
On Jan 28, 2014, at 3:06 PM, Maciej Stachowiak m...@apple.com wrote: - The domainToASCII and domainToUnicode static methods (probably not to be implemented for now based on comments in the spec discouraging it) That is unfortunate, the Web Inspector could use these to show international domains better — instead of showing punycode. Otherwise, the URL parsing parts will be useful and I look forward to using them and removing our JS URL parser! — Timothy Hatcher ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Proposal: Stop EWS bot commenting in bugs
On Jan 16, 2014, at 2:28 AM, Alexey Proskuryakov a...@webkit.org wrote: 15 янв. 2014 г., в 23:02, Ryosuke Niwa rn...@webkit.org написал(а): I think that it's good to try not dumping build failures into comments right away, and to see what happens. As for not showing style bot failures, it seems almost certain that this will make them substantially more annoying to work with. Can you describe the workflow for patch author and reviewer to deal with style bot warnings when they are not inline? Manually finding relevant lines by number can't work. I agree with Tim that dumping all tested paths along with style warnings is silly. How hard would it be it to get rid of that? The workflow is to click on the bubble to see the style errors. e.g. https://webkit-queues.appspot.com/results/6544662978363392 Seems like that would require everyone to manually match errors to code lines indeed, so I object against making this change for style checker warnings. - WBR, Alexey Proskuryakov Yeah, seeing the style warnings as a comment (which also causes them to show up in the patch review) is helpful. I was just complaining about the python path spew it also includes. — Timothy Hatcher ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Proposal: Stop EWS bot commenting in bugs
It isn't just about seeing the comment on the page, it also gets emailed. I agree, no bot comments would be better. The stye bot spew is particularly bad, mainly because it dumps all the file paths it tested not just what fails. — Timothy Hatcher On Jan 15, 2014, at 8:17 PM, Ryosuke Niwa rn...@webkit.org wrote: We could do that, or add some JS hack to Bugzilla so that it hides EWS comments by default but makes them expandable. - R. Niwa On Wed, Jan 15, 2014 at 8:09 PM, Sam Weinig wei...@apple.com wrote: Could we compromise for now, and remove all the non-test failing EWS comments (e.g. build failure, style failure)? - Sam On Jan 15, 2014, at 8:04 PM, Ryosuke Niwa rn...@webkit.org wrote: I find Mac EWS's listing the failing tests to be very useful especially because it uploads the results to Bugzilla. I do agree that comments about build failures are much less useful. - R. Niwa On Wed, Jan 15, 2014 at 7:54 PM, Sam Weinig wei...@apple.com wrote: Hi Everyone, I am becoming increasingly annoyed by the comments made in bugs.webkit.org bugs by our non-human helpers, the EWS bots. I don’t find the addition of a comment indicating that a patch has failed on a bot, over the existing indication in the bubble, to be worth the noise it creates. I propose that we stop allowing the bots to comment, and leave that space for the developers. - Sam ___ 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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] The SrcN responsive images proposal
On Nov 6, 2013, at 4:26 PM, John Mellor joh...@chromium.org wrote: I've suggested before that the attributes could be combined if that's considered simpler. My only concern is that most developers aren't used to putting line breaks in html attributes, so might feel obliged to put all the alternatives on one line, harming readability. But as long as the developer documentation encourages line breaks, that could be fine... As I replied before, there should only be one attribute — srcset. Given that your micro format extends around parts of the existing micro format of srcset, it just makes sense to reuse the same attribute. Wishing srcset didn't exist doesn't make it go away. Tweaking it is more approachable and should get better support from the WebKit community and likely other venders who are now stalled because of this proposal. Especially since the current viewport syntax in srcset has little-to-no support or implementations. Also if srcset is the attribute, the CSS function srcset() should support the same micro format. Designing this proposal around code formatting is a non-issue in my opinion and it surely didn't stop SVG from providing just one d attribute for path. Following the your logic, it should be d-N. Sure, path d=… is primarily meant to be written by software. Though, as responsive designs get more complex, people are going to rely on software to generate these src strings too. I surely don't want to be micromanaging the intrinsic widths in a viewport-urls set if I need to change the width and export again from Photoshop. Some workflow tool is likely going to generate these and having them in one attribute makes them infinitely easier for a script to manage. (And easier for humans too if things need reordered, as I mentioned earlier.) — Timothy Hatcher ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] The SrcN responsive images proposal
On Nov 7, 2013, at 2:22 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Thu, Nov 7, 2013 at 9:24 AM, Timothy Hatcher timo...@apple.com wrote: On Nov 6, 2013, at 4:26 PM, John Mellor joh...@chromium.org wrote: I've suggested before that the attributes could be combined if that's considered simpler. My only concern is that most developers aren't used to putting line breaks in html attributes, so might feel obliged to put all the alternatives on one line, harming readability. But as long as the developer documentation encourages line breaks, that could be fine... As I replied before, there should only be one attribute — srcset. Given that your micro format extends around parts of the existing micro format of srcset, it just makes sense to reuse the same attribute. Wishing srcset didn't exist doesn't make it go away. srcset doesn't significantly exist yet. It's in one browser's nightly. I'd like to resolve this soon, but it doesn't help anything to pretend that it's already a done deal that must be engineered around. It is shipping in Safari 6.1, 7 and iOS 7. That ship has sailed. Tweaking it is more approachable and srcset's parsing algorithm *cannot* be extended in the future. I gave an example of how it would fail over on blink-dev; I can reproduce it here if necessary. I don't subscribe to blink-dev. The WebKit community are the ones you need to convince. Designing this proposal around code formatting is a non-issue in my opinion and it surely didn't stop SVG from providing just one d attribute for path. Following the your logic, it should be d-N. Sure, path d=… is primarily meant to be written by software. Please don't try to use reducto ad absurdum; it usually gives absurd results. The reasoning for multiple attributes is not because it's a list, it's because it's a list of lists, and would require three different delimiters. Three whole delimiters. What a crime against humanity! — Timothy Hatcher ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] The SrcN responsive images proposal
On Nov 7, 2013, at 2:38 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Thu, Nov 7, 2013 at 9:24 AM, Timothy Hatcher timo...@apple.com wrote: As I replied before, there should only be one attribute — srcset. I have a serious suggestion - could we rename srcset to src-n (literally, src-n), and then just ship it? This puns in three interesting ways: 1. If src-N is never accepted, it's still an attribute that holds N src values, so src-n works well. 2. If src-N is accepted, but as a single attribute, src-n is just named perfectly to match the proposal name. 3. If src-N is accepted fully, the obvious ordering is clearly src-1, src-2, src-3, ..., src-n, which matches the fallback we want. A guaranteed last fallback is legitimately useful for the full src-N proposal, so I'm totally okay with integrating that into my proposal. This'll let us ship now, and then continue to discuss src-N for a while, with whatever solution we land on still having a consistent name. Win for authors no matter what the result is. No, you are just asking for support to muddy the waters and make the web your science project. — Timothy Hatcher ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] The SrcN responsive images proposal
On Nov 7, 2013, at 2:43 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: I'm pretty sure the argument is almost entirely around hand-authoring, where experience with style='' shows that lists-of-lists are bad. Until you are dealing with dozens of images per tag. That is untenable one image heavy sites and tools will need to be written to auto generate these lists of lists from the original assets. Scripts can easily deal with a micro format in one attribute. They can't easily deal with a micro format spread across multiple src-n attributes in arbitrary HTML. — Timothy Hatcher ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] The SrcN responsive images proposal
On Nov 7, 2013, at 3:49 PM, Elliott Sprehn espr...@chromium.org wrote:
It is shipping in Safari 6.1, 7 and iOS 7. That ship has sailed.
Can you please clarify this, I just tested in Safari 6.1 and 7 and I don't
see srcset on HTMLImageElement. What do you mean it's shipped?
document.createElement('img').srcset is undefined.
Sorry, I was confusing it with the CSS function. Tab is right, the HTML
attribute is only in the WebKit nightly right now.
— Timothy Hatcher
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] The SrcN responsive images proposal
On Nov 7, 2013, at 4:27 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Thu, Nov 7, 2013 at 3:39 PM, Timothy Hatcher timo...@apple.com wrote: On Nov 7, 2013, at 2:22 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: srcset's parsing algorithm *cannot* be extended in the future. I gave an example of how it would fail over on blink-dev; I can reproduce it here if necessary. I don't subscribe to blink-dev. The WebKit community are the ones you need to convince. A simple Yes would have sufficed. I was just asking if I needed to demonstrate it. Take this markup: img srcset=foo 1x, bar 2x || baz 1x, qux 2x You expect this to break into two lists, foo 1x, bar 2x and baz 1x, qux 2x, which are then each split as currently proposed. However, by the current parsing algorithm, || is read as an unsupported descriptor, so it just breaks them into foo 1x, bar 2x || baz 1x, and qux 2x. The middle one is thrown away, because of the duplicate x descriptor, and so the whole thing is just parsed to the same value as foo 1x, qux 2x, which is completely wrong. Good point. Thanks for the example. Luckily no one has shipped srcset, so it could be changed. Designing this proposal around code formatting is a non-issue in my opinion and it surely didn't stop SVG from providing just one d attribute for path. Following the your logic, it should be d-N. Sure, path d=… is primarily meant to be written by software. Please don't try to use reducto ad absurdum; it usually gives absurd results. The reasoning for multiple attributes is not because it's a list, it's because it's a list of lists, and would require three different delimiters. Three whole delimiters. What a crime against humanity! I'm not sure why you're being sarcastic and hostile. Three delimiters is a rather large mental tax for developers. Being dismissive of mental complexity isn't very friendly to authors. It's not the be-all-end-all, but it is important. And that is more of a mental tax than managing multiple attributes? Developers already understand boolean logic. They don't already understand multiple stringed together attributes. A proposal for a new paradigm of using multiple attributes deserves some resistance, careful consideration and exploration of alternatives. I feel my factual example of path d was flippantly tossed aside. So I responded in jest. — Timothy Hatcher ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] The SrcN responsive images proposal
On Nov 7, 2013, at 4:28 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Thu, Nov 7, 2013 at 3:43 PM, Timothy Hatcher timo...@apple.com wrote: On Nov 7, 2013, at 2:38 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: I have a serious suggestion - could we rename srcset to src-n (literally, src-n), and then just ship it? This puns in three interesting ways: [...] This'll let us ship now, and then continue to discuss src-N for a while, with whatever solution we land on still having a consistent name. Win for authors no matter what the result is. No, you are just asking for support to muddy the waters and make the web your science project. I have no idea what this means. Could you restate your objection in some other way? This is just a renaming request, mind, for an unreleased feature; it's not unusual. Literally supporting src-n just to test the waters with the idea of introducing src-1..src-99 later is just an abuse of the HTML language and developers attention. Design something right and support it forever. — Timothy Hatcher ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] The SrcN responsive images proposal
On Nov 5, 2013, at 2:18 AM, John Mellor joh...@chromium.org wrote: img srcset=(min-width: 640px) 0.5x ph...@0.5x.jpg, 1x ph...@1x.jpg, 2x ph...@2x.jpg || 0.5x photo-c...@0.5x.jpg, 1x photo-c...@1x.jpg, 2x photo-c...@2x.jpg I prefer this over multiple attributes. It is a syntax that needs little explanation before you can read it and use it. It also expands the existing srcset instead of confusing things with other attributes. srcN is also too fiddly. If you want to add a higher precedent srcN, you need to reorder all the existing srcN attribute names. With srcset you just need to edit a single attribute's value, adding a logic operator between the rules. — Timothy Hatcher ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] canconfirm-bit for WebKit Bugzilla account
I went ahead and turned off unconfirmed. Only New and Assigned are now allowed when creating a bug. — Timothy Hatcher On Oct 31, 2013, at 4:33 PM, Darin Adler da...@apple.com wrote: The WebKit project doesn’t use the unconfirmed state in any significant way. We probably should turn it off on bugs.webkit.org. There’s very little distinction between an unconfirmed bug and a new bug. I don’t think you really need that privilege on your account, although there’s also no harm on giving it to you. — Darin ___ 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] Proposal: Add support for focus rings in Canvas 2d
On Oct 14, 2013, at 12:43 PM, Rik Cabanier caban...@gmail.com wrote: Also, how would your suggestion tell the UA about what areas are associated with the elements? What happens if an element is no longer focused? The ring is drawn into the canvas bitmap so those pixels have to be regenerated. Focus rings are usually larger than the control they surround. How is the developer suppose to know the pixel padding needed for each platform's focus ring? Guess and hope for the best? Would drawing the system focus ring taint the canvas pixels? (Drawing form controls into canvas via SVG images and foreignObject has been considered taint worthy because it could leak the user's UI theme.) — Timothy Hatcher ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Proposal: Add support for focus rings in Canvas 2d
On Oct 14, 2013, at 3:44 PM, Rik Cabanier caban...@gmail.com wrote: Isn't focus ring drawn on the canvas? If so, it's important that the focus ring fits within the canvas. e.g. consider focusing an element of 100px by 100px inside a canvas of the same size. If the focus ring were to be drawn around the element that currently has focus, then the entire focus ring would be drawn outside of the visible region. True. That sounds like bad design though. Why? It doesn't seem particularly strange to have an element occupy the entire canvas momentarily. No, but I wouldn't never make the focus ring as large as the canvas. Even if you don't make it full size, if the focus ring is drawn into the canvas buffer, you don't know how much room you need to account for. (If the focused control is near the edge of the canvas.) — Timothy Hatcher ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Announcement: CSS3_TEXT_DECORATION flag
Can we enable CSS3_TEXT_DECORATIONS on the Apple ports once you add it? I have a legitimate use for -webkit-text-decoration-color that would allow me to eliminate a hack in the Inspector. — Timothy Hatcher On Oct 4, 2013, at 10:45 AM, Myles C. Maxfield mmaxfi...@apple.com wrote: Hello, all! Between the current and previous versions of the CSS3 Text spec, the text decoration section was split out into its own spec [1] [2] [3]. Because of this shift, I’m going to be creating a new compile-time flag: CSS3_TEXT_DECORATIONS. Proposal for the features themselves was mentioned in [4]. For those who wish to follow progress, the feature bug is at [5]. The first thing I am working on is the text-decoration-skip: ink property [6]. I will also be migrating existing text-decorations code from behind the existing CSS3_TEXT flag to behind this new CSS3_TEXT_DECORATIONS flag. Thanks, Myles C. Maxfield [1] http://www.w3.org/TR/2012/WD-css3-text-20120814/ [2] http://www.w3.org/TR/css3-text/ [3] http://www.w3.org/TR/css-text-decor-3/ [4] https://lists.webkit.org/pipermail/webkit-dev/2012-July/021715.html [5] https://bugs.webkit.org/show_bug.cgi?id=58491 [6] https://bugs.webkit.org/show_bug.cgi?id=121806 ___ 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] For your consideration: Naming scheme for fooIfExists/ensureFoo
What about? StyleResolver* existingStyleResolver() StyleResolver styleResolver() — Timothy Hatcher On Jun 19, 2013, at 11:49 AM, Balazs Kelemen kbal...@webkit.org wrote: For me optional seems very misleading and generally different prefixes suggests that those objects are not the same. Maybe IfExists does not sound nicely but at least it's clear. I would choose to have a pointer version with IfExists and a reference version which is a noun, like: StyleResolver* styleResolverIfExists() StyleResolver styleResolver() Br, -Balazs ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Web Inspector
On Tuesday the Safari team upstreamed the Safari Web Inspector to WebKit as a new top-level project — WebInspectorUI. This version of Web Inspector is nearly two years in the making. We now feel it is time to share our hard work with the WebKit project and further accelerate developer tool innovation with help from all of you. The previous Web Inspector UI is still part of WebCore and is used by a number of ports currently. However, the previous version of Web Inspector is largely unmaintained at this point — since the departure of Chromium back in April. At this time, we would like to deprecate the previous Web Inspector and encourage ports to move over to using the new WebInspectorUI project. We realize a transition like this can't happen overnight. For starters, the current UI assumes the Mac platform with keyboard shortcuts and other conventions. Another area would be making it work with the Inspector protocol vended over a WebSocket. To facilitate a smooth transition for ports, we are ready to help and review patches to get issues resolved as quickly as possible. We hope you are as excited about this as we are, and are looking forward to working with all of you to make Web Inspector even better! — Timothy Hatcher ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Web Inspector
Sorry for the duplicate message. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Web Inspector
On Tuesday the Safari team upstreamed the Safari Web Inspector to WebKit as a new top-level project — WebInspectorUI. This version of Web Inspector is nearly two years in the making. We now feel it is time to share our hard work with the WebKit project and further accelerate developer tool innovation with help from all of you. The previous Web Inspector UI is still part of WebCore and is used by a number of ports currently. However, the previous version of Web Inspector is largely unmaintained at this point — since the departure of Chromium back in April. At this time, we would like to deprecate the previous Web Inspector and encourage ports to move over to using the new WebInspectorUI project. We realize a transition like this can't happen overnight. For starters, the current UI assumes the Mac platform with keyboard shortcuts and other conventions. Another area would be making it work with the Inspector protocol vended over a WebSocket. To facilitate a smooth transition for ports, we are ready to help and review patches to get issues resolved as quickly as possible. We hope you are as excited about this as we are, and are looking forward to working with all of you to make Web Inspector even better! — Timothy Hatcher ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Enabling Experimental Features
On Apr 19, 2013, at 6:15 PM, Bear Travis betra...@adobe.com wrote: What do folks think about adding a mechanism for users to toggle features like this on in WebKit nightlies? I don't have a definite approach yet, but wanted to float the idea for feedback. I like the idea. Having things off for everyone but the engineers is a bad approach and misses out on testing. We could have WebKit modify Safari's Develop menu to provide additional items to toggle. Safari provides an Enable WebGL item, we could inject more items next to it. — Timothy Hatcher ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Rewriting binding code generator, maybe?
On Apr 10, 2013, at 6:32 PM, Ryosuke Niwa rn...@webkit.org wrote: Can we rewrite CodeGenerator*.pm in Ruby or Python? I feel that the current code is very hard to understand and hack on. In particular we have CodeGenerator.pm and CodeGeneratorJS.pm (CodeGeneratorV8.pm has been removed), and we need to merge them anyway. They can't be merged. We also have CodeGeneratorObjC.pm. (And internally we have CodeGeneratorSafari.pm.) I've seen many people expressing their inability to improve the binding code because of its being written in Perl. I've also seen people express their frustration for our tools currently written in Ruby and Python. I personally find Perl fine for this task and don't see a need to rewrite things just because. — Timothy Hatcher ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Rewriting binding code generator, maybe?
On Apr 10, 2013, at 8:17 PM, Kentaro Hara hara...@chromium.org wrote: Now that JSC is the only engine in WebKit and V8 is the only engine in V8, we both can remove a bunch of unnecessary abstractions and IDL attributes that had existed to share code between JSC and V8. In short-term, this kind of clean-up will improve our situation a lot. (I'm doing the work with the highest priority in the V8 side.) As I said in a previous email, JSC isn't the only binding we generate with these scripts. We also generate ObjC and internal Safari bindings. So those needs need to be considered for anyone rewriting these scripts. — Timothy Hatcher ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Ever increasing binary size
On Mar 22, 2013, at 3:12 AM, Ryosuke Niwa rn...@webkit.org wrote: WebKit nightly build for r135421 dated November 21st, 2012 was 46.1MB. WebKit nightly build for r145786 dated March 13th, 2013 was 49.4MB. Our binary size increased by 7.2% in just 4 months. Keep in mind that the Safari's Web Inspector is in the nightly. Also all of the frameworks and their resources are in the nightly twice (for 10.7 and 10.8). Safari's Web Inspector framework is around 2.5 MB (uncompressed) in r135421 and 4.2 MB in r145786. A 68% increase (that I will investigate further). Most of that size comes from image resources that can't be compressed further by the disk image. They are also duplicated for each OS, but the disk image compression should cancel that out. Also the WebKit Web Inspector is in the nightly. It is 5.1 MB (uncompressed) in r135421 and 6.3 MB in r145786. A 24% increase. Again, mostly images. So I don't think the majority of the download size increase correlates to in-memory size of the binaries. (See the link Eric sent later for that.) — Timothy Hatcher ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] ChangeLogs
Lately I have observed more and more and more changes going into WebKit that lack any details about why a particular change was made. It is intended that the ChangeLog (and commit message) contain some details about your change, not just the bug title and URL. The contributing information on subject is pretty sparse, which has likely caused this problem to manifest. However, the example ChangeLog linked from that page is prime example of what we all should strive for when describing our changes. To help curb this lack of detail in ChangeLogs, I propose we add script (or augment an existing script) to check for this missing information and inform the contributor. It is clear not all reviewers are asking patch authors to provide this information when reviewing, and such a tool would help enforce it. — Timothy Hatcher ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] ChangeLogs
On Mar 21, 2012, at 2:46 PM, Adam Barth wrote: On Wed, Mar 21, 2012 at 2:29 PM, Timothy Hatcher timo...@apple.com wrote: Lately I have observed more and more and more changes going into WebKit that lack any details about why a particular change was made. It is intended that the ChangeLog (and commit message) contain some details about your change, not just the bug title and URL. Since I was the reviewer for http://trac.webkit.org/changeset/111577 (although if you look in the bug thread, you'll see that I was just forwarding fishd's R+ after some trivial cleanups), I'm curious what additional information you think should have been included in that ChangeLog. There really isn't much to say about that change. Tommy was just adding thin API wrappers around WebCore objects as part of the implementation of the MediaStream API. The main point of discussion in the bug thread was whether to use the name ICE or Ice. Adam Adding thin API wrappers around WebCore objects as part of the implementation of the MediaStream API. would be a good start. I shouldn't have to troll through a bug with 21 comments to figure out a change. Also the WebCore changes are just case changes, but you wouldn't know that by just perusing the ChangeLog/commit message. — Timothy Hatcher ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] ChangeLogs
On Mar 21, 2012, at 3:14 PM, Dirk Pranke wrote: I think this is a reasonable suggestion, but I don't agree with it :). I would prefer that we try to get good changelogs through culture and convention rather than through good tooling. This is of course based on my experience in my changes and the types of changes I review, but I personally find what value there is at all in ChangeLogs in the paragraphs at the top of the change, and I find the lists of changed files and to be distracting noise far more often than not. (Perhaps things are different in changes to the core rendering code than changes to tooling and test code). I find the comments useful, even for scripts. ChangeLogs for tests are often more mundane. My particular interest is the Web Inspector, which I follow by watching bugs and commits. Often I find myself asking why? or what does this do? when perusing the commits. It sometimes isn't very obvious and a nice concise description in the ChangeLog would help. This is even more important when folks are separated by timezones or are not easy to reach for explanation. They also provide insight when looking back on changes from months or years ago when tracking down a regression. I think it is difficult to say what a good changelog is an any sort of algorithmic sense, and trying to implement something that would be done programmatically will be more annoying than useful (even if it means that I just have to delete a bunch of OOPS lines). It would be difficult to make the tool smart. I merely looking for reminder to push folks to describe their changes in some fashion, not a analytical tool parsing for good vs bad. — Timothy Hatcher ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit unit test framework
I think having something the WebKit community owns and controls is preferred over importing and using a third-party library. So that makes me prefer TestWebKitAPI (or something built from/on it) over gtest. And TestWebKitAPI already has a very simple test for WTF::Vector — just begging to be expanded. On Apr 18, 2011, at 11:36 AM, David Levin wrote: Issue: There has been a long standing bug to add unit tests to WebKit (https://bugs.webkit.org/show_bug.cgi?id=21010). It was also mentioned on webkit-dev that it would be helpful in various cases. Landscape: Surveying WebKit, it is looks like there are at least three testing frameworks being used: TestWebKitAPI/WebKitAPITest (in Tools), QTest, gtest (in Source/WebKit/chromium/). However, only one TestWebKitAPI has been used so far (as far as I can tell) for testing core WebKit items like WTF (though I was unaware of TestWebKitAPI until Friday). It seems like a good way to think about the issue of which to use in general in WebKit would be to decide on what would be desired in our framework and then see how each matches up. Here's my take on this. (It may be biased toward what I am familiar with but I welcome others to add their own criteria.) Criteria Musts: Compatible license with WebKit Builds/Can be built on the many platforms and build systems supported by WebKit (ideally without extra installs). Useful: Easy to write tests Hackable to suit our needs Well tested features (to support hackability/stability) Supports filtering of tests so you can run just the test you care about (and easily listing the tests). Supports writing out values when there is test failure. (For example, if the is verifying that A == B but that is not true, then the values of A and B should be printed.) Well documented thanks, dave ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev — Timothy Hatcher ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] DOM Mutation Events. WAS: Fwd: webkit editing rewrite?
On Aug 9, 2010, at 7:52 PM, Dimitri Glazkov wrote: I am very, very tempted to just get rid of them. As Ojan indicated, the use cases for DOM Mutation events are extremely limited and to me, most of them feel like we should be solving them differently anyway. However, with the introduction of extensions into Chromium and Safari, DOM Mutation events experience a sort of renaissance, being used to sense the DOM changes to re-apply modifications (rewrite URLs, text, etc.). So I think we will upset a bunch of extensions developers if we just go cold turkey, which is probably not the right thing -- regardless of whether techniques they employ are sound or not. With this in mind, I think we should do #1 and #3, then #2 after some time and loud over-communication (like Inspector warnings, blog posts, billboards on Hwy 101 etc.). Adding input/beforeinput events (#3) wont solve the need of most extension developers that use mutation events today (the examples you cite). So that makes it hard to remove them, especially over time, no matter how much warning you give. — Timothy Hatcher ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Commit Queue Love
On Jul 9, 2010, at 3:38 AM, Alex Milowski wrote: Being able to go around the commit queue means you can cheat. That seems like something that should be reserved for more severe problems where we know the process used by the commit queue will fail. That is not how I see it at all. And calling it cheating is quite offensive to me. Just because I want control over when and how my patch is committed is suddenly considered cheating? Some of the glaring reasons I don't use the commit queue have been resolved (svn blame mainly), but the fact that there is no control over when the path lands is my chief reason. Often I need to update Apple's internal bug database when I make a change to WebKit, so I just can't rely on the commit bot to close the bugzilla bug. That means holding a bug open and knowing go back days later when it finally lands to close the internal bug. Other times there are internal deadlines that need to be meet and hours matter. As well as keeping patches that span WebKit and Safari in-sync. So until the commit queue solves these issues, I will keep exercising my right to svn commit and be responsive to problems my commits might bring. But please lets stop calling it cheating. — Timothy Hatcher ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] On adding 'console.memory' API (and about the whole 'console' object.)
Even if that wont prevent Sam's proposed information leak, I think this would be good to do. That way developers only see what they are affecting. Otherwise a developer might chase a red herring if they have Gmail or something open in the background and keep seeing spikes of memory are not caused by their page. On Jun 2, 2010, at 2:45 PM, Mikhail Naganov wrote: Used memory count can be restricted to include only objects reachable from the caller execution context. In this case, an app could only see the amount of memory consumed by itself, not by the whole engine. — Timothy Hatcher ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] webkit-patch requests
The xed --wait is much better, since it waits for the files to be closed, not for Xcode to quit. (And quitting Xcode is pretty disruptive if you have projects open.) On May 19, 2010, at 1:08 PM, Maciej Stachowiak wrote: There’s also a tool called xed that I could probably use as an EDITOR. The xed command has an option --wait that can make it behave more like modal vi. The xed tool was created many years after I wrote those scripts. The Mac OS X open command also has a -W option which can wait for quit. I believe setting EDITOR=open -W -a Xcode would probably do it. — Timothy Hatcher ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] webkit-patch, check-webkit-style and git now support --squash and --git-commit
webkit-patch sounds useful now… On Apr 26, 2010, at 10:55 AM, Ojan Vafai wrote: Eventually, I'd like to make --squash the default, but I want this to bake and get some usage before flipping that switch. But I don't think this makes sense as a default to me. But maybe I use git differently than everyone else… I don't do the whole branch-per-bug business. I usually have one git commit per commit I plan to push to SVN (each with a separate ChangeLog entry). — Timothy Hatcher ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] #webkit and unregistered nicks
We could also appoint some channel operators that have the power to kick/ban spambots when they happen (or +r/+m the channel). On Apr 14, 2010, at 4:44 AM, Maciej Stachowiak wrote: Done. We seem to have more trouble with people being mysteriously locked out than with spambots, so we should probably only restrict the channel during active spambot attacks (if we get any). — Timothy Hatcher ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Git meeting notes
Only the first 5-7 characters are needed to identify a single commit (enough of the hash prefix to be unique). So REGRESSION(96c3b0) vs REGRESSION(r12345). On Apr 12, 2010, at 6:28 PM, Alexey Proskuryakov wrote: One thing that wasn't mentioned at the meeting is that git doesn't seem to have the same monotonously increasing revision numbers as svn does. It will be a problem to replace REGRESSION(r12345) with REGRESSION(96c3b0300ccf16b64efc260c21c85ba9030f2e3a). — Timothy Hatcher ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Commit queue blocked because of failing tests
I agree with Jeremy and David. If you are a committer you should try to land patches on your own when you can. I mainly think this because it lets svn/git blame work as intended instead of always blaming who ran the bot. Maybe we should have a commit-...@webkit.org user? On Feb 25, 2010, at 5:41 AM, Eric Seidel wrote: On Thu, Feb 25, 2010 at 5:26 AM, Jeremy Orlow jor...@chromium.org wrote: It also frees up the queue for those who need it. A common misconception, but looking at the logs the commit-queue looks to be no where near capacity. I believe it could commit every change done to WebKit in a day and still not be near capacity. :) The only thing that prevents the commit-queue from cycling regularly is the bots breaking (this includes flakey tests). :( -eric On Thu, Feb 25, 2010 at 1:17 AM, Kenneth Russell k...@google.com wrote: On Wed, Feb 24, 2010 at 3:48 PM, David Levin le...@chromium.org wrote: 1. It looks like you are a committer, so you don't need to wait for the commit queue to do this for you :) Understood -- but I prefer to use the bots where possible. I've seen multiple instances where the commit scripts failed to add new files for some reason, but the bots have always been 100% reliable. -Ken 2. But it still would be good to have this fixed. If you'd like to help move this along, you can go to http://build.webkit.org/waterfall and find which patch caused the test to start failing. Then ping the relevant person. On Wed, Feb 24, 2010 at 3:41 PM, Kenneth Russell k...@google.com wrote: On Wed, Feb 24, 2010 at 12:02 PM, Alexey Proskuryakov a...@webkit.org wrote: On 24.02.2010, at 11:47, David Levin wrote: Actually, it doesn't appear to be do to recent changes in this area. They started failing after r55177 (http://build.webkit.org/waterfall?last_time=1266975298), but that change is unrelated to these test as far as I can tell. It looks unrelated, but it somehow broke these editing tests nonetheless. I'm investigating now. Thanks. Our patch (from https://bugs.webkit.org/show_bug.cgi?id=34459) was about to be landed by the bot when the tree went red again. The test now failing is: fast/dom/prototype-inheritance-2.html - failed Could someone please look? Thanks, -Ken ___ 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] Buildbot Emails
On Feb 8, 2010, at 5:29 PM, Maciej Stachowiak wrote: That could be either webkit-dev or a new list. Maybe some won't want the spam but I bet a lot of people would like to find out about every build break. Please make it a new opt-in list. — Timothy Hatcher ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Selection highlight painting (gaps?)
On Oct 19, 2009, at 1:43 PM, Peter Kasting wrote: Note that within Chrome we put in ctrl-shift-v to paste as plain text precisely because of issues like this. Most other programs don't have that option though (and even in Chrome it's hard to discover). On Mac we call this Paste and Match Style and it is common is many Mac apps, including Safari. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Selection highlight painting (gaps?)
On Oct 19, 2009, at 1:43 PM, Peter Kasting wrote: Note that within Chrome we put in ctrl-shift-v to paste as plain text precisely because of issues like this. Most other programs don't have that option though (and even in Chrome it's hard to discover). I guess it isn't exactly what you describe, since images and other rich content are still pasted. Just not text styles. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Changes to prepare-ChangeLog
I also agree and that is the style I use. On Jul 2, 2009, at 7:05 AM, Adam Roben wrote: - I generally move the Reviewed by line after the bug number/ description/URL. When you're reading a ChangeLog entry/commit message (especially an older one), it's generally much more interesting which bug is being fixed rather than knowing who reviewed it. (Also, putting the bug description first makes git's one-line description of each commit much more useful than either having a list of dates and the person who wrote the patch or having a list of patch reviewers.) I agree with Dave on all three points. git users gotta stick together. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] how to destroy JSObjescts?
JavaScript objects and the JavaScriptCore API objects (except JSStringRef) are garbage collected. So sometime after the last reference goes away, they will release their memory. In this case when the global object goes away. If you want to release them, you can call JSObjectDeleteProperty to remove the reference. You also need to call JSStringRelease here when you are done with the jsstr variable. On Nov 25, 2008, at 8:05 AM, Iulian wrote: I create several JSObjects like this: js_object= JSObjectMakeConstructor(context, object_jsclass, Object_Constructor); globalObject = JSContextGetGlobalObject(context); jsstr = JSStringCreateWithUTF8CString(MyObject); JSObjectSetProperty(context, globalObject, jsstr, js_object, kJSPropertyAttributeNone, NULL); From JavaScript i have: MyObject obj= new MyObject(); The problem is that the objects are never destroyed. What can i do to release all these objects? ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Debugging JavaScript Core Apps that are not Safari
The debugging functionally is part of WebKit, not Safari. So you can use the JavaScript debugger that is part of the Web Inspector in any WebKit client application. But this does not include JavaScriptCore client applications. I am surprised to hear that Drosera worked, since it was similarly tied to WebKit. Please file a bug requesting this functionality. On Nov 21, 2008, at 7:06 AM, Scott Thompson wrote: It's been a while since I've looked at JavaScript Core and obviously a lot of changes have gone on. In my previous examination, I was using Drosera to debug an application which used JavaScript Core as an internal scripting engine. It would appear that all the JavaScript debugging facilities have been moved inside of Safari. Is it still possible to debug JavaScript code running through JavaScript Core in an application other than Safari? ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] High Resolution Timer API proposal(s)
Why double delayInSeconds and not milliseconds to stay consistent?
On Oct 2, 2008, at 5:32 PM, Ojan Vafai wrote:
On Thu, Oct 2, 2008 at 5:16 PM, Aaron Boodman [EMAIL PROTECTED] wrote:
On Thu, Oct 2, 2008 at 5:05 PM, Maciej Stachowiak [EMAIL PROTECTED]
wrote:
I don't really like the overengineered version. I like the fairly
minimalist version best, but is there anything from the
overengineered version that should be added to it?
I like the fairly minimalist version best as well.
The stop() method does seem a little lonely on the Timer interface all
by itself.
If others think any other members from the overengineered version
are important I would welcome them to keep stop() company.
+1. My ideal would be the following:
Timer startTimer(double delayInSeconds, bool repeating, Function
callback);
interface Timer {
void stop();
void resume();
void setDelay(double delayInSeconds);
}
That would cover the majority of cases I've seen in real-world
javascript code. The argument for setDelay is wanting to be able to
tweak the delay on the fly (e.g. Google Page Creator has autosave
code that gets a response from the server with a longer delay time
when the server is overloaded).
Ojan
___
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 catch JS exceptions/log messages from a WebView?
The Web Inspector also shows these for any WebView. On Dec 22, 2007, at 8:14 AM, Todd Ditchendorf wrote: For example, I want to implement something similar to the JavaScript Console in the Safari debug menu. Also, how do you capture statements sent to console.log(), console.warn() and console.error() within a WebView? — Timothy Hatcher ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Moving away from qmake
Apple needs to use native Xcode and VS projects to work with existing build systems. So generating an Xcode or VS project is not useful. On Nov 12, 2007, at 12:20 PM, Jean-Charles VERDIE (Pleyo) wrote: I might be wrong but I think it's useful to be able to generate, from the same sources and using a CMake facility, an Xcode project (to work under XCode on Mac), a VS project, a CMakeFile for linux- based solutions, — Timothy Hatcher ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Moving away from qmake
We could add a script that would add/remove/rename files in all the project files for the various build systems. On Nov 12, 2007, at 1:19 PM, David D. Kilzer wrote: Kevin Ollivier [EMAIL PROTECTED] wrote: [...] The tricky part AFAICT would be XCode, though, because even if there is a scripted solution for this, it would probably need to be run on a Mac where we have access to AppleScript or some other scripting tool that can read and make changes to XCode projects... [...] Xcode project files are plain text as well. It's possible to update them via script (see WebKitTools/Scripts/sort-Xcode-project-file), but it requires a little more insight than just staring at the source. — Timothy Hatcher ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Should we consider switching to git over svn?
I think Git is rather slow on Windows I hear. On Oct 8, 2007, at 9:29 PM, Oliver Hunt wrote: * Speed: Git is much faster than svn (which becomes very valuable on windows, — Timothy Hatcher ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Threading issues regarding Netscape API plugins in WebKit
WebKit does not implement NPN_PluginThreadAsyncCall. A plugin could spawn another thread, but it can not call JavaScript (or any other API call) from that other thread. On Sep 28, 2007, at 10:26 AM, Song Yuan wrote: Are plugins implemented by using Netscape APIs in WebKit thread safe? Does Netscape APIs in WebKit have similar APIs like NPN_PluginThreadAsyncCall (refer to http://developer.mozilla.org/en/docs/NPN_PluginThreadAsyncCall) in Gecko SDK in Mozilla? Will a new thread pawned from plugin main thread be able to invoke any JavaScript methods in browser? — Timothy Hatcher ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] identifying a unique iPhone?
Anything other than a cookie would be a privacy risk. So there is no other way. This list is also not the best place to ask iPhone specific questions like this. (Though I don't have another list to recommend.) On Aug 17, 2007, at 12:07 PM, Scott wrote: Hopefully this is the proper list to post to: I am writing an iPhone web application, and know how to tell that I am talking to an iPhone, but is there a way to uniquely identify a specific iPhone? For example, some header or something I can get with either server side or browser side code and store on the server side so in the future I know which iPhone this is? I know I can implement a cookie style log-in system, but I was hoping for some value I can just get and use. — Timothy Hatcher ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] lists and tables in contentEditable
We don't have plans to add support for these yet. But bug reports requesting the features and patches are always are always welcome. — Timothy Hatcher On Jul 5, 2007, at 6:54 PM, piet wrote: NSTextView supports the edition of lists and tables through orderFrontListPanel: and orderFrontTablePanel: ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
