Re: [webkit-dev] JavaScriptCore on Fuchsia
On Wed, Jun 27, 2018 at 8:05 PM Adam Barth wrote: > > Hi Yusuke, > > For some reason, your original email missed my inbox. > > On Wed, Jun 27, 2018 at 7:53 PM Michael Catanzaro > wrote: > > On Tue, Jun 26, 2018 at 6:49 PM, Yusuke SUZUKI > > wrote: > > > My suggestion is introducing Fushcia port, adding both > > > PLATFORM(FUSHCIA) and OS(FUSHCIA) ifdefs. > > > Use OS(FUSHCIA) when the change is b/c of Fushcia's APIs. And use > > > PLATFORM(FUSHCIA) to change > > > the policy of the released build (e.g. enabling / disabling FTL JIT > > > etc.). > > So far, I seem to be able to control those features on a build level > through CMake. > > > > By doing so, JSCOnly port also becomes available in Fushcia. And it > > > means that Fushcia port can benefit > > > from JSCOnly port's work for making WTF and JSC portable. > > Fuchsia appears to need to be a port in the sense of having an > OptionsFuchsia.cmake in order to set the target triple to > x86_64-unknown-fuchsia. I didn't find any other uses of > CMAKE_CXX_COMPILER_TARGET in WebKit. Is there some other mechanism > folks use to set the target triple (or maybe other folks aren't > crosscompiling using clang)? I discovered CMAKE_TOOLCHAIN_FILE and figured out how to make this work: https://bugs.webkit.org/show_bug.cgi?id=187133 > > I wonder if PLATFORM(FUSHCIA) is even needed? Maybe OS(FUSHCIA) would > > suffice? Then instead of a separate Fushcia port, we would just have > > the existing JSCOnly port running on Fuschia. > > That sounds like a good approach to start with. If we run into > trouble, we might need to adjust. > > Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] JavaScriptCore on Fuchsia
Hi Yusuke, For some reason, your original email missed my inbox. On Wed, Jun 27, 2018 at 7:53 PM Michael Catanzaro wrote: > On Tue, Jun 26, 2018 at 6:49 PM, Yusuke SUZUKI > wrote: > > My suggestion is introducing Fushcia port, adding both > > PLATFORM(FUSHCIA) and OS(FUSHCIA) ifdefs. > > Use OS(FUSHCIA) when the change is b/c of Fushcia's APIs. And use > > PLATFORM(FUSHCIA) to change > > the policy of the released build (e.g. enabling / disabling FTL JIT > > etc.). So far, I seem to be able to control those features on a build level through CMake. > > By doing so, JSCOnly port also becomes available in Fushcia. And it > > means that Fushcia port can benefit > > from JSCOnly port's work for making WTF and JSC portable. Fuchsia appears to need to be a port in the sense of having an OptionsFuchsia.cmake in order to set the target triple to x86_64-unknown-fuchsia. I didn't find any other uses of CMAKE_CXX_COMPILER_TARGET in WebKit. Is there some other mechanism folks use to set the target triple (or maybe other folks aren't crosscompiling using clang)? > I wonder if PLATFORM(FUSHCIA) is even needed? Maybe OS(FUSHCIA) would > suffice? Then instead of a separate Fushcia port, we would just have > the existing JSCOnly port running on Fuschia. That sounds like a good approach to start with. If we run into trouble, we might need to adjust. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] JavaScriptCore on Fuchsia
On Tue, Jun 26, 2018 at 2:08 PM Filip Pizlo wrote: > This looks super interesting! Thanks. :) > I have some questions: > > - Does your JSC port enable all of JSC’s optimization features, like the FTL > JIT and concurrent GC? Nope. I believe we just have the interpreter working. > - Is it a goal to enable basically everything we enable, long term? The Fuchsia project itself doesn't have any particular goals for JavaScriptCore. It's possible that our customers who want to use JavaScriptCore on Fuchsia will have goals for additional functionality in the future, but assuming we host the code on svn.webkit.org, I would imagine recommending that those customers interact directly with the WebKit project. > - Is this 32-bit, 64-bit, or both? Fuchsia supports only 64-bit architectures. We have no interest in 32-bit support in JavaScriptCore. > - Is this mainly for ARM, x86, some other CPU, or lots of CPUs? Fuchsia supports x86_64 and aarch64. > - Do you plan to do significant work on JSC, or do you mainly want to just > stay up to date with what we’re doing? I'd like to foster a healthy dynamic between the WebKit project and our mutual customers. It's hard for me to predict to where those customers will fall on that spectrum, but I would not anticipate the Fuchsia project itself making significant contributions to JSC. However, I would anticipate us maintaining the integration between JavaScriptCore and Fuchsia. > More thoughts inline: > > > On Jun 26, 2018, at 2:00 PM, Adam Barth wrote: > > > > As part of developing Fuchsia [1] (a new open-source operating > > system), we ported JavaScriptCore to run on Fuchsia [2]. At the time, > > our intent was to use this code within the Fuchsia source tree but not > > to make it available for developers writing applications for Fuchsia. > > However, recently, we've gotten a number of requests from customers > > who would like to use JavaScriptCore in their Fuchsia applications. > > > > I'd like your advice about the best way to maintain JavaScriptCore > > support for Fuchsia. Here are some possibilities I can imagine, but > > we're open to other possibilities as well: > > > > 1. Maintain a fork of JavaScriptCore somewhere on googlesource.com > > that supports Fuchsia and instruct customers to obtain the Fuchsia > > port of JavaScriptCore from googlesource.com. > > I’d be OK with this. > > > 2. Maintain a branch of JavaScriptCore in svn.webkit.org that supports > > Fuchsia. > > In my opinion, SVN branches are not significantly better than (1), and in > many ways they are worse. I wouldn’t advocate for this. Make sense. > > 3. Maintain support for JavaScriptCore in the mainline of svn.webkit.org. > > I think that I’d be OK with this, too. This seems better than (1) if you > want to stay up-to-date. Thanks! Adam > > For reference, here's the patch we applied to WTF and JavaScriptCore > > to enable Fuchsia support: > > > > https://gist.github.com/abarth/b4fc909d83be5133cd7a5af209757e96 > > > > This patch is based on webkit@206446, but we'd obviously rebase the > > patch onto top-of-tree before contributing it. > > > > I'm happy to answer any questions you might have that would help you > > provide the best advice. If you would prefer to communicate off-list, > > I'm happy to do that as well. > > > > Thanks in advance, > > Adam > > > > [1] https://fuchsia.googlesource.com/docs/+/master/README.md > > [2] Actually, if you look at > > https://fuchsia.googlesource.com/third_party/webkit, you'll see that > > we've ported WebCore as well, but this email concerns only > > JavaScriptCore. > > ___ > > webkit-dev mailing list > > webkit-dev@lists.webkit.org > > https://lists.webkit.org/mailman/listinfo/webkit-dev > ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] JavaScriptCore on Fuchsia
As part of developing Fuchsia [1] (a new open-source operating system), we ported JavaScriptCore to run on Fuchsia [2]. At the time, our intent was to use this code within the Fuchsia source tree but not to make it available for developers writing applications for Fuchsia. However, recently, we've gotten a number of requests from customers who would like to use JavaScriptCore in their Fuchsia applications. I'd like your advice about the best way to maintain JavaScriptCore support for Fuchsia. Here are some possibilities I can imagine, but we're open to other possibilities as well: 1. Maintain a fork of JavaScriptCore somewhere on googlesource.com that supports Fuchsia and instruct customers to obtain the Fuchsia port of JavaScriptCore from googlesource.com. 2. Maintain a branch of JavaScriptCore in svn.webkit.org that supports Fuchsia. 3. Maintain support for JavaScriptCore in the mainline of svn.webkit.org. For reference, here's the patch we applied to WTF and JavaScriptCore to enable Fuchsia support: https://gist.github.com/abarth/b4fc909d83be5133cd7a5af209757e96 This patch is based on webkit@206446, but we'd obviously rebase the patch onto top-of-tree before contributing it. I'm happy to answer any questions you might have that would help you provide the best advice. If you would prefer to communicate off-list, I'm happy to do that as well. Thanks in advance, Adam [1] https://fuchsia.googlesource.com/docs/+/master/README.md [2] Actually, if you look at https://fuchsia.googlesource.com/third_party/webkit, you'll see that we've ported WebCore as well, but this email concerns only JavaScriptCore. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] [Proposal] Remove support for 'multipart/x-mixed-replace' main resources
For what it's worth, we didn't receive any negative feedback from users or developers when we dropped support for this feature in Chrome. Adam On Tue, Apr 21, 2015 at 3:39 PM, Chris Dumez cdu...@apple.com wrote: Hi, I would like to suggest we remove support for 'multipart/x-mixed-replace’ main resources while keeping support for multipart images. Based on Chrome usage data, this feature is extremely rarely used by Web sites (less than 0.1% of page loads) [1]. This feature adds complexity to the loader and is a source of (security) bugs (e.g. [2] recently), current support also seems buggy. Current support in Safari / WebKit: - Support is not great is WebKit. If you load a Motion JPEG main resource for example, it will keep creating a new ImageDocument and all its DOM tree for every frame (tested on Safari / Mac). - It looks like support is broken on Safari on iOS (I tried a Motion JPEG main resource on iOS8, I see the first frame then a blank page that never finishes loading). Other browsers: - Never supported by IE (including IE11) for any resource - Chrome already dropped support for this (main resources only) almost 2 years ago [3]. - Firefox 37 still supports this based on local testing. Again, I am only proposing dropping support for main resources. For e.g., having an IMG element in a page whose src attribute points to a Motion JPEG would still work as intended. [1] https://code.google.com/p/chromium/issues/detail?id=249132 [2] https://bugs.webkit.org/show_bug.cgi?id=143979 [3] http://src.chromium.org/viewvc/blink?view=revisionrevision=152363 Kr, -- Chris Dumez - Apple Inc. - Cupertino, CA ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Please be careful with webkitpy changes!
On Apr 1, 2015 9:29 PM, Brent Fulgham bfulg...@apple.com wrote: The Windows EWS bots process patches fairly quickly. Once I corrected the problem today, it managed to process about 97 patches in about an hour. I do think one bottleneck is due to individual EWS bots “locking” patches. The first bot to reach a patch locks the patch against other bots handling it. If the patch happens to be ‘consumed’ be a bot with some kind of problem (e.g., bad local configuration, a full disk drive, etc.), that patch will not be touched again — even if the other eight EWS bots are sitting dormant. It might be worth adding the ability for a bot to unlock a patch when it detects a problem with itself. We didn't have that originally because we were paranoid about handling the case of an unclean bot shutdown and wanted to make sure we got a lot of experience with that case. At this point, it's probably an overly paranoid design. Adam Is there some other processing metric you are concerned about? Brent Fulgham - Apple Inc. On Apr 1, 2015, at 2:26 PM, Maciej Stachowiak m...@apple.com wrote: Is it possible to make EWS start processing changes more promptly? On Apr 1, 2015, at 12:42 PM, Brent Fulgham bfulg...@apple.com wrote: Hi Everyone, We lost Windows EWS coverage for the past 36 hours due to a very benign-appearing change to some webkitpy code. I haven’t yet figured out why this particular set of changes caused the Windows bots to start failing, but it has to do with various differences between the Cygwin Python 2.7.8 build and the versions used on our other EWS bots. This does not seem like something developers SHOULD have to worry about, but it’s an unfortunately reality that they really do need to. To make matters worse, the patch that introduced the problem passed EWS. This is because the EWS bots only really begin using changes to webkitpy when they restart processing (about once every 10-13 build iterations). To help combat this problem, I’d like to request that when making changes to webkitpy, please keep an eye on the various EWS bots to make sure they continue processing. If they do start failing, please roll the patch back out and we can work together to resolve the issue. I apologize for how manual and inconvenient this needs to be (at least for now), but keeping the EWS up and running is critical to the smooth function of this project. If you have any questions, please don’t hesitate to e-mail me or look for me on IRC. Thanks! -Brent ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Web Components development will continue in a branch in near future
Hi Ryosuke, On Sat, Feb 15, 2014 at 4:07 PM, Ryosuke Niwa rn...@webkit.org wrote: Now that we've removed all of the existing shadow DOM implementations from trunk in http://trac.webkit.org/changeset/164131, I'm intending to work on new web components implementations in a branch based on the feedback Apple has given on public-webapps and www-style in near future, probably starting with custom elements. I'd like to implement them in a branch to not inadvertently introduce performance regressions. The old implementation on trunk resulted in 5% overall slowdown in the page load time but we didn't quantify that until we removed the feature entirely last year. That's probably because the feature was added over years as a pile of small changesets each of which introduced immeasurably small performance regressions. Development in a branch allows a faithful performance comparison between the two. The approach we were successful with in Blink was to restructure how we construct the render tree. At the time Blink branched from WebKit, the algorithm we both used to construct the render tree was N^2. The inner loop of the N^2 algorithm contained more complex DOM traversals due to shadow DOM. When you profile the code, it looks like shadow DOM is expensive, but the bigger win is just to remove the N^2 algorithm, which we've done in Blink. After removing the N^2 algorithm, shadow DOM related code falls off the profile completely. I hope you view this message as constructive feedback. My hope is that you'll be successful implementing shadow DOM, and I wanted to share what we've learned in case that's useful to you. Good luck! Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Web Components development will continue in a branch in near future
On Tue, Feb 18, 2014 at 1:41 PM, Ryosuke Niwa rn...@webkit.org wrote: On Tue, Feb 18, 2014 at 7:44 AM, Adam Barth aba...@webkit.org wrote: On Sat, Feb 15, 2014 at 4:07 PM, Ryosuke Niwa rn...@webkit.org wrote: Now that we've removed all of the existing shadow DOM implementations from trunk in http://trac.webkit.org/changeset/164131, I'm intending to work on new web components implementations in a branch based on the feedback Apple has given on public-webapps and www-style in near future, probably starting with custom elements. I'd like to implement them in a branch to not inadvertently introduce performance regressions. The old implementation on trunk resulted in 5% overall slowdown in the page load time but we didn't quantify that until we removed the feature entirely last year. That's probably because the feature was added over years as a pile of small changesets each of which introduced immeasurably small performance regressions. Development in a branch allows a faithful performance comparison between the two. The approach we were successful with in Blink was to restructure how we construct the render tree. At the time Blink branched from WebKit, the algorithm we both used to construct the render tree was N^2. The inner loop of the N^2 algorithm contained more complex DOM traversals due to shadow DOM. When you profile the code, it looks like shadow DOM is expensive, but the bigger win is just to remove the N^2 algorithm, which we've done in Blink. After removing the N^2 algorithm, shadow DOM related code falls off the profile completely. Makes sense. I think one big problem with the old implementation was that it started off with a completely different API and feature set and the code had to evolve as the spec developed further over years and accumulated design kinks. I'm sure we can avoid introducing O(n^2) algorithms if we started from scratch looking at the latest design. To clarify: the N^2 algorithms we removed from Blink weren't specific to shadow DOM. We just fixed render tree construction in general not to be N^2. On Tue, Feb 18, 2014 at 1:54 PM, Maciej Stachowiak m...@apple.com wrote: Do you have any more specific pointers that Ryosuke et al could look at for the O(N^2) algorithm? Like a commit range or a function to look at? Removing the N^2 algorithms from render tree construction in Blink was an effort that occurred an extended period of time. As Bem mentioned one of the changes involved was the change below: https://src.chromium.org/viewvc/blink?revision=158839view=revision I believe that WebKit has done some similar work recently, but I haven't followed along in enough detail to know whether these N^2 algorithms still exist in WebKit. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Web Components development will continue in a branch in near future
On Tue, Feb 18, 2014 at 2:41 PM, Adam Barth aba...@webkit.org wrote:
On Tue, Feb 18, 2014 at 1:54 PM, Maciej Stachowiak m...@apple.com wrote:
Do you have any more specific pointers that Ryosuke et al could look at
for the O(N^2) algorithm? Like a commit range or a function to look at?
Removing the N^2 algorithms from render tree construction in Blink was an
effort that occurred an extended period of time. As Bem mentioned one of
the changes involved was the change below:
https://src.chromium.org/viewvc/blink?revision=158839view=revision
I believe that WebKit has done some similar work recently, but I haven't
followed along in enough detail to know whether these N^2 algorithms still
exist in WebKit.
It appears that WebKit still contains some N^2 algorithms in render tree
construction:
var t = Date.now();
for (var i = 0; i 5000; ++i)
document.body.appendChild(document.createElement('div'));
document.body.offsetTop;
document.body.textContent = Date.now() - t;
Here's a jsfiddle if you'd like to experiment yourself:
http://jsfiddle.net/vwG2J/2/
In today's WebKit nightly build, the code above reports a runtime of ~96.
If I multiply the loop bound by a factor of ten, the runtime goes up to
~7625, which is a factor of 79.4 (i.e., roughly quadratic). By way of
contrast, in today's Chrome canary build, the code above reports a runtime
of ~30. If I multiply the loop bound by a factor of ten, the runtime goes
up to ~264, which is a factor of 8.8 (i.e., roughly linear).
My point is not that Chrome is faster at this particular test case but
rather that we were able to resolve the issues that appear to
concern Ryosuke about shadow DOM by making general, algorithmic
improvements to the engine.
Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Web Components development will continue in a branch in near future
On Feb 18, 2014 3:59 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Tue, Feb 18, 2014 at 3:09 PM, Adam Barth aba...@webkit.org wrote:
On Tue, Feb 18, 2014 at 2:41 PM, Adam Barth aba...@webkit.org wrote:
On Tue, Feb 18, 2014 at 1:54 PM, Maciej Stachowiak m...@apple.com
wrote:
Do you have any more specific pointers that Ryosuke et al could look
at for the O(N^2) algorithm? Like a commit range or a function to look at?
Removing the N^2 algorithms from render tree construction in Blink was
an effort that occurred an extended period of time. As Bem mentioned one
of the changes involved was the change below:
https://src.chromium.org/viewvc/blink?revision=158839view=revision
I believe that WebKit has done some similar work recently, but I
haven't followed along in enough detail to know whether these N^2
algorithms still exist in WebKit.
It appears that WebKit still contains some N^2 algorithms in render tree
construction:
var t = Date.bra();
for (var i = 0; i 5000; ++i)
document.body.appendChild(document.createElement('div'));
document.body.offsetTop;
document.body.textContent = Date.now() - t;
Here's a jsfiddle if you'd like to experiment yourself:
http://jsfiddle.net/vwG2J/2/
In today's WebKit nightly build, the code above reports a runtime of
~96. If I multiply the loop bound by a factor of ten, the runtime goes up
to ~7625, which is a factor of 79.4 (i.e., roughly quadratic). By way of
contrast, in today's Chrome canary build, the code above reports a runtime
of ~30. If I multiply the loop bound by a factor of ten, the runtime goes
up to ~264, which is a factor of 8.8 (i.e., roughly linear).
Thanks for the clarification info!
My point is not that Chrome is faster at this particular test case but
rather that we were able to resolve the issues that appear to
concern Ryosuke about shadow DOM by making general, algorithmic
improvements to the engine.
Turning O(n^2) into O(n) algorithms is great but my goal here is to
assess the total cost of implementing shadow DOM, not whether we can make
compensating performance improvements.
As I wrote above, once we removed the N^2 algorithms in Blink, the shadow
DOM code dropped off the profile because we called it N times instead of
N^2 times. You might have a different experience in your implementation,
but I wanted to share our experience with this topic.
Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Infinite scrolling feature exploration
Neat! Over in Blink-land, we're also quite interested in infinite
scrolling. Do you have a doc that describes the approach you're
investigating?
We've been experimenting with how you might be able to achieve infinite
scrolling using existing web platform API. You can see the engine we're
experimenting with at the URL below:
http://src.chromium.org/viewvc/chrome/trunk/src/tools/perf/page_sets/key_silk_cases/infinite_scrolling.html
You can mix-and-match that infinite scrolling engine with template and
web components to get markup that looks roughly as follows:
app-list id=messages
app-dismissable-list class=padding-wrapper
template repeat
app-dismissable-item class=item conversation
div class=avatar style=background-color: {{ avatarColor
}}{{ avatarLetter }}/div
div class=summary
div class=topline
div class=participants{{ participants }}/div
div class=time{{ time }}/div
/div
div class=bottomline
div class=previewspan class=subject{{ subject
}}/span mdash;
span class=snippet{{ snippet }}/span/div
div class=trinkets#x2606;/div
/div
/div
/app-dismissable-item
/template
/app-dismissable-list
/app-list
The app-list custom element stamps out a number of physical list items when
the page loads and then changes the values in the template as you scroll to
different positions in the list. You can see a worked example on GitHub:
https://github.com/abarth/app-widgets/blob/master/demo.html
We've been experimenting with these widgets in Blink, which means they
might not work in Safari yet.
Adam
On Tue, Jan 28, 2014 at 3:07 PM, Beth Dakin bda...@apple.com wrote:
Hi all,
We're experimenting with engine features that could help people build
infinite scrolling websites. To start, we're prototyping an event for
triggering the loading of new content when the user has scrolled near a
content edge.
We'll be kicking off an open-ended discussion in the CSS WG about these
events as well as other possible features for infinite scrolling. As a part
of that discussion, we'd like to be able to have WG members grab a WebKit
build to play with the prototype event and get a feel for how it works and
if it's the sort of thing the platform should have.
I've got a patch that adds these events behind a flag and enables them on
the Mac port (so people can grab a nightly and try them out). I'd like to
land this patch this week so we can have a demoable prototype to talk about
in the CSS WG. If you're curious about the approach, check out the patch
here: https://bugs.webkit.org/show_bug.cgi?id=127371
If there are no objections, I'll land the patch on Thursday.
Thanks,
Beth
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Infinite scrolling feature exploration
On Jan 28, 2014 4:19 PM, Edward O'Connor eocon...@apple.com wrote: Hi, Adam wrote: Over in Blink-land, we're also quite interested in infinite scrolling. Great! It's an increasingly common pattern that could use some help from the engine. We've been experimenting with how you might be able to achieve infinite scrolling using existing web platform API. Cool. I agree with the general principle, but I want to ensure Web authors don't have to roll their own scrolling engine with transforms and rAF just to do interesting things like non-janky infinite scrolling. I think this will require some additions to the platform, but hopefully we can keep the Web-exposed changes minimal. Just to clarify, in those examples, the browser is driving the scrolling. We're just using transforms to recycle DOM nodes, which keeps the DOM finite even though the scrollable area is infinite. Adam Do you have a doc that describes the approach you're investigating? I'm in the middle of writing up an email for www-style with our thought process and what we've looked at; stay tuned. Ted ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] AX: Implement CSS -webkit-alt property (text alternative for generated content pseudo-elements ::before and ::after)
On Fri, Oct 4, 2013 at 12:08 PM, Dean Jackson d...@apple.com wrote: On 3 Oct 2013, at 4:46 am, Christian Biesinger cbiesin...@chromium.org wrote: On Tue, Oct 1, 2013 at 8:26 PM, Ryosuke Niwa rn...@webkit.org wrote: On Tue, Oct 1, 2013 at 4:53 PM, James Craig jcr...@apple.com wrote: Follow-up question: Since this hasn’t made it into the CSS4 spec yet, should we temporarily use “-webkit-alt” for the property name? I know there has been a push to move away from vendor prefixes lately, so if there are no objections, I propose we use the unprefixed version. I think that's what Mozilla and Google are doing but I don't think we necessary have to follow the suit. FYI, because IMO this is an important clarification - Mozilla and Google use unprefixed versions only *behind a (runtime) flag*, until the spec is stable. That way experimental features are not exposed to the web at large until it is unlikely that the spec will change, to avoid cross-browser compatibility risks. We decided on a slightly different approach, which is to prefix things but enable them by default in nightly builds. That way a port must still decide at their shipping time whether or not to enable the feature. In the Moz + Google case, the experimental form is exposed unprefixed to a small number of users on the Web. In our case, the experimental form is exposed prefixed. We concluded that we’ve changed things enough times while prefixed that it was worth the extra “this is experimental and may change” notice. Does this imply that you'll remove the prefixes before shipping the features in a production release? Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] AX: Implement CSS -webkit-alt property (text alternative for generated content pseudo-elements ::before and ::after)
On Fri, Oct 4, 2013 at 1:37 PM, Dean Jackson d...@apple.com wrote: On 5 Oct 2013, at 6:22 am, Adam Barth aba...@webkit.org wrote: On Fri, Oct 4, 2013 at 12:08 PM, Dean Jackson d...@apple.com wrote: On 3 Oct 2013, at 4:46 am, Christian Biesinger cbiesin...@chromium.org wrote: On Tue, Oct 1, 2013 at 8:26 PM, Ryosuke Niwa rn...@webkit.org wrote: On Tue, Oct 1, 2013 at 4:53 PM, James Craig jcr...@apple.com wrote: Follow-up question: Since this hasn’t made it into the CSS4 spec yet, should we temporarily use “-webkit-alt” for the property name? I know there has been a push to move away from vendor prefixes lately, so if there are no objections, I propose we use the unprefixed version. I think that's what Mozilla and Google are doing but I don't think we necessary have to follow the suit. FYI, because IMO this is an important clarification - Mozilla and Google use unprefixed versions only *behind a (runtime) flag*, until the spec is stable. That way experimental features are not exposed to the web at large until it is unlikely that the spec will change, to avoid cross-browser compatibility risks. We decided on a slightly different approach, which is to prefix things but enable them by default in nightly builds. That way a port must still decide at their shipping time whether or not to enable the feature. In the Moz + Google case, the experimental form is exposed unprefixed to a small number of users on the Web. In our case, the experimental form is exposed prefixed. We concluded that we’ve changed things enough times while prefixed that it was worth the extra “this is experimental and may change” notice. Does this imply that you'll remove the prefixes before shipping the features in a production release? I can’t speak for anyone other than the Apple port, and even there I’m definitely not the official word on the topic, but I don’t think that is implied. It’s likely going to depend on perceived stability of the feature, testing, community feedback, etc. The important thing is that our goal is to get to the unprefixed stable form as soon as possible. Also, our prefixing/unprefixing rules are not set in stone. I think the community will evaluate them case by case. I would encourage you (and others) not to ship new vendor-prefixed APIs in production releases. If the feature isn't stable enough to ship without a prefix, it's also harmful to the web ecosystem to ship with a vendor prefix. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Proposal: Add support for Promises
On Sun, Aug 25, 2013 at 11:41 AM, Geoffrey Garen gga...@apple.com wrote: The blink people are running into a bunch of issues by implementing them on the C++ side as opposed to inside the VM. I don’t think we can reason by analogy here. Is there a specific problem you’re concerned about? The tension in Blink is between making it easy to subclass Promise in WebIDL versus making it easy for the garbage collector to trace object graphs that includes Promises. These considerations are different in WebKit because the integration between WebCore and JavaScriptCore works differently than the integration between Blink and V8. I'm happy to explain these issues in more detail if you would find that helpful, but I agree with ggaren that there's probably not much to learn from the Blink implementation because the design pressures are different than in WebKit. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Pepper and NaCl supporting (prototype)
Very impressive. If (like me) you're curious about what changes to WebKit are required to make this work, I found the diff at the following URL: https://github.com/nacl-webkit/webkit/compare/upstream_base...master Adam On Sun, Jun 30, 2013 at 11:41 PM, halton huo halton@gmail.com wrote: Dear WebKit developers and users, I’m pleased to announce the initial contribution of Pepper[1] and NaCl[2] support for WebKit2. The home page is located at https://github.com/nacl-webkit/native_client/wiki. The initial code include supporting of: * Partial pepper api supporting includes: 2d, scripting, url_loader, file chooser, audio, mouse and keyboard events, websockets. * Basic NaCl support with post message api (HelloWorld from nacl_sdk) There are some sceenshots on https://github.com/nacl-webkit/native_client/wiki/Screenshots QA === Q: Why this project? A: We enjoy working with the WebKit projects. We also enjoy technologies like NaCl, and wanted to lower the barrier to letting people integrate NaCl into their WebKit2 based projects. We prototyped this work and now want to make it available for others to use if they want. Q: Can I modify and re-use the project? A: Yes. The code is inherited from the Chromium, WebKit2 and native_client projects. As such, this project follows the same licenses. Q: Why not upstream? A: There are two main reasons. First, the current code is only a prototype to support NaCl in the Linux EFL port of WebKit2. There still remains work to be done before the patches would be appropriate to try and take upstream. Second, the WebKit community has stated in the past that they did not want NaCl upstream. Q: How to contribute? A: Fork the repo on github and submit the pull request, committers will review the patches. For the time being, the initial contributors are committers, we're welcome to anyone who can show his ability to be as committer. Follow the https://github.com/nacl-webkit/native_client/wiki/Code to get code and build. Q: Any next plan? A: We don't have any formal plans for the project moving forward; it is being developed as a part-time effort by a few engineers. As such, there is no guarantee for future work. Again, anyone is welcome to contribute! Or fork the project and run with it. [1] http://code.google.com/p/ppapi/ [2] http://code.google.com/p/nativeclient/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] When should I use AtomicString vs String?
On Fri, May 31, 2013 at 3:18 PM, Darin Adler da...@apple.com wrote:
On May 31, 2013, at 1:57 PM, Brendan Long s...@brendanlong.com wrote:
I hope this isn't a stupid question, but I can't find any references to what
the difference between AtomicString and String is.
WTF::AtomicString is a class that has four differences from the normal
WTF::String class:
1) It’s more expensive to create a new atomic string than a non-atomic
string; doing so requires a lookup in a per-thread atomic string hash table.
2) It’s very inexpensive to compare one atomic string with another. The cost
is just a pointer comparison. The actual string length and data don’t need to
be compared, because on any one thread no AtomicString can be equal to any
other AtomicString.
3) If a particular string already exists in the atomic string table,
allocating another string that is equal to it does not cost any additional
memory. The atomic string is shared and the cost is looking it up in the
per-thread atomic string hash table and incrementing its reference count.
4) There are special considerations if you want to use an atomic string on a
thread other than the one it was created on since each thread has its own
atomic string hash table.
Generally speaking, we use AtomicString to make string comparisons fast and
to save memory when many equal strings are likely to be allocated. For
example, we use AtomicString for HTML attribute names so we can compare them
quickly, and for both HTML attribute names and values since it’s common to
have many identical ones and we save memory.
It’s not a good idea to spend the extra cost to construct an AtomicString if
neither the comparison nor the memory savings applies.
It’s unnecessarily costly to convert an atomic string to a non-atomic string
and then back to an atomic string, since it requires an additional hash table
lookup. Thus if you’re starting with an atomic string it’s best to keep the
value in variables of type AtomicString and AtomicStringImpl* if possible.
I don't mean to intrude, but I believe we store a bit on StringImpl
that makes conversion from String and StringImpl to AtomicString fast
if the underlying StringImpl is already in the AtomicStringTable:
https://trac.webkit.org/browser/trunk/Source/WTF/wtf/text/AtomicString.h#L185
ALWAYS_INLINE static PassRefPtrStringImpl add(StringImpl* r)
{
if (!r || r-isAtomic())
return r;
return addSlowCase(r);
}
Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Somewhat painful AppEngine transitions coming [Caution: Message contains Suspicious URL content]
On Thu, Apr 11, 2013 at 12:07 AM, Ryosuke Niwa rn...@webkit.org wrote: On Wed, Apr 10, 2013 at 11:48 PM, Osztrogonác Csaba o...@inf.u-szeged.hu wrote: Just out of curiosity, isn't simpler deliver the ownership of these apps from Google to Apple instead of starting new apps? We can't because both of them are special Google accounts. As to why or how they're special, I don't think I'm allowed to say anything about it. It's nothing mysterious. They're just set up for internal billing. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Google-Apple WebKit infrastructure transition has been completed
On Thu, Apr 11, 2013 at 3:29 PM, Ryosuke Niwa rn...@webkit.org wrote: Hello WebKittens, As of April 11th, 2013 10 A.M. (PST), we have completed the migration of the following previously-Google-owned WebKit infrastructures and tools: - WebKit status server: webkit-queues.appspot.com - Commit queue (now uses Mac WebKit port instead of Chromium Linux port) - Feeder queue - Style queue - webkitbot (renamed from sheriffbot) - Flakiness dashboard: webkit-test-resuls.appspot.com ^^^ Is that a typo? (resuls - results) I want to personally thank Adam Barth, Alan Cutter, Eric Seidel, and Ojan Vafai for helping us make this transition. I would have been at loss without their help. While tech journalists may never write an article about how well Chromium and non-Chromium ports collaborated over the years, this extremely smooth transition of the infrastructure alone demonstrates how well we work together. I have a lot of positive memories of cross-port/cross-organizaional collaborations over the years especially as someone who worked for both Apple and Google. I wish you all the best of luck! Thanks Ryosuke! Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] APNG support
Chromium is not interested in supporting APNG. I'm not opposed to landing this patch if other ports are interested in supporting APNG. Adam On Mar 21, 2013 4:28 AM, Allan Sandfeld Jensen k...@carewolf.com wrote: On Thursday 21 March 2013, Max Stepin wrote: What do you think? I posted the patch here: https://bugs.webkit.org/show_bug.cgi?id=17022 I don't mind. APNG is a nice simple format. GIF has limitations and MNG is almost inherently broken. To support it though, you need to make sure the patch is very clean. We can't be sure Chrome or Safari will want to enable it, and for Qt we can't control it (depends on the system libpng version after all). So the patch will probably need to extra clean and nice to convince everybody it will not be a maintenance burden later. But for its worth; I would like to see it go in at some point. Cheers `Allan (carewolf) ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Best way to disable JavaScript
On Sun, Mar 17, 2013 at 8:56 PM, Geoffrey Garen gga...@apple.com wrote: Unfortunately, you can't implement CSP that way. :( OK, let's consider this a proposal for how the disable javascript setting should behave, and leave CSP out of it. Consider the case of two same-origin iframes A and B. Suppose A has a restrictive CSP policy (say that bans everything) and B doesn't. If B uses the DOM to insert a script element into A, then CSP should block that script element from executing. Stripping script tags at parse time won't. FWIW, I interpreted the phrases enforcing a directive prevents the protected resource from performing certain actions That text is non-normative. The introductory phrase to that sentence is generally speaking. The normative requirements are more specific. :) and Enforcing a CSP policy should not interfere with the operation of user-supplied scripts as indicating that CSP applied to the resource as loaded from its origin only, and not to other scripts operating on the resulting DOM. In that sentence, user-supplied scripts is intended to refer to user scripts or content scripts from the user agent's extension system. There isn't a great way to refer to those concepts in specs because they're not really part of the open web platform. What is the CSP-expected behavior if a user-supplied script inserts an attribute event handler, javascript: URL, regular event handler, timer, or script element in order to do its work? There's a SHOULD-level requirement that the user script act as normal. That requirement is somewhat aspirational in the sense that no user agent implements it perfectly. We've made some improvements in that resource loads initiated by content scripts correctly bypass the page's CSP policy, but we have more work to do in order to make inline event handlers and JavaScript URLs created by content scripts bypass the page's CSP policy. I noticed that the CSP specification was still in draft form. Is it too late to modify this constraint? Content-Security-Policy 1.0 is a W3C Candidate Recommendation. The WebAppSec working group is working on Content-Security-Policy 1.1. If you'd like to contribute your feedback on CSP, please join the WebAppSec working group. Thus far Apple has not joined the working group and therefore hasn't been able to contribute to the standard. To me, the defense against XSS seems pretty weak if the JavaScript content isn't stripped from the resource. I'm sure the working group would be interested in your point of view. However, I'm sorry that I'm unable to take technical feedback outside the context of the working group due to IPR concerns. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Best way to disable JavaScript
Unfortunately, you can't implement CSP that way. Consider the case of two same-origin iframes A and B. Suppose A has a restrictive CSP policy (say that bans everything) and B doesn't. If B uses the DOM to insert a script element into A, then CSP should block that script element from executing. Stripping script tags at parse time won't. Adam On Sun, Mar 17, 2013 at 8:26 PM, Geoffrey Garen gga...@apple.com wrote: Hi folks. Currently, we have two different ways to disable JavaScript execution: (1) Paste / Drag n Drop / editing: Remove script elements and script attributes from untrusted source markup at parse time. (2) JavaScript disabled setting / Content Security Policy: Check settings and/or CSP at runtime. There are problems with mode (2): * It breaks features that are implemented in JavaScript. The Web Inspector, bookmarklets, extensions, Safari Reader, and Safari autofill all run JavaScript. This means that they break when users disable JavaScript. As a defense against phishing attacks, mail clients and other web content readers disable JavaScript. This means that they can't implement pieces of their UI in JavaScript. (FWIW, WebKit violates the CSP specification in this regard: Enforcing a CSP policy should not interfere with the operation of user-supplied scripts such as third-party user-agent add-ons and JavaScript bookmarklets.) * It subjects users to XSS attacks. Runtime checking mode leaves inert JavaScript in the untrusted document. This is a risky proposition. Operations that clone or adopt nodes from the untrusted document unwittingly re-vivify that inert JavaScript, subjecting the user to attack. Experience shows that this is a difficult programming model to get right. * It's hard to verify. We have 18 different call sites to canExecuteScripts() in WebKit, not counting the call sites that pertain to plug-ins. Are you confident we've caught all the right places? Do you know if the feature you just added needs to call canExecuteScripts()? * It's two different ways to do the same thing. Simplicity is a goal of the WebKit project. Proposal: If -- for any reason -- JavaScript is disabled in a given document, the document parser will elide all JavaScript. This means that runtime checks can be removed. One potential downside to this proposal is that it changes the document's internal structure. Since the changes are not generally observable, since they only take place when we're already making much bigger changes by preventing whole scripts from running, and since we haven't seen any compatibility problems from our paste / drag n drop / editing behavior in this regard, I think this downside is acceptable. Another potential downside is that CSP errors will be reported at parse time instead of runtime. FWIW, some authors might see this as an upside. Any objections? Thanks, Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] rolling out a buggy security patch
On Tue, Mar 12, 2013 at 1:36 AM, Osztrogonác Csaba o...@inf.u-szeged.hu wrote: But my question is still open about how can we avoid similar problems in the future. Why can't we let the EWS bots to build and test security patches before commit. This topic was discussed on the webkit-security mailing list in May 2010. Unfortunately, the archives of that list are not viewable publicly. Maciej's concerns at the time are summaries in his message below: On Tue, Oct 19, 2010 at 6:16 PM, Maciej Stachowiak m...@apple.com wrote: The commit bot is not a person and therefore can't agree to the security group policy, as required for security group membership. If a specific person or persons want to take responsibility for an additional email account and bugzilla account having security access, then that's not categorically excluded. But I'd like to understand who currently has access to the commit bot's email account and bugzilla account, what the policies are for more people getting access, and whether there are indirect ways of getting access such as by modifying the commit bot's code, or by uploading a patch that tries to abuse the EWS testers. And I'd like to see at least one person named to take responsibility for ensuring that the commit bot is not used as a means of violating the policy. Of course, it's entirely possible that his views have changed since then. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] rolling out a buggy security patch
On Tue, Mar 12, 2013 at 2:26 AM, Maciej Stachowiak m...@apple.com wrote: On Mar 12, 2013, at 1:48 AM, Adam Barth aba...@webkit.org wrote: On Tue, Mar 12, 2013 at 1:36 AM, Osztrogonác Csaba o...@inf.u-szeged.hu wrote: But my question is still open about how can we avoid similar problems in the future. Why can't we let the EWS bots to build and test security patches before commit. This topic was discussed on the webkit-security mailing list in May 2010. Unfortunately, the archives of that list are not viewable publicly. Maciej's concerns at the time are summaries in his message below: On Tue, Oct 19, 2010 at 6:16 PM, Maciej Stachowiak m...@apple.com wrote: The commit bot is not a person and therefore can't agree to the security group policy, as required for security group membership. If a specific person or persons want to take responsibility for an additional email account and bugzilla account having security access, then that's not categorically excluded. But I'd like to understand who currently has access to the commit bot's email account and bugzilla account, what the policies are for more people getting access, and whether there are indirect ways of getting access such as by modifying the commit bot's code, or by uploading a patch that tries to abuse the EWS testers. And I'd like to see at least one person named to take responsibility for ensuring that the commit bot is not used as a means of violating the policy. Of course, it's entirely possible that his views have changed since then. I am still curious who has access to the commit bot's bugzilla account. Is a small set of known people, is it a large set, is the password sitting around somewhere that others may get at it? I do not recall this being answered at the time, or perhaps I have forgotten. The approach we've taken is to use different bugzilla accounts for the different bot administrators. The commit-queue, the cr-linux-ews, the style-queue, and sheriffbot share one account (webkit.review.bot@gmail), whereas the queues that Ossy runs use a different account. Approximately eight people have access to the account because they have ssh access to the machines that run those queues. I can send you the list of people, if you're interested, but there are certainly folks on that list who are not members of the WebKit Security Group. In addition to the bugzilla account, we should also consider the set of people who have access to the underlying email address (since the email address can be used to reset the bugzilla password). In the case of webkit.review.bot, I'm the only person who has access to the underlying email account. (That's probably not ideal from a bus-factor point-of-view, however.) If the set with access is a small set of known people who are willing to be identified and be in the security group themselves (or already are), then I am personally fine with it. The set of people who are active maintainers of those machines is smaller than set of people who have access. A good first step would be for me to narrow down the list (and obviously rotate the password). Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Should we create an 8-bit path from the network stack to the parser?
Oh, Ok. I misunderstood your original message to say that the project as a whole had reached this conclusion, which certainly isn't the case, rather than that you personally had reached that conclusion. As for the long-term direction of the HTML parser, my guess is that the optimum design will be to deliver the network bytes to the parser directly on the parser thread. On the parser thread, we can merge charset decoding, input stream pre-processing, and tokenization to move directly from network bytes to CompactHTMLTokens. That approach removes a number of copies, 8-bit-to-16-bit, and 16-bit-to-8-bit conversions. Parsing directly into CompactHTMLTokens also means we won't have to do any copies or conversions at all for well-known strings (e.g., div and friends from HTMLNames). If you're about to reply complaining about the above, please save your complaints for another time. I realize that some parts of that design will be difficult or impossible to implement on some ports due to limitations on how then interact with their networking stack. In any case, I don't plan to implement that design anytime soon, and I'm sure we'll have plenty of time to discuss its merits in the future. Adam On Mon, Mar 11, 2013 at 8:56 AM, Michael Saboff msab...@apple.com wrote: Maciej, *I* deemed using a character type template for the HTMLTokenizer as being unwieldy. Given there was the existing SegmentedString input abstraction, it made logical sense to put the 8/16 bit coding there. If I would have moved the 8/16 logic into the tokenizer itself, we might have needed to do 8-16 up conversions when a SegmentedStrings had mixed bit-ness in the contained substrings. Even if that wasn't the case, the patch would have been far larger and likely include tricky code for escapes. As I got into the middle of the 8-bit strings, I realized that not only could I keep performance parity, but some of the techniques I came up with offered good performance improvement. The HTMLTokenizer ended up being one of those cases. This patch required a couple of reworks for performance reasons and garnered a lot of discussion from various parts of the webkit community. See https://bugs.webkit.org/show_bug.cgi?id=90321 for the trail. Ryosuke noted that this patch was responsible for a 24% improvement in the url-parser test in their bots (comment 47). My performance final results are in comment 43 and show between 1 and 9% progression on the various HTML parser tests. Adam, If you believe there is more work to be done in the HTMLTokenizer, file a bug and cc me. I'm interested in hearing your thoughts. - Michael On Mar 9, 2013, at 4:24 PM, Maciej Stachowiak m...@apple.com wrote: On Mar 9, 2013, at 3:05 PM, Adam Barth aba...@webkit.org wrote: In retrospect, I think what I was reacting to was msaboff statement that an unnamed group of people had decided that the HTML tokenizer was too unwieldy to have a dedicated 8-bit path. In particular, it's unclear to me who made that decision. I certainly do not consider the matter decided. It would be good to find out who it was that said that (or more specifically: Using a character type template approach was deemed to be too unwieldy for the HTML tokenizer.) so you can talk to them about it. Michael? Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Should we create an 8-bit path from the network stack to the parser?
On Mon, Mar 11, 2013 at 9:56 AM, Darin Adler da...@apple.com wrote: On Mar 11, 2013, at 9:54 AM, Adam Barth aba...@webkit.org wrote: If you're about to reply complaining about the above, please save your complaints for another time. Huh? The last time we tried to talk about changing the design of the HTML parser on this mailing list, I got the third degree: https://lists.webkit.org/pipermail/webkit-dev/2013-January/023271.html I just wanted to be clear that I'm not proposing making those changes now and we'll have a chance to discuss the various pros and cons of each step as we consider making them. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Should we create an 8-bit path from the network stack to the parser?
On Sat, Mar 9, 2013 at 12:48 PM, Luis de Bethencourt l...@debethencourt.com wrote: On Mar 7, 2013 10:37 PM, Brady Eidson beid...@apple.com wrote: On Thu, Mar 7, 2013 at 2:14 PM, Michael Saboff msab...@apple.com wrote: The various tokenizers / lexers work various ways to handle LChar versus UChar input streams. Most of the other tokenizers are templatized on input character type. In the case of HTML, the tokenizer handles a UChar character at a time. For 8 bit input streams, the zero extension of a LChar to a UChar is zero cost. There may be additional performance to be gained by doing all other possible handling in 8 bits, but an 8 bit stream can still contain escapes that need a UChar representation as you point out. Using a character type template approach was deemed to be too unwieldy for the HTML tokenizer. The HTML tokenizer uses SegmentedString's that can consist of sub strings with either LChar and UChar. That is where the LChar to UChar zero extension happens for an 8 bit sub string. My research showed that at the time showed that there were very few UTF-16 only resources (5% IIRC), although I expect the number to grow. On Mar 7, 2013, at 2:16 PM, Adam Barth aba...@webkit.org wrote: Yes, I understand how the HTML tokenizer works. :) I didn't understand these details, and I really appreciate Michael describing them. I'm also glad others on the mailing list had an opportunity to get something out of this. I agree with Brady. I got some interesting learning out of this thread. Always nice to read explanations and documentation about how things work. Valuable content. In retrospect, I think what I was reacting to was msaboff statement that an unnamed group of people had decided that the HTML tokenizer was too unwieldy to have a dedicated 8-bit path. In particular, it's unclear to me who made that decision. I certainly do not consider the matter decided. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] -khtml- and -apple- CSS prefixes
On Sat, Mar 9, 2013 at 5:02 PM, Maciej Stachowiak m...@apple.com wrote: On Mar 8, 2013, at 3:09 PM, Adam Barth aba...@webkit.org wrote: I've posted a patch to limit the -apple- and -khtml- CSS vendor prefixes to ENABLE(DASHBOARD_SUPPORT): https://bugs.webkit.org/show_bug.cgi?id=111890 My understanding is that I also need to add a runtime flag in order to fully hide these prefixes from the web because Safari and Dashboard share the same WebCore binary on Mac OS X. I found the following entry in Settings.in: usesDashboardBackwardCompatibilityMode initial=false, conditional=DASHBOARD_SUPPORT However, some of the paces we need to check this flag do not have easy access to the Page and therefore have trouble finding the Settings object. Would it be possible to use a global static flag to hide these prefixes from the web? I don't understand the details of how Safari and Dashboard share WebCore to know if a global static flag would work correctly. Safari and DashboardClient (the executable that actually renders widgets) link the same copy of WebCore on disk, but are separate executables at runtime. Dashboard backwards compatibility mode is triggered by the per-WebView _setDashboardBehavior: call which then sets the usesDashboardBackwardCompatibilityMode setting. It appears that any app using this SPI either sets it on all WebViews or none. So it's probably workable to make usesDashboardBackwardCompatibilityMode be effectively a global setting. Reviewing the pre-installed widgets and a random sampling of other widgets, I found: - The only -apple prefixed property used is -apple-dashboard-region. This property is seemingly always used with a -apple prefix and never with -khtml or -webkit. - The builtin widgets use a -khtml prefix for -khtml-user-select and -khtml-user-modify. I filed a bug to fix this. Some third-party widgets use the -khtml prefix on random other properties. My recommendation would be: * Do one of the following two options: - Plan A: Rename -webkit-dashboard-region to -apple-dashboard-region in CSSPropertyNames.in (it is only compiled in with ENABLE_DASHBOARD_SUPPORT anyway). - Plan B: Support -apple- as a prefix alias only for -webkit-dashboard-region (it is only compiled in with ENABLE_DASHBOARD_SUPPORT anyway). * Remove all other support for the -apple- prefix as a synonym for -webkit- * Make -khtml- prefix alias support only available if ENABLE_DASHBOARD_SUPPORT is on, and also runtime-conditional based on usesDashboardBackwardCompatibilityMode having ever been set for any Settings object. Depending on whether Plan A or Plan B is preferred, I can file a bug to replace -apple-dashboard-region with -webkit-dashboard-region in the preinstalled Dashboard widgets. That sounds like a good plan. Given that Plans A and B differ only builds shipped by Apple, I'll leave that choice up to you. I'm happy to write a patch that executes the parts of this plan that involve the WebKit codebase. Adam On Fri, Mar 1, 2013 at 4:57 PM, Maciej Stachowiak m...@apple.com wrote: I think we'll want to take these out for Apple ports as soon as we can check prevalence in older Apple-specific content (e.g. Dashboard widgets). On Fri, Mar 1, 2013 at 9:11 AM, David Hyatt hy...@apple.com wrote: I agree with you that this would be pretty terrible. We definitely don't want developers doing that. On Feb 28, 2013, at 6:02 PM, Adam Barth aba...@webkit.org wrote: I noticed this comment on the Hacker News thread about Paul Irish's recent blog post: ---8--- CSS parsing is the same, though. Slurping up your CSS and turning it into CSSOM’s pretty standard. Yeah, though Chrome accepts just the -webkit- prefix whereas Apple and other ports accept legacy prefixes like -khtml- and -apple-. Using this information, can you target Chrome with the webkit- prefix and Safari with the apple- prefix? Specifying the apple- prefix after webkit- will ensure that Safari uses that one, right? ---8--- http://news.ycombinator.com/item?id=5302150 If developers start using this technique, it might be harder to remove these prefixes in the future. Chromium's experience removing these prefixes has been quite positive. We ran into one compatibility problem on apple.com, which Apple was gracious enough to fix. I'd recommend that the rest of the ports disable ENABLE(LEGACY_CSS_VENDOR_PREFIXES) to remove support for the -khtml- and -apple- CSS prefixes before it's too late. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] -khtml- and -apple- CSS prefixes
On Sat, Mar 9, 2013 at 8:55 PM, Maciej Stachowiak m...@apple.com wrote: On Mar 9, 2013, at 8:00 PM, Adam Barth aba...@webkit.org wrote: On Sat, Mar 9, 2013 at 5:02 PM, Maciej Stachowiak m...@apple.com wrote: My recommendation would be: * Do one of the following two options: - Plan A: Rename -webkit-dashboard-region to -apple-dashboard-region in CSSPropertyNames.in (it is only compiled in with ENABLE_DASHBOARD_SUPPORT anyway). - Plan B: Support -apple- as a prefix alias only for -webkit-dashboard-region (it is only compiled in with ENABLE_DASHBOARD_SUPPORT anyway). * Remove all other support for the -apple- prefix as a synonym for -webkit- * Make -khtml- prefix alias support only available if ENABLE_DASHBOARD_SUPPORT is on, and also runtime-conditional based on usesDashboardBackwardCompatibilityMode having ever been set for any Settings object. Depending on whether Plan A or Plan B is preferred, I can file a bug to replace -apple-dashboard-region with -webkit-dashboard-region in the preinstalled Dashboard widgets. That sounds like a good plan. Given that Plans A and B differ only builds shipped by Apple, I'll leave that choice up to you. I'm happy to write a patch that executes the parts of this plan that involve the WebKit codebase. I very slightly prefer Plan A. The main downside is having a non-webkit prefix in the code with no migration path off of it. But it's a property that is not applicable to anything but Dashboard as designed[*]. So maybe lack of migration path is OK. I wasn't sure if anyone else would object to semi-permanently having code for a -apple- property, which is why I listed the alternative, which does have a migration path. That doesn't seem like a big burden for the project, especially if it's just one property and not exposed to the web. The real risk here is web sites becoming dependent on these prefixes to handle quirks between CoreAnimation and the Chromium Compositor. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] -khtml- and -apple- CSS prefixes
I've posted a patch to limit the -apple- and -khtml- CSS vendor prefixes to ENABLE(DASHBOARD_SUPPORT): https://bugs.webkit.org/show_bug.cgi?id=111890 My understanding is that I also need to add a runtime flag in order to fully hide these prefixes from the web because Safari and Dashboard share the same WebCore binary on Mac OS X. I found the following entry in Settings.in: usesDashboardBackwardCompatibilityMode initial=false, conditional=DASHBOARD_SUPPORT However, some of the paces we need to check this flag do not have easy access to the Page and therefore have trouble finding the Settings object. Would it be possible to use a global static flag to hide these prefixes from the web? I don't understand the details of how Safari and Dashboard share WebCore to know if a global static flag would work correctly. Thanks, Adam On Fri, Mar 1, 2013 at 4:57 PM, Maciej Stachowiak m...@apple.com wrote: I think we'll want to take these out for Apple ports as soon as we can check prevalence in older Apple-specific content (e.g. Dashboard widgets). On Fri, Mar 1, 2013 at 9:11 AM, David Hyatt hy...@apple.com wrote: I agree with you that this would be pretty terrible. We definitely don't want developers doing that. On Feb 28, 2013, at 6:02 PM, Adam Barth aba...@webkit.org wrote: I noticed this comment on the Hacker News thread about Paul Irish's recent blog post: ---8--- CSS parsing is the same, though. Slurping up your CSS and turning it into CSSOM’s pretty standard. Yeah, though Chrome accepts just the -webkit- prefix whereas Apple and other ports accept legacy prefixes like -khtml- and -apple-. Using this information, can you target Chrome with the webkit- prefix and Safari with the apple- prefix? Specifying the apple- prefix after webkit- will ensure that Safari uses that one, right? ---8--- http://news.ycombinator.com/item?id=5302150 If developers start using this technique, it might be harder to remove these prefixes in the future. Chromium's experience removing these prefixes has been quite positive. We ran into one compatibility problem on apple.com, which Apple was gracious enough to fix. I'd recommend that the rest of the ports disable ENABLE(LEGACY_CSS_VENDOR_PREFIXES) to remove support for the -khtml- and -apple- CSS prefixes before it's too late. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Should we create an 8-bit path from the network stack to the parser?
The HTMLTokenizer still works in UChars. There's likely some performance to be gained by moving it to an 8-bit character type. There's some trickiness involved because HTML entities can expand to characters outside of Latin-1. Also, it's unclear if we want two tokenizers (one that's 8 bits wide and another that's 16 bits wide) or if we should find a way for the 8-bit tokenizer to handle, for example, UTF-16 encoded network responses. Adam On Thu, Mar 7, 2013 at 10:11 AM, Darin Adler da...@apple.com wrote: No. I retract my question. Sounds like we already have it right! thanks for setting me straight. Maybe some day we could make a non copying code path that points directly at the data in the SharedBuffer, but I have no idea if that'd be beneficial. -- Darin Sent from my iPhone On Mar 7, 2013, at 10:01 AM, Michael Saboff msab...@apple.com wrote: There is an all-ASCII case in TextCodecUTF8::decode(). It should be keeping all ASCII data as 8 bit. TextCodecWindowsLatin1::decode() has not only an all-ASCII case, but it only up converts to 16 bit in a couple of rare cases. Is there some other case you don't think we are handling? - Michael On Mar 7, 2013, at 9:29 AM, Darin Adler da...@apple.com wrote: Hi folks. Today, bytes that come in from the network get turned into UTF-16 by the decoding process. We then turn some of them back into Latin-1 during the parsing process. Should we make changes so there’s an 8-bit path? It might be as simple as writing code that has more of an all-ASCII special case in TextCodecUTF8 and something similar in TextCodecWindowsLatin1. Is there something significant to be gained here? I’ve been wondering this for a while, so I thought I’d ask the rest of the WebKit contributors. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Should we create an 8-bit path from the network stack to the parser?
Yes, I understand how the HTML tokenizer works. :) Adam On Thu, Mar 7, 2013 at 2:14 PM, Michael Saboff msab...@apple.com wrote: The various tokenizers / lexers work various ways to handle LChar versus UChar input streams. Most of the other tokenizers are templatized on input character type. In the case of HTML, the tokenizer handles a UChar character at a time. For 8 bit input streams, the zero extension of a LChar to a UChar is zero cost. There may be additional performance to be gained by doing all other possible handling in 8 bits, but an 8 bit stream can still contain escapes that need a UChar representation as you point out. Using a character type template approach was deemed to be too unwieldy for the HTML tokenizer. The HTML tokenizer uses SegmentedString's that can consist of sub strings with either LChar and UChar. That is where the LChar to UChar zero extension happens for an 8 bit sub string. My research showed that at the time showed that there were very few UTF-16 only resources (5% IIRC), although I expect the number to grow. - Michael On Mar 7, 2013, at 11:11 AM, Adam Barth aba...@webkit.org wrote: The HTMLTokenizer still works in UChars. There's likely some performance to be gained by moving it to an 8-bit character type. There's some trickiness involved because HTML entities can expand to characters outside of Latin-1. Also, it's unclear if we want two tokenizers (one that's 8 bits wide and another that's 16 bits wide) or if we should find a way for the 8-bit tokenizer to handle, for example, UTF-16 encoded network responses. Adam On Thu, Mar 7, 2013 at 10:11 AM, Darin Adler da...@apple.com wrote: No. I retract my question. Sounds like we already have it right! thanks for setting me straight. Maybe some day we could make a non copying code path that points directly at the data in the SharedBuffer, but I have no idea if that'd be beneficial. -- Darin Sent from my iPhone On Mar 7, 2013, at 10:01 AM, Michael Saboff msab...@apple.com wrote: There is an all-ASCII case in TextCodecUTF8::decode(). It should be keeping all ASCII data as 8 bit. TextCodecWindowsLatin1::decode() has not only an all-ASCII case, but it only up converts to 16 bit in a couple of rare cases. Is there some other case you don't think we are handling? - Michael On Mar 7, 2013, at 9:29 AM, Darin Adler da...@apple.com wrote: Hi folks. Today, bytes that come in from the network get turned into UTF-16 by the decoding process. We then turn some of them back into Latin-1 during the parsing process. Should we make changes so there’s an 8-bit path? It might be as simple as writing code that has more of an all-ASCII special case in TextCodecUTF8 and something similar in TextCodecWindowsLatin1. Is there something significant to be gained here? I’ve been wondering this for a while, so I thought I’d ask the rest of the WebKit contributors. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] New web-facing CSS feature: -webkit-cursor-visibility: auto-hide
Have you proposed this feature to the relevant standards working group? Adam On Mon, Mar 4, 2013 at 4:37 PM, Jer Noble jer.no...@apple.com wrote: In an effort to improve the user-experience of watching videos in full screen mode, I have created a patch which adds a new CSS style attribute: -webkit-cursor-visibility. When set to auto-hide, this rule would change the cursor type to none after a few seconds of inactivity. UAs could then add this rule to their UA full screen style sheets for full screened video elements, but this rule can be overridden by site authors to handle hiding the cursor (or not) themselves. Sites which do not hide the cursor during playback in full screen mode (e.g. YouTube) would get this behavior for free, and sites which do (e.g. vimeo) can continue to explicitly hide the mouse cursor when hiding their custom controls. This new attribute is not currently hidden behind a feature flag. We are at the very initial stages of proposing this attribute to the CSSWG, but have already incorporated feedback from some of the WG members. Please take a look at the associated bug, if you're interested: https://bugs.webkit.org/show_bug.cgi?id=107601 Default mouse cursor behavior should be auto-hide for full screen video with custom controls -Jer ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] -khtml- and -apple- CSS prefixes
I noticed this comment on the Hacker News thread about Paul Irish's recent blog post: ---8--- CSS parsing is the same, though. Slurping up your CSS and turning it into CSSOM’s pretty standard. Yeah, though Chrome accepts just the -webkit- prefix whereas Apple and other ports accept legacy prefixes like -khtml- and -apple-. Using this information, can you target Chrome with the webkit- prefix and Safari with the apple- prefix? Specifying the apple- prefix after webkit- will ensure that Safari uses that one, right? ---8--- http://news.ycombinator.com/item?id=5302150 If developers start using this technique, it might be harder to remove these prefixes in the future. Chromium's experience removing these prefixes has been quite positive. We ran into one compatibility problem on apple.com, which Apple was gracious enough to fix. I'd recommend that the rest of the ports disable ENABLE(LEGACY_CSS_VENDOR_PREFIXES) to remove support for the -khtml- and -apple- CSS prefixes before it's too late. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Deprecating JS interface
On Sat, Feb 16, 2013 at 11:26 PM, Dirk Schulze dschu...@adobe.com wrote: On Feb 16, 2013, at 10:50 PM, Maciej Stachowiak m...@apple.com wrote: On Feb 16, 2013, at 10:16 PM, Dirk Schulze dschu...@adobe.com wrote: On Feb 16, 2013, at 6:54 PM, Adam Barth aba...@webkit.org wrote: It's much easier to discuss a concrete example. Which interface are you interested in deprecating? I can understand that it is easier to discuss on a concrete example, even if I would like to discuss this in a general scope. We have multiple interfaces that we may want to deprecate at some point. A concrete example I thought about is WebKitCSSMatrix[1]. It is not used in WebCore yet but hopefully replaced by a standardized Matrix interface in the future[2]. This new interface will not be fully compatible to WebKitCSSMatrix and I would like to warn authors before they actually start using it. Since you're the one designing the new interface (or at least you are the spec editor), why don't you just make it compatible? Breaking changes to existing Web APIs should only be done as a last resort, and I don't understand the justification for doing it here. It is a proposal so far and no draft yet. Technically, I am not the editor of it so. The proposal has quite some way to go (hopefully not too much) and I do not plan to land anything in this direction as long as the responsible WGs did not agree on continuing with the proposal and the general direction. I will post a separate mail with the actual feature implementation announcement when the time comes. Then we have a much simper transition story, and WebKitCSSMatrix can be aliased to the new class. I indeed tried to preserve the behavior of WebKitCSSMatrix as much as possible. I got an action of the SVG WG to work on a replacement for SVGMatrix. The highest priority was to preserver the behavior of SVGMatrix (which is definitely actively used by web content) and provide a basic interface that can be used beyond just SVG. There are a lot of use cases in the near future for a generalized matrix IMO. SVG, CSS Transforms, Canvas and WebGL are the obvious once. A specification interoperable format to share transformation data seems extremely desirable. I encourage everyone who is interested to look at the proposal and give feedback. Again, I think it would be better to discuss this in a wider scope but am happy to discuss it on the concrete example as well. This actually might make it easier to come up with general rules in the future. I think spamming the console is not a useful thing to do for interfaces that actually have significant usage in the wild. A more productive step would be to measure usage of WebKitCSSMatrix. If it's reasonably high, we're not going to be able to remove it. I agree that we need more metrics to discuss the next active steps on WebKitCSSMatrix and I already uploaded a patch to add it to the FeatureObserver[1]. The question remains: How do we want to continue with deprecating WebKit specific features in the long term. Especially when we have a standard compliant replacement. It is extremely hard to maintain all different behaviors. So far we have multiple implementations of background, flex-box, gradients to name some. This doesn't scale very well and there will be a time where we can not guarantee for the correct functioning of old features. This is a problem that other browsers like IE are focused for quite some time as well (not necessarily successfully). As long as we are concerned to deprecate and remove features, we increase the complexity of the code base. Less and less reviewers will be able to determine the behavior of patches to the general code base, while we increase the feature count and interoperability between modules more and more. There is no other way then to risk breaking content that relies on non-standardized behavior of platforms. And we should formalize this to give a bit more reliability to web authors. The last section on [2] is too vague at the moment. I don't think we're be successful at formalizing a general approach at this time. Instead, we should consider each case in turn and use our best judgement. If a pattern emerges over time, we might want to document that pattern in http://trac.webkit.org/wiki/DeprecatingFeatures. At the moment, deprecating WebKitCSSMatrix seems premature as there isn't yet a suitable replacement. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Deprecating JS interface
On Sun, Feb 17, 2013 at 7:26 AM, Dirk Schulze dschu...@adobe.com wrote: On Feb 17, 2013, at 1:28 AM, Maciej Stachowiak m...@apple.com wrote: On Feb 17, 2013, at 1:09 AM, Filip Pizlo fpi...@apple.com wrote: On Feb 17, 2013, at 1:04 AM, Dirk Schulze dschu...@adobe.com wrote: The discussion on each single feature let us forget the greater scope of this problem. That is why I did not start with a concrete example. What about going another direction? Right now we have compiler flags for a lot of new features. What if we turn this around? Why not having a compiler flag ENABLE_DEPRECATED_FEATURES? This must be turned on in trunk to make sure deprecated features still work properly. Release builds should turn it on to not break compatibility. But every binary build of a nightly or preview has it turned off. A lot of developers experiment with Chrome Canary and WebKit nightlies already. It might be a drop in the bucket, but still can have some influence on decreasing the use of deprecated content. Features like CSS gradients, transitions and animations might be good candidates at the beginning for this flag. This carries the risk of decreasing test coverage of Nightlies and Canaries. I don't think that is acceptable. Users who download them and cannot use a web page because that page had deprecated features will then not be able to experience what bugs we had, those deprecated features notwithstanding. I empathize with the desire to remove cruft. But we shouldn't remove things if it breaks the web, even in Nightlies and Canaries. I agree with Phil. And as a corollary, if removing something *doesn't* break the Web and we think it's otherwise bad, then there's no need to do a special dance with nightlies before removing. Then we should face it. Prefixed content for CSS gradients, animation, transition, transforms, CSS Image functions, masking and a lot more will not go away. This basically means we will need to support them for an undetermined period of time, possibly for the projects lifetime. This will be the same for every popular prefixed feature that we introduce in the future. If we are honest about this we may can prevent future content to be a burden on maintenance and use similar concepts as Mozilla does with runtime flags on unprefixed features. Just because we want to be thoughtful about which features we deprecate doesn't mean that we'll be unsuccessful in removing vendor-prefixed features. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Deprecating JS interface
It's much easier to discuss a concrete example. Which interface are
you interested in deprecating?
Adam
On Sat, Feb 16, 2013 at 5:28 PM, Dirk Schulze dschu...@adobe.com wrote:
Hi,
There are several steps on deprecating features[1]. My question is about
deprecating a whole interface and throwing warnings that the feature is
deprecated.
If I have the following interface for deprecation:
[Constructor]
interface Bla {
attribute bar;
void foo();
}
Should I just throw the deprecation warning on calling the constructor (and
any method/attribute creating the object), or on calling foo and bar as well?
Greetings,
Dirk
[1] http://trac.webkit.org/wiki/DeprecatingFeatures
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Merging the iOS port to svn.webkit.org (Re: WebCore and interlocking threads)
On Sun, Feb 10, 2013 at 10:39 AM, Ojan Vafai o...@chromium.org wrote: On Sat, Feb 9, 2013 at 7:41 PM, Maciej Stachowiak m...@apple.com wrote: Hi Peter, On Feb 9, 2013, at 3:48 PM, Peter Kasting pkast...@google.com wrote: On Sat, Feb 9, 2013 at 11:52 AM, Maciej Stachowiak m...@apple.com wrote: There are certainly pros and cons to merging. It would be great get input from the broader WebKit community on the tradeoff of merging sooner vs avoidance of weird legacy code in the main tree. In the meantime, we'll stick to merging things that are not overly controversial as much as we can. For what my opinion is worth (probably near zero for a lot of you), I would like to see you guys merge sooner rather than later, even if it leads to awkwardness that needs cleanup. Over the years there has been a nonzero amount of friction due to the iOS port not being upstreamed, and I think it would be beneficial to WebKit as a whole to fix that sooner rather than later. And it seems more likely to me that upstream first, then decide how to re-architect as needed is going to result in high-quality discussions and designs, as opposed to figure out in private how to re-architect before upstreaming, which runs the risk of just never bothering to upstream at all. There is real compromise, and perhaps humility, needed from all sides to make such a task successful. I am reminded of Eric's recent email where he pleaded for more of an explicit effort to civility towards each other. Perhaps this is an opportunity for us to practice that effort. I really appreciate you saying that. I feel the same way. For years we've been saying that we need to fix N different things before upstreaming, and in the end we concluded that it was just delaying us from upstreaming at all. And we concluded that cleaning up some of the questionable choices in the open would lead to a better final outcome. +1. I think that allowing the V8 bindings into the tree is a fairly good analogy to this situation (although it's not exactly the same). The point is that it did put a burden on the rest of the project at the benefit of getting Chromium folk working on core code and giving the ability to discuss trade-offs more directly by looking at the code in question. Ok. I'm sold. I suspect we'll want to move the iOS port off of USE(WEB_THREAD), but I can see how it's better to do that work in trunk. I wonder if it would be worth using a name like USE(DEPRECATED_WEB_THREAD) to discourage others from adopting this execution model. Thanks everyone for taking the time to discuss this issue. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Merging the iOS port to svn.webkit.org (Re: WebCore and interlocking threads)
On Fri, Feb 8, 2013 at 8:19 PM, Maciej Stachowiak m...@apple.com wrote: On Feb 8, 2013, at 2:33 PM, Darin Fisher da...@chromium.org wrote: I would recommend minimizing the re-architecture of WebCore as you are in the early stages of upstreaming. It seems like you already have a working port that you could simply upstream. You could then work with others in the community to introduce new concepts to WebCore with the full disclosure of code as an aide to the process. Another option might be to open source the entire thing as a branch somewhere. After the initial upstreaming or sharing of code is complete, you could then catalog all of the warts. The fact that isMainThread returns true when called on more than one thread would be one such wart. I can imagine a meta bug tracking all of these warts. This would make it a lot easier for others to understand the overall change in direction needed for WebKit to properly support the iOS port. That's approximately what we're planning to do. We are upstreaming incrementally, starting with simple pieces, and documenting issues. The bug that sparked this thread was a relatively change to isMainThread(), plus a function rename, and we are no longer asking for the function rename. It will likely be a dozen line patch touching a single mac/ios-specific file. We'd really like to fully upstream the simpler components like WTF (where the changes are all simple and targeted) even if we can't as easily do WebCore (where there may be more complex and controversial diffs). From what you've said, it sounds like this issue doesn't apply to WebKit2 on iOS. Perhaps we should focus on merging WebKit2 into trunk and delay having to worry about running WebCore on multiple interlocking threads. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] WebCore and interlocking threads
Context: https://bugs.webkit.org/show_bug.cgi?id=109071 Adam Barth said: It's not clear to me that running WebCore on multiple interlocked threads is a good idea. That seems like a pretty major change to WebCore's architecture. Is that something that's up for discussion? Darin Adler said: I agree that it’s not something I’d do if I was starting a project now. In the iOS context, it’s fantastic for discussion as a possibly multi-year major architecture change, but if we take a hard line on this, then we won’t have the iOS port in the tree for years, and I think it would be good if we do. iOS WebKit has worked this way for the entire history of iPhone, so it’s not a change that can be made easily. Darin Adler also said: I think where you and I may differ is on whether a good solution to the problem would be valuable to the WebKit project. Is there some way I convince you of the value of fitting an important existing port of WebKit into our tree in as clean as possible a way? I don't really know how to respond to this thread. I feel like I'm being offered the following choice: 1) Give up the ability to have technical input to how WebCore works and simply accept all the design choices made in the iOS fork, whether they be good choices or bad. 2) Keep the iOS port in an Apple-internal fork for a number of years. I feel like I'm being asked to make this choice in the context of a growing trend of unilateral action by Apple in this project. Given that trend, I don't see how I can choose option (1). As much as I would like the iOS port merged into trunk, I'm not willing to give up having a technical say in the project. Therefore, reluctantly, I'm forced to choose option (2). Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Merging the iOS port to svn.webkit.org (Re: WebCore and interlocking threads)
On Fri, Feb 8, 2013 at 2:45 PM, David Kilzer ddkil...@webkit.org wrote: On Feb 8, 2013, at 1:41 PM, Adam Barth aba...@webkit.org wrote: Context: https://bugs.webkit.org/show_bug.cgi?id=109071 Adam Barth said: It's not clear to me that running WebCore on multiple interlocked threads is a good idea. That seems like a pretty major change to WebCore's architecture. Is that something that's up for discussion? Darin Adler said: I agree that it’s not something I’d do if I was starting a project now. In the iOS context, it’s fantastic for discussion as a possibly multi-year major architecture change, but if we take a hard line on this, then we won’t have the iOS port in the tree for years, and I think it would be good if we do. iOS WebKit has worked this way for the entire history of iPhone, so it’s not a change that can be made easily. Darin Adler also said: I think where you and I may differ is on whether a good solution to the problem would be valuable to the WebKit project. Is there some way I convince you of the value of fitting an important existing port of WebKit into our tree in as clean as possible a way? I don't really know how to respond to this thread. I feel like I'm being offered the following choice: 1) Give up the ability to have technical input to how WebCore works and simply accept all the design choices made in the iOS fork, whether they be good choices or bad. 2) Keep the iOS port in an Apple-internal fork for a number of years. I feel like I'm being asked to make this choice in the context of a growing trend of unilateral action by Apple in this project. Given that trend, I don't see how I can choose option (1). As much as I would like the iOS port merged into trunk, I'm not willing to give up having a technical say in the project. Therefore, reluctantly, I'm forced to choose option (2). The iOS port does not require re-architecting WebCore. Bug 109071 was about coming up with a better name for a method that is primarily used in ASSERT()s in WebCore. Without changing the implementation of that method, debug builds of WebCore on iOS assert instantly since WebCore execution can happen on one of two threads. We can live with keeping the method name as isMainThread() and have already moved on to other things. The rest of WebCore is largely unchanged for iOS, other than the usual port-specific code you need for a port, which will be posted for review as we continue to merge. How do these multiple interlocked threads interact with code that uses thread-local storage? Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Merging the iOS port to svn.webkit.org (Re: WebCore and interlocking threads)
On Fri, Feb 8, 2013 at 4:07 PM, David Kilzer ddkil...@webkit.org wrote: On Feb 8, 2013, at 2:52 PM, Adam Barth aba...@webkit.org wrote: On Fri, Feb 8, 2013 at 2:45 PM, David Kilzer ddkil...@webkit.org wrote: The iOS port does not require re-architecting WebCore. Bug 109071 was about coming up with a better name for a method that is primarily used in ASSERT()s in WebCore. Without changing the implementation of that method, debug builds of WebCore on iOS assert instantly since WebCore execution can happen on one of two threads. We can live with keeping the method name as isMainThread() and have already moved on to other things. The rest of WebCore is largely unchanged for iOS, other than the usual port-specific code you need for a port, which will be posted for review as we continue to merge. How do these multiple interlocked threads interact with code that uses thread-local storage? The UI (main) thread and the web thread share the same thread-local storage. Those code changes are in 4 or 5 files in WTF. How does that work for code called by WebCore that doesn't use WTF's TLS abstractions? Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Merging the iOS port to svn.webkit.org (Re: WebCore and interlocking threads)
On Fri, Feb 8, 2013 at 4:29 PM, Pratik Solanki psola...@apple.com wrote: On Feb 8, 2013, at 4:14 PM, Adam Barth aba...@webkit.org wrote: On Fri, Feb 8, 2013 at 4:07 PM, David Kilzer ddkil...@webkit.org wrote: On Feb 8, 2013, at 2:52 PM, Adam Barth aba...@webkit.org wrote: On Fri, Feb 8, 2013 at 2:45 PM, David Kilzer ddkil...@webkit.org wrote: The iOS port does not require re-architecting WebCore. Bug 109071 was about coming up with a better name for a method that is primarily used in ASSERT()s in WebCore. Without changing the implementation of that method, debug builds of WebCore on iOS assert instantly since WebCore execution can happen on one of two threads. We can live with keeping the method name as isMainThread() and have already moved on to other things. The rest of WebCore is largely unchanged for iOS, other than the usual port-specific code you need for a port, which will be posted for review as we continue to merge. How do these multiple interlocked threads interact with code that uses thread-local storage? The UI (main) thread and the web thread share the same thread-local storage. Those code changes are in 4 or 5 files in WTF. How does that work for code called by WebCore that doesn't use WTF's TLS abstractions? Can you give an example? I've seen changes in Supplementable.h and WeakPtr.h (in WTF) that assert about the thread id. For those, we're adding PLATFORM(IOS) checks to check for both threads. Are there any others? One simple example is V8, which stores the current v8::Isolate in thread-local storage. However, the problem is certainly not limited to V8, nor is it even limited to the code we're using today. Running WebCore on multiple interlocked threads imposes restrictions on how all the code called by WebCore use TLS. Those restrictions might be worthwhile or they might not be worthwhile. Before adding these restrictions to WebCore, we should discuss them as a community and come to consensus about whether their benefits outweigh their costs. I don't think it's appropriate for Apple to impose these restrictions on WebCore unilaterally. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Merging the iOS port to svn.webkit.org (Re: WebCore and interlocking threads)
On Fri, Feb 8, 2013 at 4:56 PM, Maciej Stachowiak m...@apple.com wrote: On Feb 8, 2013, at 4:14 PM, Adam Barth aba...@webkit.org wrote: On Fri, Feb 8, 2013 at 4:07 PM, David Kilzer ddkil...@webkit.org wrote: On Feb 8, 2013, at 2:52 PM, Adam Barth aba...@webkit.org wrote: On Fri, Feb 8, 2013 at 2:45 PM, David Kilzer ddkil...@webkit.org wrote: The iOS port does not require re-architecting WebCore. Bug 109071 was about coming up with a better name for a method that is primarily used in ASSERT()s in WebCore. Without changing the implementation of that method, debug builds of WebCore on iOS assert instantly since WebCore execution can happen on one of two threads. We can live with keeping the method name as isMainThread() and have already moved on to other things. The rest of WebCore is largely unchanged for iOS, other than the usual port-specific code you need for a port, which will be posted for review as we continue to merge. How do these multiple interlocked threads interact with code that uses thread-local storage? The UI (main) thread and the web thread share the same thread-local storage. Those code changes are in 4 or 5 files in WTF. How does that work for code called by WebCore that doesn't use WTF's TLS abstractions? To clarify the overall iOS WebKit threading model: - Essentially all Web content processing happens on the Web thread instead of the main thread. This is approximately isomorphic to how Chromium puts Web content processing in a separate render process, or how WebKit2 puts web content processing into a Web Process. - Because this work was originally done in a hastier way and with less clear design, it does not do as good a job as Chromium or WebKit2 at sticking strictly to message passing. There are a tiny handful of pieces of WebCore code that get touched directly by the WebKit layer on the main thread. But this is the exception. We don't have a model where web content processing is broadly spread across multiple thread. We just have a few regrettable (but tricky to fix) exceptions to a message-passing model that processes Web content on a background thread. I hope this context helps you understand people's answers, and why we believe there is very little impact on WebCore from this change. Why should the entire WebKit project pay the price for this hasty design in the iOS fork? It sounds like this issue is limited to WebKit1. Perhaps the best path forward is to upstream the iOS version of WebKit2 and let the mistakes of WebKit1 on iOS lay fallow. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Adding 'X-Content-Type-Options: nosniff' support for scripts.
We should check whether IE still have that behavior (i.e., in the latest version of IE). I remember them running into some compatibility problems with that aspect of nosniff, and I'm not sure if they resolved those issue via evangelism or by adopting our behavior. Adam On Wed, Feb 6, 2013 at 1:33 AM, Mike West mk...@chromium.org wrote: Continuing my trend of digging up old threads, I'd like to implement support for 'X-Content-Type-Options: nosniff' when processing script, as discussed way back in 2011: https://lists.webkit.org/pipermail/webkit-dev/2011-November/018557.html. This should be a pretty small patch[1], but because support might require work outside WebKit, I'll implement it behind an ENABLE_NOSNIFF flag[2]. Thanks! [1]: https://bugs.webkit.org/show_bug.cgi?id=71851 [2]: https://bugs.webkit.org/show_bug.cgi?id=109029 -mike ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] SerializedScriptValue: signed vs unsigned char
On Wed, Feb 6, 2013 at 4:59 PM, Alec Flett alecfl...@chromium.org wrote: On Wed, Feb 6, 2013 at 4:48 PM, Maciej Stachowiak m...@apple.com wrote: I think we should continue to use uint8_t instead of char as the primary way to represent a raw byte in WebKit. First, it's good to distinguish raw data from C strings at the type system level, and second, the unpredictable signedness of char is actively bad for byte-oriented processing. Another library making a different choice doesn't overcome these reasons. To be fair, there hasn't been a convention in WebKit at all. uint8_t was chosen for SerializedScriptValue roughly two months ago, with specific IndexedDB support in mind: https://bugs.webkit.org/show_bug.cgi?id=104354 - this usage is not widespread, and in fact the only consumer of this type is IndexedDB. If there's particular libraries we want to use which have different conventions, the adaptation should be done at the level of interfacing the library. Changing WebKit's conventiones because of one optional dependency does not make sense to me. Maybe more simply: Vectoruint8_t was chosen very recently to replace String, in support of cleaning up IndexedDB code. IndexedDB would like to use Vectorchar now for further cleanup. Would you feel the same if we were switching from String to Vectorchar? Yeah, We use char all over WebCore to represent a byte, including in SharedBuffer. We should use for SerializedScriptValue for consistency. If we think that uint8_t is better than char to represent bytes, then we should make that change globally in WebCore separately. Adam On Wed, Feb 6, 2013 at 4:48 PM, Maciej Stachowiak m...@apple.com wrote: I think we should continue to use uint8_t instead of char as the primary way to represent a raw byte in WebKit. First, it's good to distinguish raw data from C strings at the type system level, and second, the unpredictable signedness of char is actively bad for byte-oriented processing. Another library making a different choice doesn't overcome these reasons. If there's particular libraries we want to use which have different conventions, the adaptation should be done at the level of interfacing the library. Changing WebKit's conventiones because of one optional dependency does not make sense to me. Regards, Maciej On Feb 6, 2013, at 4:35 PM, Alec Flett alecfl...@chromium.org wrote: ok, so something else has come up: SharedBuffer. SharedBuffer has an adoptVector method that allows you to adopt Vectorchar... some of the stuff I'm using that interacts with LevelDB is also dealing with SharedBuffer, hence I've had to do some nasty casting from Vectoruint8_t to Vectorchar to allow me to call SharedBuffer.adoptVector() And again, we could tweak SharedBuffer to accept Vectorunsigned char but now we have two subsystems (LevelDB, and SharedBuffer) that seem to prefer char as raw data. Personally outside of WebKit I tend to see more char* as the common denominator for raw bytes. Further, there are no subsystems that actually depend on SerializedScriptValue using uint8_t - it was just what we decided to use when (ironically) we were hooking up IndexedDB to JSC, just a month or so ago. So far Benjamin objected, and then seems to have rescinded. Glenn, do you depend on SerializedScriptValue's current method signatures? Alec On Mon, Feb 4, 2013 at 5:14 PM, Benjamin Poulain benja...@webkit.org wrote: On Mon, Feb 4, 2013 at 4:54 PM, Alec Flett alecfl...@chromium.org wrote: Well, nobody is explicitly using LChar with SerializedScriptValue (maybe it should, maybe that's another issue) but I guess this is why I'm asking - I'm happy to just deal with this in IDB with some ugly reinterpret_casts here and there (ok maybe not happy, but satisfied enough) if folks prefer that. I don't personally find uint8_t to be any more intuitive than char, but it sounds like some do. Nevermind... Well, since you never use character types and only raw data, just ignore my comment. As far as I know, it is already common to use signed char for raw data (in the network stack for example). Benjamin On Wed, Feb 6, 2013 at 4:06 PM, Alec Flett alecfl...@google.com wrote: ok, so something else has come up: SharedBuffer. SharedBuffer has an adoptVector method that allows you to adopt Vectorchar... some of the stuff I'm using that interacts with LevelDB is also dealing with SharedBuffer, hence I've had to do some nasty casting from Vectoruint8_t to Vectorchar to allow me to call SharedBuffer.adoptVector() And again, we could tweak SharedBuffer to accept Vectorunsigned char but now we have two subsystems (LevelDB, and SharedBuffer) that seem to prefer char as raw data. Personally outside of WebKit I tend to see more char* as the common denominator for raw bytes. Further, there are no subsystems that actually depend on SerializedScriptValue using uint8_t - it was just what we decided to use when
Re: [webkit-dev] Gated trunk, experiences from OpenStack
Do you know how they got rid of flakiness in their tests? We've spent a bunch of effort fixing flaky tests (and in marking the remaining flaky tests as flaky), but there's still a long tail of flakiness. I wonder if that sort of thing might be different for OpenStack if they have a different approach to testing than we do. Adam On Mon, Feb 4, 2013 at 5:14 PM, Tim Ansell mit...@mithis.com wrote: Hey guys, Last week a number of the team here at Google Sydney, including myself attended Linux.conf.au 2013 conference. The conference was a blast and the hot topic this year was OpenStack, an Open Source Cloud layer. The OpenStack project has grown from being a small project to having over 500 active committers and continues to grow at a rapid pace. Both the Continuous Integration Miniconf (http://lca2013.linux.org.au/schedule/30102/view_talk?day=monday) and main conference included talks from OpenStack leaders about how they have tried to handle this growth and I think we can learn from their successes and failures. All of the OpenStack's infrastructure is documented in the following talks http://openstack-ci.github.com/publications/ I pulled the following stats to see how comparable the projects are; OpenStack; (http://openstack-ci.github.com/publications/lca2013-ci/index.html#(3)) Over 500 Active Technical Contributors As many as 200 trunk changes an hour 18 (integrated) projects (and growing) I tried looking these up in WebKit and got the following; ~200 active contributors As many as ~12 trunk changes an hour 1 project, but 7 target platforms One of the most interesting parts of OpenStack was having a gated trunk. From their talk; Before each change to the OpenStack projects is merged into the main tree, unit and integration tests are run on the change, and only if they pass, is the change merged. We call this gating. There is a lot of debate about the value of a gated trunk on the internet; which I'm not going to repeat here. OpenStack's experience has been that it preserves the following properties; http://openstack-ci.github.com/publications/lca2013-ci/index.html#(9) Ensures Code Quality Protects developers Devs always start from working code Protects tree Bad code doesn't land Egalitarian Process is the same for everyone Process is transparent Process is automated These are all things that came up in Eric's WebKit wishes email specially the parts about having an always green tree. The egalitarian nature of the system also helps with trusting people as you *know* they can not break the tree. This system is similar to our commit queue, however nobody has privileges to bypass the queue. OpenStack has 18 projects which are all tightly integrated, for example a change in the API in one project could break another project, for this reason they gate changes on tests runs from all projects before allowing a commit to land to any of them. While WebKit is only a single project, the process of requiring multiple jobs to be green is similar to WebKit needing to support multiple platforms. They do point out that when this system is set up, the system has to be ultra repeatable and reliable; Once everything is automated, the projects stops if the automation does - http://openstack-ci.github.com/publications/lca2013-ci/index.html#(8) To allow this to happen, OpenStack has managed to eliminated all flaky tests in their suite. WebKit is not at this stage and still has a large number tests which are both failing and/or flaky. Luckily, WebKit has much better infrastructure for dealing with and tracking them down. Other things they have done to try and make this process work are; Like WebKit, every patch is required to have code review before being submitted. OpenStack requires two positive reviews before allowing a commit to be submitted, rather than the single one that WebKit needs. Like WebKit, OpenStack has an early warning system which runs all tests as soon as a patch is submitted. The complete OpenStack test suite takes around ~1 hour to run, but as they have more than 1 event per hour their landing system needs pipelining. They have developed a system called Zuul to make this happen. Before they had this pipeline process, committing was taking many hours to land. You can see their currently running system at http://zuul.openstack.org/ and find out more about Zuul at the following locations; Zuul: a Pipelining Trunk Gating System http://amo-probos.org/post/14 http://mirror.linux.org.au/linux.conf.au/2013/ogv/OpenStack_Zuul.ogv I guess this is something we should discuss further. Tim 'mithro' Ansell ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org
Re: [webkit-dev] Throwing SECURITY_ERR on cross-origin window.location property accesses (revisited).
Given the consistency of other user agents, this looks like the right thing to do for the web. We should try it in Canary to see if it's compatible with the web. Adam On Feb 4, 2013 5:05 AM, Mike West mk...@chromium.org wrote: Way back in the depths of 2010, Mihai suggested that we begin to throw exceptions when accessing Location properties across origins[1]. Currently, we log a Unsafe JavaScript attempt to access... message to the console, and return null. Hit http://talkingpointsmemo.com/ with the console open for an example of how this can get out of hand. At the moment, IE, Firefox, and Opera all throw an exception here, and the spec agrees with this behavior[2]. Given this bifurcation, developers are generally forced to have two paths for code that touches Location: one for WebKit, one for everyone else. They're generally not able to avoid the error message (though `ancestorOrigins` should now address some of the use case), which is a bit annoying. Anecdotally, I see this message quite often when browsing around with the console open in Canary, and practically never when doing the same in Firefox. This is something I'd like to address. I've resurrected the JSC side of Mihai's old patch[3], where this was discussed some more. Before getting too far along with that, however: Maciej, Sam, others, WDYT? [1]: https://lists.webkit.org/pipermail/webkit-dev/2010-August/013880.html [2]: http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#security-location [3]: https://bugs.webkit.org/show_bug.cgi?id=43891 -mike ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebKit Wishes
On Sun, Feb 3, 2013 at 11:34 AM, noam.rosent...@nokia.com wrote: On 2/3/13 7:46 PM, ext Maciej Stachowiak m...@apple.com wrote: If you're asking about phasing it out entirely, we don't have any immediate plans to deprecate or remove the WebKit1 mac API. There are quite a few Apple and third-party apps using it, and WebKit2 is not even public API on Mac OS X currently. As for implementing aspects of the WebKit1 API in a less efficient but less WebCore-intrusive way, we could probably start doing that now, on a case-by-case basis. Do you have any specific constraints you're concerned about? Maybe the problem is less about the WK1 API layer and more about WebCore/platform. In many other projects, there is a common pattern of platform adaptation layer, where there is a clear semi-public and stable interface exposed by the middleware, which allows platform adaptations to occur with less intrusive dependencies. WebKit doesn't really have that notion, making it impossible to port webkit without either participating in trunk or forking. Platform adaptations bring a lot of benefit since they allow flexibility, but they come with the cost of not being able to always achieve the most straightforward vertical integration. Accelerated compositing is, in my view, a successful example of a platform adaptation layer. GraphicsContext is perhaps less successful. A successful platform adaptation is measured by how much access is needed to the underlying platform-specific implementation. For GraphicsContext, for example, we call platformContext() inside rendering code way too much. I suggest that a good (but difficult) starting point to separating WebCore and the platform adaptation is to remove all or most calls to GraphicsContext::platformContext(), adding the appropriate functionality as public interface to GraphicsContext, making the rendering code truly platform agnostic, and perhaps later externalized as a true platform adaptation interface. But I would let others say whether this is feasible/desirable :) Yeah, another example is ResourceHandle, which is theoretically a platform-agnostic abstraction but in reality is heavily constrained by the capabilities of CFNetwork. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebKit Wishes
On Sun, Feb 3, 2013 at 11:46 AM, Adam Barth aba...@webkit.org wrote: On Sun, Feb 3, 2013 at 11:34 AM, noam.rosent...@nokia.com wrote: On 2/3/13 7:46 PM, ext Maciej Stachowiak m...@apple.com wrote: If you're asking about phasing it out entirely, we don't have any immediate plans to deprecate or remove the WebKit1 mac API. There are quite a few Apple and third-party apps using it, and WebKit2 is not even public API on Mac OS X currently. As for implementing aspects of the WebKit1 API in a less efficient but less WebCore-intrusive way, we could probably start doing that now, on a case-by-case basis. Do you have any specific constraints you're concerned about? Maybe the problem is less about the WK1 API layer and more about WebCore/platform. In many other projects, there is a common pattern of platform adaptation layer, where there is a clear semi-public and stable interface exposed by the middleware, which allows platform adaptations to occur with less intrusive dependencies. WebKit doesn't really have that notion, making it impossible to port webkit without either participating in trunk or forking. Platform adaptations bring a lot of benefit since they allow flexibility, but they come with the cost of not being able to always achieve the most straightforward vertical integration. Accelerated compositing is, in my view, a successful example of a platform adaptation layer. GraphicsContext is perhaps less successful. A successful platform adaptation is measured by how much access is needed to the underlying platform-specific implementation. For GraphicsContext, for example, we call platformContext() inside rendering code way too much. I suggest that a good (but difficult) starting point to separating WebCore and the platform adaptation is to remove all or most calls to GraphicsContext::platformContext(), adding the appropriate functionality as public interface to GraphicsContext, making the rendering code truly platform agnostic, and perhaps later externalized as a true platform adaptation interface. But I would let others say whether this is feasible/desirable :) Yeah, another example is ResourceHandle, which is theoretically a platform-agnostic abstraction but in reality is heavily constrained by the capabilities of CFNetwork. To be precise, the following WebKit API on Mac OS X is one of the root causes of these restrictions: webView:resource:willSendRequest:redirectResponse:fromDataSource This API imposes the requirement that WebCore::ResourceRequest can round-trip through NSURLRequest. That means we're unable to improve WebCore::ResourceRequest beyond the limitations of NSURLRequest. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Common build system (was Re: WebKit Wishes)
Ninja has extremely fast incremental builds and can be generated by GYP. Here are some stats from a year ago: https://plus.google.com/101038813433650812235/posts/irc26fhRtPC Ninja has gotten even faster since then. If you're interested in trying it out, you can play around with incremental builds of the Chromium port on Mac or Linux. Adam On Fri, Feb 1, 2013 at 4:58 PM, Balazs Kelemen kbal...@webkit.org wrote: I think one important aspect of build systems was not considered yet int this conversation: speed. The time an incremental build takes has a great effect on developer productivity. I don't think any of the meta-build systems we use does a great job here - although I only have experiences with qmake, cmake and autotools (and I don't have an SSD that could help somewhat). The technic I found useful here is to avoid calling build-webkit always and instead just rebuild the subproject you have edited, so I think it is important to have a build system that supports it. Let me share my experiences here. With qmake nowadays this work perfectly. The developer build is producing a shared library for every subdir (WTF, JavaScriptCore, WebCore, WebKit2), which means you only need to call make in the specific subdirectory (i.e. if I only touched WebKit2 files I do make -C WebKitBuild/Release/Source/WebKit2 which is pretty quick). Still WebCore is so big that make is quite slowly find out the files you actually edited and need to be rebuilt. What could help here is to devide WebCore into smaller parts, like the ongoing work of extracting Platform. Maybe the next logical candidate could be svg (I don't have real knowledge about how feasible it is). Note that I don't come up with qmake because I would like to recommend it as the one and only build system (in fact it has a ridiculously inconvenient syntax, and a lot of bugs), just as an example. With Cmake fast incremental rebuilds are also possible, maybe in a bit more complicated way. When working with the EFL port I found a quick rule for WebKit2 in the generated makefile. Although the makefiles are usually call back to Cmake, and make is not faster than build-webkit, if you use the special fast target, which is something like eflWebKit/fast (i.e. make -C WebKitBuild/Release/Source/WebKit2 eflWebKit/fast), it will not check dependencies but just rebuild the files that have changed. I did not find a similar thing for WebCore, I guess because it is not built as a shared library. What I dislike in Cmake is that I am disappointed by how slow a normal incremental build with it (i.e. build-webkit). qmake is not faster at all, but it generate plain makefiles that typically no call back to qmake if not specified explicitly to do so, and directly calling make is faster, yet it can handle most of the non-trivial changes, for example editing a generator file. I don't know gyp, so I wonder about how would it do in this comparison (but I guess it generates simple makefiles as well, so it's similar than qmake in this manner.) I hope I added something to this conversation that is worth to consider with my late nightly brain dump. -kbalazs ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev On Fri, Feb 1, 2013 at 4:58 PM, Balazs Kelemen kbal...@webkit.org wrote: I think one important aspect of build systems was not considered yet int this conversation: speed. The time an incremental build takes has a great effect on developer productivity. I don't think any of the meta-build systems we use does a great job here - although I only have experiences with qmake, cmake and autotools (and I don't have an SSD that could help somewhat). The technic I found useful here is to avoid calling build-webkit always and instead just rebuild the subproject you have edited, so I think it is important to have a build system that supports it. Let me share my experiences here. With qmake nowadays this work perfectly. The developer build is producing a shared library for every subdir (WTF, JavaScriptCore, WebCore, WebKit2), which means you only need to call make in the specific subdirectory (i.e. if I only touched WebKit2 files I do make -C WebKitBuild/Release/Source/WebKit2 which is pretty quick). Still WebCore is so big that make is quite slowly find out the files you actually edited and need to be rebuilt. What could help here is to devide WebCore into smaller parts, like the ongoing work of extracting Platform. Maybe the next logical candidate could be svg (I don't have real knowledge about how feasible it is). Note that I don't come up with qmake because I would like to recommend it as the one and only build system (in fact it has a ridiculously inconvenient syntax, and a lot of bugs), just as an example. With Cmake fast incremental rebuilds are also possible, maybe in a bit more complicated way. When
Re: [webkit-dev] Common build system (was Re: WebKit Wishes)
On Thu, Jan 31, 2013 at 12:25 AM, Mark Rowe mr...@apple.com wrote: On 2013-01-30, at 17:14, Dirk Pranke dpra...@chromium.org wrote: On Wed, Jan 30, 2013 at 4:15 PM, Maciej Stachowiak m...@apple.com wrote: On Jan 30, 2013, at 3:24 PM, Dirk Pranke dpra...@chromium.org wrote: On Wed, Jan 30, 2013 at 1:50 PM, Filip Pizlo fpi...@apple.com wrote: Thanks for sharing this. On Jan 30, 2013, at 1:28 PM, Eric Seidel e...@webkit.org wrote: I wish we only had one build system (it were easy to add/remove/move files). I believe changes like http://trac.webkit.org/changeset/74849 are an unhealthy sign for the project. Adam is not the only person who has chosen to empty files instead of removing them. The pain of updating 8 build system is so great, we jump through hoops to avoid it. Which means it took us months to move JavaScriptCore/wtf to WTF, and will take us years to kill WebCore/platform. +1 This is a hard problem. It is a problem worth solving. Do you have more thoughts on this, particularly since you know quite well how both Xcode and gyp work? I suspect this is one of those things that it would be hard to achieve consensus on since there are so many stakeholders. But it may be fruitful to have a what if discussion about what this might look like. I think we can solve this problem if we agree that we want to. I think we haven't in the past mostly because we couldn't reach a consensus that it was worth solving enough to really try. I would love to see this fixed and would be glad to work on it. I think we should at least pursue this far enough to fully understand what our options are and what the costs and tradeoffs might be; does anyone disagree, and is anyone else willing to help pitch in? I think there are several possible ways we could solve this. One would be to switch to a common meta-build system. My understanding is that Apple's internal production build processes impose certain constraints here that I don't fully understand, but I know we've discussed the possibility of checking in generated project files as a workaround. Maybe there are other options as well to those constraints? I would love to discuss this further w/ someone from Apple ... It's far simplest for us if: (a) There is an Xcode project (or a Makefile) that builds the Mac port checked in to source control. (b) The generated project invokes only tools that are part of the default Mac OS X install. It may not be completely impossible to violate these requirements but it will require a lot of bureaucracy. (Also, just to get this out of the way, I don't think gyp needs to be the solution). Another alternative would be to write a script that did support at least the common use cases (add/move/delete files). There have been attempts in the past, but they have foundered on at least some perceived skepticism over how well this would work w/ XCode. That said, I don't think we've really pushed this to see. At some point this script might turn into a meta-meta-build system, which might be silly but also be the shortest path to the finish line. I suggest if there is interest in this we can start a new thread to discuss further ... My preference would be to use a common meta-build system with a comfortably human-readable and human-editable syntax, and checked in generated project files for those ports that need them. I think a key to making this work is to get Chromium and the Apple Mac port onto a common build system, which will probably require both Google and Apple ponying up at least one person to work on this project for a reasonable period of time. I think the plausible meta-build-systems to use would be CMake and Gyp, but in both cases it may be necessary to modify them to work well for everyone. Premake might also be an option, though I wouldn't necessarily vote for it. Gyp's syntax is ... awkward ... but apart from that might just work for checking in generated apple mac xcode projects. We should try it (shouldn't be too hard, since abarth had it working at one point). I think Eric and/or Adam had JavaScriptCore building with gyp at one point. I’m not sure if they ever got to the other projects. We had JavaScriptCore and WebCore working. (We also had JavaScriptGlue, but that doesn't exist anymore.) I don't remember if we had WebKit/mac working. (WebKit2 didn't exist at the time.) I would consider changing or improving gyp's syntax to be on the table if it was needed to reach the goal. For what it’s worth, I also find the gyp syntax to be unpleasant. It feels as though it was optimized for being processed by a machine rather than for being written and maintained by humans. Unlike xcodeproj files. :) CMake was originally considered a non-starter for chromium since the XCode and VS projects it produced didn't look or feel like native projects. However, we've since switched to ninja for most things so I'm less sure how
Re: [webkit-dev] Breaking other ports
On Tue, Jan 29, 2013 at 11:58 PM, Maciej Stachowiak m...@apple.com wrote: I agree that the regression should be fixed. But before we discuss that... I am puzzled by the apparent stance of Alexey must immediately fix this himself or we must revert immediately. That's not the standard we have applied in the past to changes that appear generally correct but end up breaking the UI of a client of a specific port. No one said Alexey must immediately fix this himself or we must revert immediately. Here's what I said: If you cannot address the issue immediately, please let me know so that I can take further action. Further actions might include me fixing the issue myself. I hadn't figured that out yet. I just needed an answer quickly so that I could make sure we resolved this issue in the appropriate time frame. To me this example seems pretty parallel to the situation https://bugs.webkit.org/show_bug.cgi?id=108214. Can anyone explain to me why 108214 is being approached so much more aggressively than 52988. Honestly, it's because you've changed the ground rules for contributing to WebKit such that it's now ok to break other ports in some situations. When Alexey wrote: The fact that you chose to do an obvious hack instead does not make it others' responsibility to support it. I interpreted that to mean he felt justified in extending those ground rules to parts of WebCore that don't live up to his personal engineering standards. I wanted to be clear that I view that as unacceptable. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Breaking other ports
I understand that the new rules of the road for WebKit2 are that contributors are allowed to break non-Apple ports. However, those new norms do not extend to WebCore. In http://trac.webkit.org/changeset/138962, Alexey broke form resubmission confirmation in the Chromium port. In https://bugs.webkit.org/show_bug.cgi?id=108214, he is refusing to fix the regression. I don't view that as acceptable behavior from a member of the WebKit community. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Remove webkitDashArray attribute from CanvasRenderingContext2d
Our general approach to deprecating features is outlined on this wiki page: http://trac.webkit.org/wiki/DeprecatingFeatures It sounds like you're advocating the cold turkey approach here with a clear path forward for developers. Adam On Tue, Jan 29, 2013 at 5:46 PM, Dirk Schulze dschu...@adobe.com wrote: Hi WebKit folks, I would like to know if we can remove the following API's in the CanvasRenderingContext2d interface: webkitDashArray webkitLineDashOffset Both were implemented 16 months ago and replaced by the following standardized, unprefixed operations and attributes 5 months ago: setLineDash getLineDash lineDashOffset Note that the webkit prefixed attributes were just implemented in JavaScriptCore, no support for V8. Some of the main reason for supporting these attributes 16 months ago were: - Firefox supported them - PDF.js needed them for draw PDFs. PDF.js checks for the existence of the standardized operations and attributes now and uses them if supported. Would it be possible to clean up the code a bit more and remove the prefixed attributes? Greetings, Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebIDL implementation plans (was: Re: Multiple inheritance in the DOM)
On Fri, Jan 25, 2013 at 8:11 AM, Dirk Schulze dschu...@adobe.com wrote:
This is a followup to the multiple inheritance discussion.
Adam, I checked the IDL files on SVG2 [1]. The interfaces for SVG2 do not
have multiple inheritances of interfaces that are exposed to bindings. But
SVG2 still uses the implements statement for [NoInterfaceObject]
interfaces [2]. This should at least address your initial concern not to
inherit from different interfaces exposed to bindings.
However, during a discussion on IRC I got the impression that we do not plan
to support the implements statement because it can do weird things. If
this is right, I would like to understand why this is the case?
We don't intend to support all the possible things that you can do
with implements. With implements, you can define arbitrarily
complicated relationships between interfaces, including some that can
be implemented only with a QueryInterface-like mechanism. We're not
going to implement QueryInterface, so we're not going to implement any
specifications that require it.
Have the concerns been submitted to the editor and the WG working on the
WebIDL specification?
I haven't submitted my concerns. There's nothing particularly wrong
with the WebIDL language, just like there's nothing particularly wrong
with English just because you can use it to write a terrible poem.
More and more specifications describe interfaces by using WebIDL, including
HTML5, Canvas, SVG2, Filter Effects and CSS Masking. If there are general
concerns on WebIDL, they should be addressed on the spec before leaving CR
state.
I don't have any concerns with the WebIDL language. The WebIDL
language is just a mechanism for writing precise specifications.
Not implementing WebIDL could not only block this specification in
particular, but also all other specs relying on it.
That's nonsense. Just because we don't implement some crazy corner
case of WebIDL that doesn't mean that we're unable to implement *all*
specs that reply upon it. For example, HTML and DOM use WebIDL and
we're able to implement them just fine.
Or maybe worst, it gets a recommendation and we do not follow web standards
anymore. It would be great to hear a clarification. Maybe it is just a
misunderstanding on my site.
There's no experiment that you can run using web content to detect
whether we implement WebIDL. All you can detect is whether we
implement particular specifications that use WebIDL. We can just
simply not implement the specifications that require COM-like
implementations and we can continue to lead a happy life.
Adam
On Jul 25, 2012, at 9:13 PM, Dirk Schulze dschu...@adobe.com wrote:
On Jul 25, 2012, at 3:50 PM, Adam Barth wrote:
On Wed, Jul 25, 2012 at 3:44 PM, Dirk Schulze dschu...@adobe.com wrote:
On Jul 25, 2012, at 2:33 PM, Adam Barth wrote:
Eric Seidel points out that SVG uses multiple inheritance in its DOM
interfaces. However, the situation there is a bit different.
Although SVGSVGElement implements SVGLocatable, there aren't any
interfaces with methods that return SVGLocatable, which means we don't
need to implement toJS(SVGLocatable*).
SVG 2 will use WebIDL. Therefore we also reorganize our inheritance
behavior. Cameron, editor of WebIDL and SVG WG member, will update SVG 2
ED soon.
Do you anticipate adding properties or functions that return
interfaces like SVGLocatable?
Here is a Wiki what we plan to do:
http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/IDL_interface_reorganization
It might not reflect all changes that we discussed during the SVG WG meeting
today.
Greetings,
Dirk
Adam
He also points out that Node inherits from EventTarget, which already
contains a virtual interfaceName() function similar to that used by
Event. That pushes us further towards using a common DOMInterface
base class because introducing Region::interfaceName would mean that
Element would see both EventTarget::interfaceName and
Region::interfaceName.
Adam
On Wed, Jul 25, 2012 at 2:00 PM, Adam Barth aba...@webkit.org wrote:
The CSS Regions specification [1] defines a CSSOM interface named
Region, which can be mixed into interfaces for other objets that can
be CSS regions. That means that Region introduces a form of multiple
inheritance into the DOM. For example, Element implements Region but
Node does not implement Region.
There's a patch up for review that implements Region using C++
multiple inheritance [2]:
- class Element : public ContainerNode {
+ class Element : public ContainerNode, public CSSRegion {
One difficulty in implementing this feature how to determine the
correct JavaScript wrapper return for a given Region object.
Specifically, toJS(Region*) needs to return a JavaScript wrapper for
an Element if the Region pointer actually points to an Element
instance.
We've faced a similar problem elsewhere in the DOM when implementing
normal single inheritance. For example
Re: [webkit-dev] WebIDL implementation plans (was: Re: Multiple inheritance in the DOM)
On Fri, Jan 25, 2013 at 11:28 AM, Glenn Adams gl...@skynav.com wrote:
On Fri, Jan 25, 2013 at 10:14 AM, Adam Barth aba...@webkit.org wrote:
There's no experiment that you can run using web content to detect
whether we implement WebIDL. All you can detect is whether we
implement particular specifications that use WebIDL. We can just
simply not implement the specifications that require COM-like
implementations and we can continue to lead a happy life.
Speaking of implementing WebIDL (in the context of a spec that normatively
requires its support, e.g., CSSOM), what is your position on whether WK
will/should support the following? In the test at [1], neither of these are
currently supported, or at least don't yield expected results.
WebIDL 4.4.1 [2] states:
The interface object for a given non-callback interface is a function
object.
WebIDL 4.4.3 [3] states:
If the [NoInterfaceObject] extended attribute was not specified on the
interface, then the interface prototype object must also have a property
named “constructor” with attributes { [[Writable]]:true, [[Enumerable]]:
false, [[Configurable]]: true } whose value is a reference to the interface
object for the interface.
I don't have a strong opinion on those topics. I'm happy to review
patches in this area.
Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebIDL implementation plans (was: Re: Multiple inheritance in the DOM)
On Fri, Jan 25, 2013 at 2:08 PM, Dirk Schulze dschu...@adobe.com wrote: On Jan 25, 2013, at 9:14 AM, Adam Barth aba...@webkit.org wrote: On Fri, Jan 25, 2013 at 8:11 AM, Dirk Schulze dschu...@adobe.com wrote: This is a followup to the multiple inheritance discussion. Adam, I checked the IDL files on SVG2 [1]. The interfaces for SVG2 do not have multiple inheritances of interfaces that are exposed to bindings. But SVG2 still uses the implements statement for [NoInterfaceObject] interfaces [2]. This should at least address your initial concern not to inherit from different interfaces exposed to bindings. However, during a discussion on IRC I got the impression that we do not plan to support the implements statement because it can do weird things. If this is right, I would like to understand why this is the case? We don't intend to support all the possible things that you can do with implements. With implements, you can define arbitrarily complicated relationships between interfaces, including some that can be implemented only with a QueryInterface-like mechanism. We're not going to implement QueryInterface, so we're not going to implement any specifications that require it. This sounds that you consider having implements in our WebIDL interpreter, or at least would not block adding this per se. This was my concern in the first place, since this is already in use in a lot of specifications (just with [NoInterfaceObject] as far as I saw). WebKit doesn't have an WebIDL interpretor. We have a WebKitIDL compiler. If you spec something that requires a QueryInterface-like mechanism in the implementation, we will not implement it regardless of what language you write the specification in. It's a conscious design decision not to implement a COM-like (or XPCOM-like) system. Have the concerns been submitted to the editor and the WG working on the WebIDL specification? I haven't submitted my concerns. There's nothing particularly wrong with the WebIDL language, just like there's nothing particularly wrong with English just because you can use it to write a terrible poem. Well, it seems to be a bit different. Your poem would still be valid as long as it follows the grammar and can still be read, even if it does not make sense to you. You suggest not supporting everything from WebIDL, which means not accepting the full specified grammar. I think this is a concern where you would like to see limitations to the current grammar and which should be discussed. In this analogy, WebKit is like a collection of poems. We can choose not to include a terrible poem in our collection without needing to form a judgement about the language in which the poem was written. More and more specifications describe interfaces by using WebIDL, including HTML5, Canvas, SVG2, Filter Effects and CSS Masking. If there are general concerns on WebIDL, they should be addressed on the spec before leaving CR state. I don't have any concerns with the WebIDL language. The WebIDL language is just a mechanism for writing precise specifications. Not implementing WebIDL could not only block this specification in particular, but also all other specs relying on it. That's nonsense. Just because we don't implement some crazy corner case of WebIDL that doesn't mean that we're unable to implement *all* specs that reply upon it. For example, HTML and DOM use WebIDL and we're able to implement them just fine. You suggest not implementing some corner cases. And as you say, we won't be able to support specifications relying on these corner cases. It rather seems you agree with my statement, even if it does not block former named specifications yet. You're welcome to write whatever specifications you like. I'm just hoping to save you the effort by telling you that we're not going to implement a feature that requires us to build COM. I am not questioning your arguments to not support all corner cases of WebIDL. I am asking for an open discussion about particular cases on the relevant mailing lists (public-webapps for WebIDL) to address these concerns in the specification before leaving CR. I have no concerns with WebIDL. I have concerns with specifications that require an implementation of QueryInterface regardless of whether they're written in WebIDL or in English. Adam On Jul 25, 2012, at 9:13 PM, Dirk Schulze dschu...@adobe.com wrote: On Jul 25, 2012, at 3:50 PM, Adam Barth wrote: On Wed, Jul 25, 2012 at 3:44 PM, Dirk Schulze dschu...@adobe.com wrote: On Jul 25, 2012, at 2:33 PM, Adam Barth wrote: Eric Seidel points out that SVG uses multiple inheritance in its DOM interfaces. However, the situation there is a bit different. Although SVGSVGElement implements SVGLocatable, there aren't any interfaces with methods that return SVGLocatable, which means we don't need to implement toJS(SVGLocatable*). SVG 2 will use WebIDL. Therefore we also reorganize
Re: [webkit-dev] WebIDL implementation plans (was: Re: Multiple inheritance in the DOM)
On Fri, Jan 25, 2013 at 8:59 PM, Elliott Sprehn espr...@chromium.org wrote: On Fri, Jan 25, 2013 at 11:32 PM, Dirk Schulze dschu...@adobe.com wrote: ... The problem is that SVGFitToViewBox and SVGZoomAndPan of the example above are implemented by a lot of other interfaces as well. Supplemental is just supposed to be set once per interface. That is why Supplemental doesn't work for SVG. The alternative would be to implement the attributes and operations of SVGFitToViewBox and SVGZoomAndPan into every class that implements them. This would be a lot of code copies. And these are not the only interfaces that would need to be merged. That's an issue of being DRY though, which we can certainly solve in WebKit. I don't think Adam has an issue with extending webkit IDL to help with that, or at least I'd hope not. Nope. :) We could probably use multiple inheritance in C++ and copy/paste the idl defs, or add some new IDL feature for it. We already have support for that in WebKitIDL (albeit using a different syntax). See, for example, http://trac.webkit.org/browser/trunk/Source/WebCore/svg/SVGGElement.idl The problem arises if there's an API somewhere that returns, e.g., SVGTransformable. When implementing such an API, we wouldn't know which concrete type we actually have and would need to use something like QueryInterface to find out. Fortunately, no such APIs exist currently. I should also say that we've caved slightly on this stance for interaces like Event that have many subclasses and are often returned by APIs. The way we handle this case is by introducing a virtual function called interfaceName that returns the name of the most-derived interface that the concrete object supports: http://trac.webkit.org/browser/trunk/Source/WebCore/dom/Event.h#L121 At runtime, we use that information to static_cast the C++ object appropriately. It's not as general as QueryInterface, and I'm not sure how far we want to extend that mechanism given that it's relatively slow. Certainly we wouldn't want to introduce a universal base class (a la IUnknown or nsISupports) as required in COM and XPCOM, respectively. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Commit queue stopped working
Thanks for the note. We seem to have a temp file leak in run-webkit-tests. I'm rebuilding the machines now. Adam On Thu, Jan 24, 2013 at 10:03 AM, Dumez, Christophe christophe.du...@intel.com wrote: Hi, It appears the commit queue stopped working due to lack of disk space: https://bugs.webkit.org/show_bug.cgi?id=107680#c8 Failed to run ['/mnt/git/webkit-commit-queue/Tools/Scripts/webkit-patch', '--status-host=queues.webkit.org', '--bot-id=gce-cq-04', 'apply-attachment', '--no-update', '--non-interactive', 184451, '--port=chromium-xvfb'] exit_code: 2 cwd: /mnt/git/webkit-commit-queue Last 500 characters of output: -queue Parsed 4 diffs from patch file(s). patch: Can't create file /tmp/pptQe127 : No space left on device patch: Can't create file /tmp/ppIK0MM8 : No space left on device patch: Can't create file /tmp/ppTdTd08 : No space left on device patch: Can't create file /tmp/pp8tZQ8b : No space left on device Kr, -- Christophe Dumez, PhD Linux Software Engineer Intel Finland Oy - Open Source Technology Center ___ 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] DOM methods that affect [[Prototype]]
Note that WebKit re-uses the same Document after a call to document.open(). I suspect we're unlikely to change that behavior anytime soon. Adam On Thu, Jan 24, 2013 at 12:59 PM, Anne van Kesteren ann...@annevk.nl wrote: Hi, https://www.w3.org/Bugs/Public/show_bug.cgi?id=20567 could use input from the WebKit community, in particular DOM/JavaScript experts. I recommend reading through http://lists.w3.org/Archives/Public/www-dom/2012OctDec/thread.html#msg143 and https://mail.mozilla.org/pipermail/es-discuss/2012-December/thread.html#27401 to some extent first. In particular the discussion is about what happens to the [[Prototype]] of objects when objects are adopted and when document.open() is invoked. Both Gecko and IE mutate the [[Prototype]] and the tentative plan therefore is to align the standard with that. To make sure your feedback is fully considered by all parties raise it via the bug or www-...@w3.org. Thanks, -- http://annevankesteren.nl/ ___ 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] DOM methods that affect [[Prototype]]
On Thu, Jan 24, 2013 at 7:13 PM, Geoffrey Garen gga...@apple.com wrote: Note that WebKit re-uses the same Document after a call to document.open(). I suspect we're unlikely to change that behavior anytime soon. Do we know of any websites that depend on this behavior? I haven't tested this in a while, so I might be misremembering, but Gecko has magic to rewrite all JavaScript references to the old document to point to the new document. I don't know whether that magic is required by web compatibility, but I bet it is and I don't think we want to introduce more of that magic into WebKit. (We do something similar for Window today, but Window is a unique snowflake.) Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Followup on removing webkitNotifications.createHTMLNotification
On Wed, Jan 23, 2013 at 12:45 AM, Andrew Wilson atwil...@google.com wrote: Hmmm. Does FeatureObserver detect features invoked from web apps like Gmail? Yes. Because I'm fairly certain that Gmail and Google Calendar still use webkitNotifications for their notifications. Not to say that we shouldn't land this patch anyway - just pointing out that this may still be used more often than your stats would indicate. As Morrita-san writes: On Wed, Jan 23, 2013 at 12:50 AM, Hajime Morrita morr...@google.com wrote: It looks the patch is removing a specific API called createHTMLNotification(). Unless these apps are showing HTML-based notification, it should keep working even after this change. If Gmail is still using the vendor-prefixed webkitNotifications version of the API, they should update to the unprefixed new Notification version of the API, which is implemented by a number of different browsers. I know there's some amount of confusion about the current status of the web notification APIs. I'm working with Chrome's developer relation folks to update our various pieces of documentation and tutorials. Adam On Wed, Jan 23, 2013 at 1:47 AM, Adam Barth aba...@webkit.org wrote: As discussed in February 2012 [1], we have been deprecating the webkitNotifications.createHTMLNotification API for almost a year. According to FeatureObserver, the API is used in only 0.0008% of web page views, indicating that we have been successful in depreciating it. I've posted a patch to remove it: https://bugs.webkit.org/show_bug.cgi?id=107598 Thanks, Adam [1] http://lists.webkit.org/pipermail/webkit-dev/2012-February/019354.html ___ 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] Followup on removing webkitNotifications.createHTMLNotification
On Wed, Jan 23, 2013 at 1:08 AM, Andrew Wilson atwil...@google.com wrote: Apologies for the confusion - I should have finished my coffee before reading my mail. I didn't realize this only impacts HTML notifications. It's still a good reminder that Google really should migrate to the new notification APIs, though. I'll get the ball rolling on gmail, at least. Thanks! Let me know if you run into any trouble. Adam On Wed, Jan 23, 2013 at 9:58 AM, Adam Barth aba...@webkit.org wrote: On Wed, Jan 23, 2013 at 12:45 AM, Andrew Wilson atwil...@google.com wrote: Hmmm. Does FeatureObserver detect features invoked from web apps like Gmail? Yes. Because I'm fairly certain that Gmail and Google Calendar still use webkitNotifications for their notifications. Not to say that we shouldn't land this patch anyway - just pointing out that this may still be used more often than your stats would indicate. As Morrita-san writes: On Wed, Jan 23, 2013 at 12:50 AM, Hajime Morrita morr...@google.com wrote: It looks the patch is removing a specific API called createHTMLNotification(). Unless these apps are showing HTML-based notification, it should keep working even after this change. If Gmail is still using the vendor-prefixed webkitNotifications version of the API, they should update to the unprefixed new Notification version of the API, which is implemented by a number of different browsers. I know there's some amount of confusion about the current status of the web notification APIs. I'm working with Chrome's developer relation folks to update our various pieces of documentation and tutorials. Adam On Wed, Jan 23, 2013 at 1:47 AM, Adam Barth aba...@webkit.org wrote: As discussed in February 2012 [1], we have been deprecating the webkitNotifications.createHTMLNotification API for almost a year. According to FeatureObserver, the API is used in only 0.0008% of web page views, indicating that we have been successful in depreciating it. I've posted a patch to remove it: https://bugs.webkit.org/show_bug.cgi?id=107598 Thanks, Adam [1] http://lists.webkit.org/pipermail/webkit-dev/2012-February/019354.html ___ 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] Followup on removing webkitNotifications.createHTMLNotification
On Wed, Jan 23, 2013 at 11:28 AM, Jon Lee jon...@apple.com wrote: Happy to hear about this! As a follow-up question, what numbers are you seeing with the rest of the legacy API? (webkitNotifications.createNotification, webkitNotifications.checkPermission, and webkitNotifications.requestPermission) The only other API we're measuring is createNotification, which seems to be used about 4x as often as createHTMLNotification. That's certainly in the range where we should consider removing support for the prefixed version in favor of the unprefixed version. The reason I haven't done it yet is that there isn't very good developer documents explaining how to use the unprefixed API. As I mentioned earlier in this thread, I'm working with our developer relations folks to improve that situation. Once we have some good documentation out, we should consider removing the prefixed API as well. Adam On Jan 23, 2013, at 1:11 AM, Adam Barth aba...@webkit.org wrote: On Wed, Jan 23, 2013 at 1:08 AM, Andrew Wilson atwil...@google.com wrote: Apologies for the confusion - I should have finished my coffee before reading my mail. I didn't realize this only impacts HTML notifications. It's still a good reminder that Google really should migrate to the new notification APIs, though. I'll get the ball rolling on gmail, at least. Thanks! Let me know if you run into any trouble. Adam On Wed, Jan 23, 2013 at 9:58 AM, Adam Barth aba...@webkit.org wrote: On Wed, Jan 23, 2013 at 12:45 AM, Andrew Wilson atwil...@google.com wrote: Hmmm. Does FeatureObserver detect features invoked from web apps like Gmail? Yes. Because I'm fairly certain that Gmail and Google Calendar still use webkitNotifications for their notifications. Not to say that we shouldn't land this patch anyway - just pointing out that this may still be used more often than your stats would indicate. As Morrita-san writes: On Wed, Jan 23, 2013 at 12:50 AM, Hajime Morrita morr...@google.com wrote: It looks the patch is removing a specific API called createHTMLNotification(). Unless these apps are showing HTML-based notification, it should keep working even after this change. If Gmail is still using the vendor-prefixed webkitNotifications version of the API, they should update to the unprefixed new Notification version of the API, which is implemented by a number of different browsers. I know there's some amount of confusion about the current status of the web notification APIs. I'm working with Chrome's developer relation folks to update our various pieces of documentation and tutorials. Adam On Wed, Jan 23, 2013 at 1:47 AM, Adam Barth aba...@webkit.org wrote: As discussed in February 2012 [1], we have been deprecating the webkitNotifications.createHTMLNotification API for almost a year. According to FeatureObserver, the API is used in only 0.0008% of web page views, indicating that we have been successful in depreciating it. I've posted a patch to remove it: https://bugs.webkit.org/show_bug.cgi?id=107598 Thanks, Adam [1] http://lists.webkit.org/pipermail/webkit-dev/2012-February/019354.html ___ 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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Followup on removing webkitNotifications.createHTMLNotification
As discussed in February 2012 [1], we have been deprecating the webkitNotifications.createHTMLNotification API for almost a year. According to FeatureObserver, the API is used in only 0.0008% of web page views, indicating that we have been successful in depreciating it. I've posted a patch to remove it: https://bugs.webkit.org/show_bug.cgi?id=107598 Thanks, Adam [1] http://lists.webkit.org/pipermail/webkit-dev/2012-February/019354.html ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Out-of-process networking and potential for sharing memory cache (was Re: Feature Announcement: Moving HTML Parser off the Main Thread)
Some folks have pointed out to me off thread that I'm coming off as angry and harsh. I would like to apologize for my tone. My goal here is not to obstruct or block your progress on the NetworkProcess. My goal is to end up with a common design that we can share between WebKit2 and Chromium or at least have a common way of interfacing with WebCore. My concern is that I don't believe that the current path the NetworkProcess is taking leads to a common design or interface. Anyway, it's probably best to continue this conversation another time. We can certainly iterate on the approach once you all are feeling less schedule pressure. Adam On Sun, Jan 20, 2013 at 11:44 PM, Adam Barth aba...@webkit.org wrote: On Sun, Jan 20, 2013 at 1:54 PM, Maciej Stachowiak m...@apple.com wrote: On Jan 20, 2013, at 1:44 PM, Adam Barth aba...@webkit.org wrote: On Sun, Jan 20, 2013 at 1:30 PM, Oliver Hunt oli...@apple.com wrote: I take your word for it that it's not possible on Windows. Given that Chromium has many users on Windows (and other non-Mac platforms), you should now understand why this design does not fit well with Chromium's design constraints. But chromium doesn't use webkit or webkit2, so i'm not entirely sure why webkit2 design decisions should consider chromium's (pre-wk2) design decisions. The reason discussed earlier in this thread is because they have implications for how the loader works in WebCore. In particular, folks working on the NetworkProcess have been shoehorning it into WebCore by adding numerous #ifdefs throughout WebCore. Are you offerring to implement the NetworkProcess without adding a bunch of WebKit2-specific #ifdefs to WebCore? The choice of load interception point is completely orthogonal to the decision to make the network process is a process or a thread. I'm not sure that's the case. The choices are coupled because the choice of interception point determines what code is in the web process and what code is outside the web process. The more loader code that's outside the web process, the more desirable it is to sandbox that code, which pushes the design towards running the code in a sandboxable environment, like a process. One thing that I'm unclear on is how having a distinct network process can possibly be less secure than a single thread in _any_ circumstance. Fundamentally any sandbox model that allows a single thread to be sandboxed, can just sandbox the main appropriate threads in the separate networking process, vice versa is not true however. According to Maciej, one of the motivations for having a NetworkProcess is that it can be sandboxed more tightly on Mac OS X. Unfortunately, the NetworkProcess, as currently designed, cannot be sandboxed on other platforms, such as Windows. That's why the current design is not a good fit for other platforms. To be clear, I think it's fine if you want to use a Mac OS X-centric design for WebKit2. However, you shouldn't be surprised later when other ports that run on more platforms don't want to adopt your designs. Moreover, if sometime in the future, I want to implement a Chromium-centric design that involves adding a bunch of #ifdefs to WebCore, I expect that you won't mind not having input either. As I understand it, here's the payoff matrix for how much sandboxing of networking code you get, if you take the process vs thread decision in isolation: | Mac | Windows -- Networking in dedicated process| fs can be sandboxed | no meaningful sandbox -- Networking in thread in UI process | no meaningful sandbox | no meaningful sandbox Just to be absolutely clear, are you saying that the Chromium project sees the second row as a better payoff? As I wrote before, you're drawing a false dichotomy. Networking is not a monolithic blob of code. The question isn't how best to sandbox a particular blob of code you've chosen to put in the NetworkProcess. The question is how best to factor the loader across multiple processes so that the risky parts of the code can be sandboxed well on various platforms. You've chosen a Mac OS X centric design that lets you sandbox that code but that ignores the constraints that other platforms face in sandboxing. Since you asked for clarity, my answer to your specific question is that I reject it's premise. In other words, you'd consider it bad to make Mac security better in a way that can't be applied to Windows, even if it makes Windows security no worse? Again, you've returned to your false dichotomy. Instead of assuming that we've already chosen a Mac OS X centric design that screws Windows, I think we should choose a design that balances the contraints of all the platforms we care
Re: [webkit-dev] Out-of-process networking and potential for sharing memory cache (was Re: Feature Announcement: Moving HTML Parser off the Main Thread)
On Wed, Jan 16, 2013 at 11:33 PM, Maciej Stachowiak m...@apple.com wrote: On Jan 12, 2013, at 1:14 AM, Adam Barth aba...@webkit.org wrote: On Sat, Jan 12, 2013 at 12:03 AM, Maciej Stachowiak m...@apple.com wrote: Do you think thread in the UI process vs. completely separate process is a topic worth discussing? It seems like the WebCore layer is unaffected by the difference, and in fact the impact of Chromium's choice is not even visible in the WebKit repository afaict. I don't know. As I wrote above, I haven't really thought through the consequences of that design choice. My point was just that the design wasn't discussed with the community at all. The NetworkProcess and its nature as a process have been mentioned before. At the time, no one expressed an opinion about the matter or pressed for an alternative, and it seems you have not (yet) done so either. If you have an interest in discussing it yourself, I at least would be happy to discuss it. If, for example, you would like to ask questions about it, advocate for a different design, argue that it's important for WK2 and Cr architectures to be consistent in this regard, present the Chromium team's reasons for choosing a thread, or anything else, then I would gladly engage in such discussion. Indeed, if anyone has a substantive point to make, I'll concede the foul of insufficient prior discussion. If no one does, then it doesn't seem very valuable to debate the meta-point. The point isn't to concede the foul. As discussed in the rest of this thread, the current design of the NetworkProcess might be a good design on Mac OS X, but it doesn't work well on other platforms. To the extent that the impact of its design is limited to WebKit2, I don't really care. The consequence, however, is that Chromium is unlikely to want to share any abstractions or mechanisms whose design follows from that design decision. (One reason for our particular choice, FYI, is so that we can give the NetworkProcess a tighter sandbox profile than the Safari UI process). I'm surprised that the Mac OS X sandboxing mechanisms are sophisticated enough to provide a meaningful sandbox for the NetworkProcess. That's certainly not possible on other platforms (e.g., Windows). The reference monitor we use in Chromium for network requests contains a great deal of web-specific details that are necessary to prevent, for example, an attacker from stealing confidential information (such as tax returns) stored in the user's file system. I take your word for it that it's not possible on Windows. Given that Chromium has many users on Windows (and other non-Mac platforms), you should now understand why this design does not fit well with Chromium's design constraints. I'm certainly not blowing off your use case. But I would like to understand how it impacts the design. Can you explain why the WebKit2 approach to out-of-process networking is incompatible with software fault isolation based API integrity, whereas interposing at the ResourceHandle layer is? Is it (a) because some loads don't go through the CachedResource layer currently, (b) because there are some loads you think it is fundamentally impossible (or at least unduly challenging) to send through the CachedResource layer, or (c) some other reason? Issue (a) is already a problem with the CachedResource approach with the sandbox we use today. Network requests that don't get intercepted will not work on Windows because code running inside the sandbox we use on Windows cannot talk to the network. Our long-term goal is to make all WebCore loads go through ResourceLoader/CachedResource, and have nothing hit ResourceHandle directly. I agree with you that this is not the case today. I take it from your response that you don't think it is fundamentally impossible or overly complex to make this happen. And it seems like attaining this goal would have a number of advantages regardless of the interposition layer of choice, such as making all loads, even obscure ones, correctly respect ResourceLoader-level concepts such as ApplicationCache and WebArchives. Even while we've been having this discussion, more patches have landed that don't follow this design. For example, a patch landed that shoehorned an interception point into FrameLoader. Given that your team appears to be prioritizing schedule over implementing this feature in an architecturally sound way, I don't think we'll be able to work together on this topic. As I've written before, on Windows and other platforms, we don't have the fallback option of issuing network requests from the web process. Maybe in the long-term when you're done refactoring all network loading paths to flow though ResourceLoader, we might be able to reconsider. In the mean time, the code that your team is landing does not work in a secure way on non-Mac platforms. I will note, however, that if instead you simply chose
Re: [webkit-dev] Out-of-process networking and potential for sharing memory cache (was Re: Feature Announcement: Moving HTML Parser off the Main Thread)
On Sun, Jan 20, 2013 at 1:30 PM, Oliver Hunt oli...@apple.com wrote: I take your word for it that it's not possible on Windows. Given that Chromium has many users on Windows (and other non-Mac platforms), you should now understand why this design does not fit well with Chromium's design constraints. But chromium doesn't use webkit or webkit2, so i'm not entirely sure why webkit2 design decisions should consider chromium's (pre-wk2) design decisions. The reason discussed earlier in this thread is because they have implications for how the loader works in WebCore. In particular, folks working on the NetworkProcess have been shoehorning it into WebCore by adding numerous #ifdefs throughout WebCore. Are you offerring to implement the NetworkProcess without adding a bunch of WebKit2-specific #ifdefs to WebCore? One thing that I'm unclear on is how having a distinct network process can possibly be less secure than a single thread in _any_ circumstance. Fundamentally any sandbox model that allows a single thread to be sandboxed, can just sandbox the main appropriate threads in the separate networking process, vice versa is not true however. According to Maciej, one of the motivations for having a NetworkProcess is that it can be sandboxed more tightly on Mac OS X. Unfortunately, the NetworkProcess, as currently designed, cannot be sandboxed on other platforms, such as Windows. That's why the current design is not a good fit for other platforms. To be clear, I think it's fine if you want to use a Mac OS X-centric design for WebKit2. However, you shouldn't be surprised later when other ports that run on more platforms don't want to adopt your designs. Moreover, if sometime in the future, I want to implement a Chromium-centric design that involves adding a bunch of #ifdefs to WebCore, I expect that you won't mind not having input either. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Out-of-process networking and potential for sharing memory cache (was Re: Feature Announcement: Moving HTML Parser off the Main Thread)
On Sun, Jan 20, 2013 at 1:54 PM, Maciej Stachowiak m...@apple.com wrote: On Jan 20, 2013, at 1:44 PM, Adam Barth aba...@webkit.org wrote: On Sun, Jan 20, 2013 at 1:30 PM, Oliver Hunt oli...@apple.com wrote: I take your word for it that it's not possible on Windows. Given that Chromium has many users on Windows (and other non-Mac platforms), you should now understand why this design does not fit well with Chromium's design constraints. But chromium doesn't use webkit or webkit2, so i'm not entirely sure why webkit2 design decisions should consider chromium's (pre-wk2) design decisions. The reason discussed earlier in this thread is because they have implications for how the loader works in WebCore. In particular, folks working on the NetworkProcess have been shoehorning it into WebCore by adding numerous #ifdefs throughout WebCore. Are you offerring to implement the NetworkProcess without adding a bunch of WebKit2-specific #ifdefs to WebCore? The choice of load interception point is completely orthogonal to the decision to make the network process is a process or a thread. I'm not sure that's the case. The choices are coupled because the choice of interception point determines what code is in the web process and what code is outside the web process. The more loader code that's outside the web process, the more desirable it is to sandbox that code, which pushes the design towards running the code in a sandboxable environment, like a process. One thing that I'm unclear on is how having a distinct network process can possibly be less secure than a single thread in _any_ circumstance. Fundamentally any sandbox model that allows a single thread to be sandboxed, can just sandbox the main appropriate threads in the separate networking process, vice versa is not true however. According to Maciej, one of the motivations for having a NetworkProcess is that it can be sandboxed more tightly on Mac OS X. Unfortunately, the NetworkProcess, as currently designed, cannot be sandboxed on other platforms, such as Windows. That's why the current design is not a good fit for other platforms. To be clear, I think it's fine if you want to use a Mac OS X-centric design for WebKit2. However, you shouldn't be surprised later when other ports that run on more platforms don't want to adopt your designs. Moreover, if sometime in the future, I want to implement a Chromium-centric design that involves adding a bunch of #ifdefs to WebCore, I expect that you won't mind not having input either. As I understand it, here's the payoff matrix for how much sandboxing of networking code you get, if you take the process vs thread decision in isolation: | Mac | Windows - - Networking in dedicated process| fs can be sandboxed | no meaningful sandbox - - Networking in thread in UI process | no meaningful sandbox | no meaningful sandbox Just to be absolutely clear, are you saying that the Chromium project sees the second row as a better payoff? As I wrote before, you're drawing a false dichotomy. Networking is not a monolithic blob of code. The question isn't how best to sandbox a particular blob of code you've chosen to put in the NetworkProcess. The question is how best to factor the loader across multiple processes so that the risky parts of the code can be sandboxed well on various platforms. You've chosen a Mac OS X centric design that lets you sandbox that code but that ignores the constraints that other platforms face in sandboxing. Since you asked for clarity, my answer to your specific question is that I reject it's premise. In other words, you'd consider it bad to make Mac security better in a way that can't be applied to Windows, even if it makes Windows security no worse? Again, you've returned to your false dichotomy. Instead of assuming that we've already chosen a Mac OS X centric design that screws Windows, I think we should choose a design that balances the contraints of all the platforms we care about. IMHO, this thread had gone on too long without any tangible results. The code that your team is landing just plain doesn't work on other platforms. Even if you follow though on your long-term ResourceLoader-based design (which I'll note is *not* what you're actually implementing---see the recent hacks to FrameLoader.cpp), you'll get a design that might work well on Mac OS X but that won't have good security properties on other platforms, such as Windows. As a result, the Chromium port is unlikely to adopt the design in the future. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Can't upload patch
Have you tried uploading the patch manually by running svn-create-patch and using the attachments UI in bugs.webkit.org? One possibility is that your patch is too big for bugs.webkit.org to handle. You mention that it contains a number of binary files, which might be the cause of the problem. Adam On Thu, Jan 17, 2013 at 9:43 AM, Raymond Toy r...@google.com wrote: I'm trying to upload a patch and webkit-patch upload appears to do everything except actually add the patch to the bug. I first ran webkit-patch upload and it correctly created the bug (https://bugs.webkit.org/show_bug.cgi?id=106955) for me, but didn't upload the patch. When I run webkit-patch upload again, it correctly shows the diff, which consists of a a change to TestExpectations and several binary files. It says it adding the patch, but when I look at the bug, there's no patch. I'm missing something, but I don't know what it is. I've uploaded patches before, so I know it used to work. :-( Any suggestions? Ray ___ 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] EWS commenting about ancient patches
Maybe we shouldn't bother feeding the bots patches that are over a certain age (perhaps a week)? Adam On Thu, Jan 17, 2013 at 11:50 AM, Eric Seidel e...@webkit.org wrote: I believe the queue was actually cleared when they were brought online. As Ossy notes, this is expected behavior. Every time the feeder queue boots up (which is every 2 hours), it sends *all* patches marked for review to queues.webkit.org. queues.webkit.org makes sure that each individual EWS queue has either has a result for each patch, or adds it to each individual queue. Since there are some ancient patches still marked r?, new queues will process ancient patches. :) (The feeder-queue is then smart enough to keep an in-memory list of what it's sent to queues.webkit.org, so it only send incremental lists until it restarts itself again in 2 hours.) -eric On Thu, Jan 17, 2013 at 11:43 AM, Ryosuke Niwa rn...@webkit.org wrote: Sorry, that's my fault. I added Mac-WK2 EWS to the EWS queue much earlier than we added bots. So we ended up having 1000+ backlogs of patches. As Ossy points out, Mac WK2 EWS bots have caught up with patches so this shouldn't be a problem in the future. - R. Niwa On Thu, Jan 17, 2013 at 8:40 AM, Alexey Proskuryakov a...@webkit.org wrote: On several occasions over the last few days, I noticed EWS commenting in bugs that didn't have any recent activity, e.g. https://bugs.webkit.org/show_bug.cgi?id=87527. Is EWS picking ancient patches, or is it posting comments to wrong bugs? - WBR, Alexey Proskuryakov ___ 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 ___ 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] Is the New XMLParser dead?
Maciej has asked that we keep it around until the end of February: https://bugs.webkit.org/show_bug.cgi?id=100710 Adam On Thu, Jan 17, 2013 at 4:10 PM, Ryosuke Niwa rn...@webkit.org wrote: Hi, It has been 11 months since Eric initially raised the concern. Can we go ahead and remove the parser now? - R. Niwa ___ 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] request of canconfirm-bit
We more or less ignore the is confirmed bit in bugs.webkit.org. Adam On Wed, Jan 16, 2013 at 6:35 AM, 徐征 xz91...@yahoo.co.jp wrote: Hello everyone This is Zheng and nice to meet you. I want to confirm some issue(https://bugs.webkit.org/show_bug.cgi?id=78957) and try to create patch for it. However, it seems I need canconfirm-bit based on http://www.webkit.org/quality/bugzilla.html So, could someone give me the right to confirm and fix it. BR, Zheng ___ 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] Changing Github repository to mirror git.webkit.org (was Github vs. git.webkit.org)
If you were using GitHub to contribute to WebKit previously, you might want to delete your fork of https://github.com/WebKit/webkit and re-fork https://github.com/WebKit/webkit. It's also possible to push a force update to your repository that re-writes the hashes, but I found that re-forking was easier. Adam On Wed, Jan 16, 2013 at 4:55 AM, Jesus Sanchez-Palencia je...@webkit.org wrote: Hi, The mirror is finally ready again: https://github.com/WebKit/webkit It now follows the same hashes of git.webkit.org. People who have forked this repository on github before will now have to rebase their branches. I was hold back a bit because Github wasn't allowing me to push more than 2GB. I contacted them but before I could get answer I decide to 'split' the push. First I git reset --hard the repository back to a commit from 2008, pushed this, then reset --hard to 2009 and pushed this, and so on. In the middle of the process the folks from github increased our push limit to 20GB and David (barrbrain) was kind enough to push one last sync, getting us back to 2012. After that I kept the syncing manullay for a few hours but now the repository is being updated automatically every 5 minutes to stay in sync with git.webkit.org . I will now coordinate with William so we can get Apple pushing to the mirror at the same time they push to git.webkit.org . Thanks everyone that got involved for the help! Cheers, jesus 2013/1/14 Jesus Sanchez-Palencia je...@webkit.org: Hi, Just yet another quick heads-up: 2013/1/14 Jesus Sanchez-Palencia je...@webkit.org: We have decided that the best approach for this is to start a new repository (webkit-mirror), delete the old one (https://github.com/WebKit/webkit) and then rename the new repository. I had to change my strategy here after talking to a few people on #github. It seems that doing a git push -f to the current repository (https://github.com/WebKit/webkit) will actually have less impact on people branching/forking it on github. In other words, it should be less painful to rebase your fork on github for the new hashes after I'm done with the setup. I will let you know when the switching is done. Cheers, jesus I will be doing the mirroring myself for while, until Apple can set this up from the same machine that git pushes to git.webkit.org. People that are using the current github repository will probably have to re-clone and rebase their branches. This won't affect git.webkit.org or any other official WebKit repository. Cheers, jesus 2012/12/11 Jesus Sanchez-Palencia jesus.palen...@openbossa.org: Hi, 2012/12/4 Tor Arne Vestbø tor.arne.ves...@digia.com: Bill, what do you think about pushing the official SVN import to GitHub as well? tor arne Any updates about this? Cheers, jesus So we might be able to rename the existing one and ask github to pull our git.webkit.org http://git.webkit.org repository into github/WebKit/webkit. Apparently Apache takes that way: https://github.com/apache The mirroring icon indicates kind of official-ness. I don't know how long their mirroring delay is, though. On Sat, Dec 1, 2012 at 12:07 AM, Tor Arne Vestbø tor.arne.ves...@digia.com mailto:tor.arne.ves...@digia.com wrote: On 11/28/12 16:55 , Adam Barth wrote: My sense is that the WebKit community would prefer that the hashes in GitHub match the hashes in git.webkit.org http://git.webkit.org so that folks can more easily move branches between the two. For my part, I've switched over to using GitHub exclusive of git.webkit.org http://git.webkit.org, so the the difference in hashes aren't an issue for me, but I can understand why they'd be problematic for other people. Yepp, agreed. Let's switch it over. After the force-push, would you still be able to push updates automatically? If so, you can switch the hashes whenever is convenient for you. (It might be nice to announce the date/time on this list so that folks aren't taken by surprise.) The mirror is also pushed to http://gitorious.org/webkit/__webkit http://gitorious.org/webkit/webkit, which I was planning to keep as is for now, so that would mean setting up an extra mirroring for the non-author-rewritten history :/ Also, the server I run this on has a somewhat uncertain future. With that in mind it's probably easier to just push directly from the same import that's pushed to git.webkit.org http://git.webkit.org, and make the GitHub mirror an official mirror? tor arne _ webkit-dev mailing list webkit-dev@lists.webkit.org mailto:webkit-dev@lists.webkit.org http://lists.webkit.org/__mailman/listinfo/webkit-dev http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] SVG external referencing not working as of latest chrome canary
On Mon, Jan 14, 2013 at 12:51 AM, Steve Williams stephen.j.h.willi...@googlemail.com wrote: 1. It's been on your bug database for ages hence filing another entry won't move anything forwards. 2. svg 1.1 spec seems a little over the top in places so not personally interested in full support - just the good stuff. 3. Have provided you with a minimal test case in the previous post. 4. Cite real-world sites using the functionality to the relevant bugs. ? chicken and egg. that's not how we make progress ! I'll use it in our site when it works but can't until it does. For now I have to iframe as a workaround but that sucks because iframes grab the entire rect for mouse input which means you can't subtly blend svg over html. Have you considered using SVG-in-HTML? https://developer.mozilla.org/en-US/docs/SVG_In_HTML_Introduction Adam 5. Like you, I am busy. I don't have time to fix this (really). Sorry, appreciate you don't like that but it is what it is. 6. Would be great if this could be advanced in priority to enable us to raise the bar, cross browser. Am sure you won't appreciate this fired back at the mailing list I realise I'm risking a ban when you've asked me not to do this, but I'm a bit of a rebel :) Thanks for all your hard work. FF has svg bugs too - different (lower priority niggles). Will go hassle them next. IE9 a bit wobbly too, but well ... :) If basic support can be solidified cross browser, we have an interesting platform over above html5. Best regards, Steve. On 13/01/2013 21:37, Maciej Stachowiak wrote: Hi Steve, If you're interested in more complete SVG support, here are some things you can do: (1) File bugs for any missing features that don't have bugs already. (2) Create a meta-bug for complete SVG 1.1 support or what have you that's blocked by all the relevant feature bugs. (3) Add useful reduced test cases to the relevant bugs. (4) Cite real-world sites using the functionality to the relevant bugs. (5) Work on implementing some of these features yourself. (6) Persuade WebKit hackers that you know (offlist) to work on some of these features. (7) Contact one of the vendors that works on WebKit via their developer relations channels and ask them to implement the features you care about. If you are interested in more complete SVG support, I encourage you to do some or all of these things. Note, however, that posting feature requests or advocacy for specific bugs is not really appropriate for this list. It's for talking about the development of WebKit itself, and no one uses requests on this list as a way to drive priorities. I'm glad to see you are interested in WebKit's SVG support and I hope you will consider some of the possible steps above to improve it. Cheers, Maciej On Jan 13, 2013, at 8:37 AM, Steve Williams stephen.j.h.willi...@googlemail.com wrote: Hi all, I've done a little experimenting to see where we're at wrt to svg feature set and it seems webkit is lagging some way behind gecko. Of particular concern is lack of external referencing capability through the svg use tag. I attach a simple example that works in firefox for your consideration. root.svg should link through to object.svg and render it. It doesn't in latest chrome canary. You've had a bug filed on this for a long time but it's still unresolved so thought I'd mail. https://bugs.webkit.org/show_bug.cgi?id=12499 We are lowering the priority because this is not heavily used. The feature is not used heavily because it doesn't work properly. Never use lack of use as a reason to not do something :) SVG is important because it's the lowest common denominator high spec graphics interface across all major browsers. Looks like you're behind ie9 in terms of implementation. You should at least match their implementation so we can raise the bar. Of course IE should implement webgl but until they do SVG is the best we've got across all mainstream browsers. Thanks in advance for your consideration. webkit is behind the curve in implementation of this web standard - please address this. Best regards, Steve Williams root.svgobject.svg___ 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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Recommended commit procedure for large EFL rebaseline?
On Mon, Jan 14, 2013 at 8:39 AM, Dominik Röttsches dominik.rottsc...@intel.com wrote: when we land https://bugs.webkit.org/show_bug.cgi?id=106774 we'll have to do a large rebaseline of EFL results. (subpixel and FreeType related change) Now, for landing, what we had in mind is, (optionally) take our bots offline, 1) land the actual patch, 2) then manually land the new baselines. Then restart the bots. I probably wouldn't take your bots offline. Instead, I would add the tests to TestExpectations so that the bots expect them to fail. As you land new baselines, you can remove the tests for TestExpectations. That way you'll be able to incrementally check your work. Regarding step 2) there: Would you recommend to land the rebaselines in smaller chunks or in one big SVN commit? If in chunks - what sizes work well? Generally it's a good idea to land the baselines in chunks. If you're landing image baselines, I'd probably try chunks between 100 and 500 baselines. If you're landing text baselines, it's less important to use chunks because they are much smaller. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Out-of-process networking and potential for sharing memory cache (was Re: Feature Announcement: Moving HTML Parser off the Main Thread)
On Sat, Jan 12, 2013 at 12:03 AM, Maciej Stachowiak m...@apple.com wrote: On Jan 11, 2013, at 2:53 PM, Adam Barth aba...@webkit.org wrote: On Fri, Jan 11, 2013 at 2:19 AM, Maciej Stachowiak m...@apple.com wrote: On Jan 11, 2013, at 12:21 AM, Adam Barth aba...@webkit.org wrote: Is that really the case? If so, I'm surprised that the patches for the shared memory cache and the NetworkProcess landed. I raised similar questions to the ones you're raising now, but the folks purposing those changes basically ignored me and landed their patches anyway. NetworkProcess itself exists primarily for correctness reasons in the face of process-per-tab. I hope the idea of handling networking outside any of the web/render processes in a process-per-tab architecture is not itself controversial. I don't want delve too deeply into this issue because it's primarily a WebKit2 concern. However, I'll note that in Chromium, networking is just a thread in the UIProcess rather than a separate process. I haven't really thought though the consequences of that design choice. My point is more that folks just started landing patches for the NetworkProcess without discussing the design with the community. That's fine if you're not interested feedback from the community, but I've also heard repeated requests to share more code between Chromium and WebKit2. If you don't seek feedback on your designs, it's unlikely that you'll happen to design something that Chromium will be able to adopt in the future. Put another way, I don't think it's reasonable to simultaneously design WebKit2 without community feedback and also to complain when Chromium doesn't adopt WebKit2 (in part or in whole). Do you think thread in the UI process vs. completely separate process is a topic worth discussing? It seems like the WebCore layer is unaffected by the difference, and in fact the impact of Chromium's choice is not even visible in the WebKit repository afaict. I don't know. As I wrote above, I haven't really thought through the consequences of that design choice. My point was just that the design wasn't discussed with the community at all. (One reason for our particular choice, FYI, is so that we can give the NetworkProcess a tighter sandbox profile than the Safari UI process). I'm surprised that the Mac OS X sandboxing mechanisms are sophisticated enough to provide a meaningful sandbox for the NetworkProcess. That's certainly not possible on other platforms (e.g., Windows). The reference monitor we use in Chromium for network requests contains a great deal of web-specific details that are necessary to prevent, for example, an attacker from stealing confidential information (such as tax returns) stored in the user's file system. The main point I was trying to make in the document is that hooking in at the CachedResource layer has worse security properties than hooking in at the ResourceHandle layer. I understand that Safari and Chromium have different goals when it comes to security, which I believe is the main reason you're even willing to consider hooking in at the CachedResource layer. In particular, Chromium needs to be able to run in a strong sandbox on Windows XP. Unlike Mac OS X, Windows XP does not have a particularly sensible sandboxing mechanism, mostly because the OS mechanisms that we use in Chromium were not intended to be used for sandboxing by the designers of XP. As a consequence, any network requests that we fail to hook will simply fail (or more likely just crash). For that reason, we need complete interposition, which means we need to hook into WebCore at a layer like ResourceHandle that has actually has complete interposition. Moreover, we've enjoyed the security benefits of complete interposition for a while now and have raised our security goals, namely we're interested in achieving software fault isolation based API integrity. As far as I can tell, the approach WebKit2 has taken to out-of-proces networking is not compatible with software fault isolation based API integrity. Now, I understand if that sounds very futuristic to you given the current security posture of the apple-mac port, but if you're serious about working on a common design, you need to be willing to accept design goals and constraints beyond those that affect the apple-mac port. As long as you minimize or ignore those constraints, it's unlikely that the folks who have those goals and constraints will be interested in adopting your designs. I'm certainly not blowing off your use case. But I would like to understand how it impacts the design. Can you explain why the WebKit2 approach to out-of-process networking is incompatible with software fault isolation based API integrity, whereas interposing at the ResourceHandle layer is? Is it (a) because some loads don't go through the CachedResource layer currently, (b) because there are some loads you think
Re: [webkit-dev] Feature Announcement: Moving HTML Parser off the Main Thread
On Thu, Jan 10, 2013 at 9:19 PM, Maciej Stachowiak m...@apple.com wrote: On Jan 10, 2013, at 12:07 PM, Adam Barth aba...@webkit.org wrote: On Thu, Jan 10, 2013 at 12:37 AM, Maciej Stachowiak m...@apple.com wrote: I presume from your other comments that the goal of this work is responsiveness, rather than page load speed as such. I'm excited about the potential to improve responsiveness during page loading. The goals are described in the first link Eric gave in his email: https://bugs.webkit.org/show_bug.cgi?id=106127#c0. Specifically: ---8--- 1) Moving parsing off the main thread could make web pages more responsive because the main thread is available for handling input events and executing JavaScript. 2) Moving parsing off the main thread could make web pages load more quickly because WebCore can do other work in parallel with parsing HTML (such as parsing CSS or attaching elements to the render tree). ---8--- OK - what test (if any) will be used to test whether the page load speed goal is achieved? All of them. :) More seriously, Chromium runs a very large battery of performance tests continuously on a matrix of different platforms, including desktop and mobile. You can see one of the overview dashboards here: http://build.chromium.org/f/chromium/perf/dashboard/overview.html The ones that are particularly relevant to this work are the various page load tests, both with simulated network delays and without network delays. For iterative benchmarking, we plan to use Chromium's Telemetry framework http://www.chromium.org/developers/telemetry. Specifically, I expect we plan to work with the top_25 dataset http://src.chromium.org/viewvc/chrome/trunk/src/tools/perf/page_sets/top_25.json?view=markup, but we might use some other data sets if there are particular areas we want to measure more carefully. One question: what tests are you planning to use to validate whether this approach achieves its goals of better responsiveness? The tests we've run so far are also described in the first link Eric gave in his email: https://bugs.webkit.org/show_bug.cgi?id=106127. They suggest that there's a good deal of room for improvement in this area. After we have a working implementation, we'll likely re-run those experiments and run other experiments to do an A/B comparison of the two approaches. As Filip points out, we'll likely end up with a hybrid of the two designs that's optimized for handling various work loads. I agree the test suggests there is room for improvement. From the description of how the test is run, I can think of two potential ways to improve how well it correlates with actual user-perceived responsiveness: (1) It seems to look at the max parsing pause time without considering whether there's any content being shown that it's possible to interact with. If the longest pauses happen before meaningful content is visible, then reducing those pauses is unlikely to actually materially improve responsiveness, at least in models where web content processing happens in a separate process or thread from the UI. One possibility is to track the max parsing pause time starting from the first visually non-empty layout. That would better approximate how much actual user interaction is blocked. Consider, also, that pages might be parsing in the same process in another tab, or in a frame in the current tab. (2) It might be helpful to track max and average pause time from non-parsing sources, for the sake of comparison. If you looked at the information Eric provided in his initial email, you might have noticed https://docs.google.com/spreadsheet/ccc?key=0AlC4tS7Ao1fIdGtJTWlSaUItQ1hYaDFDcWkzeVAxOGc#gid=0, which is precisely that. These might result in a more accurate assessment of the benfits. The reason I ask is that this sounds like a significant increase in complexity, so we should be very confident that there is a real and major benefit. One thing I wonder about is how common it is to have enough of the page processed that the user could interact with it in principle, yet still have large parsing chunks remaining which would prevent that interaction from being smooth. If you're interested in reducing the complexity of the parser, I'd recommend removing the NEW_XML code. As previously discussed, that code creates significant complexity for zero benefit. Tu quoque fallacy. From your glib reply, I get the impression that you are not giving the complexity cost of multithreading due consideration. I hope that is not actually the case and I merely caught you at a bad moment or something. I'm quite aware of the complexity of multithreaded code having written a great deal of it for Chromium. One of the things I hope comes out of this project is a good example of how to do multithreaded processing in WebCore. Currently, every subsystem seems rolls their own threading abstractions, I think largely because there hasn't been
Re: [webkit-dev] Unprefixed and prefixed DOM events.
That does sound like a tricky problem. Your approach sounds reasonable to me. If you like, we can use the FeatureObserver [1] to estimate how often these various cases occur. Adam [1] http://lists.webkit.org/pipermail/webkit-dev/2012-September/022239.html On Fri, Jan 11, 2013 at 11:30 AM, Alexis Menard ale...@webkit.org wrote: Hi all, As you know I'm working on unprefixing CSS transitions and I need a few advice from the DOM experts. Problem : CSS Transitions when they finish to animate send a DOM event transitionend as specified there [1] to give the developer a notice that the transition finished. Today WebKit sends the prefixed counterpart webkitTransitionEnd. Animations also have the same event and few more. So today the problem is when we should send the prefixed event and when we should send the unprefixed one, and if we should send both. I think that sending both events will break content somewhere as JS functions attached with addEventListener will be called two times. Sending only the unprefixed event will break WebKit-only content the day we ship CSS Transitions unprefixed. I know they should not produce WebKit only code but it's not the point of the discussion. A solution is to send the prefixed or the unprefixed event depending if someone is listening to it or not. Let me explain. Let say there is a listener on the prefixed event only then we deliver the prefixed event *only*. If there is a listener on the unprefixed event only we deliver the unprefixed event *only*. If there are listeners on both events then we send the unprefixed one *only* forcing people to rely on the unprefixed. It seems that this approach is an elegant one and allows us to remove later in the future the support for prefixed transitions (including the events). As a side note Opera is acting the same as the proposed solution. Now obviously prefixed and unprefixed events in the DOM is something new because it never happens in the past so we don't have support for having such a mechanism for event delivery. I thought that we could somewhere in the Animation/Transition code be smart and try to figure which event to send but it practically impossible to access the EventListenerMap so I thought we could support it somehow generically in the DOM events code. It will be useful for the animations and maybe in the future (we're not really sure if prefixed event will again show but who knows). So I did a first patch there [2] and I would like to gather feedback whether the approach is correct (I don't know much the DOM related code) or if somebody has a better idea on how to resolve the problem. Also if I have missed something, please point it to me. The patch doesn't include the support for HTML ontransitionend attribute which I prefer to do in a later patch. Thanks. [1] http://dev.w3.org/csswg/css3-transitions/#transition-shorthand-property [2] https://bugs.webkit.org/show_bug.cgi?id=105647 -- Software Engineer @ Intel Open Source Technology Center ___ 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] Out-of-process networking and potential for sharing memory cache (was Re: Feature Announcement: Moving HTML Parser off the Main Thread)
On Fri, Jan 11, 2013 at 2:19 AM, Maciej Stachowiak m...@apple.com wrote: On Jan 11, 2013, at 12:21 AM, Adam Barth aba...@webkit.org wrote: If you're actually planning to make a significant complexity-imposing architectural change for performance reasons, without any way to test whether it delivers the claimed performance benefits, or how it compares to less complex approaches, then why should any rational person agree with that approach? When attempting to improve performance, the burden of proof is on the person proposing the performance improvement, not on others to create a test to figure out if the performance improvement works. It's not valid to respond to a request for performance testing info with the equivalent of patches welcome. Is that really the case? If so, I'm surprised that the patches for the shared memory cache and the NetworkProcess landed. I raised similar questions to the ones you're raising now, but the folks purposing those changes basically ignored me and landed their patches anyway. NetworkProcess itself exists primarily for correctness reasons in the face of process-per-tab. I hope the idea of handling networking outside any of the web/render processes in a process-per-tab architecture is not itself controversial. I don't want delve too deeply into this issue because it's primarily a WebKit2 concern. However, I'll note that in Chromium, networking is just a thread in the UIProcess rather than a separate process. I haven't really thought though the consequences of that design choice. My point is more that folks just started landing patches for the NetworkProcess without discussing the design with the community. That's fine if you're not interested feedback from the community, but I've also heard repeated requests to share more code between Chromium and WebKit2. If you don't seek feedback on your designs, it's unlikely that you'll happen to design something that Chromium will be able to adopt in the future. Put another way, I don't think it's reasonable to simultaneously design WebKit2 without community feedback and also to complain when Chromium doesn't adopt WebKit2 (in part or in whole). What I know is controversial, and I believe merits further follow-up discussion, is the choice of where proxying of networking to an outside process should hook in - whether at the ResourceHandle layer (as Chromium does it), or at the CachedResource layer, as WebKit2 is doing it. That choice involves hypotheses about both performance and appropriate architecture. I feel that the WebKit2 folks have not provided sufficient public data to fully justify the choice of where to hook things in, and I will encourage things to do so. On the other hand, Chromium folks historically did not really provide a lot of data or justification for why the ResourceHandle was the right place. Rather, it was presented as a constraint and a must-have for merging back to the WebKit repository. To me, that's seems like a pretty revisionist version of history. At the time Chromium landed, it wasn't at all practical to hook in at the cached resource layer because many (most?) loading codepaths bypassed the memory cache. It's only because of Nat's work to unify the loader code paths that it's even possible today. As Brady found, it wasn't even possible when he started out because main resources didn't flow through the memory cache until this past month. Long term, it is obviously somewhat regrettable if we end up diverging on this point, and therefore having two different insertion points for proxying, as that makes WebKit overall more complex. Agreed. I think your whitepaper on the topic was a good start on outlining some of the pros and cons. I commented on it a bit in email and via the comment system, but discussion died down (probably due to vacations and then the holidays). Here it is for reference of others: https://docs.google.com/document/d/1ihpwbiG_EDirnLibkkglEtyFoEEcf7t9XNAn8JD4fQY/edit?pli=1 In addition to my previous comments, I believe some topic not yet fully covered by your whitepaper are: - Hooking in proxying at the ResourceHandle layer may require threading information through ResourceHandle that it logically should not need to know (if one thinks of it as a an abstraction on top of a low-level networking API), such as association with a specific frame/page, or - How to connect loading mechanisms that bypass ResourceHandle or otherwise bypass the network stack (e.g. Application Cache, WebArchives, blob: URLs (currently implemented as a magic ResourceHandle subclass), etc. The two approaches have different architectural implications for this type of feature. I am not sure offhand which approach is cleaner or whether one way or the other has more pragmatic benefits. I'll add also that it seems possible in principle to make all WebCore loading go through the CachedResource layer, jut as it's possible
Re: [webkit-dev] Feature Announcement: Moving HTML Parser off the Main Thread
Thanks everyone for your feedback. Detailed responses inline. On Wed, Jan 9, 2013 at 9:41 PM, Filip Pizlo fpi...@apple.com wrote: I think your biggest challenge will be ensuring that the latency of shoving things to another core and then shoving them back will be smaller than the latency of processing those same things on the main thread. Yes. That's something we know we have to worry about. Given that we need to retain the ability to parse HTML on the main thread to handle document.write and innerHTML, we should be able to easily do A/B comparisons to make sure we understand any performance trade-offs that might arise. For small documents, I expect concurrent tokenization to be a pure regression because the latency of waking up another thread to do just a small bit of work, plus the added cost of whatever synchronization operations will be needed to ensure safety, will involve more total work than just tokenizing locally. Once we have the ability to tokenize on a background thread, we can examine cases like these and heuristically decide whether to use the background thread or not at runtime. As I wrote above, we'll need these ability anyway, so keeping the ability to optimize these cases shouldn't add any new constraints to the design. We certainly see this in the JSC parallel GC, and in line with traditional parallel GC design, we ensure that parallel threads only kick in when the main thread is unable to keep up with the work that it has created for itself. Do you have a vision for how to implement a similar self-throttling, where tokenizing continues on the main thread so long as it is cheap to do so? It's certainly something we can tune in the optimization phase. I don't think we need a particular vision to be able to do it. Given that we want to implement speculative parsing (to replace preload scanning---more on this below), we'll already have the ability to checkpoint and restore the tokenizer state across threads. Once you have that primitive, it's easy to decide whether to continue tokenization on the main thread or on a background thread. On Wed, Jan 9, 2013 at 10:04 PM, Ian Hickson i...@hixie.ch wrote: Parsing and (maybe to a lesser extent) compiling JS can be moved off the main thread, though, right? That's probably worth examining too, if it hasn't already been done. Yes, once we have the tokenizer running on a background thread, that opens up the possibility of parsing other sorts of data on the background thread as well. For example, when the tokenizer encounters an inline script block, you could imagine parsing the script on the background thread as well so that the main thread has less work to do. (You could also imagine making the optimizations without a background tokenizer, but the design constraints would be a bit different.) On Thu, Jan 10, 2013 at 12:11 AM, Zoltan Herczeg zherc...@webkit.org wrote: Parsing, especially JS parsing still takes a large amount of time on page loading. We tried to improve the preload scanner by moving it into anouther thread, but there was no gain (except some special cases). Synchronization between threads is surprisingly (ridiculously) costly, usually worth for those tasks, which needs quite a few million instructions to be executed (and tokenization takes far less in most cases). For smaller tasks, SIMD instruction sets can help, which is basically a parallel execution on a single thread. Anyway it is worth trying, but it is really challenging to make it work in practice. Good luck! This is something we're worried about and will need to be careful about. In the design we're proposing, preload scanning is replaced by speculative parsing, so the overhead of the preload scanner is removed entirely. The way this works is a follows: When running on the background thread, the tokenizer produces a queue of PickledTokens. As these tokens are queued, we can scan them to kick off any preloads that we find. Whenever the tokenizer queues a token that creates a new insertion point (in the terminology of the HTML specification), the tokenizer checkpoints itself but continues tokenizing speculatively. (Notice that tokens produced in this situation are still scanned for preloads but might not ever actually result in DOM being constructed.) After the main thread has processed the token that created the insertion point, if no characters were inserted, the main thread continues processing PickledTokens that were created speculative. If some characters were inserted, the main thread instead instructs the tokenizer to roll back to that checkpoint and continue tokenizing in a new state. In this case, the queue of speculative tokens is discarded. Notice that in the common case, we're execute JavaScript and tokenize in parallel, something that's not possible with a main-thread tokenizer. Once the script is done executing, we expect it to be common to be able to result tree building immediately as the
Re: [webkit-dev] commit-queue and JSC/WK2 specific changes
The solution I'd recommend is to make the JavaScriptCore and/or WebKit2 bots faster. If those bots are able to complete their processing before the commit-queue, then they'll stop the patch from being committed by marking the patch commit-queue-. Adam On Thu, Jan 10, 2013 at 9:22 PM, Ryosuke Niwa rn...@webkit.org wrote: Hi all, As you might all know, the commit-queue uses chromium linux port. Consequently, any JavaScriptCore and WebKit2 specific changes (and any non-Chromium port specific changes) are never tested. Commit-queue doesn't even detect whether it builds or not. This is a source of confusion because many (new) contributors appear to mistakenly think that commit-queue ensures that the patch builds passes tests on all platforms yet commit-queue doesn't wait until EWS bots process a patch before landing it. As a result, I've seen quite a few people landing patches that break JSC/WK2 via commit-queue. My initial proposal was to make commit-queue wait until EWS bots catch up when landing a port specific or JSC/WK2 specific changes. However, Adam thinks that's a bad idea (webkit.org/b/74776) because EWS bots are only advisory and waiting for EWS bots slows things down. Is this a problem worth finding a solution? If so, do you have any suggestions? - R. Niwa ___ 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 Announcement: Moving HTML Parser off the Main Thread
On Wed, Jan 9, 2013 at 6:00 PM, Eric Seidel e...@webkit.org wrote: We're planning to move parts of the HTML Parser off of the main thread: https://bugs.webkit.org/show_bug.cgi?id=106127 This is driven by our testing showing that HTML parsing on mobile is be slow, and long (causing user-visible delays averaging 10 frames / 150ms). https://bug-106127-attachments.webkit.org/attachment.cgi?id=182002 Complete data can be found at [1]. In case it's not clear from that link, the ParseHTML column is the total amount of time the web inspector attributes to HTML parsing when loading those URLs on a Nexus 7 using a top-of-tree build of Chromium's content_shell (similar to WebKitTestRunner). The HTML parser parses data a chunk at a time, which means the total time doesn't tell the whole story. The ParseHTML_max column shows the largest single block of time spent in the HTML parser, which is more of a measure of the main thread jank caused by the parser. Antti has pointed out that the inspector isn't the best source of data. He measured total time using instruments, and got numbers that are consistent (within a factor of 2) of the inspector measurements. (We were using different data sets, so we wouldn't expect perfect agreement even if we were measuring precisely the same thing.) Adam Mozilla moved their parser onto a separate thread during their HTML5 parser re-write: https://developer.mozilla.org/en-US/docs/Mozilla/Gecko/HTML_parser_threading We plan to take a slightly simpler approach, moving only Tokenizing off of the main thread: https://docs.google.com/drawings/d/1hwYyvkT7HFLAtTX_7LQp2lxA6LkaEWkXONmjtGCQjK0/edit The left is our current design, the middle is a tokenizer-only design, and the right is more like mozilla's threaded-parser design. Profiling shows Tokenizing accounts for about 10x the number of samples as TreeBuilding. Including Antti's recent testing (.5% vs. 3%): https://bugs.webkit.org/show_bug.cgi?id=106127#c10 If after we do this we measure and find ourselves still spending a lot of main-thread time parsing, we'll move the TreeBuilder too. :) (This work is a nicely separable sub-set of larger work needed to move the TreeBuilder.) We welcome your thoughts and comments. 1. https://docs.google.com/spreadsheet/ccc?key=0AlC4tS7Ao1fIdGtJTWlSaUItQ1hYaDFDcWkzeVAxOGc#gid=0 (Epic thanks to Nat Duca for helping us collect that data.) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Feature Announcement: Moving HTML Parser off the Main Thread
On Wed, Jan 9, 2013 at 7:35 PM, Benjamin Poulain benja...@webkit.org wrote: On Wed, Jan 9, 2013 at 7:07 PM, Eric Seidel e...@webkit.org wrote: On Wed, Jan 9, 2013 at 6:38 PM, Oliver Hunt oli...@apple.com wrote: How will we ensure thread safety? Even at just the tokenizing level don't we use AtomicString? AtromicString isn't threadsafe wrt StringImpl IIRC so this seems like it sould add a world of hurt. AtomicString is already usable from other threads (http://trac.webkit.org/changeset/38094), but are correct this is the core concern! PickledToken (or whatever it's called) will have to be written very carefully in order to minimize/eliminate copies, while still guaranteeing thread safety. The correct design and handling of PickledToken is the entire question of this whole endeavor. That is probably what you meant, but just in case... AtomicString can be used from different threads, but is not thread safe. You must make an isolatedCopy() for message passing if you keep a reference to the String in your thread. Not the end of the world, but something to be aware of :) Yeah, we're aware of this issue. We'll probably end up doing something slightly customized for this use case. For example, many of the AtomicStrings used in parsing are tag and attribute names that are known at compile time (e.g., div, href). When moving these strings back to the main thread, we need only the hash of the string and not the underlying characters in the string (because we know statically that the hash will exist in the main thread's atomic string table). It's tempting to optimize these things prematurely. We'll likely start with a simple approach that makes copies and then optimize away the copies over the development of the feature as indicated by profiles. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Update on removing webkitPostMessage
Based on our discussion in September, the Chromium port has been shipping for a while with webkitPostMessage compiled out. We've been monitoring our support channels and haven't found any reports of compatibility problems. (By way of comparison, we did find some compatibility problems with removing WebKitBlobBuilder, but we were able to resolve those with evangelism.) Based on this experience and my scouring the web for uses of webkitPostMessage, I think it's safe to remove the prefixed version of the API: https://bugs.webkit.org/show_bug.cgi?id=105910 In my web searches, I did manage to find a couple developers who were using the prefixed version of the API, but I contacted them directly and they've now changed their content to use the identical (unprefixed) postMessage API. Thanks, Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Possible device scale factor emulation approaches?
On Wed, Dec 5, 2012 at 10:44 PM, Alexander Pavlov apav...@chromium.org wrote: On Thu, Dec 6, 2012 at 5:36 AM, Dana Jansens dan...@chromium.org wrote: On Wed, Dec 5, 2012 at 8:28 PM, Adam Barth aba...@webkit.org wrote: On Wed, Dec 5, 2012 at 7:16 AM, Alexander Pavlov apav...@chromium.org wrote: I'm working on emulating the device scale factor with Web Inspector. My goal is to let web developers see their pages on normal (device pixel ratio == 1) monitors the way they would look on e.g. retina screens. Page::setDeviceScaleFactor() is not something we can use, since it will have the reverse effect when used by platform-specific compositor code (which I saw on Chromium, and its compositor is far from being ready for such abnormal treatment.) I'm not sure I fully understand what you're trying to accomplish. Is the developer using a high density screen or a low density screen? A low density screen is used (that's what I meant by normal (device pixel ratio == 1) monitors). Imagine two 24 monitors, one high-density (H) and one low-density (L), standing next to each other. I want any page to be rendered exactly the same both on H and L monitor. So, @media and image set elements should be chosen as if L monitor were H, but then the respective images/glyphs/whatever downscaled to match the visible size of the same items in the H monitor. I'm not sure I understand. L has fewer pixels than H. It's not clear how two things can render exactly the same given that they'll render using a different number of pixels. Chromium has a command line option for setting a fake device pixel ratio. For example, if you're using a low density screen, you can pass something like --device-pixel-ratio 2 to ask Chromium to render as if your device has a high density display. The net effect is that the glyphs get really big (since they use 2x the pixels in each dimension). Alternatively, I can imagine that the developer is using a high density screen but wants to develop a web site that looks good on a low density screen. In that case, they want to set a --device-pixel-ratio 1 but then render the web page pixel doubled (i.e., rasterizing each pixel as a 2x2 quad). I don't think there's a command line option for that in Chromium, but it's something you might reasonably do in the compositor. Naturally, but I would prefer not to touch the compositor code, as it is currently converging to the hardware-accelerated Ash implementation, and it's going to take a while until the dust settles down. That's not really a good reason to pick an inferior design. In general, though, trying to shim this feature into WebCore isn't likely the right approach. For WebKit2, for example, both the UI process and the web process need to agree about the device pixel ratio or else the system gets confused about how big various regions of memory ought to be. If you look at how we test high density rendering That's one reason why I do not want to fiddle with ACTUAL device pixel ratios (the same holds for the WebCore and compositor code in Chromium; the compositor code in desktop Chromium (non-Ash) is not ready to see anything other than 1 as device pixel ratio (WebViewImpl::setPageScaleFactor() has the following comment, Don't allow page scaling when compositor scaling is being used, as they are currently incompatible.)). What value do you want to return from window.devicePixelRatio? If you're going to return 1 on L but 2 on H, then the two are unlikely to render similarly as JavaScript on the page is likely to branch (or select subresources) based on that value. on low density machines, you'll see that we override the device's actual pixel density via the WebKit/WebKit2 API. That's to avoid this confusion. Yes, this is exactly my scenario - render pages on low-density (DPR==1) monitors as if they were high-density (DPR==2 or something else.) So, if the device's actual pixel density is overridden in WebKit/WebKit2, will glyphs and images get 2x bigger than those without the override? My goal is to have them visually remain the same size (because 1 CSS pixel should still correspond to 1 device pixel, as DPR==1 for low-density screens) along with the @media rules and -webkit-image-set elements (and perhaps some other things) appropriate for DPR==2 taking effect (downscaling larger 2x DPR images where applicable, so that they will look as if they were rendered on a high-density screen.) Do you think this can be emulated through the page settings, same was as the touch emulation (WebCore::Settings::setTouchEventEmulationEnabled()) instead? That's a super strange rendering mode. I took the approach of instrumenting the WebCore/css and WebCore/page code relying on the page-deviceScaleFactor() value. This worked pretty well, and you can see the respective patch at https://bugs.webkit.org/attachment.cgi?id=172046action=prettypatch (https
Re: [webkit-dev] Possible device scale factor emulation approaches?
On Wed, Dec 5, 2012 at 7:16 AM, Alexander Pavlov apav...@chromium.org wrote: I'm working on emulating the device scale factor with Web Inspector. My goal is to let web developers see their pages on normal (device pixel ratio == 1) monitors the way they would look on e.g. retina screens. Page::setDeviceScaleFactor() is not something we can use, since it will have the reverse effect when used by platform-specific compositor code (which I saw on Chromium, and its compositor is far from being ready for such abnormal treatment.) I'm not sure I fully understand what you're trying to accomplish. Is the developer using a high density screen or a low density screen? Chromium has a command line option for setting a fake device pixel ratio. For example, if you're using a low density screen, you can pass something like --device-pixel-ratio 2 to ask Chromium to render as if your device has a high density display. The net effect is that the glyphs get really big (since they use 2x the pixels in each dimension). Alternatively, I can imagine that the developer is using a high density screen but wants to develop a web site that looks good on a low density screen. In that case, they want to set a --device-pixel-ratio 1 but then render the web page pixel doubled (i.e., rasterizing each pixel as a 2x2 quad). I don't think there's a command line option for that in Chromium, but it's something you might reasonably do in the compositor. In general, though, trying to shim this feature into WebCore isn't likely the right approach. For WebKit2, for example, both the UI process and the web process need to agree about the device pixel ratio or else the system gets confused about how big various regions of memory ought to be. If you look at how we test high density rendering on low density machines, you'll see that we override the device's actual pixel density via the WebKit/WebKit2 API. That's to avoid this confusion. I took the approach of instrumenting the WebCore/css and WebCore/page code relying on the page-deviceScaleFactor() value. This worked pretty well, and you can see the respective patch at https://bugs.webkit.org/attachment.cgi?id=172046action=prettypatch (https://bugs.webkit.org/show_bug.cgi?id=100762), but now I'm wondering if there are better ways to implement this without instrumenting lots of page-deviceScaleFactor() call sites. Comments, ideas, suggestions, please? If you want to see how this is done in Chromium, you might want to study the --device-pixel-ratio command line flag. In general, I don't think you want to try to implementing this feature by hacking WebCore as it requires coordination beyond WebCore to do correctly. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] commit-queue offline for the rest of the day
There's some problem with the commit-queue failing with some git error. I'm taking it offline for the rest of the day. Hopefully I'll figure it out tonight. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] commit-queue offline for the rest of the day
Both the commit hashes mentioned in the log appear to be real hashes from today, about ten revisions apart. I'm not enough of a git expert to understand what's going on. Adam On Tue, Dec 4, 2012 at 2:49 PM, Osztrogonac Csaba o...@inf.u-szeged.hu wrote: Hi, Is it possible if http://git.chromium.org/external/Webkit is broken? Or somebody pushed non fast forward commits? Maybe a manual kick can help: git reset --hard HEAD~1000 git clean -dxf git pull These lines always helped me if something went wrong on my git repository. Ossy Eric Seidel írta: An example of the git failures can be found here: http://queues.webkit.org/results/15120956 (For any with git-knowledge who might know what's wrong.) On Tue, Dec 4, 2012 at 12:36 PM, Adam Barth aba...@webkit.org wrote: There's some problem with the commit-queue failing with some git error. I'm taking it offline for the rest of the day. Hopefully I'll figure it out tonight. Adam ___ 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
[webkit-dev] Multiprocess networking in WebKit
There's been a somewhat fragmented discussion across webkit-dev and various bugs about how we ought to approach multiprocess networking in WebKit. In an attempt to organize my thoughts, I wrote up a short design document that compares various approaches: https://docs.google.com/document/d/1ihpwbiG_EDirnLibkkglEtyFoEEcf7t9XNAn8JD4fQY/edit My hope is that this document will be useful as a starting point for discussion. If other folks have written similar documents, those might make valuable contributions to the discussion as well. I welcome your feedback, either via comments in the document or via this email thread. Thanks, Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] pointer events specification - first editors draft
On Wed, Nov 28, 2012 at 5:53 PM, Benjamin Poulain benja...@webkit.org wrote: On Wed, Nov 28, 2012 at 8:23 AM, Adam Barth aba...@webkit.org wrote: I'm sympathetic to these concerns, but, unfortunately, I don't see any other path that leads to interoperability with Internet Explorer. Currently, there is little to no content that supports pointer events. There is also little to no demand for it for the reasons I mentioned before. It seems very likely that authors will write content that uses pointer events given that it's the only way to learn about touch input on IE 10 on Windows 8. If we don't implement pointer events, all of these web sites are going to have separate code paths for IE+Firefox and for Safari+Chrome. If we wait for this content to be authored before implementing pointer events, we'll have dug ourselves a deep hole that we'll spend years crawling out of. I would prefer WebKit to be wise and wait for either good use cases, or a better spec. In my view, the wise course of action is for all user agents to implement an interoperable set of input events so that authors don't need to have separate code paths for different user agents. As far as I can tell, the only candidate for those events are pointer events. I asked you before if you knew of any other paths to interoperability and you didn't respond. (Of course, that doesn't mean we should slavishly implement whatever Microsoft proposes. That's why there's a working group in the W3C: to refine and improve the feature's design and specification.) Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Feature announcement: HTMLTemplateElement
On Thu, Nov 29, 2012 at 9:23 PM, Glenn Adams gl...@skynav.com wrote: On Thu, Nov 29, 2012 at 10:00 PM, Ryosuke Niwa rn...@webkit.org wrote: On Thu, Nov 29, 2012 at 8:55 PM, Glenn Adams gl...@skynav.com wrote: On Wed, Nov 28, 2012 at 1:31 PM, Rafael Weinstein rafa...@chromium.org wrote: Hello, WebKit! I plan to start landing the implementation of the HTMLTemplateElement (behind a compile flag). The spec is here: http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html A recent discussion on public-webapps explored the issue and considered alternative approaches, but ultimately converged back to the semantics described in the spec above. The spec has support from Microsoft. Google (spec authors) and Mozilla. How much support? Have they implemented? Deployed? What test suites are available? What is the W3C plan for adopting this feature in the official W3C HTML5.* spec track? We don’t typically require test suites to be available prior to implementing it in WebKit or it be in the official HTML5 specification. I didnt' suggest it was. However, if test suites are not available, then I would wonder about the maturity and or consensus status within the W3C arena. I ask because I'm curious about the maturity/stability of this feature. I also find it useful to apply a degree of caution to features that are coming from WHATWG if there is no counter-commitment to move those features forward in the official W3C REC track. Our intention is to move these this spec through the W3C REC process and update the implementation as the spec evolves. As Maciej says, there has already been a good deal of discussion about this spec in the WebApps working group. It's not clear to me whether it's more appropriate for the WebApps working group (where much if the other web components work is taking place) or the HTML working group (where HTML parsing is defined). I'm sure that's something we'll need to discuss with the chairs and the W3C team at the appropriate time. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Github vs. git.webkit.org
On Wed, Nov 28, 2012 at 3:53 AM, Tor Arne Vestbø tor.arne.ves...@digia.com wrote: On 11/25/12 1:12 , Adam Barth wrote: On Sat, Nov 24, 2012 at 1:53 PM, Gergely Kis gerg...@homejinni.com wrote: Yes, I saw that thread, but I got confused by this other thread: https://lists.webkit.org/pipermail/webkit-dev/2012-April/020339.html Here most of the participants seemed to agree that moving the 2 repositories to use the same SHA ids is the best course of action. Unfortunately, the folks who maintain the mirror don't appear to agree. Given that they've been gracious enough to let us use their mirror, it's hard for us to ask them to change how they run it. This is not accurate. I replied directly to you Adam based on the above mentioned thread, countering a few points from the thread, but closing off by saying that if the consensus was that syncing the mirrors was the way to go, I was perfectly fine with that too. I still am -- all it takes is someone letting me know when to stop pushing and to do the mentioned force-push. Oh, I must have misunderstood your message. My sense is that the WebKit community would prefer that the hashes in GitHub match the hashes in git.webkit.org so that folks can more easily move branches between the two. For my part, I've switched over to using GitHub exclusive of git.webkit.org, so the the difference in hashes aren't an issue for me, but I can understand why they'd be problematic for other people. After the force-push, would you still be able to push updates automatically? If so, you can switch the hashes whenever is convenient for you. (It might be nice to announce the date/time on this list so that folks aren't taken by surprise.) Thanks for letting us use your mirror. I've found it very useful to be able to push work-in-progress branches to GitHub to share with folks. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] pointer events specification - first editors draft
It looks like this thread got dropped over Thanksgiving. (Responses inline.) On Thu, Nov 22, 2012 at 1:43 PM, Benjamin Poulain benja...@webkit.org wrote: On Wed, Nov 21, 2012 at 2:42 PM, Rick Byers rby...@chromium.org wrote: Outside of the design details, are there any thoughts or concerns about WebKit getting an implementation of pointer events at some point? In my opinion, the pointer events spec is a bad idea (at least, in its current state). I think adding it to WebKit would be hurting both the Web and WebKit. The premise of the specification is that using mouse event and touch events interchangeably is needed. In reality, nobody was really asking for that because it is a terrible idea. You can already easily unify pen, touch and mouse by writing very little JavaScript, but it is only useful in very few cases. For the common case, where you want to use touch and mouse events differently, the pointer events makes it harder to write correct code. Each event have a set of attributes with different meaning depending on the event type. I'm sympathetic to these concerns, but, unfortunately, I don't see any other path that leads to interoperability with Internet Explorer. As far as I can tell, the underlying problem is that Apple as not made the usual IPR commitments regarding touch events. For example, Apple has not joined the Web Events Working Group in the W3C [1]. As a result, Microsoft has chosen to implement pointer events in Internet Explorer rather than touch events. Moreover, Microsoft has been willing to support the openness of the web platform by joining the Pointer Events Working Group in the W3C [2]. Do you see another path that leads to interoperability? I also think there are some serious issues with the spec. If you would like to provide technical feedback about the specification, please join the W3C Pointer Events Working Group and provide the feedback in that forum. Adam [1] http://www.w3.org/2000/09/dbwg/details?group=45559public=1gs=1 [2] http://www.w3.org/2000/09/dbwg/details?group=59096public=1gs=1 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Custom V8 bindings for WebWorkers
Sounds like a reasonable idea. Would you be willing to file a bug and write a patch? Adam On Mon, Nov 26, 2012 at 3:18 PM, Marshall Greenblatt magreenbl...@gmail.com wrote: Hi All, Applications embedding WebKit and Chromium can use existing C++ APIs to dynamically add custom V8 JavaScript bindings. These bindings allow closer integration between the script execution environment and the host application and are currently supported for page contexts via the FrameLoaderClient::didCreateScriptContext callback. However, custom V8 bindings are not currently supported for WebWorkers. Combining the multi-threaded capabilities of WebWorkers with the flexibility offered by custom V8 bindings would be an extremely useful feature for some applications. How would people feel about exposing a V8 binding capability for WebWorkers? Would adding new callbacks similar to Platform::didStartWorkerRunLoop and Platform::didStopWorkerRunLoop be a reasonable implementation approach? Thanks, Marshall ___ 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] Github vs. git.webkit.org
On Sat, Nov 24, 2012 at 1:53 PM, Gergely Kis gerg...@homejinni.com wrote: Yes, I saw that thread, but I got confused by this other thread: https://lists.webkit.org/pipermail/webkit-dev/2012-April/020339.html Here most of the participants seemed to agree that moving the 2 repositories to use the same SHA ids is the best course of action. Unfortunately, the folks who maintain the mirror don't appear to agree. Given that they've been gracious enough to let us use their mirror, it's hard for us to ask them to change how they run it. In any case, if the github repo is the way to go now, then we will do the transition... That's likely the path of least resistance. Adam On Sat, Nov 24, 2012 at 10:48 PM, Eric Seidel e...@webkit.org wrote: This has come up in the past. I believe the current recommended path is to use the github.com SHAs and just live in a github-only world. https://lists.webkit.org/pipermail/webkit-dev/2012-March/020002.html has some discussion. https://trac.webkit.org/wiki/UsingGitHub I am not aware of any plan to change the SHAs in the github mirror or git.webkit.org (which is unfortunate, but the current reality). -eric On Sat, Nov 24, 2012 at 3:39 PM, Gergely Kis gerg...@homejinni.com wrote: Hi, It looks like that the github mirror and git.webkit.org still has different SHA ids for commits. Is this final, or is the plan still to switch to the git.webkit.org SHA ids? For our MIPS staging repository we created a new mirror on github from git.webkit.org, and now we were asked by the github admins to reduce the repository to less than 1GB. I assume that if we would fork from the github.com/WebKit/webkit repository, then it would be fine with the github admins. However, if it is still the plan to switch to the git.webkit.org SHA ids in the github mirror as well, then we would like to avoid the extra work of rebasing our work to the github mirror commits, and then rebasing it back when the transition is made. We have to decide in the next couple days, because github will disable access to our repository again, so any status update on this transition plan would be helpful. Alternatively, if you have any experience with the github admins in how to ask for more space for webkit repositories, any advice would be very appreciated. Best Regards, Gergely Kis ___ 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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] r- your own patches [was: Re: RenderArena: Teaching an old dog new tricks]
On Thu, Nov 15, 2012 at 4:28 PM, Mike Lawther mikelawt...@google.com wrote: On 16 November 2012 09:59, Ryosuke Niwa rn...@webkit.org wrote: While I don’t want to further agitate the issue or go off on a tangent, and agree that we must address the security aspect before getting rid of RenderArena, only WebKit reviewers can r- patches written by other contributors. You’re not even supposed to set r- on your own patches. See http://www.webkit.org/coding/commit-review-policy.html I see that page says 'Note that you should not put r+ nor r- on patches in such unofficial reviews' with respect to a non-reviewer doing a shadow review. I can't see the extrapolation from that to 'you can't r- your own patches'. I thought r-'ing your own patch was a relatively common practice when uploading a WIP patch, as a signal that 'I have no intention of landing this patch', and as a courtesy so a reviewer will not waste any time looking at it (unless specifically asked). I don't see why I wouldn't be allowed to r- my own patch? It seems fine to r- your own patch. You can also clear the review flag if you're not interested in having someone review your patch. If you want to upload a work-in-progress patch, one pattern I use is the following: webkit-patch upload --no-review -m Work-in-progress That will avoid setting the review flag and will label the patch as a work in progress. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Is UseV8.cmake still used?
On Sun, Nov 11, 2012 at 6:09 PM, Hajime Morrita morr...@chromium.org wrote: IIRC, Android (non-Chrome) uses V8. I'm not sure whether PLATFORM(CHROMIUM) is on there. non-Chromium Android is no longer supported on trunk. On Sun, Nov 11, 2012 at 6:32 PM, Ryosuke Niwa rn...@webkit.org wrote: The last time I checked, Qt folks were interested in being able to use V8 as well as JSC. I'm not sure if their needs have changed since then. I don't believe they are anymore. 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
To update this thread: I've now got this working in the V8 bindings.
The next step is to make this work in the JSC bindings. If you're
interested in the details, the work will occur on
https://bugs.webkit.org/show_bug.cgi?id=101279.
On Thu, Nov 1, 2012 at 10:51 AM, Alexey Proskuryakov a...@apple.com wrote:
Do you have a rough estimate of how large of a win we are talking about?
As a simple example, adding ScriptWrappable as a base class for
DOMImplementation makes document.implementation 23% faster, at least
as measured with the V8 bindings (see
https://bug-101279-attachments.webkit.org/attachment.cgi?id=172440).
Although I doubt that document.implementation itself is a performance
bottleneck, using ScriptWrappable more widely seems likely to improve
both performance and memory usage.
On Thu, Nov 1, 2012 at 4:10 PM, Maciej Stachowiak m...@apple.com wrote:
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.
Do you have a suggestion for what data to use? As far as I can tell,
adding ScriptWrappable as a base class is a win whenever at least half
of the instances of the object have JavaScript wrappers (in the main
world):
A) It's always faster to get and set the JavaScript wrapper with
ScriptWrappable.
B) In terms of memory, we pay 1*sizeof(void*) for every instance with
ScriptWrappable compared to 2*sizeof(void*) for every instance that
has a JavaScript wrapper in the non-ScriptWrappable case (discounting
the fact that Hashtable actually seems to keep a constant fraction of
its buckets free).
(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.
Turns out we don't need the IDL attribute (see the next question).
(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.
Thanks for the suggestion. I got this work (at least for the V8
bindings---JSC is next on my list). To make something
ScriptWrappable, you just need to add ScriptWrappable as a base class:
-class DOMImplementation {
+class DOMImplementation : public ScriptWrappable {
I'm not super excited about the name given that all DOM objects are
wrappable by script. If folks have thoughts about a better name, I'd
appreciate suggestions.
Thanks,
Adam
On Thu, Nov 1, 2012 at 10:36 AM, 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
