Re: [webkit-dev] DOM tree vs. Render tree
I'm not sure this will help you Song, but here is a talk I gave a couple years back which talks some about the DOM vs. Rendering tree separation: http://www.youtube.com/watch?v=RVnARGhhs9w Best of luck in your exploration. -eric On Thu, Jun 16, 2011 at 4:34 PM, Darin Adler wrote: > On Jun 16, 2011, at 4:30 PM, song.7@nokia.com wrote: > >> Thanks, but why not generate a tree according to document ang css style at >> the same time? Or why is the post style decision needed? > > I can see from your question that you didn’t understand, but I’m not sure how > to clear things up. > > The DOM tree needs to match the document structure and can’t be influenced by > style. This is what makes the DOM API work; the DOM tree is a parsed form of > the document explicitly exposed as API. Style can change many ways at times > when the DOM must not change, for example, when a stylesheet finishes > loading, the styles from that sheet can affect how the DOM elements are > displayed. We can’t change the DOM tree in response to style changes. > > I think we’ll have to get to a more specific question to have a useful > discussion. > > -- 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] How to integrate HbbTV with WebKit
Please do not cross-post. A cursory internet search shows HbbTV has little to do with WebKit. What spec covers HbbTV? What other browsers implement such? Your mail does not seem appropriate for this list. -eric On Sun, Jun 19, 2011 at 10:26 PM, Vicky Tux wrote: > Hi, > We have to implement HbbTV specification using WebKit. > We have no idea to integrate HbbTV with WebKit. > So please advice us, below queries for developing HbbTV. > 1. How to add new HTML tags and attributes in WebKit? > 2. How to add new styles in WebKit? > 3. How to add new class,method and property in JavaScript? > 4. Please share HbbTV related sample code for our development purpose. It's > very helpful for us. > Regards, > Vicky. > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] How to integrate HbbTV with WebKit
Hi, We have to implement *HbbTV *specification using WebKit. We have no idea to integrate *HbbTV *with WebKit. So please advice us, below queries for developing *HbbTV*. 1. How to add new HTML tags and attributes in WebKit? 2. How to add new styles in WebKit? 3. How to add new class,method and property in JavaScript? 4. Please share *HbbTV* related* *sample code for our development purpose. It's very helpful for us. Regards, Vicky. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] review flags (was bugs in pending-commit)
It might get a little squirrelly to have things like: LANDED(12345): REVERTED(12344): LANDED(12343): Patch But I'm happy to write up the patches to make it so. -eric On Sun, Jun 19, 2011 at 6:32 PM, Antonio Gomes wrote: > Personally, I like this pattern a lot. > > Would it also be helpful when sheriff bot rolls out a patch to attach the > rolled out patch with a nice description like ROLLOUT(rX) to the bug? > > On Sun, Jun 19, 2011 at 8:36 PM, Eric Seidel wrote: >> >> On Sun, Jun 19, 2011 at 11:31 AM, Darin Adler wrote: >> > On Jun 18, 2011, at 9:01 PM, Antonio Gomes wrote: >> > >> >> I actually do not like the way the review flags are cleared today only >> >> in order to make the tools and pending-xxx pages happier. IMO the review >> >> flags give much about the history of the bug. In that matter, I dislike >> >> webkit-patch's ways of clearing "r-" flags of patches while it marks it as >> >> obsolete and uploads a new one. Reason: an easy-to-see r-'ed patch is very >> >> helpful to me to understand the chronological progresses in the bug. >> > >> > I agree that it would be clearer to leave review flags for clarity about >> > the history of a patch. I also have been irritated by our work flow that >> > involves clearing review flags to appease the tools. >> > >> > However, even if we fixed everything so that was no longer necessary, I >> > would still want a way to clearly communicate “this patch is known to be >> > bad >> > and not suitable for landing, despite the fact that a reviewer approved it >> > at one point”. >> > >> > And I also think that if we were redesigning the bug system it would be >> > good if there was a way to communicate that a patch was landed other than >> > having a bug marked RESOLVED, because people continue to put multiple >> > patches in a single bug, and so the bugs state can’t really tell us the >> > status of a patch. >> >> I'm happy to change webkit-patch to change the descriptions on patches >> to prefix "LANDED(r12354):" when landing/obsoleting, etc. if you think >> that would help. >> >> -eric >> >> > -- 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 > > > > -- > --Antonio Gomes > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] review flags (was bugs in pending-commit)
Personally, I like this pattern a lot. Would it also be helpful when sheriff bot rolls out a patch to attach the rolled out patch with a nice description like ROLLOUT(rX) to the bug? On Sun, Jun 19, 2011 at 8:36 PM, Eric Seidel wrote: > On Sun, Jun 19, 2011 at 11:31 AM, Darin Adler wrote: > > On Jun 18, 2011, at 9:01 PM, Antonio Gomes wrote: > > > >> I actually do not like the way the review flags are cleared today only > in order to make the tools and pending-xxx pages happier. IMO the review > flags give much about the history of the bug. In that matter, I dislike > webkit-patch's ways of clearing "r-" flags of patches while it marks it as > obsolete and uploads a new one. Reason: an easy-to-see r-'ed patch is very > helpful to me to understand the chronological progresses in the bug. > > > > I agree that it would be clearer to leave review flags for clarity about > the history of a patch. I also have been irritated by our work flow that > involves clearing review flags to appease the tools. > > > > However, even if we fixed everything so that was no longer necessary, I > would still want a way to clearly communicate “this patch is known to be bad > and not suitable for landing, despite the fact that a reviewer approved it > at one point”. > > > > And I also think that if we were redesigning the bug system it would be > good if there was a way to communicate that a patch was landed other than > having a bug marked RESOLVED, because people continue to put multiple > patches in a single bug, and so the bugs state can’t really tell us the > status of a patch. > > I'm happy to change webkit-patch to change the descriptions on patches > to prefix "LANDED(r12354):" when landing/obsoleting, etc. if you think > that would help. > > -eric > > >-- 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 > -- --Antonio Gomes ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] review flags (was bugs in pending-commit)
On Sun, Jun 19, 2011 at 11:31 AM, Darin Adler wrote: > On Jun 18, 2011, at 9:01 PM, Antonio Gomes wrote: > >> I actually do not like the way the review flags are cleared today only in >> order to make the tools and pending-xxx pages happier. IMO the review flags >> give much about the history of the bug. In that matter, I dislike >> webkit-patch's ways of clearing "r-" flags of patches while it marks it as >> obsolete and uploads a new one. Reason: an easy-to-see r-'ed patch is very >> helpful to me to understand the chronological progresses in the bug. > > I agree that it would be clearer to leave review flags for clarity about the > history of a patch. I also have been irritated by our work flow that involves > clearing review flags to appease the tools. > > However, even if we fixed everything so that was no longer necessary, I would > still want a way to clearly communicate “this patch is known to be bad and > not suitable for landing, despite the fact that a reviewer approved it at one > point”. > > And I also think that if we were redesigning the bug system it would be good > if there was a way to communicate that a patch was landed other than having a > bug marked RESOLVED, because people continue to put multiple patches in a > single bug, and so the bugs state can’t really tell us the status of a patch. I'm happy to change webkit-patch to change the descriptions on patches to prefix "LANDED(r12354):" when landing/obsoleting, etc. if you think that would help. -eric > -- 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] Lets use PassRefPtr for arguments less; lets use RefPtr for locals and data members more
On Sun, Jun 19, 2011 at 2:05 PM, Darin Adler wrote: > On Jun 19, 2011, at 2:03 PM, Ryosuke Niwa wrote: > > > One of the most common security bugs I have seen in editing is that we > keep a raw pointer to a node and call some helper method that modifies DOM > (therefore invoking scripts). > > > > I'm sometimes tempted to replace all instances of Node* in the editing > component by RefPtr/PassRefPtr. > > I suspect that if the data members and local variables had type RefPtr, > then it mostly wouldn’t matter if argument types were PassRefPtr or raw > pointers for this purpose. > Right, although it's tricky to catch cases where we call a function that takes multiple arguments (one of them being Node*) with the return value of a function that modifies DOM. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] review flags (was bugs in pending-commit)
Hi Darin. Few comments inlined. On Sun, Jun 19, 2011 at 2:31 PM, Darin Adler wrote: > On Jun 18, 2011, at 9:01 PM, Antonio Gomes wrote: > > > I actually do not like the way the review flags are cleared today only in > order to make the tools and pending-xxx pages happier. IMO the review flags > give much about the history of the bug. In that matter, I dislike > webkit-patch's ways of clearing "r-" flags of patches while it marks it as > obsolete and uploads a new one. Reason: an easy-to-see r-'ed patch is very > helpful to me to understand the chronological progresses in the bug. > > I agree that it would be clearer to leave review flags for clarity about > the history of a patch. I also have been irritated by our work flow that > involves clearing review flags to appease the tools. > I agree. > However, even if we fixed everything so that was no longer necessary, I > would still want a way to clearly communicate “this patch is known to be bad > and not suitable for landing, despite the fact that a reviewer approved it > at one point”. > > And I also think that if we were redesigning the bug system it would be good > if there was a way to communicate that a patch was landed other than having > a bug marked RESOLVED, because people continue to put multiple patches in a > single bug, and so the bugs state can’t really tell us the status of a > patch. > See what I do myself in patches in bug https://bugs.webkit.org/show_bug.cgi?id=50666 , for example. We could/should teach toosl to do that. -- --Antonio Gomes ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Lets use PassRefPtr for arguments less; lets use RefPtr for locals and data members more
On Jun 19, 2011, at 2:03 PM, Ryosuke Niwa wrote: > One of the most common security bugs I have seen in editing is that we keep a > raw pointer to a node and call some helper method that modifies DOM > (therefore invoking scripts). > > I'm sometimes tempted to replace all instances of Node* in the editing > component by RefPtr/PassRefPtr. I suspect that if the data members and local variables had type RefPtr, then it mostly wouldn’t matter if argument types were PassRefPtr or raw pointers for this purpose. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Lets use PassRefPtr for arguments less; lets use RefPtr for locals and data members more
On Sun, Jun 19, 2011 at 12:48 PM, Darin Adler wrote: > > > Con (of abandoning PassRefPtr for function arguments entirely): > > > Possible accidental freed memory access bugs. > > I think the reverse of this Con is one of the stronger Pro arguments for > using PassRefPtr even more for arguments rather than my proposal to use it > less. Object lifetime mistakes are much less likely when raw pointers are > kept to an absolute minimum. I thought about this when reviewing the design > of Automatic Reference Counting. The ARC design largely eliminates raw > pointers for Objective-C objects. > One of the most common security bugs I have seen in editing is that we keep a raw pointer to a node and call some helper method that modifies DOM (therefore invoking scripts). I'm sometimes tempted to replace all instances of Node* in the editing component by RefPtr/PassRefPtr. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Lets use PassRefPtr for arguments less; lets use RefPtr for locals and data members more
The arguments about abandoning PassRefPtr for arguments entirely are attacking a straw man. We know PassRefPtr offers an important optimization and do not want to drop that! On Jun 18, 2011, at 10:58 PM, Maciej Stachowiak wrote: > (1) Use PassRefPtr for every parameter that takes ownership. I still think this is the appropriate rule, and always have, but I think “takes ownership” is not defined to my satisfaction. > Pro (of using PassRefPtr for every parameter that takes ownership): >Bright-line rule; fairly clear how to apply it. This is where my problem comes in. I am not sure what the bright-line rule is. Generally, in the DOM, the rule is that all reachable objects need to be kept alive, so reference counting is used to implement reachability, which does not match with my sense of the word ownership. For a shared ownership model there are multiple possible definitions of whether a function takes ownership to an object passed as an argument. Here are some of my attempts to describe the bright line: a) Hands off ownership to what could possibly be the sole owner in most code paths. b) Keeps a reference to the object after the function completes in most code paths. c) Takes a reference to the object at least once in most code paths. d) Hands off ownership to what could possibly be the sole owner in some code paths. e) Keeps a reference to the object after it completes in some code paths. f) Takes a reference to the object at least once in some code paths. Is the bright line rule you have in mind (b) or perhaps (e)? Or something not listed here at all? Editing operations that are undoable often meet (b) but not (a). It’s confusing to me that editing operations want to “take ownership” of arguments. To make editing undoable the undo machinery may have to reference these objects, but it may also have to reference objects as well, perhaps the document or other elements. It’s not clear to me that requesting editing by passing arguments that specify where in the document the edit should take place means that the function takes ownership of those arguments. If we tell the document which is the currently active title element by calling setTitleElement, the function meets (b) but not (a). Similarly, some functions call out to operations that could cause the last owner for one of their arguments to dereference the object. They are likely to fit into category (c) or (f). In a sense the caller does have to pass ownership of the object, because the operation can only be successfully done if the function takes ownership to make sure the object does not disappear while the code is working with it. > Con (of using PassRefPtr for every parameter that takes ownership): >Possible accidental self-zeroing bugs. I think the “possible” adjective here makes this sound like a smaller problem than it is. Alexey and I have both seen multiple examples of this, particularly in contexts like constructor initialization lists where the prp idiom does not work well. > Con (of abandoning PassRefPtr for function arguments entirely): > Possible accidental freed memory access bugs. I think the reverse of this Con is one of the stronger Pro arguments for using PassRefPtr even more for arguments rather than my proposal to use it less. Object lifetime mistakes are much less likely when raw pointers are kept to an absolute minimum. I thought about this when reviewing the design of Automatic Reference Counting. The ARC design largely eliminates raw pointers for Objective-C objects. I tried to find the examples that bother me. Here are some DOM examples where the term ownership seems wrong, and it’s more about reachability: HTMLCollection::create: Does a collection own the node it is rooted in? MessageEvent::initMessageEvent: Does a message event own the source DOM window? Range::create: Does a range own the document its nodes are in and the nodes that are used to specify the endpoints? Storage::create: Does a storage object own its storage area? UIEvent::create: Does an event own its abstract view? Here are some examples that are not purely DOM reachability that I find confusing: Document::setTitleElement: Does a document own its title element? FrameLoaderClient::dispatchWillSubmitForm: Does communication of a pending form submission involve passing ownership of form state? I couldn’t quickly find other examples, but I have a vague sense that there are some that are even more confusing. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] review flags (was bugs in pending-commit)
On Jun 18, 2011, at 9:01 PM, Antonio Gomes wrote: > I actually do not like the way the review flags are cleared today only in > order to make the tools and pending-xxx pages happier. IMO the review flags > give much about the history of the bug. In that matter, I dislike > webkit-patch's ways of clearing "r-" flags of patches while it marks it as > obsolete and uploads a new one. Reason: an easy-to-see r-'ed patch is very > helpful to me to understand the chronological progresses in the bug. I agree that it would be clearer to leave review flags for clarity about the history of a patch. I also have been irritated by our work flow that involves clearing review flags to appease the tools. However, even if we fixed everything so that was no longer necessary, I would still want a way to clearly communicate “this patch is known to be bad and not suitable for landing, despite the fact that a reviewer approved it at one point”. And I also think that if we were redesigning the bug system it would be good if there was a way to communicate that a patch was landed other than having a bug marked RESOLVED, because people continue to put multiple patches in a single bug, and so the bugs state can’t really tell us the status of a patch. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
