Re: [webkit-dev] moving focus when clicking on scrollbars
On Oct 31, 2012, at 9:32 PM, Ojan Vafai o...@chromium.org wrote: I'd like to r+ https://bugs.webkit.org/show_bug.cgi?id=96335, but wanted to give a heads up in case anyone wants to object. Every native platform that has scrollbars does *not* move focus when you click on them. Every browser engine, except Gecko, moves focus when you click on scrollbars *unless* you're clicking on the viewport scrollbar (e.g. clicking on the scrollbar of an scrollable div that fills the viewport will move focus). Gecko does not move focus when you click on any scrollbar unless you are clicking on the scrollbar of a form control (e.g. textarea) scrollbar. I'd like to change our behavior to either match Gecko or go fully native and never move focus when clicking on scrollbars. The latter sounds better to me, but either solution would satisfy me. Any strong opinions/objections? We've already discussed this on whatwg and the feedback has been that this is up to browser vendors to match the platform conventions: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-October/037676.html. Is our current behavior the same as the every browser engine, except Gecko behavior described above? I like the idea of being more like native control behavior. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] does anyone still use 'webkit-patch rebaseline-server'?
On Wed, Oct 31, 2012 at 10:47 PM, Dirk Pranke dpra...@chromium.org wrote: It is/was intended to be useful for quickly reviewing and rebaselining a bunch of failures in a local (on-disk) checkout. It's been largely unmaintained and ignored for quite some time in favor of garden-o-matic. I have recently started to land some patches that will make garden-o-matic work locally as well as with the bots, and it will ultimately replace rebaseline-server; I'm attempting to consolidate all of our different change-reviewing UIs so that they are more consistent and share more code. The local garden-o-matic should roughly work now, but the UI isn't well-tuned for this use case and there's some things left do to. If you have any features you would like to add to the garden-o-matic UI (or want to make sure are transferred over from rebaseline-server), now would be a good time to mention them. And, if no one speaks up to say that rebaseline-server is still being used, I will assume I can delete it when I'm ready to do so. Thanks! I'm still using this for landing Android baselines, and would appreciate if it could stick around for another two weeks. I'll definitely start looking in to using garden-o-matic for this purpose as well, however. It's great that the tools we have are converging into a few more powerful, common ones! Thanks, Peter -- Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Slide deck: How WebKit Works
I like those slides. Thanks for putting them where we can all see and use them. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] moving focus when clicking on scrollbars
On Thu, Nov 1, 2012 at 4:42 AM, Maciej Stachowiak m...@apple.com wrote: ... Is our current behavior the same as the every browser engine, except Gecko behavior described above? Yes. - Native *never* moves focus, even if the control is focusable (ex. the wireless networks list in OS X Preferences.app) - Trident, WebKit and Presto blur the activeElement when clicking a scrollbar even if the element with the scrollbar is not focusable. This results in the body being focused. - Gecko *only* blurs the activeElement if the element with the scrollbar is focusable (ex. overflow div + tabindex). That is, Gecko will only blurs if the focus can be transfered to the scrollbar owner. I like the idea of being more like native control behavior. I agree. I'll update the patch to match Gecko's mostly native, but web friendly behavior. - E ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] moving focus when clicking on scrollbars
On Thu, Nov 1, 2012 at 10:13 AM, Elliott Sprehn espr...@chromium.orgwrote: On Thu, Nov 1, 2012 at 4:42 AM, Maciej Stachowiak m...@apple.com wrote: I like the idea of being more like native control behavior. I agree. I'll update the patch to match Gecko's mostly native, but web friendly behavior. Sounds like we all agree here. The separate question is whether we should avoid moving focus even when you click on the scrollbar of a focusable element. That fully matches native, but doesn't match any existing browser. Maciej, would you prefer that? I'm on the fence and could easily be swayed either direction. In the meantime, Elliott's patch matching the Gecko behavior seems uncontroversial. I'll r+ once it's ready for review. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Making more use of ScriptWrappable
We currently use two different approaches for associating JavaScript wrappers with DOM objects. For some objects, we store the wrapper inline in the object itself by making object inherit from ScriptWrappable. For other types of objects, we use a HashMap to translate the object into a JavaScript wrapper. Whether to use ScriptWrappable or a HashMap is a trade-off that depends on the workload. For DOM objects that rarely have a JavaScript wrapper, using a HashMap is more memory efficient because we don't need to store a large number of null pointers in objects that do not have wrappers. By contrast, if an object almost always has a JavaScript wrapper, using ScriptWrappable is both faster (because we avoid the hash table lookup) and uses less memory (because we don't need to store both the key and the value in the HashMap---we just need to store the value in the object itself). Today, we use ScriptWrappable for Nodes only, but we would benefit by making more use of ScriptWrappable, particularly for DOM objects that almost always have JavaScript wrappers. For example, XMLHttpRequest objects exist only when created by script, which means that every XMLHttpRequest object has a JavaScript wrapper. My plan is to introduce an interface-level IDL attribute named something like [OftenHasJSWrapper] that informs the code generator that the object inherits from ScriptWrappable and that we should make use of the inline wrapper. We can then deploy this attribute as appropriate throughout WebCore to reduce memory usage and improve performance. Please let me know if you have any feedback. Thanks! Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Implementing rendering support for -webkit-text-decoration-skip
Hi all,
I am trying to implement https://bugs.webkit.org/show_bug.cgi?id=92801
[css3-text] Add support for -webkit-text-decoration-skip and have some doubts
about the best way to do it for all parsed values for
-webkit-text-decoration-skip (objects, spaces, ink) [1]
The attached patch implements text-decoration-skip: objects. Now I am trying
to implement text-decoration-skip: spaces. That one seems tricky since I need
to identify all white spaces in a phrase, skip the decoration for all white
spaces but keep it for the words (and other objects). I was reading [2] and one
though I could enclose all white spaces in a block (or inline) and then use what
I did for decoration-skip: objects, but that seems like a lot of overhead to
render the text. Anybody have a better suggestion about how to implement it?
[1] http://www.w3.org/TR/css3-text/#text-decoration-skip0
[2] https://www.webkit.org/blog/115/webcore-rendering-ii-blocks-and-inlines/
Cheers,
Lamarque V. Souzadiff --git a/Source/WebCore/css/StyleResolver.cpp b/Source/WebCore/css/StyleResolver.cpp
index 03d12d2..ed4bbf9 100644
--- a/Source/WebCore/css/StyleResolver.cpp
+++ b/Source/WebCore/css/StyleResolver.cpp
@@ -1845,9 +1845,15 @@ static EDisplay equivalentBlockDisplay(EDisplay display, bool isFloating, bool s
// and absolute or relatively positioned elements.
static bool doesNotInheritTextDecoration(RenderStyle* style, Element* e)
{
+// Lamarque 31/10/2012: use this as basis for text-decoration-skip
return style-display() == TABLE || style-display() == INLINE_TABLE || style-display() == RUN_IN
|| style-display() == INLINE_BLOCK || style-display() == INLINE_BOX || isAtShadowBoundary(e)
-|| style-isFloating() || style-hasOutOfFlowPosition();
+|| style-isFloating() || style-hasOutOfFlowPosition()
+#if ENABLE(CSS3_TEXT)
+|| (style-textDecorationSkip() == TextDecorationSkipObjects
+ (style-display() == INLINE || style-display() == INLINE_FLEX || style-display() == INLINE_GRID));
+#endif // CSS3_TEXT
+;
}
static bool isDisplayFlexibleBox(EDisplay display)
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Making more use of ScriptWrappable
On Thu, Nov 1, 2012 at 10:51 AM, Alexey Proskuryakov a...@apple.com wrote: 01.11.2012, в 10:36, Adam Barth aba...@webkit.org написал(а): Today, we use ScriptWrappable for Nodes only, but we would benefit by making more use of ScriptWrappable, particularly for DOM objects that almost always have JavaScript wrappers. For example, XMLHttpRequest objects exist only when created by script, which means that every XMLHttpRequest object has a JavaScript wrapper. This looks like a great idea for investigation to me. Do you have a rough estimate of how large of a win we are talking about? I don't have numbers currently, but I'm happy to gather some. My recollection is that the win for nodes was substantial on DOM benchmarks. I would expect the win to be fairly large for DOM objects like NodeList where script is likely to access properties like length and item frequently (e.g., in a loop). For example, XMLHttpRequests are probably not numerous enough to matter. Also, this would not be an improvement for XMLHttpRequest objects created in secondary worlds. Yeah. This is a main-world optimization only. Even for Nodes, we use a HashMap for secondary worlds. Adam I expect there to be cases where the win is more clear though. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Making more use of ScriptWrappable
Sounds like a good idea. For some objects, we store the wrapper inline in the object itself by making object inherit from ScriptWrappable. For other types of objects, we use a HashMap to translate the object into a JavaScript wrapper. The current situation is not either ScriptWrappable or the HashMap. Currently we store all wrappers into the HashMap and store some wrappers into ScriptWrappable as a cache. In other words, wrappers stored in ScrpitWrappable are also stored in the HashMap. The fact that the HashMap knows all wrappers is being used at some places e.g. when GC enumerate wrappers. Thanks to the recent efforts of Adam Barth, V8 bindings are going to remove the need to enumerate all wrappers, and thus the HashMap does not need to store all wrappers. On the other hand, what about JSC bindings? Either way, I would support the idea of introducing ScriptWrappable for more DOM objects. On Thu, Nov 1, 2012 at 6:36 PM, Adam Barth aba...@webkit.org wrote: We currently use two different approaches for associating JavaScript wrappers with DOM objects. For some objects, we store the wrapper inline in the object itself by making object inherit from ScriptWrappable. For other types of objects, we use a HashMap to translate the object into a JavaScript wrapper. Whether to use ScriptWrappable or a HashMap is a trade-off that depends on the workload. For DOM objects that rarely have a JavaScript wrapper, using a HashMap is more memory efficient because we don't need to store a large number of null pointers in objects that do not have wrappers. By contrast, if an object almost always has a JavaScript wrapper, using ScriptWrappable is both faster (because we avoid the hash table lookup) and uses less memory (because we don't need to store both the key and the value in the HashMap---we just need to store the value in the object itself). Today, we use ScriptWrappable for Nodes only, but we would benefit by making more use of ScriptWrappable, particularly for DOM objects that almost always have JavaScript wrappers. For example, XMLHttpRequest objects exist only when created by script, which means that every XMLHttpRequest object has a JavaScript wrapper. My plan is to introduce an interface-level IDL attribute named something like [OftenHasJSWrapper] that informs the code generator that the object inherits from ScriptWrappable and that we should make use of the inline wrapper. We can then deploy this attribute as appropriate throughout WebCore to reduce memory usage and improve performance. Please let me know if you have any feedback. Thanks! Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev -- Kentaro Hara, Tokyo, Japan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Making more use of ScriptWrappable
On Thu, Nov 1, 2012 at 2:09 PM, Kentaro Hara hara...@google.com wrote: ... Thanks to the recent efforts of Adam Barth, V8 bindings are going to remove the need to enumerate all wrappers, and thus the HashMap does not need to store all wrappers. On the other hand, what about JSC bindings? JSC has a map per world, and the main world wrappers are stored in the ScriptWrappable, not in the map. Only Node's are ScriptWrappable it seems. http://code.google.com/searchframe#OAMlx_jo-ck/src/third_party/WebKit/Source/WebCore/bindings/js/JSDOMBinding.hl=137 http://code.google.com/searchframe#OAMlx_jo-ck/src/third_party/WebKit/Source/WebCore/bindings/js/JSNodeCustom.hl=42 I'm not sure why setInlineCachedWrapper takes a Node* specifically, it should just take a ScriptWrappable* so Adam's change works for JSC too. - E ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Making more use of ScriptWrappable
On Thu, Nov 1, 2012 at 11:21 AM, Elliott Sprehn espr...@chromium.org wrote: On Thu, Nov 1, 2012 at 2:09 PM, Kentaro Hara hara...@google.com wrote: ... Thanks to the recent efforts of Adam Barth, V8 bindings are going to remove the need to enumerate all wrappers, and thus the HashMap does not need to store all wrappers. Yes, the last patch in that series landed a few minutes before I sent this email. On the other hand, what about JSC bindings? JSC has a map per world, and the main world wrappers are stored in the ScriptWrappable, not in the map. Only Node's are ScriptWrappable it seems. http://code.google.com/searchframe#OAMlx_jo-ck/src/third_party/WebKit/Source/WebCore/bindings/js/JSDOMBinding.hl=137 http://code.google.com/searchframe#OAMlx_jo-ck/src/third_party/WebKit/Source/WebCore/bindings/js/JSNodeCustom.hl=42 I'm not sure why setInlineCachedWrapper takes a Node* specifically, it should just take a ScriptWrappable* so Adam's change works for JSC too. Yes, this should be straightforward for the JSC bindings. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Making more use of ScriptWrappable
On Thu, Nov 1, 2012 at 11:04 AM, Adam Barth aba...@webkit.org wrote: On Thu, Nov 1, 2012 at 10:51 AM, Alexey Proskuryakov a...@apple.com wrote: 01.11.2012, в 10:36, Adam Barth aba...@webkit.org написал(а): Today, we use ScriptWrappable for Nodes only, but we would benefit by making more use of ScriptWrappable, particularly for DOM objects that almost always have JavaScript wrappers. For example, XMLHttpRequest objects exist only when created by script, which means that every XMLHttpRequest object has a JavaScript wrapper. This looks like a great idea for investigation to me. Do you have a rough estimate of how large of a win we are talking about? I don't have numbers currently, but I'm happy to gather some. My recollection is that the win for nodes was substantial on DOM benchmarks. I would expect the win to be fairly large for DOM objects like NodeList where script is likely to access properties like length and item frequently (e.g., in a loop). Definitely. The last I checked, we spent 3-5% just looking for the wrapper in the hash map when iterating over NodeList items. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] moving focus when clicking on scrollbars
It seems worth noting over here that on the whatwg discussion for this, native really means Mac and Ubuntu. Notably it's not clear whether this matches Windows, which is 90+% of the userbase for Chrome. I am a little nervous making blanket statements like this is native behavior when we're not sure whether it is for such large user groups. I'm not sure how to test this on Windows, though. Gecko's behavior makes me a little less worried than the never move focus behavior in the absence of data to answer the above question. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Making more use of ScriptWrappable
On the other hand, what about JSC bindings? JSC bindings do not store the wrapper in two places. Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Making more use of ScriptWrappable
On Thu, Nov 1, 2012 at 12:41 PM, Geoffrey Garen gga...@apple.com wrote: On the other hand, what about JSC bindings? JSC bindings do not store the wrapper in two places. I'm not sure I fully understand your message. JSC uses ScriptWrappable for Nodes and uses a HashMap for non-Nodes (in the main world), just like V8 does. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] moving focus when clicking on scrollbars
On Thu, Nov 1, 2012 at 12:32 PM, Peter Kasting pkast...@chromium.orgwrote: It seems worth noting over here that on the whatwg discussion for this, native really means Mac and Ubuntu. Notably it's not clear whether this matches Windows, which is 90+% of the userbase for Chrome. I am a little nervous making blanket statements like this is native behavior when we're not sure whether it is for such large user groups. I'm not sure how to test this on Windows, though. We know Windows doesn't move focus when you click on the scrollbar of the top-level window (e.g. if something inside the window has focus, it doesn't clear focus when you click on the scrollbar), right? We just don't know of a way of testing nested, native scrollbars on Windows. So, I still think it's accurate to call this the Windows native scrollbar behavior. FWIW, see the related http://crbug.com/6759http://code.google.com/p/chromium/issues/detail?id=6759 . Gecko's behavior makes me a little less worried than the never move focus behavior in the absence of data to answer the above question. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Making more use of ScriptWrappable
On Nov 1, 2012, at 6:36 PM, Adam Barth aba...@webkit.org wrote: We currently use two different approaches for associating JavaScript wrappers with DOM objects. For some objects, we store the wrapper inline in the object itself by making object inherit from ScriptWrappable. For other types of objects, we use a HashMap to translate the object into a JavaScript wrapper. Whether to use ScriptWrappable or a HashMap is a trade-off that depends on the workload. For DOM objects that rarely have a JavaScript wrapper, using a HashMap is more memory efficient because we don't need to store a large number of null pointers in objects that do not have wrappers. By contrast, if an object almost always has a JavaScript wrapper, using ScriptWrappable is both faster (because we avoid the hash table lookup) and uses less memory (because we don't need to store both the key and the value in the HashMap---we just need to store the value in the object itself). Today, we use ScriptWrappable for Nodes only, but we would benefit by making more use of ScriptWrappable, particularly for DOM objects that almost always have JavaScript wrappers. For example, XMLHttpRequest objects exist only when created by script, which means that every XMLHttpRequest object has a JavaScript wrapper. My plan is to introduce an interface-level IDL attribute named something like [OftenHasJSWrapper] that informs the code generator that the object inherits from ScriptWrappable and that we should make use of the inline wrapper. We can then deploy this attribute as appropriate throughout WebCore to reduce memory usage and improve performance. Please let me know if you have any feedback. Sounds like a good idea. Three additional thoughts: (1) It would be best to choose the objects to apply this to in some data-driven way. (2) If we have an IDL attribute, I think it should be named by the effect it has, not the possible conceptual-level reason for applying it. [ScriptWrappable] or [InlineWrapper] or something. Because it's not a judgment call, it is a statement about the code. (3) I suspect that we can handle this without adding an IDL attribute at all. C++ overloaded functions could let the bindings do something different for objects that inherit ScriptWrappable from ones that do not in a generic way, without having to explicitly tell the bindings layer about the ways to do it. Consider the ways unwrap() and toJS() are done. We don't have to say anything special in the IDL or have any interface-specific knowledge in the bindings, C++ overloading takes care of it. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Making more use of ScriptWrappable
On Thu, Nov 1, 2012 at 4:10 PM, Maciej Stachowiak m...@apple.com wrote: On Nov 1, 2012, at 6:36 PM, Adam Barth aba...@webkit.org wrote: We currently use two different approaches for associating JavaScript wrappers with DOM objects. For some objects, we store the wrapper inline in the object itself by making object inherit from ScriptWrappable. For other types of objects, we use a HashMap to translate the object into a JavaScript wrapper. Whether to use ScriptWrappable or a HashMap is a trade-off that depends on the workload. For DOM objects that rarely have a JavaScript wrapper, using a HashMap is more memory efficient because we don't need to store a large number of null pointers in objects that do not have wrappers. By contrast, if an object almost always has a JavaScript wrapper, using ScriptWrappable is both faster (because we avoid the hash table lookup) and uses less memory (because we don't need to store both the key and the value in the HashMap---we just need to store the value in the object itself). Today, we use ScriptWrappable for Nodes only, but we would benefit by making more use of ScriptWrappable, particularly for DOM objects that almost always have JavaScript wrappers. For example, XMLHttpRequest objects exist only when created by script, which means that every XMLHttpRequest object has a JavaScript wrapper. My plan is to introduce an interface-level IDL attribute named something like [OftenHasJSWrapper] that informs the code generator that the object inherits from ScriptWrappable and that we should make use of the inline wrapper. We can then deploy this attribute as appropriate throughout WebCore to reduce memory usage and improve performance. Please let me know if you have any feedback. Sounds like a good idea. Three additional thoughts: (1) It would be best to choose the objects to apply this to in some data-driven way. (2) If we have an IDL attribute, I think it should be named by the effect it has, not the possible conceptual-level reason for applying it. [ScriptWrappable] or [InlineWrapper] or something. Because it's not a judgment call, it is a statement about the code. (3) I suspect that we can handle this without adding an IDL attribute at all. C++ overloaded functions could let the bindings do something different for objects that inherit ScriptWrappable from ones that do not in a generic way, without having to explicitly tell the bindings layer about the ways to do it. Consider the ways unwrap() and toJS() are done. We don't have to say anything special in the IDL or have any interface-specific knowledge in the bindings, C++ overloading takes care of it. That's a good idea. I'll see if we can avoid the IDL attribute. I wonder if we can do the same for the ActiveDOMObject IDL attribute, which similarly announces the presence of a base class. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
