Re: [webkit-dev] Adding main element to WebCore
Maciej Stachowiak wrote: [*] If Mozilla on the whole is agains adding this feature, that is relevant new information. Mozilla as a whole does not often take definitive pro/con positions on things like main. So I polled a few w3 Mozilla regulars, including dbaron, tantek, dbolter. We should switch to another list and spare webkit-dev. I believe dbolter found main interesting but had further thoughts not reflected in its spec. /be ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Fwd: Adding main element to WebCore
I'm stunned that people are arguing this on webkit-dev. Just FYI, Mozillians with whom I have spoken generally agree that main does not meet the high bar required to add a new element to HTML. Shopping a patch to implementors, to get something into a standard spec by asserting de-facto status based on the patch(es) landing, is bad form. Back to the whatwg list! /be Dominic Mazzoni wrote: On Tue, Nov 27, 2012 at 4:22 PM, Ian Hickson i...@hixie.ch mailto:i...@hixie.ch wrote: The use case for main is accessibility navigation. If authors use it incorrectly, the feature *doesn't work*. The element becomes pointless. But it won't break accessibility. Worst case, it starts the screen reader user at an unusual point in the page. A single keystroke will bring the user back to the top of the page, so it's no big deal. So I'm in favor of it, because it's easy for developers, there's a small positive accessibility benefit, and I don't see any harm if it's sometimes used incorrectly. - Dominic ___ 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] Feature Request: Dynamic Application Cache
Brady Eidson wrote: On Nov 17, 2012, at 7:47 AM, sridharnsridhar.ndr...@gmail.com wrote: Any updates / plans for this feature ?? What feature? Sridharn did not cite context, but his message is in the thread whose head is this post: https://lists.webkit.org/pipermail/webkit-dev/2012-April/020455.html where Stefan Wagner wrote: Mozilla Firefox supports dynamic adding of resources into the application cache for offline use with the function: window.applicationCache.mozAdd(URI String) https://developer.mozilla.org/en/nsIDOMOfflineResourceList This is great for persistent storage of assets via javascipt. Instead of predefining those assets in the manifest file one can use javascript to cache the needed assets. Is there something similar planed? Like window.applicationCache.webkitAdd(URI String) ? /be I do agree with Stefan on this .. I've been banging my head on how to cache video files using html 5 storage features and there just doesn't seem to be a straightforward way (they all are currently intended for small size text / mobile webkit doesn't support file system and blah blah) to do that and feel appcache is cleaner way going forward too for media files .. Where are you seeing this not work? At least on the Apple port you should be able to stick audio/video in the app cache. There are a handful of bugzillas that show this work being done a long time ago. If it's not working for you, I look forward to reading the bug you file at bugs.webkit.org. Also, mobile webkit (chrome/safari in ios4) don't seem to appcache mp3 files (~5MB) .. Is this a known issue ? iOS4 is ancient. I forget when this first shipped but it should work in iOS6. This should hopefully go away once the dynamic mechanism is added I hope .. Again, not sure precisely which dynamic mechanism you're talking about since you included no context in your email, but I don't see how a dynamic app cache mechanism is related to the app cache supporting media, which it does. ~Brady ___ 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] RenderArena: Teaching an old dog new tricks
Eric Seidel wrote: However, like those bell-bottoms in your father's closet, RenderArena is back in vogue and Chromium's security team very excited about RenderArena's security benefits. Disco, like the drive-in, will never die. http://robert.ocallahan.org/2010/10/mitigating-dangling-pointer-bugs-using_15.html discusses the frame-poisoning work in Gecko. It saved us from quite a number of potential 0days in the last two years, as far as I can tell. /be ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] …Inlines.h vs …InlineMethods.h
Geoffrey Garen wrote: The proposed design requires adding a FooInlines.h include to source files that use that function, when any function moves into FooInlines.h. This can happen any time a function is made inline or when a short inline function gets longer. You convinced me; I hadn't considered this burden. Le me amend: (2) Adopt the convention that any class using *Inlines.h defines all inline functions defined out-of-line in *Inlines.h To (2) Adopt the convention that nothing goes into *Inlines.h by default, and functions are added on demand as we discover functions that cause compile failures or long compile times. Hi Geoff, sorry to stick my nose in it but Mozilla uses WebKit code (YARR, 3) so we care. The strong reason we've found beyond compile failures and long compile times (or really, this is the underlying cause of either compile failures or, alternatively, long compile times): inline method implementations are not appropriate to put in interface definitions. In other words, Foo.h declaring class Foo can focus on interface over implementation, even with a few short inline methods defined within the class or right after it -- but larger inlines may be required for performance, and their bodies can easily depend on headers not properly part of Foo.h-as-interface, which should therefore not bootleg along via nested #includes. Whereas FooInlines.h can nest its implementation dependencies freely. Implementation vs. interface distinctions can be fuzzy, but we've found it helpful to use this as a razor when shaving header files with inlines, before compile errors or compile time problems bite. /be Geoff ___ 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] …Inlines.h vs …InlineMethods.h
Filip Pizlo wrote: On Nov 5, 2012, at 4:15 PM, Brendan Eichbren...@mozilla.org wrote: Implementation vs. interface distinctions can be fuzzy, but we've found it helpful to use this as a razor when shaving header files with inlines, before compile errors or compile time problems bite. I think that the total time spent fixing dependencies due to inline methods being in the main header is going to be less than the total time spent having to search through multiple headers when doing normal work. Oh, for sure -- it doesn't make sense to expend effort changing existing code just to match a vague rule about separating implementation from interface. Sorry if I seemed to suggest that. I started from a general inline method implementations are not appropriate to put in interface definitions assertion but allowed for even with a few short inline methods defined within the class or right after it. I should have allowed for other reasons not to split out FooInline.h. As I've pointed out in past messages in this thread, we have classes where the best documentation of a method is the method's body - hence having the body inline is a big win for productivity. Agreed. This may have more to due with how JSC is laid out. I think the last time I encountered a need to put a method body outside of the main header was over a month ago, if not more. That's cool. If you end up needing all the relevant headers and the topological sort is straightforward, fewer files wins. /be ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Improving DOM Exception console messages.
Ojan Vafai wrote: This isn't spec'ed anywhere. I agree it would be ideal to get a spec for this, but I don't think we need to block on that in this instance. This is an area where browsers are completely incompatible already. I don't see much benefit from blocking on creating a specification to make this situation better for web developers. It's actually not that big of a deal if the error messages from different browsers are different. That error messages and details differ among browsers is not the issue. The cross-browser concern is the security model that distinguishes errors that can be presented fully to JS and the inspector or a console, and those than must be censored from JS. /be On Mon, Oct 1, 2012 at 4:56 PM, Ojan Vafai o...@google.com mailto:o...@google.com wrote: This isn't spec'ed anywhere. I agree it would be ideal to get a spec for this, but I don't think we need to block on that in this instance. This is an area where browsers are completely incompatible already. I don't see much benefit from blocking on creating a specification to make this situation better for web developers. It's actually not that big of a deal if the error messages from different browsers are different. On Mon, Oct 1, 2012 at 10:52 AM, Ryosuke Niwa rn...@webkit.org mailto:rn...@webkit.org wrote: Where is this spec'ed? If we're exposing this to the Web, we definitely a spec. for this BEFORE implementing it in WebKit. On Mon, Oct 1, 2012 at 2:57 AM, Mike West mk...@chromium.org mailto:mk...@chromium.org wrote: I had a brief conversation about this with Adam and Maciej on IRC about this, and Ojan chimed in on the bug[1]. Since I'm in the wrong time-zone for discussion (and I'd like a wider audience anyway), I'm pulling this back to the list. 1. Maciej raised the concern that we might be exposing sensitive information to JavaScript by making the exception's message more detailed. For example, if if a resource allowed by CSP redirects to a resource disallowed by CSP, we shouldn't give JavaScript access to the latter URL. 2. Adam suggested storing the context on the exception object, using it for rendering in the console but not exposing it to JavaScript. The current patch does this for JSC[2]. 3. On the bug, Ojan noted that many apps on the web send stack traces back to the server for analysis, and exposing context only to the Inspector would deprive these apps of context. I'd like to ensure that we end up with a solution that WebKit developers will actually use. One solution would be to treat SECURITY_ERR differently than other DOM exceptions. For instance, SYNTAX_ERR is thrown in a variety of contexts where security seems to be unaffected ([3] for instance); for that error, I don't think there's any concern with providing the same string to JavaScript and to the Inspector. For security errors involving redirects and other information that JavaScript shouldn't have access to, we could go the more complicated route of providing one string to JavaScript, and the other to the Inspector. Concretely, this might involve adding two properties to ExceptionBase: 'context' and 'totallySektitContext' (or similar... :) ). The first would always be appended to the message generated in ExceptionBase's constructor, the latter only when the error is reported to the console. At each setDOMException callsite, we'd have to provide some mechanism for setting one or both strings. This might involve turning ExceptionCode enum into a struct containing the code and slots for two strings. Does that seem like a tenable solution? -Mike [1]: https://bugs.webkit.org/show_bug.cgi?id=97654 [2]: https://bugs.webkit.org/attachment.cgi?id=166300action=prettypatch https://bugs.webkit.org/attachment.cgi?id=166300action=prettypatch [3]: https://bugs.webkit.org/show_bug.cgi?id=97984 On Wed, Sep 26, 2012 at 5:12 PM, Mike West mk...@chromium.org mailto:mk...@chromium.org wrote: Hello, webkit-dev! TL;DR: I'd like to improve the console messages displayed for DOM exceptions. I'm hoping that no one thinks this is a miserable,
Re: [webkit-dev] Improving DOM Exception console messages.
Ryosuke Niwa wrote: On Mon, Oct 1, 2012 at 5:18 PM, Ojan Vafai o...@chromium.org mailto:o...@chromium.org wrote: This is an area where browsers are completely incompatible already. I don't see much benefit from blocking on creating a specification to make this situation better for web developers. It's actually not that big of a deal if the error messages from different browsers are different. If Web developers wanted to know the details of failures on their websites as opposed to on Inspector, wouldn't it better to add some sort of API that could interoperate on all browsers? Straw proposal for JS: http://wiki.ecmascript.org/doku.php?id=strawman:error_stack Discussion head: https://mail.mozilla.org/pipermail/es-discuss/2012-June/023238.html Same concerns about information leaks. /be ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] new -webkit-user-select value: atomic
Alice Cheng wrote: Could you elaborate more on the difference? Maybe the difference is small enough that it makes sense to reuse all. e.g. Mozilla might be willing to change their behavior for all. Mozilla is not selecting atomically using shift + right. It also does not select atomically upon dragging. These might just be bugs, but we do hope Mozilla will clarify their behavior via the www-style thread. Here is a link: http://lists.w3.org/Archives/Public/www-style/2012Jul/0541.html Mozilla people will take this up on www-style and in the CSS WG. We would prefer if vendors not add more divergence to user-select or other prefixed properties. We'll try to work quickly to reach consensus in the WG. /be ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Adding ENABLE_NAVIGATOR_BUILDTYPE to WebCore
Adam Barth wrote: On Thu, Jun 7, 2012 at 1:00 PM, Ryosuke Niwarn...@webkit.org wrote: What is the rationale for adding this property on the navigator object instead of the chrome object we also expose if your'e not expecting this property to be ever standarized? Generally, we avoid implementing web visible features via the chrome object because that makes them Chrome-proprietary. In this case, it seems entirely reasonable for other browsers (e.g., Firefox) to want to implement this feature. By putting it on navigator, we invite them to implement it as well. No, that's not how you invite someone to do something, in conventional human-to-human interactions :-|. It's a bit aggro -- if it makes a de-facto standard, others will follow whether they like it or not. If it has undesirable unintended consequences, too bad. As Dean pointed out, it also contradicts the pitch in Annie's first message. As Annie noted, we don't feel the need since our UA string has some [ab] cruft in it at the end, and a number after the letter that's important. But UA groveling sucks. Could we instead discuss navigator.buildType in some appropriate W3C or WHATWG list? /be ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] (no subject)
Maciej Stachowiak wrote: On Apr 29, 2012, at 1:25 PM, Ryosuke Niwarn...@webkit.org wrote: I'm actually curious as to how the session participants reached this consensus (probably on a separate thread). It seems like the bar shouldn't too high for removing prefixed APIs when they are unprefixed equivalents because I'm certain web developers want to use the ones that work on all browsers instead of just on WebKit. Here's some evidence that Web developers do not always care about this, and that lack of support for webkit-prefixed properties can be detrimental to Web compatibility: http://dev.opera.com/articles/view/opera-mobile-emulator-experimental-webkit-prefix-support/ I agree with this, including the careful do not always and can be detrimental words ;-). This message may not be interesting to webkit-dev. Skip if you are not interested in prefix usage studies, what Mozilla might do about prefixes, etc. We have been studying prefix usage in: https://bugzilla.mozilla.org/show_bug.cgi?id=708406 The situation for Opera is much worse than for Mozilla for many properties, e.g. border-radius, where -moz- is often observed to be used alongside -webkit-. See in particular: https://bugzilla.mozilla.org/show_bug.cgi?id=708406#c39 The table's tabs don't lay out nicely in bugzilla. Here's my attempt at fixing the layout by hand: base_property num_domains num_rules pct_no_unprefixed_and_no_moz animation-count11 100.0 animation-delay5137 80.0 animation-direction810 62.5 animation-duration 73 324 87.9 animation-fill-mode23 50.0 animation-iteration-count 51 78 84.7 animation-name 72 756 87.6 animation-play-state 230.0 animation-timing-function 51 100 94.5 text-size-adjust 779 635299.5 transform-origin 68 196 56.9 transform-origin-y 230.0 transform-style35 50 100.0 transition-delay 19 53 63.2 transition-duration208 853 71.5 transition-property156 491 76.2 transition-timing 120.0 transition-timing-function 45 111 58.9 Clearly Mozilla feels Opera's pain for certain properties, e.g. text-size-adjust. Per the bug, 99.5% of 6352 found instances do not have unprefixed or -moz-prefixed equivalents of text-size-adjust. Lack of -webkit- prefix support may not be detrimental to a particular browser's mobile web compatibility where that browser engine's prefix (or no prefix) is widely used. It depends on the browser and the particular style property. So (just FYI) we at Mozilla are not contemplating emulating -webkit- quite so much as Opera may be. We do want to sort this all out in the CSS-WG and avoid unnecessary fragmentation. /be ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] JavaScriptCore and ES6
On Dec 16, 2011, at 1:24 AM, Anne van Kesteren wrote: In general I think versioning is a bad idea, but out-of-band is even worse. ES.next is going to have a use version 6; in-band pragma. /be ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] JavaScriptCore and ES6
As you probably know, the ECMA TC39 committee is slowly approaching consensus on a new revision of the ECMAScript language. The interim results of this process have gone under various names: Harmony, ES.next, and ES6. They are the same thing. Hi Andy, one nit to pick: Harmony is the full post-ES4 agenda, not just what fits in any one edition. So ES.next is a subset of Harmony, and we talk about proposals being in Harmony vs. strawman. We consider strawman proposals that won't make ES.next, even as we work to finalize ES.next. We may reorder proposals to correct mistaken priorities or stale decisions. We try to look at the big picture and follow the hermeneutic spiral. Harmony is also an approach to evolving JS (a shared set of requirements, goals, technical values and aesthetics if you will), as well as a set of evolving proposals that span future editions. See http://wiki.ecmascript.org/doku.php?id=harmony:harmony for requirements and more links. /be ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
