[webkit-dev] saving the current state of webkit
Hello. I want to partially prevent the user from loosing focus from the current page being displayed. As I see, this can be done by saving the current state of webkit which means serializing the DOM tree. But I don't know if traversing the DOM tree is sufficient and which information is relevant to restore the previous state. Is there already some API for session restoration? Greets, Luka ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] How to develop NPAPI plugin with webkit lib
Are you calling NPN_CreateObject using the function pointers that were exchanged during initialization? You're probably aware that the browser provides pointers to the browser side of the NPAPI and it is your job as the plugin author to populate the function pointers that make up the plugin side of the NPAPI. On Mon, Jul 13, 2009 at 4:06 AM, Harry Zhangzhangha...@gmail.com wrote: Besides the issue of missing NPAPI headers, i also failed to find npruntime symbols such as NPN_CreateObject in libwekbit-1.0 (i used objdump -t to check the symbols), so i got undefined reference to NPN_CreateObject during the link phase, somehow confused. I'm a newbie in this NPAPI plugin area, am i on the right track? On Fri, Jul 10, 2009 at 7:27 PM, Harry Zhang zhangha...@gmail.com wrote: Hi all, after i built and make install the webkit (r4) gtk port on Ubuntu, i want to develop a NPAPI plugin for webkit, however i cannot found related NPAPI headers (such as npapi.h, npruntime.h) in webkit-1.0 include directory, can anybody point out where to find these headers, or what i've missed in the build and install steps? Many thanks in advance! Regards, Harry ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- Regards Jack ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Patch process - let's make it better
Hi Luke, I think your webkit-dev emails are becoming disruptive. Sending profanity-laced walls of text is not an appropriate use of this list. Please find a way to communicate without annoying the rest of the list, or I will ask the list administrators to censor you from the mailing list for the period of at least a week. Regards, Maciej On Jul 12, 2009, at 10:47 PM, Luke Kenneth Casson Leighton wrote: Hi everyone, One common topic for discussion has been how to make our process around patch submission better. As the project grows, it's becoming more important for this process to work really smoothly, and we are seeing some breakdowns. well, this is interesting - some good timing on sending this message. i believe it would be reasonable to say that regarding #16401, breakdown would be an understatement of the first order. I've been doing a lot of thinking about this, and discussion with some project old hands. I think the right way to tackle this is to identify the process problems, and make sure we address each one. yes. perhaps, as i have been on the receiving end of some quite shit and unnecessary treatment, i can help give some insights here. 1) there is no charter for webkit. one absolutely vital thing which prevents problems is to have a charter which outlines, up-front, the expectations and development of the project. the apache foundation charter states clearly that: * developers shall treat each other with mutual respect. * contributions shall be considered on technical merit for the freedce foundation, after the samba fiasco in which continuous goal-post moving and technical bullying was utilised to make significant technical contributions - and their contributors - look like shit, we modified this to: * contributions shall be considered on strategic technical merit providing a charter clearly outlines an encouraging environment, and also allows you to gently - or forcefully - bring people back into line. in the case of webkit, then, a charter containing these vital guidelines would have stopped the disrespectful treatment i got absolutely dead in its tracks. if a free software developer says, no, i am a free software _contributor_, not a paid-up employee whom you can [effectively] _demand_ [sponge off]. i don't have time or money to give more than i have to get this issue dealt with, it ing well means no, you can't ask for more than i've already gifted to this project, and the people who were asking should, instead of getting stroppy, go oh - sorry, i apologise for that! i didn't mean in any way to etc. and generally indicate gratitude for, and respect for, the contributions made. read the comments on #16401 bearing in mind that they are _free_ and _unpaid_ contributions (not funded by any company or sponsor), and watch the breakdown in the conversation due to assumptions made by apple paid-up employees - it's very interesting reading. 2) there are no branches the KDE development process has what, over a hundred contributors. they don't step on each others' toes. why? because the committers are allowed to create branches. a branch, with relaxed conditions, allows people to collaborate BEFORE quotes landing quotes and still feel like they are part of the project. take the #16401 work as a classic example: with over 5,000 lines, not one of the groups of contributors could officially collaborate on improvements because the contributors had no central official place in which to collaborate, to meet the over-strict and far too time-consuming review requirements. also, if you look around, there are one hell of a lot of unofficial branches of webkit. i found _yet another one_ recently, this time by intel, as part of their 3D desktop project! intel should never have felt it necessary to create a separate repository: they should have been _invited_ to have commit rights. there are plenty of scripts out there that can protect commits to branches etc. so the main trunk can be protected. 3) the review process is hostile and confrontational. it even says, up-front, this process may seem daunting. that's got to stop. i would not be surprised if the confrontational approach is a hang-over from internal apple development ethos. it doesn't work in the free software world: if you're going to state, up-front, we're going to be tough on you, then potential contributors will just say sod you, then and walk away. 4) automation of coding standards checking this is trivial to do. hindent immediately springs to mind. it could even be added as a commit hook to trunk (leaving branches alone of course). 5) assumptions that people know where to read about webkit standards and processes there seems to be an assumption that people know all about webkit's standards, and irritation and in some cases outright hostility when people with enthusiasm and the willingness to contribute simply are not aware of these standards. 5) assumptions that people
Re: [webkit-dev] How to develop NPAPI plugin with webkit lib
Zhang, The napi.h is located under WebCore/bridge folder. Please check to see why it didn't include in the build. -Hieu -Original Message- From: webkit-dev-boun...@lists.webkit.org [mailto:webkit-dev-boun...@lists.webkit.org] On Behalf Of Jack Wootton Sent: Monday, July 13, 2009 4:50 PM To: Harry Zhang Cc: webkit-dev@lists.webkit.org; webkit-h...@lists.webkit.org Subject: Re: [webkit-dev] How to develop NPAPI plugin with webkit lib Are you calling NPN_CreateObject using the function pointers that were exchanged during initialization? You're probably aware that the browser provides pointers to the browser side of the NPAPI and it is your job as the plugin author to populate the function pointers that make up the plugin side of the NPAPI. On Mon, Jul 13, 2009 at 4:06 AM, Harry Zhangzhangha...@gmail.com wrote: Besides the issue of missing NPAPI headers, i also failed to find npruntime symbols such as NPN_CreateObject in libwekbit-1.0 (i used objdump -t to check the symbols), so i got undefined reference to NPN_CreateObject during the link phase, somehow confused. I'm a newbie in this NPAPI plugin area, am i on the right track? On Fri, Jul 10, 2009 at 7:27 PM, Harry Zhang zhangha...@gmail.com wrote: Hi all, after i built and make install the webkit (r4) gtk port on Ubuntu, i want to develop a NPAPI plugin for webkit, however i cannot found related NPAPI headers (such as npapi.h, npruntime.h) in webkit-1.0 include directory, can anybody point out where to find these headers, or what i've missed in the build and install steps? Many thanks in advance! Regards, Harry ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- Regards Jack ___ 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] Patch process - let's make it better
I think your webkit-dev emails are becoming disruptive. Sending profanity-laced walls of text is not an appropriate use of this list. Please find a way to communicate without annoying the rest of the list, or I will ask the list administrators to censor you from the mailing list for the period of at least a week. I concur with Maciej. Luke, in some other culture your posts are already considered derogatory and insulting. -- Ariya Hidayat, Nokia ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Patch process - let's make it better
On 7/13/09, Maciej Stachowiak m...@apple.com wrote: Hi Luke, hi maciej, I think your webkit-dev emails are becoming disruptive. whilst at the same time apologising for being disruptive, i'd like to ask you why you consider that to be a bad thing. Sending profanity-laced walls of text is not an appropriate use of this list. i apologise for the use of profanity which may cause offense. i ask you to consider this: if it wasn't for the frustration at being treated in a completely inappropriate fashion, i wouldn't feel the need to use profanity to express frustration, would i? if you see things from my perspective, it's that i have great enthusiasm to contribute to free software in areas which require such a wild and overwhelming mix of expertise that nobody is willing to step up to the plate. that's where i step in. Please find a way to communicate without annoying the rest of the list, i will be delighted to do so. in return, you - apple employees - will treat my contributions with a little more respect, and perhaps even apologise for some of the inappropriate treatment. or I will ask the list administrators to censor you from the mailing list for the period of at least a week. i'm sorry to have to say this but i promise you that that will do nothing but prove my point. _read_ what i've written. sticking fingers in ears will only get the ends of your fingers sticky, not solve the problem. sorry i have to go, baby's crying. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Patch process - let's make it better
I concur with Maciej. Luke, in some other culture your posts are already considered derogatory and insulting. dear ariya, i apologise for that. i invite you to consider this, especially in light of the subject being discussed: if there was not a deep seated problem with the way that apple is treating people who contribute to the webkit project, then my ire would not have been raised such that i felt it necessary to express my frustration using swearwords, would it? saying that again, in shorter form: if there were no problems with the patch process, there would be no swearing. so, if you would like to help contribute something, please help apple take into consideration the lessons learned from #16401 so that something like the absolutely appalling lack of respect shown for my contributions does not happen again. l. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Patch process - let's make it better
On 7/13/09, Luke Kenneth Casson Leighton luke.leigh...@googlemail.com wrote: I concur with Maciej. Luke, in some other culture your posts are already considered derogatory and insulting. also - (i apologise for not thinking of this earlier) - it's worth emphasising that early on in the #16401 development process, when things were going well, the development was progressing rapidly, and i was collecting valuable contributions, advice and input from several sources, including apple employees as well as free software sources, i felt absolutely no need to swear. then, as the sheer scale of the work began to become clear to the reviewers, they began to feel overwhelmed, and, in an effort to reduce stress levels, began to throw up barriers. i began to provide technical counter-arguments and justifications for the progress, and still i did not feel any need to swear. i was asked to take several weeks worth of steps backwards, and began to feel pressurised: eight weeks at eleven hour days has a price. alp toker noticed that things were not going swimmingly and asked that the cost - financial and psychological - be taken into consideration. it was not. at this point, with rules and procedures and processes being placed over-and-above actual people, things started to break down. now we're suddenly gone from development being fun and exciting into development that is about fulfilling your duty and fulfilling the committment to the free software community that you serve, _especially_ in the face of continued hostility and complete lack of respect. this is the experience that you, apple, should never subject anyone to - should not be should not have been responsible for subjecting onto _anyone_. i trust that you, apple, will learn from this breakdown in communications. i trust that the changes to procedures and processes that you will make will help you to spot such things well in advance and act accordingly and appropriately, to make contributing to webkit as interesting and exciting as it should be. lastly, ariya, i've mentioned this elsewhere, but it's worth reiterating, here. as an experienced and gifted developer, i can take any code, from anywhere, and can pretty much immediately make useful contributions to it. i then also have the skills to manage, build and release that code. not everyone has the ability to do that. so i put up with a lot of flak from people such as apple employees in order to serve those users and developers who do _not_ have the ability that i do. and i invite you to ask yourselves: whom do _you_ serve? the answer to that question is the reason why i make the recommendation that webkit gets a charter. l. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Patch process - let's make it better
On 7/13/09, Maciej Stachowiak m...@apple.com wrote: Hi Luke, I think your webkit-dev emails are becoming disruptive. Sending profanity-laced [apologised and explained already] walls of text maciej, i thought i'd best pick up on this one and nip it in the bud, even though i've replied already. look at what i wrote. it says that webkit is missing a charter, and cites the apache software foundation charter's key point of treating people with respect as part of the success of the ASF's development and progress. describing the very contribution in which i mention that respect for contributions is key as walls of text is therefore somewhat ironic, is it not, as it clearly says i have no respect for your contribution, yes? you might want to think about that, yes? and perhaps write a message saying, i apologise, i did not mean to convey disrespect, i was upset by the swearwords that you included, which, i also realise from what you've said they were provoked, but i was still upset. also i'd like to officially apologise on behalf of apple for apple employees subjecting you to personal attack and denigration when you were only trying to help contribute to webkit's success. something like that would go down well, and would be a good indication that apple recognises the root of the problem and is willing to engage with unpaid, unsponsored free software contributors in an appropriate and inclusory way. l. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Query regarding Rendering
Hi, I need to get Rect region where a node is rendered. As per my understanding xPos() and yPos() methods on any Renderer of a node, give coordinates relative to parent node but not exact coordinates where rendering happens for that Renderer. Is there any way to find Render region for a node other than in Paint ? Regards JayaSai Kishore ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Patch process - let's make it better
On Monday 13 July 2009 13:47:13 Luke Kenneth Casson Leighton wrote: On 7/13/09, Luke Kenneth Casson Leighton luke.leigh...@googlemail.com wrote: I concur with Maciej. Luke, in some other culture your posts are already considered derogatory and insulting. also - (i apologise for not thinking of this earlier) - it's worth emphasising that early on in the #16401 development process, when things were going well, the development was progressing rapidly, and i was collecting valuable contributions, advice and input from several sources, including apple employees as well as free software sources, i felt absolutely no need to swear. then, as the sheer scale of the work began to become clear to the reviewers, they began to feel overwhelmed, and, in an effort to reduce stress levels, began to throw up barriers. Dear Luke, webkit-dev is really no place for your paranoia. greetings from your unpaid volunteer that feels well treated by the apple engineers working on webkit.org[1]. z. [1] I can not speak for all of apple, because I didn't meet every single person of currently employed by apple... ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Query regarding Rendering
I need to get Rect region where a node is rendered. Please post such questions to webkit-help, see http://lists.webkit.org/mailman/listinfo.cgi/webkit-help Rationale: read https://lists.webkit.org/pipermail/webkit-dev/2009-July/008681.html https://lists.webkit.org/pipermail/webkit-dev/2009-July/008860.html ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Patch process - a fresh thread (Was: Patch process - let's make it better)
Am 13.07.2009 um 15:33 schrieb Holger Freyther: On Monday 13 July 2009 13:47:13 Luke Kenneth Casson Leighton wrote: On 7/13/09, Luke Kenneth Casson Leighton luke.leigh...@googlemail.com wrote: I concur with Maciej. Luke, in some other culture your posts are already considered derogatory and insulting. also - (i apologise for not thinking of this earlier) - it's worth emphasising that early on in the #16401 development process, when things were going well, the development was progressing rapidly, and i was collecting valuable contributions, advice and input from several sources, including apple employees as well as free software sources, i felt absolutely no need to swear. then, as the sheer scale of the work began to become clear to the reviewers, they began to feel overwhelmed, and, in an effort to reduce stress levels, began to throw up barriers. Dear Luke, webkit-dev is really no place for your paranoia. greetings from your unpaid volunteer that feels well treated by the apple engineers working on webkit.org[1]. z. [1] I can not speak for all of apple, because I didn't meet every single person of currently employed by apple... I can only agree with Adam Holger. That said, we should really get back to the topic of this thread. Maciejs attempt to move forward with our patch process will help WebKit much more than discussing a particular patch here on the list, distracting everyones attention. -- I absolutely agree with the key issues Maciej highlighted within the review process. If that's general consensus, we should discuss the action plan from now on. I'd propose to create bug reports for important steps of the individual phases, as well as a master bug depending on all of the sub- bugs, so it's easy for anyone to follow the decision process. It may be a wise idea to move the discussion into these bug reports, as I suspect discussing all phases here, may lead to confusion. What do you others think of this? Greetings (from a long time unpaid volunteer, who feels home in WebKit as well), Niko ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Query regarding Rendering
Hi,
This should help you going:
class Element : public ContainerNode {
PassRefPtrClientRectList getClientRects() const;
PassRefPtrClientRect getBoundingClientRect() const;
}
Christophe
JayaSai Kishore wrote:
Hi,
I need to get Rect region where a node is rendered.
As per my understanding xPos() and yPos() methods on any Renderer of
a
node, give coordinates relative to parent node but not exact coordinates
where rendering happens for that Renderer.
Is there any way to find Render region for a node other than in
Paint
?
Regards
JayaSai Kishore
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
--
View this message in context:
http://www.nabble.com/Query-regarding-Rendering-tp24460697p24465571.html
Sent from the Webkit mailing list archive at Nabble.com.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] ENABLE_FORM_VALIDATION
I noticed that some new form validation code is landing (e.g., http://trac.webkit.org/changeset/45739). That change adds stubs for the ValidityState object. What I didn't see in that patch is any kind of ENABLE flag. I suspect there should be one since otherwise it becomes difficult for a web developer to know the difference between a complete implementation and the currently incomplete implementation. Web developers might have to resort to nasty UA-sniffing hacks, which doesn't make anyone happy. I'd like to propose that we add an ENABLE_FORM_VALIDATION flag (or something similarly named). I'm writing this to webkit-dev because I want to make sure that other new web platform features that may be in development get similar treatment while they are still in development. Any objections? This issue exists because we don't have a roadmap or release schedule for WebKit. Instead, we try to maintain a trunk stable development model, in which releases by various vendors may be cut at any time. I think we can continue to manage that provided new, in-progress features get developed under the appropriate #ifdef. Regards, -(other)Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] ENABLE_FORM_VALIDATION
On Mon, Jul 13, 2009 at 10:40 AM, Darin Fisher da...@chromium.org wrote: I'd like to propose that we add an ENABLE_FORM_VALIDATION flag (or something similarly named). I'm writing this to webkit-dev because I want to make sure that other new web platform features that may be in development get similar treatment while they are still in development. Any objections? No objections, but I'd like to note that I'm about to back out the upstream patch for this since in addition to this problem and it breaking the Chromium build downstream (easy fix), it also has issues with bindings, and it broke a layout test. It's easier to just fix these all at once. When it relands I will see if I can figure out what the ENABLE flag should cover and make sure it's covered. I'm concerned about other things already in the tree with valid in their name, e.g. readonly attribute boolean willValidate -- not sure if these should also be under the flag for now. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] ENABLE_FORM_VALIDATION
I agree. We should formalize this as policy too in my opinion. Maybe something time-based, e.g., if you have an implementation of a new Web technology that is going to take (1month?) to implement, then the feature should be landed inside ENABLE ifdefs (that can then be removed when the feature is sufficiently far along). dave On Jul 13, 2009, at 12:40 PM, Darin Fisher wrote: I noticed that some new form validation code is landing (e.g., http://trac.webkit.org/changeset/45739) . That change adds stubs for the ValidityState object. What I didn't see in that patch is any kind of ENABLE flag. I suspect there should be one since otherwise it becomes difficult for a web developer to know the difference between a complete implementation and the currently incomplete implementation. Web developers might have to resort to nasty UA-sniffing hacks, which doesn't make anyone happy. I'd like to propose that we add an ENABLE_FORM_VALIDATION flag (or something similarly named). I'm writing this to webkit-dev because I want to make sure that other new web platform features that may be in development get similar treatment while they are still in development. Any objections? This issue exists because we don't have a roadmap or release schedule for WebKit. Instead, we try to maintain a trunk stable development model, in which releases by various vendors may be cut at any time. I think we can continue to manage that provided new, in-progress features get developed under the appropriate #ifdef. Regards, -(other)Darin ___ 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] ENABLE_FORM_VALIDATION
2009/7/13 Darin Fisher da...@chromium.org: I'd like to propose that we add an ENABLE_FORM_VALIDATION flag (or something similarly named). I'm writing this to webkit-dev because I want to make sure that other new web platform features that may be in development get similar treatment while they are still in development. Any objections? Hi Darin, no objection, it sounds quite reasonable indeed. Let's wait for others' opinion, in the meantime I get the code ready, just in case. -- Milton Berle - If opportunity doesn't knock, build a door. - http://www.brainyquote.com/quotes/authors/m/milton_berle.html ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] ENABLE_FORM_VALIDATION
2009/7/13 Peter Kasting pkast...@google.com: When it relands I will see if I can figure out what the ENABLE flag should cover and make sure it's covered. I'm concerned about other things already in the tree with valid in their name, e.g. readonly attribute boolean willValidate -- not sure if these should also be under the flag for now. At this time the willValidate flag has a concrete, even if uncomplete, behaviour. Anyway it depends upon other things (like new input types). So I tend to agree on that too. -- Gilda Radner - Adopted kids are such a pain - you have to teach them how to look like you. - http://www.brainyquote.com/quotes/authors/g/gilda_radner.html ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] ENABLE_FORM_VALIDATION
On Mon, Jul 13, 2009 at 10:47 AM, David Hyatt hy...@apple.com wrote: I agree. We should formalize this as policy too in my opinion. Maybe something time-based, e.g., if you have an implementation of a new Web technology that is going to take (1month?) to implement, then the feature should be landed inside ENABLE ifdefs (that can then be removed when the feature is sufficiently far along). For Chromium this kind of time frame can be problematic, since there's pretty much no guarantee of when a WebKit trunk build could be shipped as (eventually) a stable Chromium/Google Chrome release. Even having an incomplete feature in the tree a few days can result in the incomplete feature getting shipped to web authors. There is a general problem here of when is the WebKit trunk shippable by third-parties, which is an issue too large and hairy for me to get into, let alone propose concrete changes for. However, if we simply had a policy of if a web author can detect and try to use the feature, but it doesn't work right yet, then put it under a flag, that would at least take care of this piece of the problem. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] A module that changes webserver configuration?
Hello, I am looking for pointers to module(s) that change the webserver configuration (in-memory and maybe also in the config files on disk) for any reason. Are there any such modules? Or is Apache inherently an ecosystem where the config (config files) are not written to by the webserver itself? Any pointers are really appreciated. Thanks. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] ENABLE_FORM_VALIDATION
On Jul 13, 2009, at 12:52 PM, Peter Kasting wrote: On Mon, Jul 13, 2009 at 10:47 AM, David Hyatt hy...@apple.com wrote: I agree. We should formalize this as policy too in my opinion. Maybe something time-based, e.g., if you have an implementation of a new Web technology that is going to take (1month?) to implement, then the feature should be landed inside ENABLE ifdefs (that can then be removed when the feature is sufficiently far along). For Chromium this kind of time frame can be problematic, since there's pretty much no guarantee of when a WebKit trunk build could be shipped as (eventually) a stable Chromium/Google Chrome release. Even having an incomplete feature in the tree a few days can result in the incomplete feature getting shipped to web authors. The way to ship ToT (in my opinion) is to cut a branch, watch ToT for any regressions from recent work, merge those fixes into the branch, and then turn off anything that is in-progress on the branch. Expecting ToT to actually be shippable all the time is not very practical. Realistically people will always be causing occasional regressions from bug fixes and feature work. Branches are the way to stabilize from some known point. dave (hy...@apple.com) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] ENABLE_FORM_VALIDATION
On Mon, Jul 13, 2009 at 11:40 AM, David Hyatt hy...@apple.com wrote: On Jul 13, 2009, at 12:52 PM, Peter Kasting wrote: On Mon, Jul 13, 2009 at 10:47 AM, David Hyatt hy...@apple.com wrote: I agree. We should formalize this as policy too in my opinion. Maybe something time-based, e.g., if you have an implementation of a new Web technology that is going to take (1month?) to implement, then the feature should be landed inside ENABLE ifdefs (that can then be removed when the feature is sufficiently far along). For Chromium this kind of time frame can be problematic, since there's pretty much no guarantee of when a WebKit trunk build could be shipped as (eventually) a stable Chromium/Google Chrome release. Even having an incomplete feature in the tree a few days can result in the incomplete feature getting shipped to web authors. The way to ship ToT (in my opinion) is to cut a branch, watch ToT for any regressions from recent work, merge those fixes into the branch, and then turn off anything that is in-progress on the branch. Expecting ToT to actually be shippable all the time is not very practical. Realistically people will always be causing occasional regressions from bug fixes and feature work. Branches are the way to stabilize from some known point. I agree, but I also agree with Peter's heuristic for when things should be behind a flag. Regressions can always happen, but if you're knowingly introducing something that's half-baked it really seems like it should be behind a flag. Note also that Chromium's dev channel releases are pretty much weekly, so cutting a branch for those is not practical. Some web developers do use WebKit's nightly builds and Chromium's dev channel, so keeping things relatively stable (with not much cost...flags are easy to add) seems like the right way to go. J ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] ENABLE_FORM_VALIDATION
On Jul 13, 2009, at 1:52 PM, Jeremy Orlow wrote: On Mon, Jul 13, 2009 at 11:40 AM, David Hyatt hy...@apple.com wrote: On Jul 13, 2009, at 12:52 PM, Peter Kasting wrote: On Mon, Jul 13, 2009 at 10:47 AM, David Hyatt hy...@apple.com wrote: I agree. We should formalize this as policy too in my opinion. Maybe something time-based, e.g., if you have an implementation of a new Web technology that is going to take (1month?) to implement, then the feature should be landed inside ENABLE ifdefs (that can then be removed when the feature is sufficiently far along). For Chromium this kind of time frame can be problematic, since there's pretty much no guarantee of when a WebKit trunk build could be shipped as (eventually) a stable Chromium/Google Chrome release. Even having an incomplete feature in the tree a few days can result in the incomplete feature getting shipped to web authors. The way to ship ToT (in my opinion) is to cut a branch, watch ToT for any regressions from recent work, merge those fixes into the branch, and then turn off anything that is in-progress on the branch. Expecting ToT to actually be shippable all the time is not very practical. Realistically people will always be causing occasional regressions from bug fixes and feature work. Branches are the way to stabilize from some known point. I agree, but I also agree with Peter's heuristic for when things should be behind a flag. Regressions can always happen, but if you're knowingly introducing something that's half-baked it really seems like it should be behind a flag. I agree with that. I'm just asserting that some reasonable time limit before requiring ifdefs is ok. If a feature only takes 1-2 weeks to land, I think it's total overkill to put it inside an ifdef. Any cut branch should take long enough to stabilize that it could merge the rest of the feature in anyway. If you're ever cutting a branch off ToT and shipping it as a full-blown release with less than 2 weeks turnaround, you're doing it wrong in my opinion. dave (hy...@apple.com) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] ENABLE_FORM_VALIDATION
On Mon, Jul 13, 2009 at 11:57 AM, David Hyatt hy...@apple.com wrote: On Jul 13, 2009, at 1:52 PM, Jeremy Orlow wrote: On Mon, Jul 13, 2009 at 11:40 AM, David Hyatt hy...@apple.com wrote: On Jul 13, 2009, at 12:52 PM, Peter Kasting wrote: On Mon, Jul 13, 2009 at 10:47 AM, David Hyatt hy...@apple.com wrote: I agree. We should formalize this as policy too in my opinion. Maybe something time-based, e.g., if you have an implementation of a new Web technology that is going to take (1month?) to implement, then the feature should be landed inside ENABLE ifdefs (that can then be removed when the feature is sufficiently far along). For Chromium this kind of time frame can be problematic, since there's pretty much no guarantee of when a WebKit trunk build could be shipped as (eventually) a stable Chromium/Google Chrome release. Even having an incomplete feature in the tree a few days can result in the incomplete feature getting shipped to web authors. The way to ship ToT (in my opinion) is to cut a branch, watch ToT for any regressions from recent work, merge those fixes into the branch, and then turn off anything that is in-progress on the branch. Expecting ToT to actually be shippable all the time is not very practical. Realistically people will always be causing occasional regressions from bug fixes and feature work. Branches are the way to stabilize from some known point. I agree, but I also agree with Peter's heuristic for when things should be behind a flag. Regressions can always happen, but if you're knowingly introducing something that's half-baked it really seems like it should be behind a flag. I agree with that. I'm just asserting that some reasonable time limit before requiring ifdefs is ok. If a feature only takes 1-2 weeks to land, I think it's total overkill to put it inside an ifdef. Any cut branch should take long enough to stabilize that it could merge the rest of the feature in anyway. Hm. Now that I think about it, I'm mixing up breaking existing behavior and adding new features which are in flux. In the former case, it should always be behind a flag, right? But yeah, for the latter case, I guess 1-2 weeks seems reasonable to me. If you're ever cutting a branch off ToT and shipping it as a full-blown release with less than 2 weeks turnaround, you're doing it wrong in my opinion. I think we can all agree with that. :-) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Please welcome GYP to the our dysfunctional build family
Generate Your Projects, or GYP, was designed around Chromium's needs. Maintaining distinct project files for different build environments and different platforms put a great burden on our team, and was never intended to be a long-term solution. We really wanted to have a single canonical description of the build from which we could generate the native project files that developers were accustomed to. One proposed solution was to treat our SCons build as canonical and have it generate native project files. This integration never really came to fruition. We had SCons generating Visual Studio projects for simpler projects, but mapping the flexible SCons input language to the more restrictive descriptions used in IDE project files proved difficult. We also considered CMake, and had it demonstrably working for some of our smaller projects as well. Unfortunately, transitioning to CMake would have required moving everything over at once, without allowing for some existing projects to be maintained by hand during a transition period. CMake-generated files contain absolute paths, so a .tar or .zip of the source tree could not be primed with CMake output, complicating the bootstrapping process for new contributors. A less significant factor was that CMake introduced an additional binary build prerequisite, which would have had to have been installed everywhere. Python is already a prerequisite for Chromium, so a Python tool was easier to deploy. The net result of all of this was GYP, which was designed specifically to meet Chromium's needs. We were able to get GYP to generate project files on all three of our main platforms fairly rapidly, and we designed for (and eventually executed on some platforms) a staged transition from the existing build. GYP helped Chromium solve more problems in less time than any of the other options that we experimented with, but it's important to remember that Chromium's needs are not necessarily the same as those of other projects. There are several valid ways to solve the too many build systems problem, and GYP just happens to be one that has worked well for us. Mark (Full disclosure: I'm the principal designer of GYP, and would be happy to discuss it in further detail) Brent Fulgham wrote: So Cmake seems equivalent to GYP. GYP probably has unique features that make it more desireable than Cmake for one reason or another (perhaps it's easier to add new platform support or something), but at the moment those benefits are not obvious to me. I'm afraid that as far as I can tell, GYP seems like a case of NIH syndrome. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Please welcome GYP to the our dysfunctional build family
On Mon, Jul 13, 2009 at 12:24 PM, Mark Mentovai m...@chromium.org wrote: We also considered CMake, and had it demonstrably working for some of our smaller projects as well. BTW, Mark's list of issues with CMake is non-exhaustive (we can share more if desired), but we're not trying to slag CMake - it's a good tool in a lot of ways, it just didn't happen to be the right fit for us. So perhaps the takeaway other ports should have from all this is not that we're selling GYP as the be-all, end-all build tool for everyone, we're simply noting that since it's in the tree and we're maintaining it, if other people want to make use of it too, they'd be welcome if it fits their needs the way it fits ours. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] ExecState::thisObject()
1. Is it correct for the ExecState to carry the thisValue? As Adam realized later (I think), ExecState carries the value for this inside the calling function. It does not carry the object whose property is being accessed. Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] ExecState::thisObject()
Re-sending from correct address. On Mon, Jul 13, 2009 at 1:23 PM, Eric Seidelesei...@google.com wrote: I'm looking at this more today. I'm first fixing JSCell::new subclasses to make sure they're always allocating in the correct heap. If we're to map from objects to the associated globalobject via the heap, we need to fix allocation first. I started by just removing all versions of new (and jsNumberCell, etc.) which used ExecState instead of JSGlobalData* I'm wondering if I should instead be changing ExecState to carry a current global object member (the global object which carries the heap that objects should be allocated in, and prototypes should be looked up from. This is different from either the lexical or global objects). That would require fixing many callsites, but probably fewer than my current approach. -eric On Fri, Jul 10, 2009 at 11:08 PM, Adam Barthaba...@webkit.org wrote: On Fri, Jul 10, 2009 at 6:29 PM, Maciej Stachowiakm...@apple.com wrote: On Jul 10, 2009, at 6:10 PM, Adam Barth wrote: That's correct. Other browser's get this case right. Here are a couple test cases you might find interesting: http://webblaze.org/abarth/tests/protoconfused/test1.html http://webblaze.org/abarth/tests/protoconfused/test2.html The question is how to compute the correct wrapper context in all cases. There are a bunch of approaches that cover 80% of the cases. The trick is finding an approach that works for 100% of the causes. Well, for DOM Nodes you can almost always chase backpointers all the way up to the Document and from there to the Window, but this could be inefficient. And there's objects in the DOM that are not Nodes at all, and can't readily reach a Node. We tried this approach for a while, but we came across CSSValue, which has no obvious back pointers. It's a bit unclear how to do this for all Nodes even. For example, DocType Nodes might not have an associated Document. It's possible we could change WebCore to have all the appropriate back pointers. However, it might be easier to have all the wrapper objects hold the global object directly (or indirectly via their heap placement). I will ask Sam and Geoff for their thoughts in person if they don't chime in on the list. Thanks. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] ExecState::thisObject()
Our current thinking is to add a parameter to toJS() to receive the JSGlobalObject in which to create the wrapper. Seems logical. Once we do that, the question is how to find the proper JSGlobalObject at each call site. In most cases, you have another JSObject sitting around that is from the right JSGlobalObject. In the document.body example, the getter for body has the JSDocument from which it gets the body property. We can then use Heap::heap(sittingAroundObject)-globalData() to get back to the right JSGlobalObject. Heap::heap() will give you a JSGlobalData pointer, but not a JSGlobalObject pointer. All JSGlobalObjects in WebCore share the same Heap and the same JSGlobalData. Using a different heap for each JSGlobalObject would be a pretty major change. An alternative is to add state to every JSDOMObject to remember with which JSGlobalObject it's associated. This might have memory overhead. Almost all DOM access proceeds from [ window ] - [ document ] - [ interior stuff ], so it's probably feasible to propagate a window pointer along all chains of property access. This would also be a pretty major change, though. In JavaScript, it's trivial to figure out the global object that originated execution, and the global object in which the currently executing function was defined. So, if script S calls function F, it's trivial to figure out the window in which S was loaded, and also the window in which F was defined. But figuring out the window from which an arbitrary object originated seems challenging. Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] ExecState::thisObject()
Is it definitely right for document.body to make a wrapper using prototypes from the document's host window, rather than from the accessing function's window? What do other browsers do? That's correct. Other browser's get this case right. Is there a particular security or other benefit here, or do we just want to make this change to match other browsers? Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] ExecState::thisObject()
I'm first fixing JSCell::new subclasses to make sure they're always allocating in the correct heap. If we're to map from objects to the associated globalobject via the heap, we need to fix allocation first. I'm not sure what you guys have been meaning by the phrase correct heap. Barring workers, all WebCore objects are allocated from the same heap. I'm wondering if I should instead be changing ExecState to carry a current global object member (the global object which carries the heap that objects should be allocated in, and prototypes should be looked up from. This is different from either the lexical or global objects). That would require fixing many callsites, but probably fewer than my current approach. If you want to pass an argument indicating where something should be allocated, I don't think ExecState is the right place to do it. ExecState is a read-only pointer into the calling function's stack. It can answer questions about the calling function's state, but that's it. Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Build File Maintenance (was Re: Please welcome GYP to the our dysfunctional build family)
One belated comment on this topic. It would be neat if some port agreed to be the guinea pig to see if gyp could plausibly work for more than Google's ports. The Wx port probably has the lowest resources of any complete port in the tree, so they might not be the best choice of experimental subject, particularly if for them the process required writing a new gyp back end and if they are not yet entirely comfortable going the gyp route. Regards, Maciej On Jul 10, 2009, at 3:03 PM, Jeremy Orlow wrote: On Fri, Jul 10, 2009 at 1:14 PM, Kevin Ollivier kev...@theolliviers.com wrote: Hi David, On Jul 10, 2009, at 11:06 AM, David Kilzer wrote: So, does anyone think this would be a bad idea, or have any alternate suggestions on how to improve things? What about adding support for waf to gyp? If we're talking about Chromium, waf is much faster for building WebKit than scons is, so yeah, I would say adding the ability to use it instead of scons is a no-brainer. As for wx, while I'm open to the idea of using gyp to help others out or simplify matters for the core devs, for us I'm pretty sure it will mostly just be one more added layer to our build system. I've been using Bakefile for years now and while I thought the idea was great at first, I've found it mostly a pain to work with. Some of that is due to Bakefile itself, of course (like the latest bug...), but a lot of it is just the general approach and issues inherent with adding one more tool to the toolchain. Even though there's some sort of meta-tool generating the build projects, it only reduces, not removes, the need to understand and deal with the native project formats it outputs. Also, since the meta-tool can have bugs or missing features too, there's an additional point of failure added, and also added work in terms of maintaining the build system. Plus, any time you want to add a feature, you should look into how to implement it in the various formats that gyp supports to avoid hacks, a process which can sometimes require pretty creative solutions for less capable build tools. And there's also the fact that, if wx uses gyp, people are going to start asking for support for their favorite project format, which is just one more thing to deal with. In short, I think I've just come to be soured on the approach in general. I think I've come to agree with the point that the waf site makes about domain-specific languages not being a good idea for build systems, and when you use a tool like Bakefile or gyp, you not only need to become familiar with that tool's project file language, but also to some level with the formats of the project files that it outputs in order to debug or add new capabilities. With waf, all I ever really need to know is Python, which I already know, and the waf APIs, which I'm learning but for the most part have been pretty simple and straightforward to work with. The bottom line for me is that anything that has me spending less time on maintaining the build system and more on the actual product is a good thing in my book. ;-) Your argument makes sense if WebKit is only built for one platform/ build-system. Unfortunately it's not. So the question is whether it's easier to maintain lots of different build files or whether it's easier to maintain one file that's perhaps a bit more abstract + the tool that interprets it. I agree that working directly in the project file for your platform is easier IF you're only developing for one platform. But once you start maintaining more than one project file, I think GYP is a big win. While we hope that others will update our GYPI file when they add/ remove files, our build depends on it...so we'll definitely be keeping it in sync. So I think the question then becomes whether it's easier for you to maintain your new build format, or whether it's easier to make it a target for GYP. I honestly don't know what the answer is, but I think it's worth taking a closer look at GYP. J Thanks, Kevin The only format I'm not sure if we could automate reliably would be the XCode format (at least, on non-Mac machines), because IIUC we'd need some sort of parser for it, but Apple is the only port maintaining those directly IIUC, as now Chromium will be using GYP to update their XCode projects. If you hand-edit Xcode project files enough times you start to understand them, but you also may go insane in the process. I don't know that you have to write a full parser for it, but there is some non-trivial, minimal structure you have to understand to update the file properly. So even if we couldn't solve the XCode issue, that would drop it to updating two locations tops. I count 6 build systems in use currently (SCons support was added and removed within the last year): - Apple's Xcode - Apple's vcproj (also used by at least one other Windows port) - wx Bakefile (which
Re: [webkit-dev] ExecState::thisObject()
On Mon, Jul 13, 2009 at 1:36 PM, Geoffrey Garengga...@apple.com wrote:
I'm not sure what you guys have been meaning by the phrase correct heap.
Barring workers, all WebCore objects are allocated from the same heap.
We had wrongly assumed that each window got its own. OK. This
invalidates using heaps as a way to get back to a global object, thank
you.
If you want to pass an argument indicating where something should be
allocated, I don't think ExecState is the right place to do it. ExecState is
a read-only pointer into the calling function's stack. It can answer
questions about the calling function's state, but that's it.
It's important for objects to be allocated with the right prototype
chain, otherwise we will have bugs, some of them security related. :)
Example:
A.html:
iframe name=B href=B.html
scriptB.doSomething();/script
B.html:
iframe name=C href=C.html
scriptfunction doSomething() { return C.contentDocument.body; }/script
C.html:
body
In this example:
A is the dynamicGlobalObject
B is the lexicalGlobalObject
but C is the current global object (the one that the
JSHTMLBodyElement) should be allocated in and from which the
JSHTMLBodyElement prototype chain should come from. All browsers get
variants of this idiom wrong in different places.
There are two was I can see to fix this:
1. Pass a current global object through to all toJS calls (lots of
callsites changed)
2. Store a current global object off of the ExecState (set by the
JS engine before leaving into custom native code for property lookup
or function execution).
I tried #1 this morning, and now think #2 is the cleaner way to go.
I'm very interested in your thoughts.
-eric
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Build File Maintenance (was Re: Please welcome GYP to the our dysfunctional build family)
On Mon, Jul 13, 2009 at 1:56 PM, Maciej Stachowiak m...@apple.com wrote: One belated comment on this topic. It would be neat if some port agreed to be the guinea pig to see if gyp could plausibly work for more than Google's ports. The Wx port probably has the lowest resources of any complete port in the tree, so they might not be the best choice of experimental subject, particularly if for them the process required writing a new gyp back end and if they are not yet entirely comfortable going the gyp route. Another note, based on some #chromium conversations: if someone passionate made CMake (or any other tool) into something compelling enough to work better for Chromium than gyp does (or at least to work close-to-as-well), and that tool was more plausible for other ports in the WK tree to adopt, we wouldn't be opposed in principle to using it. The potential benefits of a shared build system are clear, and we're not trying to tell people that system has to be gyp; we're just probably not prepared to be the ones to go determine other ports' needs and decide on the Build System To Rule Them All. If no one wants to do this, but other ports do want to try gyp, we can lend them a hand in checking it out too. Whatever makes things at least a little easier. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] ExecState::thisObject()
On Mon, Jul 13, 2009 at 1:57 PM, Eric Seidel e...@webkit.org wrote:
On Mon, Jul 13, 2009 at 1:36 PM, Geoffrey Garengga...@apple.com wrote:
I'm not sure what you guys have been meaning by the phrase correct
heap.
Barring workers, all WebCore objects are allocated from the same heap.
We had wrongly assumed that each window got its own. OK. This
invalidates using heaps as a way to get back to a global object, thank
you.
If you want to pass an argument indicating where something should be
allocated, I don't think ExecState is the right place to do it. ExecState
is
a read-only pointer into the calling function's stack. It can answer
questions about the calling function's state, but that's it.
It's important for objects to be allocated with the right prototype
chain, otherwise we will have bugs, some of them security related. :)
Example:
A.html:
iframe name=B href=B.html
scriptB.doSomething();/script
B.html:
iframe name=C href=C.html
scriptfunction doSomething() { return C.contentDocument.body; }/script
C.html:
body
In this example:
A is the dynamicGlobalObject
B is the lexicalGlobalObject
but C is the current global object (the one that the
JSHTMLBodyElement) should be allocated in and from which the
JSHTMLBodyElement prototype chain should come from. All browsers get
variants of this idiom wrong in different places.
There are two was I can see to fix this:
1. Pass a current global object through to all toJS calls (lots of
callsites changed)
2. Store a current global object off of the ExecState (set by the
JS engine before leaving into custom native code for property lookup
or function execution).
I tried #1 this morning, and now think #2 is the cleaner way to go.
I'm very interested in your thoughts.
I discussed this a bit with Darin and Geoff, and we came to the conclusion
that the correct fix is to have each JS DOMObject store a JSGlobalObject
pointer and augment the toJS methods to pass a global object instead of an
ExecState (close to you #1). I would not advocate storing more data on the
ExecState.
The tricky part will be getting cases the edge cases such as events and
callbacks correct.
-Sam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] ExecState::thisObject()
On Mon, Jul 13, 2009 at 2:18 PM, Sam Weinigsam.wei...@gmail.com wrote: I discussed this a bit with Darin and Geoff, and we came to the conclusion that the correct fix is to have each JS DOMObject store a JSGlobalObject pointer and augment the toJS methods to pass a global object instead of an ExecState (close to you #1). There are classes in JavaScriptCore with mutable prototype chains which will not be covered by this fix, no? 1.__proto__ for instance, no? Adam would have to comment as to how much of a concern that would be. I would not advocate storing more data on the ExecState. The tricky part will be getting cases the edge cases such as events and callbacks correct. -Sam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Build File Maintenance (was Re: Please welcome GYP to the our dysfunctional build family)
On Jul 13, 2009, at 2:03 PM, Peter Kasting wrote: On Mon, Jul 13, 2009 at 1:56 PM, Maciej Stachowiak m...@apple.com wrote: One belated comment on this topic. It would be neat if some port agreed to be the guinea pig to see if gyp could plausibly work for more than Google's ports. The Wx port probably has the lowest resources of any complete port in the tree, so they might not be the best choice of experimental subject, particularly if for them the process required writing a new gyp back end and if they are not yet entirely comfortable going the gyp route. Another note, based on some #chromium conversations: if someone passionate made CMake (or any other tool) into something compelling enough to work better for Chromium than gyp does (or at least to work close-to-as-well), and that tool was more plausible for other ports in the WK tree to adopt, we wouldn't be opposed in principle to using it. The potential benefits of a shared build system are clear, and we're not trying to tell people that system has to be gyp; we're just probably not prepared to be the ones to go determine other ports' needs and decide on the Build System To Rule Them All. If no one wants to do this, but other ports do want to try gyp, we can lend them a hand in checking it out too. Whatever makes things at least a little easier. I haven't yet reviewed all the issues, but I personally find gyp to be a more plausible choice than CMake based on what I know. I will see how Apple's build system folks feel about the matter. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] ExecState::thisObject()
1. Pass a current global object through to all toJS calls (lots of callsites changed) 2. Store a current global object off of the ExecState (set by the JS engine before leaving into custom native code for property lookup or function execution). I discussed this a bit with Darin and Geoff, and we came to the conclusion that the correct fix is to have each JS DOMObject store a JSGlobalObject pointer and augment the toJS methods to pass a global object instead of an ExecState (close to you #1). I would not advocate storing more data on the ExecState. To add to what Sam just said, I don't think #2 is viable. Where would the JS engine get the current global object from? Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] ExecState::thisObject()
On Jul 13, 2009, at 2:18 PM, Sam Weinig wrote: I discussed this a bit with Darin and Geoff, and we came to the conclusion that the correct fix is to have each JS DOMObject store a JSGlobalObject pointer and augment the toJS methods to pass a global object instead of an ExecState (close to you #1). You probably mean in addition to rather than instead of. - Maciej (As a side note, I'm not sure this is really a security issue, since we're primarily talking about same-origin access here. For the few cases where cross-origin access is allowed, we would *not* want to expose the home window's prototype chain. So for Window.postMessage for instance, cross-origin access need to give you a distinct wrapper.) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] ExecState::thisObject()
I discussed this a bit with Darin and Geoff, and we came to the conclusion that the correct fix is to have each JS DOMObject store a JSGlobalObject pointer and augment the toJS methods to pass a global object instead of an ExecState (close to you #1). You probably mean in addition to rather than instead of. We talked about instead of. We think the JSGlobalObject will render the ExecState irrelevant, since the ExecState was only used to access the heap, which JSGlobalObject can do, and to select a prototype, which this fix will do. (As a side note, I'm not sure this is really a security issue, since we're primarily talking about same-origin access here. For the few cases where cross-origin access is allowed, we would *not* want to expose the home window's prototype chain. So for Window.postMessage for instance, cross-origin access need to give you a distinct wrapper.) Yeah, probably not a security issue. Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] ExecState::thisObject()
I discussed this a bit with Darin and Geoff, and we came to the conclusion that the correct fix is to have each JS DOMObject store a JSGlobalObject pointer and augment the toJS methods to pass a global object instead of an ExecState (close to you #1). There are classes in JavaScriptCore with mutable prototype chains which will not be covered by this fix, no? After the engine properly constructs an object with the correct prototype, the author can change that prototype, yes. But I don't think that invalidates our strategy for property constructing objects with the correct prototype. Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] ENABLE_FORM_VALIDATION
On Jul 13, 2009, at 11:57 AM, David Hyatt wrote: On Jul 13, 2009, at 1:52 PM, Jeremy Orlow wrote: On Mon, Jul 13, 2009 at 11:40 AM, David Hyatt hy...@apple.com wrote: On Jul 13, 2009, at 12:52 PM, Peter Kasting wrote: On Mon, Jul 13, 2009 at 10:47 AM, David Hyatt hy...@apple.com wrote: I agree. We should formalize this as policy too in my opinion. Maybe something time-based, e.g., if you have an implementation of a new Web technology that is going to take (1month?) to implement, then the feature should be landed inside ENABLE ifdefs (that can then be removed when the feature is sufficiently far along). For Chromium this kind of time frame can be problematic, since there's pretty much no guarantee of when a WebKit trunk build could be shipped as (eventually) a stable Chromium/Google Chrome release. Even having an incomplete feature in the tree a few days can result in the incomplete feature getting shipped to web authors. The way to ship ToT (in my opinion) is to cut a branch, watch ToT for any regressions from recent work, merge those fixes into the branch, and then turn off anything that is in-progress on the branch. Expecting ToT to actually be shippable all the time is not very practical. Realistically people will always be causing occasional regressions from bug fixes and feature work. Branches are the way to stabilize from some known point. I agree, but I also agree with Peter's heuristic for when things should be behind a flag. Regressions can always happen, but if you're knowingly introducing something that's half-baked it really seems like it should be behind a flag. I agree with that. I'm just asserting that some reasonable time limit before requiring ifdefs is ok. If a feature only takes 1-2 weeks to land, I think it's total overkill to put it inside an ifdef. Any cut branch should take long enough to stabilize that it could merge the rest of the feature in anyway. If you're ever cutting a branch off ToT and shipping it as a full-blown release with less than 2 weeks turnaround, you're doing it wrong in my opinion. I'm more or less with Hyatt on this one. I think it would be process overkill to require ifdef for every feature that has more than one implementation step. A month sounds like about the right time scale where a switch is useful. One other thing to keep in mind: sometimes an incomplete implementation of a feature may still be a state that's useful to ship. I'm hoping people can exercise good judgment here and ping the list when in doubt. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] ENABLE_FORM_VALIDATION
On Mon, Jul 13, 2009 at 2:55 PM, Maciej Stachowiak m...@apple.com wrote: On Jul 13, 2009, at 11:57 AM, David Hyatt wrote: On Jul 13, 2009, at 1:52 PM, Jeremy Orlow wrote: On Mon, Jul 13, 2009 at 11:40 AM, David Hyatt hy...@apple.com wrote: On Jul 13, 2009, at 12:52 PM, Peter Kasting wrote: On Mon, Jul 13, 2009 at 10:47 AM, David Hyatt hy...@apple.com wrote: I agree. We should formalize this as policy too in my opinion. Maybe something time-based, e.g., if you have an implementation of a new Web technology that is going to take (1month?) to implement, then the feature should be landed inside ENABLE ifdefs (that can then be removed when the feature is sufficiently far along). For Chromium this kind of time frame can be problematic, since there's pretty much no guarantee of when a WebKit trunk build could be shipped as (eventually) a stable Chromium/Google Chrome release. Even having an incomplete feature in the tree a few days can result in the incomplete feature getting shipped to web authors. The way to ship ToT (in my opinion) is to cut a branch, watch ToT for any regressions from recent work, merge those fixes into the branch, and then turn off anything that is in-progress on the branch. Expecting ToT to actually be shippable all the time is not very practical. Realistically people will always be causing occasional regressions from bug fixes and feature work. Branches are the way to stabilize from some known point. I agree, but I also agree with Peter's heuristic for when things should be behind a flag. Regressions can always happen, but if you're knowingly introducing something that's half-baked it really seems like it should be behind a flag. I agree with that. I'm just asserting that some reasonable time limit before requiring ifdefs is ok. If a feature only takes 1-2 weeks to land, I think it's total overkill to put it inside an ifdef. Any cut branch should take long enough to stabilize that it could merge the rest of the feature in anyway. If you're ever cutting a branch off ToT and shipping it as a full-blown release with less than 2 weeks turnaround, you're doing it wrong in my opinion. I'm more or less with Hyatt on this one. I think it would be process overkill to require ifdef for every feature that has more than one implementation step. A month sounds like about the right time scale where a switch is useful. One other thing to keep in mind: sometimes an incomplete implementation of a feature may still be a state that's useful to ship. I'm hoping people can exercise good judgment here and ping the list when in doubt. Regards, Maciej This small interval rule-of-thumb idea sounds pretty good, but I still wish it didn't put the burden on the guy doing the branch to figure out what is or isn't incomplete about a particular snapshot of WebKit. That guy might not be savy enough to know what he should be concerned about. The developer of the new feature, on the other hand, is the expert and should be in the best position to know when their work is shippable. It seems like there should be a low-cost way for such developers to flag a feature as incomplete and then clear that flag when it becomes safe to ship the feature. Afterall, it would seem to be in that developer's best interest to not have their new work shipped prematurely (thus causing its adoption to be stunted by incompatibility issues). Adding an ENABLE flag doesn't seem like that great of a tax to me. Alternatively, perhaps there could be more communication from the developer landing an incomplete feature? A simple heads-up to the list might be enough. Hey, I just landed the first part of HTML5 foo bar. Right now, everything is just stubbed out, but I will be landing the implementation in the next few days. -Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] ExecState::thisObject()
On Mon, Jul 13, 2009 at 1:33 PM, Geoffrey Garengga...@apple.com wrote: Is it definitely right for document.body to make a wrapper using prototypes from the document's host window, rather than from the accessing function's window? What do other browsers do? That's correct. Other browser's get this case right. Is there a particular security or other benefit here, or do we just want to make this change to match other browsers? Our current behavior is buggy, unpredictable, and out of spec. This has led to security bugs in the past and will lead to security bugs in the future. Is there a particular reason to keep our current behavior? Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] ENABLE_FORM_VALIDATION
On Jul 13, 2009, at 5:02 PM, Darin Fisher wrote: This small interval rule-of-thumb idea sounds pretty good, but I still wish it didn't put the burden on the guy doing the branch to figure out what is or isn't incomplete about a particular snapshot of WebKit. That guy might not be savy enough to know what he should be concerned about. That's exactly who the burden should be on though. ToT is a development tree. It's the organization shipping their product that should be working to determine when their product is shippable. The developer of the new feature, on the other hand, is the expert and should be in the best position to know when their work is shippable. It seems like there should be a low-cost way for such developers to flag a feature as incomplete and then clear that flag when it becomes safe to ship the feature. Afterall, it would seem to be in that developer's best interest to not have their new work shipped prematurely (thus causing its adoption to be stunted by incompatibility issues). Adding an ENABLE flag doesn't seem like that great of a tax to me. I think it would be a great annoyance for very small features. I also expect that people would sit on their feature until it was completely done and stop properly staging work in order to avoid adding such short-lived ifdefs to the project. That would just make the patch review process more painful, and make it harder to track down individual bugs caused by the lack of incremental landings. Alternatively, perhaps there could be more communication from the developer landing an incomplete feature? A simple heads-up to the list might be enough. Hey, I just landed the first part of HTML5 foo bar. Right now, everything is just stubbed out, but I will be landing the implementation in the next few days. I think that's an excellent idea. We could try to do that more via checkin comments and ChangeLogs also. dave (hy...@apple.com) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] ExecState::thisObject()
On Mon, Jul 13, 2009 at 2:26 PM, Maciej Stachowiakm...@apple.com wrote: For the few cases where cross-origin access is allowed, we would *not* want to expose the home window's prototype chain. So for Window.postMessage for instance, cross-origin access need to give you a distinct wrapper. That's correct. In fact, Firefox had this exact bug as recently as a year ago. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] ENABLE_FORM_VALIDATION
On Jul 13, 2009, at 5:17 PM, David Hyatt wrote: It's the organization shipping their product that should be working to determine when their product is shippable. This may in fact be the most incomprehensible sentence I have ever typed. :) dave (hy...@apple.com) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Build File Maintenance (was Re: Please welcome GYP to the our dysfunctional build family)
Maciej Stachowiak wrote: Another note, based on some #chromium conversations: if someone passionate made CMake (or any other tool) into something compelling enough to work better for Chromium than gyp does (or at least to work close-to-as-well), and that tool was more plausible for other ports in the WK tree to adopt, we wouldn't be opposed in principle to using it. The potential benefits of a shared build system are clear, and we're not trying to tell people that system has to be gyp; we're just probably not prepared to be the ones to go determine other ports' needs and decide on the Build System To Rule Them All. If no one wants to do this, but other ports do want to try gyp, we can lend them a hand in checking it out too. Whatever makes things at least a little easier. I haven't yet reviewed all the issues, but I personally find gyp to be a more plausible choice than CMake based on what I know. I will see how Apple's build system folks feel about the matter. The other obvious choice to start with is qmake, since it's already used by the Qt port. Have you got a list of issues with that similar to the list for cmake? Joe ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] ExecState::thisObject()
Is there a particular security or other benefit here, or do we just want to make this change to match other browsers? Our current behavior is buggy, unpredictable, and out of spec. This has led to security bugs in the past and will lead to security bugs in the future. I don't disagree with you, but I'm not immediately convinced that a large design change will automatically reduce the bug count, either. Which spec did you have in mind? I'd like to read it. Is there a particular reason to keep our current behavior? No, I don't think so -- and I don't mean to object to this idea, either. I was just asking for clarification. Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] ExecState::thisObject()
I discussed this a bit with Darin and Geoff, and we came to the conclusion that the correct fix is to have each JS DOMObject store a JSGlobalObject pointer and augment the toJS methods to pass a global object instead of an ExecState (close to you #1). I would not advocate storing more data on the ExecState. Sam and I just noticed that, to fully support this behavior, any host object that lazily constructs function properties using the functions in lookup.h must either (a) change in the same way as DOM objects must change or (b) eagerly construct its function properties with the correct prototype. Consider this case, which does not involve a DOM object: frames[0].Array.prototype.push.__proto__ == Array.prototype.push.__proto__ Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] A module that changes webserver configuration?
It seems like you have confused this mailing list with another one. ~Brady On Jul 13, 2009, at 11:10 AM, Elison Smith wrote: Hello, I am looking for pointers to module(s) that change the webserver configuration (in-memory and maybe also in the config files on disk) for any reason. Are there any such modules? Or is Apache inherently an ecosystem where the config (config files) are not written to by the webserver itself? Any pointers are really appreciated. Thanks. ___ 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] ExecState::thisObject()
On Mon, Jul 13, 2009 at 3:29 PM, Geoffrey Garengga...@apple.com wrote: Our current behavior is buggy, unpredictable, and out of spec. This has led to security bugs in the past and will lead to security bugs in the future. I don't disagree with you, but I'm not immediately convinced that a large design change will automatically reduce the bug count, either. Which spec did you have in mind? I'd like to read it. Essentially, the ECMAScript spec requires this. In spec-land, these objects are all created at the beginning of time. The fact that we create them lazily is what leads to this bug. Depending on who touches them first, they end up with different prototype chains, which doesn't make sense to ECMAScript. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] ExecState::thisObject()
Which spec did you have in mind? I'd like to read it. Essentially, the ECMAScript spec requires this. In spec-land, these objects are all created at the beginning of time. The fact that we create them lazily is what leads to this bug. Depending on who touches them first, they end up with different prototype chains, which doesn't make sense to ECMAScript. I agree that it's strange for an object's behavior to change based on which global object accesses it first, but I don't think the ECMA spec is a good guide here, since, according to ECMA 262, the very notion of more than one global object is invalid. That's correct. Other browser's get this case right. Here are a couple test cases you might find interesting: http://webblaze.org/abarth/tests/protoconfused/test1.html http://webblaze.org/abarth/tests/protoconfused/test2.html I tried these tests, with mixed results: IE8: Exception thrown during load. Firefox 3.0: mixture of passes and fails on test1.html. Exception thrown during load of test2.html. Chrome 2.0: Mixture of passes and fails. Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] ExecState::thisObject()
Yep... My guess is that (a) is probably better, but you two are more expert on why we use lazy construction. Heh -- lazy construction in JSC is even older than I am! :) The goal is to reduce memory use and startup cost in cases where certain functions aren't used. I'm not sure how much of a difference it makes in practice. Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] ENABLE_FORM_VALIDATION
On Mon, Jul 13, 2009 at 3:17 PM, David Hyatt hy...@apple.com wrote: On Jul 13, 2009, at 5:02 PM, Darin Fisher wrote: This small interval rule-of-thumb idea sounds pretty good, but I still wish it didn't put the burden on the guy doing the branch to figure out what is or isn't incomplete about a particular snapshot of WebKit. That guy might not be savy enough to know what he should be concerned about. That's exactly who the burden should be on though. ToT is a development tree. ToT is a development tree, but it follows a trunk stable development model, enforced by layout tests. What layout tests don't reflect is the incompleteness of the features tested. It's the organization shipping their product that should be working to determine when their product is shippable. I agree in principle. My point was that the original developer is the expert on their feature. To an embedder of WebKit, a feature may seem mostly complete, passing all of the existing layout tests, and yet... it might be considered a shame to ship it in that state. It is easy to miss subtle details, even when reviewed by someone expert in the field. It seems like it hurts WebKit compat to have products out there with incomplete implementations of new APIs, so there are incentives not only for the organization shipping a WebKit-based product but also for all involved with WebKit. The developer of the new feature, on the other hand, is the expert and should be in the best position to know when their work is shippable. It seems like there should be a low-cost way for such developers to flag a feature as incomplete and then clear that flag when it becomes safe to ship the feature. Afterall, it would seem to be in that developer's best interest to not have their new work shipped prematurely (thus causing its adoption to be stunted by incompatibility issues). Adding an ENABLE flag doesn't seem like that great of a tax to me. I think it would be a great annoyance for very small features. I also expect that people would sit on their feature until it was completely done and stop properly staging work in order to avoid adding such short-lived ifdefs to the project. That would just make the patch review process more painful, and make it harder to track down individual bugs caused by the lack of incremental landings. I'm not sure I follow... A particular port could choose to enable the flag from day one. Nothing changes if you are the developer of both the feature and the port that has the flag enabled from day one. Other ports could opt-in later, or be forced to opt-in once the feature is complete and the ENABLE flag is removed. Alternatively, perhaps there could be more communication from the developer landing an incomplete feature? A simple heads-up to the list might be enough. Hey, I just landed the first part of HTML5 foo bar. Right now, everything is just stubbed out, but I will be landing the implementation in the next few days. I think that's an excellent idea. We could try to do that more via checkin comments and ChangeLogs also. Thanks! -Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] ExecState::thisObject()
On Jul 13, 2009, at 3:36 PM, Geoffrey Garen wrote: I discussed this a bit with Darin and Geoff, and we came to the conclusion that the correct fix is to have each JS DOMObject store a JSGlobalObject pointer and augment the toJS methods to pass a global object instead of an ExecState (close to you #1). I would not advocate storing more data on the ExecState. Sam and I just noticed that, to fully support this behavior, any host object that lazily constructs function properties using the functions in lookup.h must either (a) change in the same way as DOM objects must change or (b) eagerly construct its function properties with the correct prototype. Consider this case, which does not involve a DOM object: frames[0].Array.prototype.push.__proto__ == Array.prototype.push.__proto__ Built-in classes work somewhat differently. I believe they use the calling function's global object (lexical global object) rather than having some notion of home object. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] ExecState::thisObject()
Consider this case, which does not involve a DOM object: frames[0].Array.prototype.push.__proto__ == Array.prototype.push.__proto__ Built-in classes work somewhat differently. I believe they use the calling function's global object (lexical global object) rather than having some notion of home object. In Firefox 3.0, built-ins use a home object. Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] ExecState::thisObject()
On Mon, Jul 13, 2009 at 4:01 PM, Geoffrey Garengga...@apple.com wrote: That's correct. Other browser's get this case right. Here are a couple test cases you might find interesting: http://webblaze.org/abarth/tests/protoconfused/test1.html http://webblaze.org/abarth/tests/protoconfused/test2.html I tried these tests, with mixed results: IE8: Exception thrown during load. Firefox 3.0: mixture of passes and fails on test1.html. Exception thrown during load of test2.html. Chrome 2.0: Mixture of passes and fails. Yes. All the browsers suck on these tests. :) Would you like me to go look for more exploitable cases? It seems like the only reason not to fix this issue is because we're afraid of code churn. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] ExecState::thisObject()
On Jul 13, 2009, at 3:40 PM, Adam Barth wrote: On Mon, Jul 13, 2009 at 3:29 PM, Geoffrey Garengga...@apple.com wrote: Our current behavior is buggy, unpredictable, and out of spec. This has led to security bugs in the past and will lead to security bugs in the future. I don't disagree with you, but I'm not immediately convinced that a large design change will automatically reduce the bug count, either. Which spec did you have in mind? I'd like to read it. Essentially, the ECMAScript spec requires this. In spec-land, these objects are all created at the beginning of time. The fact that we create them lazily is what leads to this bug. Depending on who touches them first, they end up with different prototype chains, which doesn't make sense to ECMAScript. While the behavior you describe seems problematic, I don't think it is an ECMAScript violation, since ECMAScript essentially allows host objects to do anything. If this is defined by spec, the specs that are relevant would be HTML5 and Web IDL. I'm not sure if those clearly define the behavior. - Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] ExecState::thisObject()
On Mon, Jul 13, 2009 at 4:08 PM, Maciej Stachowiakm...@apple.com wrote: Built-in classes work somewhat differently. I believe they use the calling function's global object (lexical global object) rather than having some notion of home object. You might be thinking of boxing primitive values, which do indeed get their prototypes from the current lexical scope. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] ExecState::thisObject()
On Jul 13, 2009, at 4:12 PM, Adam Barth wrote: On Mon, Jul 13, 2009 at 4:08 PM, Maciej Stachowiakm...@apple.com wrote: Built-in classes work somewhat differently. I believe they use the calling function's global object (lexical global object) rather than having some notion of home object. You might be thinking of boxing primitive values, which do indeed get their prototypes from the current lexical scope. Hmm. Exporting home global object behavior to some of the built-in JS types would be more challenging than doing it just for DOM objects. Some of the built-in classes are up against the JSC cell size limit. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] ExecState::thisObject()
On Jul 13, 2009, at 4:11 PM, Adam Barth wrote: On Mon, Jul 13, 2009 at 4:01 PM, Geoffrey Garengga...@apple.com wrote: That's correct. Other browser's get this case right. Here are a couple test cases you might find interesting: http://webblaze.org/abarth/tests/protoconfused/test1.html http://webblaze.org/abarth/tests/protoconfused/test2.html I tried these tests, with mixed results: IE8: Exception thrown during load. Firefox 3.0: mixture of passes and fails on test1.html. Exception thrown during load of test2.html. Chrome 2.0: Mixture of passes and fails. Yes. All the browsers suck on these tests. :) Would you like me to go look for more exploitable cases? It seems like the only reason not to fix this issue is because we're afraid of code churn. My own interest would be in weighing the tradeoffs. In the Pro column: 1) Are there aspects of this issue that create security holes? 2) Are there aspects of this issue that create Web compatibility problems? 3) Would enforcing a new consistent behavior for this reduce the likelihood of future mistakes that cause material problems? In the potential Con column: A) Will there be a performance or memory penalty? B) Will the change increase code complexity? C) Is there a risk of introducing regressions with the change? If the benefits are high, then it's not that important to assess the risks - we will just live with them. If the benefits are low but the costs are also low, then I'd say having logical behavior wins out. It's only if the costs are high and the benefits are low that I'd be concerned about making the change at all. I wouldn't say code churn is categorically ruled out. Personally I am convinced that the answers to (3) and (C) are both yes, and I don't know about any of the other points. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] ExecState::thisObject()
On Mon, Jul 13, 2009 at 4:20 PM, Maciej Stachowiakm...@apple.com wrote: My own interest would be in weighing the tradeoffs. In the Pro column: 1) Are there aspects of this issue that create security holes? CVE-2009-1702 is an example of such as security hole. I'm sure that I can find more if I look for them. 2) Are there aspects of this issue that create Web compatibility problems? I don't know of any web compatibility problems arising from this behavior. The great deviation between browsers here makes this less likely 3) Would enforcing a new consistent behavior for this reduce the likelihood of future mistakes that cause material problems? You're already convinced the answer here is yes. In the potential Con column: A) Will there be a performance or memory penalty? I suspect the new behavior will take more memory, but I don't know how much. B) Will the change increase code complexity? In some cases, the change might actually reduce code complexity. For example, if you look at the bindings code around events and database transactions, we do a lot of machinating to find the right security context. Much of this code is buggy. Having the appropriate JSGlobalObject nearby might help. C) Is there a risk of introducing regressions with the change? There is indeed a chance of regressions. We'll want to test thoroughly. Personally I am convinced that the answers to (3) and (C) are both yes, and I don't know about any of the other points. I can try to provide more information as best I can. Another option is to make this change incrementally and assess the costs as we go. For example, we could fix the SVG prototypes first. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] ExecState::thisObject()
On Jul 13, 2009, at 4:34 PM, Adam Barth wrote: CVE-2009-1702 is an example of such as security hole. I'm sure that I can find more if I look for them. I think objects attached to the global object and accessible cross- origin are a special case here. (The advisory cited is about Location and History.) Values that can be accessed cross-origin are the most likely locus for security issues in this area. And they also likely need behavior that's different from the generally proposed pattern, since revealing or allowing the mutation of home origin prototypes is a security risk. If security is one motivation for this work, then I'd like us to understand the pattern we want to use for cross-origin-accessible objects. Should they use the home global object prototype but protect it from mutation or access to extended properties, should they use the prototype of the referencing frame (lexical global object) or something else? Personally I am convinced that the answers to (3) and (C) are both yes, and I don't know about any of the other points. I can try to provide more information as best I can. Another option is to make this change incrementally and assess the costs as we go. For example, we could fix the SVG prototypes first. Doing the change incrementally seems wise, if it is feasible to do so. Maybe even a patch demonstrating how it would work for a single class could be a good way to evaluate the change. Perhaps separate trailblazing examples could be given for both an ordinary class and one that is cross-origin accessible. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] ExecState::thisObject()
On Mon, Jul 13, 2009 at 4:59 PM, Maciej Stachowiakm...@apple.com wrote: If security is one motivation for this work, then I'd like us to understand the pattern we want to use for cross-origin-accessible objects. Should they use the home global object prototype but protect it from mutation or access to extended properties, should they use the prototype of the referencing frame (lexical global object) or something else? I can study this question, but I believe Firefox solves this problem by having cross-origin viewers of these properties see a fresh copy of the object that isn't === the object as seen by same-origin viewers. The fresh copy ignores any changes the page might has made to the object and has a prototype chain connects to the viewer's prototypes. If two different cross-origin viewers look at the same object, they each see fresh copies. Doing the change incrementally seems wise, if it is feasible to do so. Maybe even a patch demonstrating how it would work for a single class could be a good way to evaluate the change. Perhaps separate trailblazing examples could be given for both an ordinary class and one that is cross-origin accessible. Sounds like a plan. Thanks for all your input on this topic. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] ExecState::thisObject()
On Jul 13, 2009, at 5:34 PM, Adam Barth wrote: On Mon, Jul 13, 2009 at 4:59 PM, Maciej Stachowiakm...@apple.com wrote: If security is one motivation for this work, then I'd like us to understand the pattern we want to use for cross-origin-accessible objects. Should they use the home global object prototype but protect it from mutation or access to extended properties, should they use the prototype of the referencing frame (lexical global object) or something else? I can study this question, but I believe Firefox solves this problem by having cross-origin viewers of these properties see a fresh copy of the object that isn't === the object as seen by same-origin viewers. The fresh copy ignores any changes the page might has made to the object and has a prototype chain connects to the viewer's prototypes. If two different cross-origin viewers look at the same object, they each see fresh copies. That pattern sounds workable. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Development Tools on Safari
Any chance HTMLTidy will be integrated into Safari? http://zappatic.net/safaritidy/ Firebug is also a must: http://getfirebug.com/ Those are the only things keeping me from ditching Firefox, well aside from the Web Developer Toolbar: http://chrispederick.com/work/web-developer/ and Tamper Data: https://addons.mozilla.org/en-US/firefox/addon/966as well. What tools are available for Safari/Webkit that match or exceed the above? They are sorely needed for web development. -Juan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Development Tools on Safari
On 2009-07-13, at 19:28, Juan Madrigal wrote: Any chance HTMLTidy will be integrated into Safari? http://zappatic.net/safaritidy/ Firebug is also a must: http://getfirebug.com/ Those are the only things keeping me from ditching Firefox, well aside from the Web Developer Toolbar: http://chrispederick.com/work/web-developer/ and Tamper Data: https://addons.mozilla.org/en-US/firefox/addon/ 966as well. What tools are available for Safari/Webkit that match or exceed the above? They are sorely needed for web development. http://www.apple.com/safari/features.html#developer - Mark smime.p7s Description: S/MIME cryptographic signature ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Development Tools on Safari
On Jul 13, 2009, at 7:28 PM, Juan Madrigal wrote: Any chance HTMLTidy will be integrated into Safari? http://zappatic.net/safaritidy/ Firebug is also a must: http://getfirebug.com/ Those are the only things keeping me from ditching Firefox, well aside from the Web Developer Toolbar: http://chrispederick.com/work/web-developer/ and Tamper Data: https://addons.mozilla.org/en-US/firefox/addon/ 966as well. What tools are available for Safari/Webkit that match or exceed the above? They are sorely needed for web development. Mark pointed you to the wealth of tools available in the Web Inspector and Develop menu. If you have any specific feature requests beyond what the tools can do already, please file bugs at http://bugs.webkit.org . We're always looking for ways to improve the tools. Built-in validation support would be one cool enhancement, but we'd probably want to use validator.nu as the back end instead of using tidy, since it supports HTML5. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Development Tools on Safari
On Jul 13, 2009, at 7:28 PM, Juan Madrigal wrote: Firebug is also a must: http://getfirebug.com/ Why is Firebug a must, when we have the WebKit inspector? Is there something missing from the inspector tool? Or do you find performing certain actions less efficient? Thanks, -Brent ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
