Re: [webkit-dev] webkit-resource: referring to resources in User Agent stylesheet
On Tue, Apr 26, 2011 at 7:50 PM, Maciej Stachowiak wrote: > > On Apr 26, 2011, at 1:45 PM, Dimitri Glazkov wrote: > >> On Tue, Apr 26, 2011 at 1:27 PM, Jer Noble wrote: >>> >>> >>> FWIW, WebKit/mac generates these images programmatically, so there's not >>> really a URL for "play button hover state" which can be targeted. That >>> said, if the URL scheme could be overloaded to handle generated content, I >>> guess this could still work. WebKit/mac could either parse the URL path and >>> special case "media-controls/play-button-hover.png", or define our own URL >>> scheme, e.g. "background: >>> url(webkit-generated:media-play-button-playing-hover);" But then we're just >>> back to something functionally identical to -webkit-appearance. >>> I guess what I'm getting at is, if support for webkit-resource: is added, >>> great. However, at least one port will still need the old behavior. >> >> Yes! The -webkit-appearance must stay. This is purely an additive thing. > > Would we end up with different stylesheets for different ports, then? (Or is > media control styling already different between ports?) Yeah, it's already different. :DG< > > Regards, > Maciej > > > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] webkit-resource: referring to resources in User Agent stylesheet
On Apr 26, 2011, at 1:45 PM, Dimitri Glazkov wrote: > On Tue, Apr 26, 2011 at 1:27 PM, Jer Noble wrote: >> >> >> FWIW, WebKit/mac generates these images programmatically, so there's not >> really a URL for "play button hover state" which can be targeted. That >> said, if the URL scheme could be overloaded to handle generated content, I >> guess this could still work. WebKit/mac could either parse the URL path and >> special case "media-controls/play-button-hover.png", or define our own URL >> scheme, e.g. "background: >> url(webkit-generated:media-play-button-playing-hover);" But then we're just >> back to something functionally identical to -webkit-appearance. >> I guess what I'm getting at is, if support for webkit-resource: is added, >> great. However, at least one port will still need the old behavior. > > Yes! The -webkit-appearance must stay. This is purely an additive thing. Would we end up with different stylesheets for different ports, then? (Or is media control styling already different between ports?) Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Optional parameter in IDL and undefined JS value
To be clear, the reason "undefined" converts to 0 in this case is because the argument uses Web IDL type "long", so the argument is converted using ToInt32 (defined in ECMA-262 in terms of ToNumber). ToNumber converts undefined to NaN, and ToInt32 then converts NaN to +0. -Ken On Tue, Apr 26, 2011 at 1:34 PM, Jian Li wrote: > Kenneth pointed out that NaN should then be converted to 0 per ECMA. So > we're doing the right thing in our code generators. Since File API has been > updated to get this issue clarified, we're fine here with nothing particular > that needs to be done. Thanks for all your help. > > On Mon, Apr 25, 2011 at 4:43 PM, Jian Li wrote: >> >> Please see inline for the reply from the spec author Arun about your >> questions. >> >> Arun has updated Blob.slice in the File API spec to explicitly illustrate >> the case for optional end parameter. >> >> If the optional end parameter is not used as a parameter when making this >> call, let relativeEnd be size. >> >> For undefined value being passed to optional numeric parameter, should we >> consider following ECMA-262 (referred from Web IDL) that defines the >> conversion of undefined to "NaN" (see Table 12 in Section 9.3)? >> >> > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] webkit-resource: referring to resources in User Agent stylesheet
It would be extremely easy to limit it to UA sheets only.
:DG<
On Tue, Apr 26, 2011 at 2:05 PM, Sam Weinig wrote:
> Would we want this to be web facing? Or should we limit it to inside the
> built-in stylesheets?
>
> -Sam
>
> On Apr 26, 2011, at 1:18 PM, Dimitri Glazkov wrote:
>
>> Hello,
>>
>> SUMMARY: we would like to introduce a "webkit-resource" URL scheme for
>> CSS, which would refer to images baked into WebKit.
>>
>> BACKGROUND: in order to style media controls today, we rely on the
>> ControlPart enum
>> (http://codesearch.google.com/codesearch/p#OAMlx_jo-ck/src/third_party/WebKit/Source/WebCore/platform/ThemeTypes.h&l=48&exact_package=chromium),
>> which is exposed as the -webkit-appearance CSS attribute. For
>> example:
>>
>> video::-webkit-media-controls-play-button {
>> -webkit-appearance: media-play-button;
>> }
>>
>> In addition, the state of the button is further adjusted by looking at
>> the runtime state or media characteristics of the element (is the user
>> currently hovering or clicking on the element? is it playing? is it
>> streaming? has an error occurred?). This happens at the port layer, in
>> RenderTheme implementation.
>>
>> With impending introduction of media element pseudo-classes and the
>> patch in bug 58342 landing, we will be able to sense these extra
>> states at the CSS level:
>>
>> video:playing::-webkit-media-controls-play-button:hover {
>> -webkit-appearance: media-play-button-playing-hover;
>> }
>>
>> This would result in a lot less of mindless style-flipping
>> RenderTheme/MediaControlElement code and provide more flexibility for
>> each port to design their pretty things.
>>
>> However, sticking with existing -webkit-appearance strategy will
>> result in ControlPart enum exploding as combinatorial math suggests.
>> Which is a ...
>>
>> PROBLEM: We need a way to somehow in CSS associate an element state
>> with a relatively arbitrary key to avoid ControlPart from becoming the
>> tallest enum ever.
>>
>> SOLUTION: Looking at the current media controls implementations, most
>> of the -webkit-appearance states are kind of like background images,
>> each reflecting appearance of an element at a particular state. Thus,
>> it seems we should be able to solve this by just using CSS
>> backgrounds:
>>
>> video:playing::-webkit-media-controls-play-button:hover {
>> background: url(/media-controls/play-button-hover.png);
>> }
>>
>> That is how the authors would style the media controls. However, at
>> the UA level, we shouldn't probably be loading resources from random
>> sites. Instead, we need a way to bake these images into the WebKit
>> runtime, and then a way to refer to them from the stylesheet.
>>
>> This is where a vendor-specific URL scheme comes in:
>>
>> video:playing::-webkit-media-controls-play-button:hover {
>> background: url(webkit-resource:/media-controls/play-button-hover.png);
>> }
>>
>> A quick poll of smart people (abarth and smfr) seems to indicate it's
>> not a completely horrid idea.
>>
>> WDYT? Thoughts? Comments?
>>
>> :DG<
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] webkit-resource: referring to resources in User Agent stylesheet
Would we want this to be web facing? Or should we limit it to inside the
built-in stylesheets?
-Sam
On Apr 26, 2011, at 1:18 PM, Dimitri Glazkov wrote:
> Hello,
>
> SUMMARY: we would like to introduce a "webkit-resource" URL scheme for
> CSS, which would refer to images baked into WebKit.
>
> BACKGROUND: in order to style media controls today, we rely on the
> ControlPart enum
> (http://codesearch.google.com/codesearch/p#OAMlx_jo-ck/src/third_party/WebKit/Source/WebCore/platform/ThemeTypes.h&l=48&exact_package=chromium),
> which is exposed as the -webkit-appearance CSS attribute. For
> example:
>
> video::-webkit-media-controls-play-button {
> -webkit-appearance: media-play-button;
> }
>
> In addition, the state of the button is further adjusted by looking at
> the runtime state or media characteristics of the element (is the user
> currently hovering or clicking on the element? is it playing? is it
> streaming? has an error occurred?). This happens at the port layer, in
> RenderTheme implementation.
>
> With impending introduction of media element pseudo-classes and the
> patch in bug 58342 landing, we will be able to sense these extra
> states at the CSS level:
>
> video:playing::-webkit-media-controls-play-button:hover {
> -webkit-appearance: media-play-button-playing-hover;
> }
>
> This would result in a lot less of mindless style-flipping
> RenderTheme/MediaControlElement code and provide more flexibility for
> each port to design their pretty things.
>
> However, sticking with existing -webkit-appearance strategy will
> result in ControlPart enum exploding as combinatorial math suggests.
> Which is a ...
>
> PROBLEM: We need a way to somehow in CSS associate an element state
> with a relatively arbitrary key to avoid ControlPart from becoming the
> tallest enum ever.
>
> SOLUTION: Looking at the current media controls implementations, most
> of the -webkit-appearance states are kind of like background images,
> each reflecting appearance of an element at a particular state. Thus,
> it seems we should be able to solve this by just using CSS
> backgrounds:
>
> video:playing::-webkit-media-controls-play-button:hover {
> background: url(/media-controls/play-button-hover.png);
> }
>
> That is how the authors would style the media controls. However, at
> the UA level, we shouldn't probably be loading resources from random
> sites. Instead, we need a way to bake these images into the WebKit
> runtime, and then a way to refer to them from the stylesheet.
>
> This is where a vendor-specific URL scheme comes in:
>
> video:playing::-webkit-media-controls-play-button:hover {
> background: url(webkit-resource:/media-controls/play-button-hover.png);
> }
>
> A quick poll of smart people (abarth and smfr) seems to indicate it's
> not a completely horrid idea.
>
> WDYT? Thoughts? Comments?
>
> :DG<
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] webkit-resource: referring to resources in User Agent stylesheet
On Tue, Apr 26, 2011 at 1:27 PM, Jer Noble wrote:
>
> On Apr 26, 2011, at 1:18 PM, Dimitri Glazkov wrote:
>
> SOLUTION: Looking at the current media controls implementations, most
> of the -webkit-appearance states are kind of like background images,
> each reflecting appearance of an element at a particular state. Thus,
> it seems we should be able to solve this by just using CSS
> backgrounds:
>
> video:playing::-webkit-media-controls-play-button:hover {
> background: url(/media-controls/play-button-hover.png);
> }
>
> That is how the authors would style the media controls. However, at
> the UA level, we shouldn't probably be loading resources from random
> sites. Instead, we need a way to bake these images into the WebKit
> runtime, and then a way to refer to them from the stylesheet.
>
> This is where a vendor-specific URL scheme comes in:
>
> video:playing::-webkit-media-controls-play-button:hover {
> background: url(webkit-resource:/media-controls/play-button-hover.png);
> }
>
> A quick poll of smart people (abarth and smfr) seems to indicate it's
> not a completely horrid idea.
>
> WDYT? Thoughts? Comments?
>
> FWIW, WebKit/mac generates these images programmatically, so there's not
> really a URL for "play button hover state" which can be targeted. That
> said, if the URL scheme could be overloaded to handle generated content, I
> guess this could still work. WebKit/mac could either parse the URL path and
> special case "media-controls/play-button-hover.png", or define our own URL
> scheme, e.g. "background:
> url(webkit-generated:media-play-button-playing-hover);" But then we're just
> back to something functionally identical to -webkit-appearance.
> I guess what I'm getting at is, if support for webkit-resource: is added,
> great. However, at least one port will still need the old behavior.
Yes! The -webkit-appearance must stay. This is purely an additive thing.
> -Jer
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Optional parameter in IDL and undefined JS value
Kenneth pointed out that NaN should then be converted to 0 per ECMA. So we're doing the right thing in our code generators. Since File API has been updated to get this issue clarified, we're fine here with nothing particular that needs to be done. Thanks for all your help. On Mon, Apr 25, 2011 at 4:43 PM, Jian Li wrote: > Please see inline for the reply from the spec author Arun about your > questions. > > Arun has updated Blob.slice in the File API spec to explicitly illustrate > the case for optional end parameter. > > If the optional end parameter is not used as a parameter when making this > call, let relativeEnd be size. > > > For undefined value being passed to optional numeric parameter, should we > consider following ECMA-262 (referred from Web IDL) that defines the > conversion of undefined to "NaN" (see Table 12 in Section 9.3)? > > > > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Some compile time data
On Apr 26, 2011, at 1:30 PM, David Kilzer wrote: > On Apr 25, 2011, at 4:59 PM, Stephanie Lewis wrote: > >> One point brought up during the compile time discussion today was that if >> you pulled once a day, you were likely to have rebuild the world. I thought >> it would be interesting to see which files were contributing to rebuilding >> the world the most often. >> >> Using the data provided by Mihai at >> http://persistent.info/webkit/tools/buildbot/ I wrote a script to find all >> of the revisions that took ~2x the average time to compile. Then I matched >> that up with the file list from svn log to get an idea of which files are >> triggering world builds the most often (or at least recently). >> >> Of the 500 revisions 152 spiked compile time. >> >> Here are the most common changed files, full data attached. >> >> 12 /trunk/Source/WebCore/bindings/scripts/CodeGeneratorJS.pm >> 12 /trunk/Source/WebCore/bindings/js/JSDOMBinding.h >> 10 /trunk/Source/WebCore/WebCore.exp.in > > Changing WebCore.exp.in should only require relinking WebCore, not > recompiling it, although linking WebCore takes a non-trivial amount of time. > (The WebCoreExportGenerator project will get recompiled, but that's generally > negligible compared to WebCore itself.) It seems likely that WebCore.exp.in is changing in conjunction with other files, in particular header files which are #included by WebKit. -Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Some compile time data
On Apr 25, 2011, at 4:59 PM, Stephanie Lewis wrote: > One point brought up during the compile time discussion today was that if you > pulled once a day, you were likely to have rebuild the world. I thought it > would be interesting to see which files were contributing to rebuilding the > world the most often. > > Using the data provided by Mihai at > http://persistent.info/webkit/tools/buildbot/ I wrote a script to find all of > the revisions that took ~2x the average time to compile. Then I matched that > up with the file list from svn log to get an idea of which files are > triggering world builds the most often (or at least recently). > > Of the 500 revisions 152 spiked compile time. > > Here are the most common changed files, full data attached. > > 12/trunk/Source/WebCore/bindings/scripts/CodeGeneratorJS.pm > 12/trunk/Source/WebCore/bindings/js/JSDOMBinding.h > 10/trunk/Source/WebCore/WebCore.exp.in Changing WebCore.exp.in should only require relinking WebCore, not recompiling it, although linking WebCore takes a non-trivial amount of time. (The WebCoreExportGenerator project will get recompiled, but that's generally negligible compared to WebCore itself.) Dave ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] webkit-resource: referring to resources in User Agent stylesheet
On Apr 26, 2011, at 1:18 PM, Dimitri Glazkov wrote:
> SOLUTION: Looking at the current media controls implementations, most
> of the -webkit-appearance states are kind of like background images,
> each reflecting appearance of an element at a particular state. Thus,
> it seems we should be able to solve this by just using CSS
> backgrounds:
>
> video:playing::-webkit-media-controls-play-button:hover {
> background: url(/media-controls/play-button-hover.png);
> }
>
> That is how the authors would style the media controls. However, at
> the UA level, we shouldn't probably be loading resources from random
> sites. Instead, we need a way to bake these images into the WebKit
> runtime, and then a way to refer to them from the stylesheet.
>
> This is where a vendor-specific URL scheme comes in:
>
> video:playing::-webkit-media-controls-play-button:hover {
> background: url(webkit-resource:/media-controls/play-button-hover.png);
> }
>
> A quick poll of smart people (abarth and smfr) seems to indicate it's
> not a completely horrid idea.
>
> WDYT? Thoughts? Comments?
FWIW, WebKit/mac generates these images programmatically, so there's not really
a URL for "play button hover state" which can be targeted. That said, if the
URL scheme could be overloaded to handle generated content, I guess this could
still work. WebKit/mac could either parse the URL path and special case
"media-controls/play-button-hover.png", or define our own URL scheme, e.g.
"background: url(webkit-generated:media-play-button-playing-hover);" But then
we're just back to something functionally identical to -webkit-appearance.
I guess what I'm getting at is, if support for webkit-resource: is added,
great. However, at least one port will still need the old behavior.
-Jer
smime.p7s
Description: S/MIME cryptographic signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] webkit-resource: referring to resources in User Agent stylesheet
Hello,
SUMMARY: we would like to introduce a "webkit-resource" URL scheme for
CSS, which would refer to images baked into WebKit.
BACKGROUND: in order to style media controls today, we rely on the
ControlPart enum
(http://codesearch.google.com/codesearch/p#OAMlx_jo-ck/src/third_party/WebKit/Source/WebCore/platform/ThemeTypes.h&l=48&exact_package=chromium),
which is exposed as the -webkit-appearance CSS attribute. For
example:
video::-webkit-media-controls-play-button {
-webkit-appearance: media-play-button;
}
In addition, the state of the button is further adjusted by looking at
the runtime state or media characteristics of the element (is the user
currently hovering or clicking on the element? is it playing? is it
streaming? has an error occurred?). This happens at the port layer, in
RenderTheme implementation.
With impending introduction of media element pseudo-classes and the
patch in bug 58342 landing, we will be able to sense these extra
states at the CSS level:
video:playing::-webkit-media-controls-play-button:hover {
-webkit-appearance: media-play-button-playing-hover;
}
This would result in a lot less of mindless style-flipping
RenderTheme/MediaControlElement code and provide more flexibility for
each port to design their pretty things.
However, sticking with existing -webkit-appearance strategy will
result in ControlPart enum exploding as combinatorial math suggests.
Which is a ...
PROBLEM: We need a way to somehow in CSS associate an element state
with a relatively arbitrary key to avoid ControlPart from becoming the
tallest enum ever.
SOLUTION: Looking at the current media controls implementations, most
of the -webkit-appearance states are kind of like background images,
each reflecting appearance of an element at a particular state. Thus,
it seems we should be able to solve this by just using CSS
backgrounds:
video:playing::-webkit-media-controls-play-button:hover {
background: url(/media-controls/play-button-hover.png);
}
That is how the authors would style the media controls. However, at
the UA level, we shouldn't probably be loading resources from random
sites. Instead, we need a way to bake these images into the WebKit
runtime, and then a way to refer to them from the stylesheet.
This is where a vendor-specific URL scheme comes in:
video:playing::-webkit-media-controls-play-button:hover {
background: url(webkit-resource:/media-controls/play-button-hover.png);
}
A quick poll of smart people (abarth and smfr) seems to indicate it's
not a completely horrid idea.
WDYT? Thoughts? Comments?
:DG<
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Dropping support for WML?
I think it's ok to keep WML code if we can avoid the form control issue. We can terminate the form control abstraction for HTML and WML. e.g. - Merge dom/InputElement to html/HTMLInputElement - Merge dom/InputElement to wml/WMLInputElement - Remove dom/InputElement - Copy RenderTextControlSingleLine as RenderTextControlWML - RenderTextControlSingleLine only supports HTMLInputElement - RenderTextControlWML only supports WMLInputElement We would have some duplicated code. But it would be better than the current situation. On Fri, Apr 8, 2011 at 10:08, Darin Adler wrote: On Apr 8, 2011, at 2:09 AM, Ryosuke Niwa wrote: > We have been discussing the possibility of dropping WML support in WebKit on IRC for a while now because > • None of core ports (Mac, Windows, GTK, Qt, & Chromium) use it by default > • Maintenance cost is high I’ll just add one other thing: HTML form element implementations have factoring that are twisted and complicated because of WML in a way that makes working on those classes unpleasant for me. It would make form work considerably easier if we drop WML support. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- TAMURA Kent Software Engineer, Google ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] OSX 64 bit plugin support not ready
On 2011-04-26, at 05:11, Alan Swartz wrote: > That's good to know. It's not the support of the Cocoa event model and > CoreGraphics that appears broken, it's that the code that checks these > options appears to be compiled out by the NP_NO_CARBON #define for 64 bit > builds in PlugInViewMac.mm. > > With the current code, I don't see how any NPAPI plug-ins could work on OSX > on 64-bit builds. It's worth noting that what Kevin stated applies to Netscape plug-ins loaded via the Mac port of WebKit. The Qt port of WebKit uses a different implementation of the Netscape plug-in API than the Mac port. My reading of the Qt NPAPI implementation brings me to a similar conclusion to that which you reached: when NP_NO_CARBON is not defined the code in PluginViewMac.mm will not allow any plug-ins to be loaded. It's also worth noting that there does not appear to be any code in PluginViewMac.mm to deal with the Cocoa event model. This suggests that there is a non-trivial amount of work required in order for it to support plug-ins on 64-bit Mac OS X. - Mark ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit unit test framework
I talked with Dave at the contributor meeting and I think we should try to move our existing tests over to GTest and see if we can get them all to pass and not be any slower. If that is doable, I think we should switch over. If, in the future, we find GTest to not have the features we need and not be hackable enough, we can always go back, and add the features TestWebKItAPI that we want (though that seems unlikely). -Sam On Apr 20, 2011, at 4:01 PM, Sam Weinig wrote: > I am really not an expert on testing frameworks, and just put together > something that met my needs (as has been the tradition in this project). > That said, the only features I like about TestWebKitAPI is that I know how it > works and can hack > it to do what I want, and that it has the ability to run each test in its own > invocation (I also like the color output from the tests, because it's is in > color!) > > So, my questions for people who have used gtest is, "Is it hackable?" What > kind of changes have you had success making? Is a death test as scary as it > sounds? > > -Sam > > > On Apr 18, 2011, at 11:36 AM, David Levin wrote: > >> Issue: There has been a long standing bug to add unit tests to WebKit >> (https://bugs.webkit.org/show_bug.cgi?id=21010). It was also mentioned on >> webkit-dev that it would be helpful in various cases. >> >> Landscape: Surveying WebKit, it is looks like there are at least three >> testing frameworks being used: TestWebKitAPI/WebKitAPITest (in Tools), >> QTest, gtest (in Source/WebKit/chromium/). However, only one TestWebKitAPI >> has been used so far (as far as I can tell) for testing core WebKit items >> like WTF (though I was unaware of TestWebKitAPI until Friday). >> >> It seems like a good way to think about the issue of which to use in general >> in WebKit would be to decide on what would be desired in our framework and >> then see how each matches up. >> >> Here's my take on this. (It may be biased toward what I am familiar with but >> I welcome others to add their own criteria.) >> >> Criteria >> >> Musts: >> Compatible license with WebKit >> Builds/Can be built on the many platforms and build systems supported by >> WebKit (ideally without extra installs). >> Useful: >> Easy to write tests >> Hackable to suit our needs >> Well tested features (to support hackability/stability) >> Supports filtering of tests so you can run just the test you care about (and >> easily listing the tests). >> Supports writing out values when there is test failure. (For example, if the >> is verifying that A == B but that is not true, then the values of A and B >> should be printed.) >> Well documented >> thanks, >> dave >> >> ___ >> webkit-dev mailing list >> webkit-dev@lists.webkit.org >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] API for Handling Browser Fingerprinting
Hi, I am trying to build a set of requirements for an anti-fingerprinting API in WebKit. I have a wiki page where I've started dumping all the things such an API needs to worry about: https://trac.webkit.org/wiki/Fingerprinting >From an implementation point of view I've started by looking at two primary sources for leaking distincitive information about the user: DOM objects and CSS Style sheets. Even though these are hard to solve, by the standards of the other items they are the nearest to low-hanging fruit and the shape of the solution required is relatively straightforward. At the moment, WebKit doesn't offer a dedicated mechanism for managing the information exposed by DOM objects. However it is possible to use something of a side-channel to manage the objects that JSCore does not consider read- only, e.g. Navigator and Screen (since https://bugs.webkit.org/show_bug.cgi?id=41802). In Qt's case, I'm referring to QWebFrame::addToJavaScriptWindowObject(), which allows a client to add a custom object to the DOM and by a happy side-effect also allows you to overload replaceable built-in objects. This approach comes unstuck for read-only objects in JSCore, namely document, window and history. The properties exposed by these objects are mostly stored internally by WebCore or inspected directly from the user's application environment. The same goes for CSS. It seems a good thing, in it's own right, for WebCore to pass this sort of inspection through WebKit so that ports can decide the level of client delegation required, e.g. through FrameLoaderClient or ChromeClient. I've submitted patches for this at: https://bugs.webkit.org/show_bug.cgi?id=56274 (DOM) https://bugs.webkit.org/show_bug.cgi?id=56482 (CSS) Note that I'm talking primarily about a client-facing API rather than a web-facing API that can be used by extensions. This is a product of my own use-case - which is a browser that implements an anti-fingerprinting policy itself. A web-facing API faces inherent problems with sites circumventing it maliciously - see https://www.torproject.org/torbutton/en/design/#jshooks and the links to side-stepping overloading firefox's window object there. I'm not saying this is a problem that exists in WebKit too, but it is a problem to which client-facing API is much less vulnerable. So can you guys give me some feedback on this? Am I going the right way about exposing the user's environment information to the port and client in 56274 and 56482? Thanks, Robert - ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] OSX 64 bit plugin support not ready
That's good to know. It's not the support of the Cocoa event model and CoreGraphics that appears broken, it's that the code that checks these options appears to be compiled out by the NP_NO_CARBON #define for 64 bit builds in PlugInViewMac.mm. With the current code, I don't see how any NPAPI plug-ins could work on OSX on 64-bit builds. Alan From: Kevin Decker To: Alan Swartz Cc: Avi Drissman ; webkit-dev@lists.webkit.org Sent: Tue, April 26, 2011 12:25:06 AM Subject: Re: [webkit-dev] OSX 64 bit plugin support not ready On Apr 25, 2011, at 2:43 PM, Alan Swartz wrote: I thought as you do that "Theoretically, a plugin with a Cocoa event model and CoreGraphics drawing should work". > The combination of NPDrawingModelCoreGraphics and NPEventModelCocoa has been supported since Safari 4. -kd___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
