[webkit-dev] Use dashboard region to support dragging frameless window in chromium extensions

2012-06-21 Thread Jian Li
Hi,

In Chromium port, we're working on supporting frameless windows for
extensions, that allow the web contents to have complete control of the
window. Frameless windows do not have the standard frame and the web
contents cover the whole window. Thus we need to provide a way to let the
web contents denote which part of the content area can be used to drag the
window. For example, the web contents draw the custom titlebar with the
icon, title, close button and etc. We want to let the user be able to drag
the titlebar in order to move the window around.

WebKit has already implemented the dashboard region support and exposed a
special CSS property -webkit-dashboard-region that lets you specify regions
for certain purpose, i.e. being excluded from dragging. The syntax of this
property is:
 -webkit-dashboard-region: dashboard-region(label geometry-type
offset-top offset-right offset-bottom offset-left)

Is it OK to reuse the dashboard region implementation to provide a way for
frameless windows to know about draggable regions? Can we introduce another
CSS property -webkit-widget-region, that is essentially a synonym of
-webkit-dashboard-region, since we do not want to get confused with
dashboard region support in Apple/WebKit. How do you think about this
approach?
 -webkit-widget-region: region(label geometry-type offset-top
offset-right offset-bottom offset-left)

Currently the existing dashboard region codes are wrapped inside the
feature guard ENABLE(DASHBOARD_SUPPORT). We're considering of putting this
new CSS property in a new feature guard, like ENABLE(WIDGET_REGION_SUPPORT)
such that -webkit-dashboard-region is only provided
under ENABLE(DASHBOARD_SUPPORT) as it is now and -webkit-widget-region
is only exposed under ENABLE(WIDGET_REGION_SUPPORT). How do you think?


Thanks,

Jian
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Separating ENABLE(NOTIFICATIONS) and ENABLE(LEGACY_NOTIFICATIONS)

2012-03-13 Thread Jian Li
Jon, could you please provide what are going to be included in
LEGACY_NOTIFICATIONS? Does LEGACY_NOTIFICATION only includes HTML
notification and old syntax we're considering to deprecate?

Jian


On Mon, Mar 12, 2012 at 7:11 PM, Adam Barth aba...@webkit.org wrote:

 That sounds like a good approach.  Chromium will likely need to
 remember to disable NOTIFICATIONS on any upcoming release branches
 (until the work is complete).

 Adam


 On Mon, Mar 12, 2012 at 6:58 PM, Jon Lee jon...@apple.com wrote:
  Hi WebKit!
 
  In order to ease the migration path for the nascent notifications API,
 I'd like to separate the current dependency between NOTIFICATION and
 LEGACY_NOTIFICATIONS. Currently, in order to support the legacy API, both
 defines are needed, but ends up also including the new API.
 
  Since the future is to eventually move to the spec'd API, I like to
 separate the two defines, so that NOTIFICATIONS covers the new API, and
 LEGACY_NOTIFICATIONS the previous one. Currently all ports that support
 notifications will support both.
 
  https://bugs.webkit.org/show_bug.cgi?id=80922 tracks the work, and
 once the patch lands,
  ports that wish to avoid exposing the new API should remove the
 NOTIFICATION define.
 
  Any concerns?
 
  Thanks,
  Jon
  ___
  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


Re: [webkit-dev] Separating ENABLE(NOTIFICATIONS) and ENABLE(LEGACY_NOTIFICATIONS)

2012-03-13 Thread Jian Li
What will NOTIFICATIONS cover after LEGACY_NOTIFICATIONS is being added?
Does it cover new syntax only or any syntax that are not considered old?

Jian


On Tue, Mar 13, 2012 at 1:29 PM, Jon Lee jon...@apple.com wrote:

 LEGACY_NOTIFICATIONS, for the most part, is exactly what NOTIFICATIONS
 covers now. So yes, it includes HTML notifications and old syntax, and will
 not remove anything that already exists.

 Jon

 On Mar 13, 2012, at 1:25 PM, Jian Li jia...@chromium.org wrote:

 Jon, could you please provide what are going to be included in
 LEGACY_NOTIFICATIONS? Does LEGACY_NOTIFICATION only includes HTML
 notification and old syntax we're considering to deprecate?

 Jian


 On Mon, Mar 12, 2012 at 7:11 PM, Adam Barth aba...@webkit.org wrote:

 That sounds like a good approach.  Chromium will likely need to
 remember to disable NOTIFICATIONS on any upcoming release branches
 (until the work is complete).

 Adam


 On Mon, Mar 12, 2012 at 6:58 PM, Jon Lee jon...@apple.com wrote:
  Hi WebKit!
 
  In order to ease the migration path for the nascent notifications API,
 I'd like to separate the current dependency between NOTIFICATION and
 LEGACY_NOTIFICATIONS. Currently, in order to support the legacy API, both
 defines are needed, but ends up also including the new API.
 
  Since the future is to eventually move to the spec'd API, I like to
 separate the two defines, so that NOTIFICATIONS covers the new API, and
 LEGACY_NOTIFICATIONS the previous one. Currently all ports that support
 notifications will support both.
 
  https://bugs.webkit.org/show_bug.cgi?id=80922 tracks the work, and
 once the patch lands,
  ports that wish to avoid exposing the new API should remove the
 NOTIFICATION define.
 
  Any concerns?
 
  Thanks,
  Jon
  ___
  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


Re: [webkit-dev] Removing obsolete File attributes

2012-02-24 Thread Jian Li
Can we introduce some sort of Obsolete IDL attribute so that it will
automatically produce console warning messages for those attributes and
could even trigger metric gathering for those platforms that have interest?
It seems that this addition could be useful in deprecating some other
attributes in the future.

Jian


On Fri, Feb 24, 2012 at 12:20 PM, Darin Fisher da...@chromium.org wrote:



 On Fri, Feb 24, 2012 at 12:13 PM, Maciej Stachowiak m...@apple.com wrote:


 On Feb 24, 2012, at 12:06 PM, Darin Fisher wrote:



 On Fri, Feb 24, 2012 at 12:00 PM, Maciej Stachowiak m...@apple.comwrote:


 On Feb 24, 2012, at 11:52 AM, Darin Fisher wrote:

 As I mentioned in the bug, it is encouraging news that Mozilla has
 already removed these attributes (for a couple releases now).  I would like
 to see them go away too.

 There's unfortunately, the real possibility that there may be some
 existing webkit-specific or chrome-specific (extensions) content out there
 that is expecting these properties to exist.  I think we need to be a bit
 cautious since we've included these properties in webkit for such a long
 time (since 2008!).  Here's the revision that added them:
 http://trac.webkit.org/changeset/34702


 Is there a good way to quantify and/or mitigate this risk?


 Well, we could certainly instrument a Chrome nightly build to measure
 accesses made on these attributes, and see what that turns up.  I haven't
 thought about it enough to decide what a good metric would be.  You
 probably want to know the percentage of unique pages that depend on these
 features.  It is probably easier to measure percentage of navigations that
 resulted in a document that depended on these features.  That would
 over-estimate usage if a page that needs these features is navigated to
 frequently.

 I'm concerned that it may be tricky to grep the repository of Chrome
 extensions (or Google's index of the web) since fileName and fileSize
 are likely to be very common terms.


 Though you did not say so explicitly, it sounded to me like your
 suggested approach to this issue was let's remove these eventually, but
 maybe not right now. That sounds like a reasonable approach.

 But then we'll need to figure out if it's actually too costly to remove
 them right now, and if so, figure out how to get to the point that we feel
 comfortable removing them. I don't really have a specific kind of idea of
 what data would tell us these things.  Your suggestions above seem ok.

 Regards,
 Maciej




 Perhaps a concrete good first step is to log a console warning when they
 are used?  Warning, blahBlah is a deprecated attribute.  Use fluxCapacitor
 instead.

 -Darin

 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Web Notifications API

2012-02-15 Thread Jian Li
On Wed, Feb 15, 2012 at 9:46 AM, Jon Lee jon...@apple.com wrote:

 On Feb 13, 2012, at 5:51 PM, Andrew Wilson atwil...@google.com wrote:
  I don't have an answer for you here, as the internet is vast :) Among
 google properties, Gmail and Google Calendar currently use it. I'm not
 aware of any other google property that uses it in their web pages, but
 some do via extensions.



 On Feb 13, 2012, at 5:29 PM, Adam Barth aba...@webkit.org wrote:
  IRCCloud is an example of a site that I use every day that uses
 notifications.


 Ok, thanks for providing these sites.

 It seems to me that we are in agreement with most of the proposal. I would
 like to begin work on these changes. I will file a master bug so that we
 can track progress. I think we can make these improvements without
 disturbing what we already have, to maintain current compatibility. Does
 this sound good?


Sounds good, as long as we keep in mind of not to breaking
backward compatibility until app developers can switch to new syntax and
scheme.


 Jon
 ___
 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] Web Notifications API

2012-02-14 Thread Jian Li
Both GMail and Google Calendar are using text based notification, not html
notification.

What kind of notifications do IRCCloud, New York Timers skimmer view, and
TweetDeck use, text based or html? Are notifications trigger from the web
site or Chrome App extension?


On Mon, Feb 13, 2012 at 6:05 PM, Adam Barth aba...@webkit.org wrote:

 On Mon, Feb 13, 2012 at 5:31 PM, David Levin le...@chromium.org wrote:
  On Mon, Feb 13, 2012 at 5:29 PM, Adam Barth aba...@webkit.org wrote:
  On Mon, Feb 13, 2012 at 5:23 PM, Jon Lee jon...@apple.com wrote:
   I also have concerns about backwards compatibility support. Aside from
   Gmail, what other web sites have integrated the notifications
 feature? I
   could only find example pages, one of which was using already an
   outdated
   API.
 
  IRCCloud is an example of a site that I use every day that uses
  notifications.
 
  Google Calendar fwiw
  (
 http://www.howtogeek.com/howto/28573/how-to-enable-desktop-notifications-for-google-calendar-in-chrome/
 )

 They're also used by the New York Times skimmer view as well as
 TweetDeck.  (These are just web sites I happened to use personally,
 not any sort of exhaustive list.)

 Adam
 ___
 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] Propose adding button support to text based notifications (Was: Removing HTML notifications from WebKit)

2012-02-14 Thread Jian Li
One of the reasons for using html notifications is to allow direct
interaction with the notifications. Here're some scenarios from our
customers that want to use html notifications purely for this purpose:

1) In calendar notifications, the user might want to snooze the reminder
for some time.
2) In email notifications, it might be very convenient if the user can
archive/delete directly from the notification, since often the snippet will
provide enough context to do this.
3) In voice/video chat notifications, the user could click on Answer or
Accept button directly, instead of clicking on the notification message
and then being presented with another UI where Answer or Accept is
there.

It seems to be very useful if we could enhance the text notifications by
adding optional button support. If the underlying system does not support
showing extra buttons, it will get handled in the traditional way.

Thanks,

Jian


On Mon, Feb 13, 2012 at 11:23 AM, Maciej Stachowiak m...@apple.com wrote:


 This plan sounds reasonable to me. No disruption of Chrome extensions in
 the short term, but we would better align with each other and with
 standards in the longer term.

 Jon?

 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

2011-04-26 Thread Jian Li
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 jia...@chromium.org 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] Optional parameter in IDL and undefined JS value

2011-04-25 Thread Jian Li
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)?


On Fri, Apr 22, 2011 at 3:00 PM, Geoffrey Garen gga...@apple.com wrote:

  I would suggest updating the specification for Blob.slice() so that it
 doesn't expect passing undefined for the second argument to have
 identical behavior to not passing the argument at all. The subarray
 method in the Typed Array spec [1], which has similar behavior to
 slice(), doesn't mention the undefined value.


 I am afraid that this suggested change might not be preferred since we're
 trying to mimic the behavior of Blob.slice to Array.slice and Array.slice
 does allow passing undefined and treat it as omitting the value.


 Jian,

 Can you clarify why we want Blob.slice to mimic Array.prototype.slice in
 this strange argument quirk?

 Let me suggest three reasons why we don't want Blob.slice to mimic
 Array.prototype.slice in this strange argument quirk:

 1. Legacy argument quirks exist for legacy compatibility and nothing else.
 Since Blobs have no legacy requirements, they should not re-introduce the
 mistakes of JavaScript past. There are many legacy argument quirks in
 JavaScript. They often confuse programmers, rather than enabling them. For
 example, new Array(x) creates an array with ToInteger(x) elements in it,
 while new Array(x, y) creates an array with 2 elements in it, x and y. Would
 you mimic that quirk in Blobs if you could?


(From Arun): Can't argue with his intent in saying this :-).  But, WebIDL
takes care of any calls that ECMA-262 makes w.r.t. numerical arguments (e.g.
there is a ToNumber call presumed for long long arguments), *and* we can't
really do calls of the sort new Blob(x).  Rather, we go via Blob.slice( ) or
BlobBuilder calls.g


 2. A Blob is not an Array. Blobs are incompatible with all other Array
 semantics. They don't have a length property. They don't support bracket
 access. They don't support destructive modification. If Blobs were like
 Arrays, you could just use Array.prototype.slice to slice a Blob. But you
 can't, because they're not alike at all.


(From Arun): Blobs are more like Strings -- so I agree with the above.  In
fact, I'm worried about our use of some Array semantics w.r.t. Blob.slice,
but I'm reassured by the fact that byte-order semantics for the start
argument to a Blob.slice call matches character-order semantics for the
start argument to a String.slice call.  I wonder if there are any other
gotchas here?


 3. Your specification doesn't actually conform to the exact semantics of
 all the argument quirks of Array.prototype.slice. There are a number of
 other quirks that you have left out because they are strange and you are not
 familiar with them. I will leave it as a thought experiment for you to go
 and find all the other quirks of Array.prototype.slice that you have missed.
 While you are seeking them out, you can meditate on whether you are making
 your API better or worse.


(From Arun): Hah!  He makes the point strongly here, but he isn't wrong.
I've spent a while reading ECMA-262.  Honestly, Blob is the first host
object that introduces a slice method (to the best of my knowledge) and
WebIDL constructs aren't too close to ECMA-262 constructs.



 Geoff

___
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

2011-04-22 Thread Jian Li
This seems not to work. When we call foo(arg1, undefined), arguments.length
is 2 and thus we convert undefined to 0 and pass it to impl-foo(arg1,
arg2). But we want default value for arg2 other than 0.

On Fri, Apr 22, 2011 at 8:52 AM, Oliver Hunt oli...@apple.com wrote:

 An alternative would be to generate code for optional args along the lines
 of (pseudo code):
 void foo(Arg1Type arg1, [Optional] Arg2Type arg2);
 =
 Arg1Type arg1 = toArg1Type(arguments[0]);
 if (arguments.length  2)
 return impl-foo(arg1);
 Arg2Type arg2 = toArg2Type(arguments[1]);
 return impl-foo(arg1, arg2);


 This would allow the C++ impl to use overloading to resolve things
 correctly.

 --Oliver

 On Apr 21, 2011, at 10:16 PM, Jian Li wrote:

 One other way is to write custom binding code to handle this
 case specially.


 On Thu, Apr 21, 2011 at 10:07 PM, Maciej Stachowiak m...@apple.com wrote:


 On Apr 21, 2011, at 6:29 PM, Jian Li wrote:

  I've pinged the spec author to make it clear in the spec. What is meant
 in the spec is really that we want Blob.slice to have the same exact
 behavior as Array.slice defined in ECMAScript 5, 15.4.4.10. That is,
 Blob.slice(start) has the same result as Blob.slice(start, undefined).

 The current code generator scripts will convert undefined value to 0. But
 we really want to use the custom default value for Blob.slice. Do we want to
 consider adding DefaultValue= extended attribute support to IDL?


 I'd prefer if we can find a way to solve it that does not require
 diverging our IDL dialect further from Web IDL, especially since this is the
 only method likely to need the feature. Are there any other practical
 solutions?

 Regards,
 Maciej


 Thanks,

 Jian


 On Thu, Apr 21, 2011 at 3:38 AM, Maciej Stachowiak m...@apple.com wrote:


 On Apr 21, 2011, at 12:14 AM, Jian Li wrote:

  The current File API spec says that:
  If the end parameter is not provided (undefined), let relativeEnd
 be size.

 That seems like loose wording. Parameter not provided and parameter
 provided with a value of undefined are in general not the same thing. The
 spec should be explicit about which cases it's talking about.

 Regards,
 Maciej




 ___
 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

2011-04-22 Thread Jian Li
On Fri, Apr 22, 2011 at 12:21 PM, Kenneth Russell k...@google.com wrote:

 The generated code for optional arguments in WebKit IDL already does
 this sort of dispatch. See Jian Li's first message on this thread and
 the code snippet he cited.

 The problem is that undefined is being passed explicitly as the
 second argument. If this weren't being done, the default value for the
 argument defined by the C++ header would be used correctly.

 I would suggest updating the specification for Blob.slice() so that it
 doesn't expect passing undefined for the second argument to have
 identical behavior to not passing the argument at all. The subarray
 method in the Typed Array spec [1], which has similar behavior to
 slice(), doesn't mention the undefined value.


I am afraid that this suggested change might not be preferred since we're
trying to mimic the behavior of Blob.slice to Array.slice and Array.slice
does allow passing undefined and treat it as omitting the value.


 -Ken

 [1] http://www.khronos.org/registry/typedarray/specs/latest/#7

 On Fri, Apr 22, 2011 at 10:01 AM, Jian Li jia...@chromium.org wrote:
  This seems not to work. When we call foo(arg1, undefined),
 arguments.length
  is 2 and thus we convert undefined to 0 and pass it to impl-foo(arg1,
  arg2). But we want default value for arg2 other than 0.
 
  On Fri, Apr 22, 2011 at 8:52 AM, Oliver Hunt oli...@apple.com wrote:
 
  An alternative would be to generate code for optional args along the
 lines
  of (pseudo code):
  void foo(Arg1Type arg1, [Optional] Arg2Type arg2);
  =
  Arg1Type arg1 = toArg1Type(arguments[0]);
  if (arguments.length  2)
  return impl-foo(arg1);
  Arg2Type arg2 = toArg2Type(arguments[1]);
  return impl-foo(arg1, arg2);
 
  This would allow the C++ impl to use overloading to resolve things
  correctly.
  --Oliver
  On Apr 21, 2011, at 10:16 PM, Jian Li wrote:
 
  One other way is to write custom binding code to handle this
  case specially.
 
  On Thu, Apr 21, 2011 at 10:07 PM, Maciej Stachowiak m...@apple.com
 wrote:
 
  On Apr 21, 2011, at 6:29 PM, Jian Li wrote:
 
  I've pinged the spec author to make it clear in the spec. What is meant
  in the spec is really that we want Blob.slice to have the same exact
  behavior as Array.slice defined in ECMAScript 5, 15.4.4.10. That is,
  Blob.slice(start) has the same result as Blob.slice(start, undefined).
  The current code generator scripts will convert undefined value to 0.
 But
  we really want to use the custom default value for Blob.slice. Do we
 want to
  consider adding DefaultValue= extended attribute support to IDL?
 
  I'd prefer if we can find a way to solve it that does not require
  diverging our IDL dialect further from Web IDL, especially since this
 is the
  only method likely to need the feature. Are there any other practical
  solutions?
  Regards,
  Maciej
 
  Thanks,
  Jian
 
 
  On Thu, Apr 21, 2011 at 3:38 AM, Maciej Stachowiak m...@apple.com
 wrote:
 
  On Apr 21, 2011, at 12:14 AM, Jian Li wrote:
 
   The current File API spec says that:
   If the end parameter is not provided (undefined), let
 relativeEnd
   be size.
 
  That seems like loose wording. Parameter not provided and parameter
  provided with a value of undefined are in general not the same thing.
 The
  spec should be explicit about which cases it's talking about.
 
  Regards,
  Maciej
 
 
 
  ___
  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


Re: [webkit-dev] Optional parameter in IDL and undefined JS value

2011-04-22 Thread Jian Li
I will pass your good arguments to the spec author. Personally I am not in
strong favor of mimicking Array.slice. I just found the problems we have
during implementation and seek the solution.

On Fri, Apr 22, 2011 at 3:00 PM, Geoffrey Garen gga...@apple.com wrote:

  I would suggest updating the specification for Blob.slice() so that it
 doesn't expect passing undefined for the second argument to have
 identical behavior to not passing the argument at all. The subarray
 method in the Typed Array spec [1], which has similar behavior to
 slice(), doesn't mention the undefined value.


 I am afraid that this suggested change might not be preferred since we're
 trying to mimic the behavior of Blob.slice to Array.slice and Array.slice
 does allow passing undefined and treat it as omitting the value.


 Jian,

 Can you clarify why we want Blob.slice to mimic Array.prototype.slice in
 this strange argument quirk?

 Let me suggest three reasons why we don't want Blob.slice to mimic
 Array.prototype.slice in this strange argument quirk:

 1. Legacy argument quirks exist for legacy compatibility and nothing else.
 Since Blobs have no legacy requirements, they should not re-introduce the
 mistakes of JavaScript past. There are many legacy argument quirks in
 JavaScript. They often confuse programmers, rather than enabling them. For
 example, new Array(x) creates an array with ToInteger(x) elements in it,
 while new Array(x, y) creates an array with 2 elements in it, x and y. Would
 you mimic that quirk in Blobs if you could?

 2. A Blob is not an Array. Blobs are incompatible with all other Array
 semantics. They don't have a length property. They don't support bracket
 access. They don't support destructive modification. If Blobs were like
 Arrays, you could just use Array.prototype.slice to slice a Blob. But you
 can't, because they're not alike at all.

 3. Your specification doesn't actually conform to the exact semantics of
 all the argument quirks of Array.prototype.slice. There are a number of
 other quirks that you have left out because they are strange and you are not
 familiar with them. I will leave it as a thought experiment for you to go
 and find all the other quirks of Array.prototype.slice that you have missed.
 While you are seeking them out, you can meditate on whether you are making
 your API better or worse.

 Geoff

___
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

2011-04-21 Thread Jian Li
The current File API spec says that:
If the end parameter is not provided (undefined), let relativeEnd be
size.
This seems to indicate that passing undefined as end parameter is same as
omitting it. Per the latest discussion on public-webapps, we're in the
process of making it be more like Array.slice. I will also ping the spec
author about this issue.

Unfortunately we have inconsistency between Array.slice and other DOM
methods, in terms of handling undefined parameter value in WebKit. We also
have inconsistency among different browser vendors for interpreting
Array.slice(start, undefined).


On Wed, Apr 20, 2011 at 11:17 PM, Cameron McCormack c...@mcc.id.au wrote:

 Jian Li:
   I am referring to Blob.slice(start, end) that mimics Array.slice. Where
 in
   WebIDL has this behavior defined? Sorry I can't find it in the spec.
  
   For Array.slice(start, end), both Safari and Chrome treat passing
 undefined
   as omitted parameter, while Firefox and IE treat passing undefined as
 0.

 Ryosuke Niwa:
  Doesn't that mean the current behavior (i.e. treating undefined as 0) is
  correct since that's what other browsers do?

 The File API spec currently says:

  Blob slice(in optional long long start,
 in optional long long end,
 in optional DOMString contentType);

 and Web IDL says that if you call

  blob.slice(10, undefined);

 then this is calling the function with two arguments, where the second
 argument will be converted to 0 due to how the conversion of JS
 undefined to an IDL long long value is defined.  This is not the same as
 calling

  blob.slice(10);

 Whenever some optional arguments are omitted, the prose for the
 definition of the operation defines what that means; it’s not
 automatically “convert from undefined”.

 There is no way in Web IDL to state that when undefined is passed as an
 argument explicitly that it is handled differently from the rules in
 http://dev.w3.org/2006/webapi/WebIDL/#es-type-mapping (although the
 authors of the File API spec could include this additional requirement
 in prose, overriding Web IDL, if they wanted).

 --
 Cameron McCormack ≝ http://mcc.id.au/

___
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

2011-04-21 Thread Jian Li
It seems that we're doing the right thing for Array.slice in WebKit in order
to be consistent with ECMAScript 5, 15.4.4.10. Since Blob.slice in File API
is following the same route, we probably want to fix the handling in
Blob.slice and keep other DOM methods as they're now.

On Thu, Apr 21, 2011 at 12:14 AM, Jian Li jia...@chromium.org wrote:

 The current File API spec says that:
 If the end parameter is not provided (undefined), let relativeEnd be
 size.
 This seems to indicate that passing undefined as end parameter is same as
 omitting it. Per the latest discussion on public-webapps, we're in the
 process of making it be more like Array.slice. I will also ping the spec
 author about this issue.

 Unfortunately we have inconsistency between Array.slice and other DOM
 methods, in terms of handling undefined parameter value in WebKit. We also
 have inconsistency among different browser vendors for interpreting
 Array.slice(start, undefined).


 On Wed, Apr 20, 2011 at 11:17 PM, Cameron McCormack c...@mcc.id.au wrote:

 Jian Li:
   I am referring to Blob.slice(start, end) that mimics Array.slice.
 Where in
   WebIDL has this behavior defined? Sorry I can't find it in the spec.
  
   For Array.slice(start, end), both Safari and Chrome treat passing
 undefined
   as omitted parameter, while Firefox and IE treat passing undefined as
 0.

 Ryosuke Niwa:
  Doesn't that mean the current behavior (i.e. treating undefined as 0) is
  correct since that's what other browsers do?

 The File API spec currently says:

  Blob slice(in optional long long start,
 in optional long long end,
 in optional DOMString contentType);

 and Web IDL says that if you call

  blob.slice(10, undefined);

 then this is calling the function with two arguments, where the second
 argument will be converted to 0 due to how the conversion of JS
 undefined to an IDL long long value is defined.  This is not the same as
 calling

  blob.slice(10);

 Whenever some optional arguments are omitted, the prose for the
 definition of the operation defines what that means; it’s not
 automatically “convert from undefined”.

 There is no way in Web IDL to state that when undefined is passed as an
 argument explicitly that it is handled differently from the rules in
 http://dev.w3.org/2006/webapi/WebIDL/#es-type-mapping (although the
 authors of the File API spec could include this additional requirement
 in prose, overriding Web IDL, if they wanted).

 --
 Cameron McCormack ≝ http://mcc.id.au/



___
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

2011-04-21 Thread Jian Li
I've pinged the spec author to make it clear in the spec. What is meant in
the spec is really that we want Blob.slice to have the same exact behavior
as Array.slice defined in ECMAScript 5, 15.4.4.10. That is,
Blob.slice(start) has the same result as Blob.slice(start, undefined).

The current code generator scripts will convert undefined value to 0. But we
really want to use the custom default value for Blob.slice. Do we want to
consider adding DefaultValue= extended attribute support to IDL?

Thanks,

Jian


On Thu, Apr 21, 2011 at 3:38 AM, Maciej Stachowiak m...@apple.com wrote:


 On Apr 21, 2011, at 12:14 AM, Jian Li wrote:

  The current File API spec says that:
  If the end parameter is not provided (undefined), let relativeEnd be
 size.

 That seems like loose wording. Parameter not provided and parameter
 provided with a value of undefined are in general not the same thing. The
 spec should be explicit about which cases it's talking about.

 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

2011-04-21 Thread Jian Li
One other way is to write custom binding code to handle this case specially.


On Thu, Apr 21, 2011 at 10:07 PM, Maciej Stachowiak m...@apple.com wrote:


 On Apr 21, 2011, at 6:29 PM, Jian Li wrote:

 I've pinged the spec author to make it clear in the spec. What is meant in
 the spec is really that we want Blob.slice to have the same exact behavior
 as Array.slice defined in ECMAScript 5, 15.4.4.10. That is,
 Blob.slice(start) has the same result as Blob.slice(start, undefined).

 The current code generator scripts will convert undefined value to 0. But
 we really want to use the custom default value for Blob.slice. Do we want to
 consider adding DefaultValue= extended attribute support to IDL?


 I'd prefer if we can find a way to solve it that does not require diverging
 our IDL dialect further from Web IDL, especially since this is the only
 method likely to need the feature. Are there any other practical solutions?

 Regards,
 Maciej


 Thanks,

 Jian


 On Thu, Apr 21, 2011 at 3:38 AM, Maciej Stachowiak m...@apple.com wrote:


 On Apr 21, 2011, at 12:14 AM, Jian Li wrote:

  The current File API spec says that:
  If the end parameter is not provided (undefined), let relativeEnd be
 size.

 That seems like loose wording. Parameter not provided and parameter
 provided with a value of undefined are in general not the same thing. The
 spec should be explicit about which cases it's talking about.

 Regards,
 Maciej




___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


[webkit-dev] Optional parameter in IDL and undefined JS value

2011-04-20 Thread Jian Li
Hi,

I've just found a problem in our generated code for handling optional
parameters. Suppose we define a method with optional parameter in numeric
type, like the following in IDL:
 Foo bar(in [Optional] long long start, in [Optional] long long
end);

And we declare our C++ method as the following. Note that the default value
of the 2nd parameter is not 0.
 PassRefPtrFoo bar(long long start = 0, long long end =
std::numeric_limitslong long::max());

If we call the JS method with only 1 parameter, everything works as
expected. However, if we call the JS method with 2 parameters and pass
'undefined' as the 2nd parameter, we trigger the problem.

By looking into the generated JSC code below, I found out that we are
converting undefined JS value to 0 and pass it to the function. As the
result, the default parameter value in the declaration is not respected.

EncodedJSValue JSC_HOST_CALL jsFooPrototypeFunctionFoo(ExecState* exec)
{

JSValue thisValue = exec-hostThisValue();
if (!thisValue.inherits(JSFoo::s_info))
return throwVMTypeError(exec);
JSFoo* castedThis = static_castJSFoo*(asObject(thisValue));
Foo* imp = static_castFoo*(castedThis-impl());

int argsCount = exec-argumentCount();
if (argsCount = 0) {
JSC::JSValue result = toJS(exec, castedThis-globalObject(),
WTF::getPtr(imp-bar()));
return JSValue::encode(result);
}

long long start(static_castlong
long(exec-argument(0).toInteger(exec)));
if (exec-hadException())
return JSValue::encode(jsUndefined());
if (argsCount = 1) {
JSC::JSValue result = toJS(exec, castedThis-globalObject(),
WTF::getPtr(imp-bar(start)));
return JSValue::encode(result);
}

long long end(static_castlong
long(exec-argument(1).toInteger(exec)));
if (exec-hadException())
return JSValue::encode(jsUndefined());

JSC::JSValue result = toJS(exec, castedThis-globalObject(),
WTF::getPtr(imp-bar(start, end)));
return JSValue::encode(result);
}


One solution is to add the default value support in IDL. For example, we can
change the above definition of bar to something like:
 Foo bar(in [Optional, DefaultValue=0] long long start, in
[Optional, DefaultValue=2147483647] long long end);

Or the other way is to add a bool parameter for each optional parameter in
the class method declaration, that is used to indicate if the passing
parameter is defined or not. This would involve the change to both code
generator scripts and the existing implementations.

How do you think? Personally I like the 1st approach since it is simpler.

Thanks,

Jian
___
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

2011-04-20 Thread Jian Li
I am referring to Blob.slice(start, end) that mimics Array.slice. Where in
WebIDL has this behavior defined? Sorry I can't find it in the spec.

For Array.slice(start, end), both Safari and Chrome treat passing undefined
as omitted parameter, while Firefox and IE treat passing undefined as 0. If
it is true that passing undefined should be treated as 0, we do not have a
bug in JSC and V8 bindings layer. However, we do have a bug in JSC and V8
internals.


On Wed, Apr 20, 2011 at 7:28 PM, Maciej Stachowiak m...@apple.com wrote:


 On Apr 20, 2011, at 6:16 PM, Jian Li wrote:

 Hi,

 I've just found a problem in our generated code for handling optional
 parameters. Suppose we define a method with optional parameter in numeric
 type, like the following in IDL:
  Foo bar(in [Optional] long long start, in [Optional] long long
 end);

 And we declare our C++ method as the following. Note that the default value
 of the 2nd parameter is not 0.
  PassRefPtrFoo bar(long long start = 0, long long end =
 std::numeric_limitslong long::max());

 If we call the JS method with only 1 parameter, everything works as
 expected. However, if we call the JS method with 2 parameters and pass
 'undefined' as the 2nd parameter, we trigger the problem.


 Is it actually a bug that explicitly passing undefined acts like passing 0,
 instead of like an omitted parameter? I think it's correct per Web IDL.
 What's the specific case where this is a problem?

 Regards,
 Maciej


 By looking into the generated JSC code below, I found out that we are
 converting undefined JS value to 0 and pass it to the function. As the
 result, the default parameter value in the declaration is not respected.

 EncodedJSValue JSC_HOST_CALL jsFooPrototypeFunctionFoo(ExecState* exec)
 {

 JSValue thisValue = exec-hostThisValue();
 if (!thisValue.inherits(JSFoo::s_info))
 return throwVMTypeError(exec);
 JSFoo* castedThis = static_castJSFoo*(asObject(thisValue));
 Foo* imp = static_castFoo*(castedThis-impl());

 int argsCount = exec-argumentCount();
 if (argsCount = 0) {
 JSC::JSValue result = toJS(exec, castedThis-globalObject(),
 WTF::getPtr(imp-bar()));
 return JSValue::encode(result);
 }

 long long start(static_castlong
 long(exec-argument(0).toInteger(exec)));
 if (exec-hadException())
 return JSValue::encode(jsUndefined());
 if (argsCount = 1) {
 JSC::JSValue result = toJS(exec, castedThis-globalObject(),
 WTF::getPtr(imp-bar(start)));
 return JSValue::encode(result);
 }

 long long end(static_castlong
 long(exec-argument(1).toInteger(exec)));
 if (exec-hadException())
 return JSValue::encode(jsUndefined());

 JSC::JSValue result = toJS(exec, castedThis-globalObject(),
 WTF::getPtr(imp-bar(start, end)));
 return JSValue::encode(result);
 }


 One solution is to add the default value support in IDL. For example, we
 can change the above definition of bar to something like:
  Foo bar(in [Optional, DefaultValue=0] long long start, in
 [Optional, DefaultValue=2147483647] long long end);

 Or the other way is to add a bool parameter for each optional parameter in
 the class method declaration, that is used to indicate if the passing
 parameter is defined or not. This would involve the change to both code
 generator scripts and the existing implementations.

 How do you think? Personally I like the 1st approach since it is simpler.

 Thanks,

 Jian


 ___
 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

2011-04-20 Thread Jian Li
On Wed, Apr 20, 2011 at 9:58 PM, Ryosuke Niwa rn...@webkit.org wrote:

 On Wed, Apr 20, 2011 at 9:37 PM, Jian Li jia...@chromium.org wrote:

 I am referring to Blob.slice(start, end) that mimics Array.slice. Where in
 WebIDL has this behavior defined? Sorry I can't find it in the spec.

 For Array.slice(start, end), both Safari and Chrome treat passing
 undefined as omitted parameter, while Firefox and IE treat passing undefined
 as 0.


 Doesn't that mean the current behavior (i.e. treating undefined as 0) is
 correct since that's what other browsers do?

 If it is true that passing undefined should be treated as 0, we do not have
 a bug in JSC and V8 bindings layer. However, we do have a bug in JSC and V8
 internals.


 I don't get what you mean here.  If there are no bugs in JSC/V8 bindings,
 then what are you trying to fix?


I mean we need to fix Array.slice behavior in JSC and V8 since Array.slice
is not defined in our IDL.


 - Ryosuke

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Plan to move TypedArray out of WebGL feature guard

2010-12-23 Thread Jian Li
Sounds like a good idea. I am going to add TYPED_ARRAY guard for this.

Thanks,

Jian

On Thu, Dec 23, 2010 at 8:13 AM, Chris Marrin cmar...@apple.com wrote:


 On Dec 22, 2010, at 5:34 PM, Jian Li wrote:

  Hi,
 
  TypedArray has been used in some non-WebGL areas, like File API and XHR.
 It would be nice if we move it out of WebGL feature guard. Any objection?

 It would probably be best if it had its own guard. Then its various users
 could turn it on in config.h

 -
 ~Chris
 cmar...@apple.com





___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Plan to move TypedArray out of WebGL feature guard

2010-12-23 Thread Jian Li
Currently the definition of TypedArray is guarded by ENABLE(3D_CANVAS) ||
ENABLE(BLOB). It has been used in the following features:

   - WebGL
   - File API: FileReader and BlobBuilder
   - XMLHttpRequest: send and response

We do not add an additional check expression when TypedArray is added to
XHR. We should do that but it will incur updating lots of files. If
TypedArray is used in another conditional feature, we will have to repeat
the same update.

I think it would be better if we could use a single guard or remove the
guard.


On Thu, Dec 23, 2010 at 11:01 AM, Darin Adler da...@apple.com wrote:

 Yes, we want correct conditionals, and TypedArray should not be in the
 WebGL feature guard if it’s used in other features.

 Adding a feature new guard would not be good if it has to be set
 explicitly. It would be much better if the build just decided correctly
 based on the other feature guards.

 If TypedArray is used in multiple conditional features, then we have to use
 the correct expression to check the feature guards.

 If it’s used in any unconditional feature, then it should not have a
 feature guard at all.

-- Darin


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Plan to move TypedArray out of WebGL feature guard

2010-12-23 Thread Jian Li
Currently it is guarded by the same guarding expression.

CC Chris who implemented this feature since he knows whether it is ready all
versions or not.


On Thu, Dec 23, 2010 at 11:23 AM, Darin Adler da...@apple.com wrote:

 On Dec 23, 2010, at 11:21 AM, Jian Li wrote:

  We do not add an additional check expression when TypedArray is added to
 XHR.

 Is the TypedArray support in XHR a feature in its own right? Should it be
 off by default or is it ready to be on for all versions of WebKit?

-- Darin


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


[webkit-dev] Plan to move TypedArray out of WebGL feature guard

2010-12-22 Thread Jian Li
Hi,

TypedArray has been used in some non-WebGL areas, like File API and XHR. It
would be nice if we move it out of WebGL feature guard. Any objection?

Thanks,

Jian
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] ArrayBuffer supprot

2010-11-14 Thread Jian Li
Kenneth, if you have not started working on adding DataView support, I can
take this to make it work. How do you think? Thanks.

On Wed, Oct 13, 2010 at 8:37 AM, Jian Li jia...@chromium.org wrote:



 On Tue, Oct 12, 2010 at 2:17 PM, Kenneth Russell k...@google.com wrote:

 On Fri, Oct 8, 2010 at 2:46 PM, Jian Li jia...@chromium.org wrote:
  Hi,
  I am looking into hooking up ArrayBuffer support in FileReader and
  BlobBuilder. It seems that most of the typed array types (ArrayBuffer,
  ArrayBufferView, Uint8Array, and etc) have already been implemented in
  WebKit, except TypedArray.get() and DataView.

 Since most of the other questions have been answered:

 https://bugs.webkit.org/show_bug.cgi?id=46541 covers implementation of
 DataView. I will try to take care of this in the next week or two. Let
 me know if you need it before I've gotten to it.


 I do not need it in implementing ArrayBuffer support in FileReader and
 BlobBuilder. Currently I just instantiate a subinstance of ArrayBufferView
 to get the data for testing purpose. But it would be better if we can have
 DataView implemented in order to provide a way for the user to
 read heterogeneous data.


  Currently all these typed array supports are put under 3D_CANVAS feature
  guard. Since they're going to be widely used in other areas, like File
 API
  and XHR, should we remove the conditional guard 3D_CANVAS from all the
  related files? Should we also move these files out of html\canvas, say
 into
  html\ or html\typearrays?
  In addition, get() is not implemented for typed array views. Should we
 add
  it?

 Both the setter and getter in the Web IDL are defined as omittable,
 which means that in the ECMAScript binding the indexing operator []
 is used for both getting and setting values. Both are fully
 implemented in JSC and V8. At the C++ level, the item and set
 methods (see IntegralTypedArrayBase and Float32Array for example) are
 used in certain cases to implement the getter and setter.


 I noticed that and already used it in my test scripts. Thanks for pointing
 it out.


 -Ken

  Jian
 
  ___
  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] ArrayBuffer supprot

2010-10-12 Thread Jian Li
On Tue, Oct 12, 2010 at 2:17 PM, Kenneth Russell k...@google.com wrote:

 On Fri, Oct 8, 2010 at 2:46 PM, Jian Li jia...@chromium.org wrote:
  Hi,
  I am looking into hooking up ArrayBuffer support in FileReader and
  BlobBuilder. It seems that most of the typed array types (ArrayBuffer,
  ArrayBufferView, Uint8Array, and etc) have already been implemented in
  WebKit, except TypedArray.get() and DataView.

 Since most of the other questions have been answered:

 https://bugs.webkit.org/show_bug.cgi?id=46541 covers implementation of
 DataView. I will try to take care of this in the next week or two. Let
 me know if you need it before I've gotten to it.


I do not need it in implementing ArrayBuffer support in FileReader and
BlobBuilder. Currently I just instantiate a subinstance of ArrayBufferView
to get the data for testing purpose. But it would be better if we can have
DataView implemented in order to provide a way for the user to
read heterogeneous data.


  Currently all these typed array supports are put under 3D_CANVAS feature
  guard. Since they're going to be widely used in other areas, like File
 API
  and XHR, should we remove the conditional guard 3D_CANVAS from all the
  related files? Should we also move these files out of html\canvas, say
 into
  html\ or html\typearrays?
  In addition, get() is not implemented for typed array views. Should we
 add
  it?

 Both the setter and getter in the Web IDL are defined as omittable,
 which means that in the ECMAScript binding the indexing operator []
 is used for both getting and setting values. Both are fully
 implemented in JSC and V8. At the C++ level, the item and set
 methods (see IntegralTypedArrayBase and Float32Array for example) are
 used in certain cases to implement the getter and setter.


I noticed that and already used it in my test scripts. Thanks for pointing
it out.


 -Ken

  Jian
 
  ___
  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] ArrayBuffer supprot

2010-10-08 Thread Jian Li
Hi,

I am looking into hooking up ArrayBuffer support in FileReader and
BlobBuilder. It seems that most of the typed array types (ArrayBuffer,
ArrayBufferView, Uint8Array, and etc) have already been implemented in
WebKit, except TypedArray.get() and DataView.

Currently all these typed array supports are put under 3D_CANVAS feature
guard. Since they're going to be widely used in other areas, like File API
and XHR, should we remove the conditional guard 3D_CANVAS from all the
related files? Should we also move these files out of html\canvas, say into
html\ or html\typearrays?

In addition, get() is not implemented for typed array views. Should we add
it?

Jian
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] ArrayBuffer supprot

2010-10-08 Thread Jian Li
Sounds good. I will add the File API feature guard to it and still keep
those files under html/canvas.

On Fri, Oct 8, 2010 at 2:55 PM, Darin Adler da...@apple.com wrote:

 On Oct 8, 2010, at 2:46 PM, Jian Li wrote:

  Currently all these typed array supports are put under 3D_CANVAS feature
 guard. Since they're going to be widely used in other areas, like File API
 and XHR, should we remove the conditional guard 3D_CANVAS from all the
 related files?

 I suggest we keep the guard up to date. These arrays should be compiled in
 if any of the features that use them are compiled in. Once they are used in
 XMLHttpRequest, then they won’t need feature guards at all, but I believe
 the File API may still be under a feature guard.

-- Darin


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] ArrayBuffer supprot

2010-10-08 Thread Jian Li
On Fri, Oct 8, 2010 at 3:29 PM, Maciej Stachowiak m...@apple.com wrote:


 On Oct 8, 2010, at 3:05 PM, Jian Li wrote:

 Sounds good. I will add the File API feature guard to it and still keep
 those files under html/canvas.


 Another possibility is to have an ArrayBuffer feature guard and ensure that
 it is on if at least one of the features depending on it is on.

 This also sounds good. Personally I prefer appending File API feature guard
since it is simpler. When array buffer is used in XHR, we can then simply
remove all the feature guards. Otherwise, we will have to update all the
config files to add a new feature guard.


  - Maciej


 On Fri, Oct 8, 2010 at 2:55 PM, Darin Adler da...@apple.com wrote:

 On Oct 8, 2010, at 2:46 PM, Jian Li wrote:

  Currently all these typed array supports are put under 3D_CANVAS feature
 guard. Since they're going to be widely used in other areas, like File API
 and XHR, should we remove the conditional guard 3D_CANVAS from all the
 related files?

 I suggest we keep the guard up to date. These arrays should be compiled in
 if any of the features that use them are compiled in. Once they are used in
 XMLHttpRequest, then they won’t need feature guards at all, but I believe
 the File API may still be under a feature guard.

-- Darin


 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev



___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Testing XHR

2010-09-21 Thread Jian Li
Yes, I have just gone through all the tests in this suite
and categorized and filed some WebKit bugs. Some other test failures seem to
be due to something wrong with tests themselves. I am pinging Anne about
these issues.

Thanks,

Jian

On Mon, Sep 20, 2010 at 11:43 PM, Alexey Proskuryakov a...@webkit.org wrote:


 I don't think that the suite is testing much besides what we already have
 regression tests for. For the most part, it just has different expectations.

 There doesn't seem to be any harm in importing it as a whole now, but
 looking over the failing tests, categorizing them and sending feedback to
 public-webapps working groups is more important at this point. Jian Li from
 Chromium team is currently filing bugs for tests that fail in WebKit.

 - WBR, Alexey Proskuryakov

 20.09.2010, в 22:34, Ojan Vafai написал(а):

 Filed https://bugs.webkit.org/show_bug.cgi?id=46164 for the script to pull
 the tests into our repo.

 On Tue, Sep 21, 2010 at 3:27 PM, Maciej Stachowiak m...@apple.com wrote:


 On Sep 20, 2010, at 10:19 PM, Ojan Vafai wrote:

 
  How about we create http/tests/xmlhttprequest/w3c-experimental or
 something like that? That can tide us over until the official version comes
 out, at which point, we can delete the w3c-experimental directory and just
 add a w3c directory.
 
  It would be nice if we could start fixing these things before they
 become part of the official test suite as a way of evaluating whether there
 are issues with the spec and/or test suite.

 That is in fact exactly what we should be doing at this stage of the
 standards process for XHR.

 
  Also, it seems to me like to does make sense to add an
 update-experimental-w3c-xhr-tests script or something until there is an
 official version.

 Indeed. And even after the test suite is official, it is likely to expand
 over time. We should also look over our own XHR tests to see if there are
 any that it would make sense to contribute to the W3C.

 Cheers,
 Maciej


 ___
 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


Re: [webkit-dev] Blob scheme implementation

2010-09-14 Thread Jian Li
When I implemented the blob scheme handling, I intentionally tried to have
some common implementation that could be used by all applicable platforms.
But it seems that introducing BlobResourceHandle derived from ResourceHandle
might not be a good hook up point because ResourceHandle is only a wrapper
around the platform loading logics.

To fix this problem, I can move all the blob handling logic to the platform
specific layer (for WebKit mac) and it is up to other individual platform to
implement it when needed.

Jian


On Tue, Sep 14, 2010 at 5:22 PM, Adam Barth aba...@webkit.org wrote:

 Jian Li just had a conversation in #webkit about where the code for
 implementing the Blob URL scheme should live.  I thought I'd open the
 discussion to webkit-dev in case folks had a different perspective.

 As part of the fileapi, we're introducing a new URL scheme, called
 blob, which represents a bucket of bits, usually from a file, but
 potentially from another location.  Assigning these objects URL is
 helpful because then they integrate with the rest of the web platform.
  For example, you can use them as images via the img element or
 videos via the video element, etc.

 Currently, the blob URL scheme is implemented with a subclass of
 ResourceHandle (our primary network abstraction) called
 BlobResourceHandle.  My sense is that this isn't the right place in
 the architecture to add support for the blob URL scheme.  The issue is
 that each port has a table somewhere that maps URL schemes to
 networking backends.  In Chromium, for example, that mapping is
 provided by URLRequestFactory, which lives in the net module.  By
 implementing the blob URL scheme at the ResourceHandle layer, we're
 short-circuiting that table.

 In some sense, this is analogous to adding an HTTPResourceHandle and
 implementing the HTTP protocol inside of WebCore.  While its true that
 most (all?) users of WebKit will need to wire WebCore up to an HTTP
 library, that doesn't necessarily mean that WebCore should contain an
 implementation of the HTTP protocol.  In the same way, even if a large
 number of WebKit users will wish to support the blob URL scheme, that
 doesn't necessarily mean that WebCore should contain an implementation
 of the scheme.

 I can certainly see the appeal of sharing the blob URL implementation
 code between different ports of WebKit, but we can achieve that goal
 in a number of ways, including creating an external library or a
 separate BlobCore module.

 Adam

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Blob scheme implementation

2010-09-14 Thread Jian Li
I think it is a good idea but it will involve lots of work to figure out how
to build and test such module that could be used by all the ports. My
concern is that I do not have enough resource to speak of for all other
ports. Thanks.


On Tue, Sep 14, 2010 at 5:42 PM, Adam Barth aba...@webkit.org wrote:

 What do you think of the idea of having a re-useable BlobCore module
 that all the ports can share?

 Adam


 On Tue, Sep 14, 2010 at 5:39 PM, Jian Li jia...@chromium.org wrote:
  When I implemented the blob scheme handling, I intentionally tried to
 have
  some common implementation that could be used by all applicable
 platforms.
  But it seems that introducing BlobResourceHandle derived from
 ResourceHandle
  might not be a good hook up point because ResourceHandle is only a
 wrapper
  around the platform loading logics.
  To fix this problem, I can move all the blob handling logic to the
 platform
  specific layer (for WebKit mac) and it is up to other individual platform
 to
  implement it when needed.
  Jian
 
  On Tue, Sep 14, 2010 at 5:22 PM, Adam Barth aba...@webkit.org wrote:
 
  Jian Li just had a conversation in #webkit about where the code for
  implementing the Blob URL scheme should live.  I thought I'd open the
  discussion to webkit-dev in case folks had a different perspective.
 
  As part of the fileapi, we're introducing a new URL scheme, called
  blob, which represents a bucket of bits, usually from a file, but
  potentially from another location.  Assigning these objects URL is
  helpful because then they integrate with the rest of the web platform.
   For example, you can use them as images via the img element or
  videos via the video element, etc.
 
  Currently, the blob URL scheme is implemented with a subclass of
  ResourceHandle (our primary network abstraction) called
  BlobResourceHandle.  My sense is that this isn't the right place in
  the architecture to add support for the blob URL scheme.  The issue is
  that each port has a table somewhere that maps URL schemes to
  networking backends.  In Chromium, for example, that mapping is
  provided by URLRequestFactory, which lives in the net module.  By
  implementing the blob URL scheme at the ResourceHandle layer, we're
  short-circuiting that table.
 
  In some sense, this is analogous to adding an HTTPResourceHandle and
  implementing the HTTP protocol inside of WebCore.  While its true that
  most (all?) users of WebKit will need to wire WebCore up to an HTTP
  library, that doesn't necessarily mean that WebCore should contain an
  implementation of the HTTP protocol.  In the same way, even if a large
  number of WebKit users will wish to support the blob URL scheme, that
  doesn't necessarily mean that WebCore should contain an implementation
  of the scheme.
 
  I can certainly see the appeal of sharing the blob URL implementation
  code between different ports of WebKit, but we can achieve that goal
  in a number of ways, including creating an external library or a
  separate BlobCore module.
 
  Adam
 
 

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Blob scheme implementation

2010-09-14 Thread Jian Li
On Tue, Sep 14, 2010 at 6:02 PM, Adam Barth aba...@webkit.org wrote:

 On Tue, Sep 14, 2010 at 5:56 PM, David Levin le...@chromium.org wrote:
  On Tue, Sep 14, 2010 at 5:42 PM, Adam Barth aba...@webkit.org wrote:
  What do you think of the idea of having a re-useable BlobCore module
  that all the ports can share?
 
  I don't think this is a good idea. This re-usable module would only be
  used by the Safari WebKit port. As I understand it, Chromium wouldn't be
  able to re-use it due to not re-using WebKit types in general. With only
 one
  port using it, the module seems like it would not be able to have a good
  design.
 
  So if there is a change, it seems better to just write it for the Safari
  WebKit port and as other ports want to implement it, if they find
  commonality, it would be in their best interest to refractor the existing
  code for better re-use.

 Would Chromium be able to re-use the code if it were part of WebCore?
 I guess I don't understand what's different about those two cases.


No. As David said, one reason is to avoid incurring the unnecessary cost of
converting between WebCore type data and Chromium type data.


 Another question, does this design allow blob URLs to be used by the
 video element?  My understanding is that video bypasses
 ResourceHandle because ResourceHandle isn't smart enough to handle
 range requests (or something like that).

 Unfortunately it does not work for video elements since they're loaded in
different code path.


 Adam

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Blob changes to SecurityOrigin.cpp

2010-09-03 Thread Jian Li
On Fri, Sep 3, 2010 at 3:43 PM, Adam Barth aba...@webkit.org wrote:

 On Fri, Sep 3, 2010 at 3:19 PM, Jian Li jia...@google.com wrote:
  Some parts of changes are due to the File API work I have worked on.
  On Fri, Sep 3, 2010 at 2:50 PM, Adam Barth aba...@webkit.org wrote:
 
  I was looking at SecurityOrigin.cpp today and I saw a bunch of code
  relating to Blob URLs.  I don't really understand why this code is
  correct.  Would someone be willing to explain it to me?
 
  Some specific questions:
 
  1) Why do blob URLs get exception from the unique origin check?  How
  does that interact with the HTML5 sandboxing model?
 
  The origin of blob URL is said to be the origin of the page under which
 the
  blob URL is created. It is encoded as part of the blob URL:
  blob:encoded_origin/id. We're not ignoring any security origin checks.
  Instead, we need to pull the encoded origin out of the blob URL and use
 it
  as the base for the origin check.
 
  The reason that we skip the unique origin check here is to allow a local
  running worker script to be able to access a blob URL. Do we want to
  disallow this case?

 The access rights of locally running content are controlled by a
 WebCore::Setting.  Currently, Chrome sets that setting to the most
 restrictive value to mitigate the harm a downloaded HTML file can
 cause.  It doesn't seem like a good idea to circumvent that security
 setting.


Ok, this sounds right. It means that we should not allow accessing a blob
URL from a local worker script per the settings, right?  If so, I can get
rid of this particular step.


  If there is a security reason for doing this, I can go
  ahead to revert this part of change.

 Thanks.

  2) Why does SecurityOrigin::canLoad take a document as an argument?
  What are the semantics of this parameter?  In particular, why does a
  SecurityOrigin::canLoad ignore |this| when called with a document
  argument on a blob URL?  That seems like a very bad idea.
 
  SecurityOrigin::canLoad is a static method. Does it have |this| to use?

 Oh, that's right.  SecurityOrigin::canLoad is junk we moved over from
 FrameLoader.  We need to make it an instance method since all the
 callers have a document anyway.

 I don't quite understand what this code is trying to do:

 bool SecurityOrigin::canLoad(const KURL url, const String referrer,
 Document* document)
 {
 #if ENABLE(BLOB)
if (url.protocolIs(blob)  document) {
SecurityOrigin* documentOrigin = document-securityOrigin();
RefPtrSecurityOrigin targetOrigin = SecurityOrigin::create(url);
return documentOrigin-isSameSchemeHostPort(targetOrigin.get());
}
 #endif

 Why should canLoad care about isSameSchemeHostPort?  In the past,
 canLoad's job was to stop web sites from loading content from your
 local file system (e.g., in frames or as images).


Per the File API spec, the blob URL should not be accessed from the page in
other security domain. Checking isSameSchemeHostPort will help us enforce
this policy when other page in different domain that tries to load this URL
from the cache. Probably I need to put better comment here or maybe find a
better place to do such check.



 Adam

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Blob changes to SecurityOrigin.cpp

2010-09-03 Thread Jian Li
On Fri, Sep 3, 2010 at 4:08 PM, Adam Barth aba...@webkit.org wrote:

 On Fri, Sep 3, 2010 at 4:02 PM, Jian Li jia...@chromium.org wrote:
  On Fri, Sep 3, 2010 at 3:43 PM, Adam Barth aba...@webkit.org wrote:
  On Fri, Sep 3, 2010 at 3:19 PM, Jian Li jia...@google.com wrote:
   The reason that we skip the unique origin check here is to allow a
 local
   running worker script to be able to access a blob URL. Do we want to
   disallow this case?
 
  The access rights of locally running content are controlled by a
  WebCore::Setting.  Currently, Chrome sets that setting to the most
  restrictive value to mitigate the harm a downloaded HTML file can
  cause.  It doesn't seem like a good idea to circumvent that security
  setting.
 
  Ok, this sounds right. It means that we should not allow accessing a blob
  URL from a local worker script per the settings, right?  If so, I can get
  rid of this particular step.

 Yes, great.

  I don't quite understand what this code is trying to do:
 
  bool SecurityOrigin::canLoad(const KURL url, const String referrer,
  Document* document)
  {
  #if ENABLE(BLOB)
 if (url.protocolIs(blob)  document) {
 SecurityOrigin* documentOrigin = document-securityOrigin();
 RefPtrSecurityOrigin targetOrigin =
 SecurityOrigin::create(url);
 return documentOrigin-isSameSchemeHostPort(targetOrigin.get());
 }
  #endif
 
  Why should canLoad care about isSameSchemeHostPort?  In the past,
  canLoad's job was to stop web sites from loading content from your
  local file system (e.g., in frames or as images).
 
  Per the File API spec, the blob URL should not be accessed from the page
 in
  other security domain. Checking isSameSchemeHostPort will help us enforce
  this policy when other page in different domain that tries to load this
 URL
  from the cache. Probably I need to put better comment here or maybe find
 a
  better place to do such check.

 Sorry canLoad is poorly named.  I'm working on a patch now to rename
 it to something more sensible (canDisplay, perhaps?).  We use canLoad
 to control things like frame src=... and img src=  When
 you say not accessible, do you mean that they shouldn't be able to
 be displayed with the image element?

 Yes. Let me use an example to explain this.

Suppose page1 (http://foo/page1) creates a blob URL blob://id1 from an
image file. In page1, blob://id1 is loaded and put into cache when we
replace any img element. In page2 (http://bar/page2), it grabs this blob URL
in some way and uses it towards its img element. We should not allow this
happen per the File API spec. Without this check in canLoad(), page2 has no
problem to use it directly from the cache.



 Adam

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


[webkit-dev] Some landed patches have incorrect date in commit messages and ChangeLog

2010-08-09 Thread Jian Li
Hi,

I noticed that several patches landed recently have the incorrect date put
in the commit messages and ChangeLog. Please fix the incorrect information
in ChangeLog. For the commit messages, anyone know if we can fix them or
not?

Please make sure the correct date is used when you land your patch manually.
Thanks.

Jian
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] How to handle a new protocol for Blob.url support?

2010-06-02 Thread Jian Li
This will probably work for most of the platforms, except the one that uses
multi-process architecture. How do we handle the case that a page is trying
to access a blob URL that is created in another process (assume the
accessing page is in the same security domain)? I think for the platform,
like Chromium, we can choose to delegate to the host to do the right job,
while all other platforms will share the same handling logic defined at a
higher level.

In addition, we might need to hook up additional logic if we want to support
using it in the shared worker process.


On Wed, Jun 2, 2010 at 6:08 PM, Darin Adler da...@apple.com wrote:

 On Jun 1, 2010, at 5:14 PM, Jian Li wrote:

 I am working on Blob.url support as defined in the latest version of File
 API (http://dev.w3.org/2006/webapi/FileAPI/). The Blob.url will return a
 URL that can be used to refer to the blob object in a resource request, like
 blobdata:f81d4fae-7dec-11d0-a765-00a0c91e6bf6. The blob object can represent
 a whole file, a partial file (created by Blob.slice), or a byte array
 (created by BlobBuilder defined in the FileWriter spec). What is the right
 place I can hook up with in order to interpret and process the blobdata
 request? Should it be in the WebKit library layer that will be implemented
 by individual platform or in the higher layer like what application cache
 does the work?


 Definitely a higher level. We don’t want to have to reimplement a feature
 like this for each platform.

 -- Darin


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


[webkit-dev] How to handle a new protocol for Blob.url support?

2010-06-01 Thread Jian Li
Hi,

I am working on Blob.url support as defined in the latest version of File
API (http://dev.w3.org/2006/webapi/FileAPI/). The Blob.url will return a URL
that can be used to refer to the blob object in a resource request, like
blobdata:f81d4fae-7dec-11d0-a765-00a0c91e6bf6. The blob object can represent
a whole file, a partial file (created by Blob.slice), or a byte array
(created by BlobBuilder defined in the FileWriter spec). What is the right
place I can hook up with in order to interpret and process the blobdata
request? Should it be in the WebKit library layer that will be implemented
by individual platform or in the higher layer like what application cache
does the work?

Thanks,

Jian
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Broken test

2010-05-18 Thread Jian Li
I am investigating it. It seems that some test cases, like testing
non-existent and empty files, are not robust enough. I am disable these test
cases in this test file and going to land the fix soon.

On Tue, May 18, 2010 at 10:15 AM, Adam Barth aba...@webkit.org wrote:

 The same test is failing on essentially all the bots:

 fast/files/file-reader.html


 http://build.webkit.org/results/SnowLeopard%20Intel%20Release%20(Tests)/r59670%20(10305)/fast/files/file-reader-pretty-diff.html

 The blame list computed by the bots is as follows:

 http://trac.webkit.org/changeset/59660
 http://trac.webkit.org/changeset/59661
 http://trac.webkit.org/changeset/59662

 However, that list doesn't make much sense.  If you touched some code
 related to this test yesterday, can you help figure out why its
 failing?

 Thanks,
 Adam
 ___
 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] Question regarding build flags for the features

2010-03-23 Thread Jian Li
Hi,

I've introduced a build flag ENABLE(BLOB_SLICE) for the Blob.slice feature.
To continue implementing other File API features, we probably need a couple
more build flags, like ENABLE(FILE_URN) and ENABLE(FILE_READER). When the
embedder implements the necessary support, these flags can be turned on
respectively. Do we want to use multiple flags to control File API features
or simply use one flag? For the latter, all the features will only
be available after the embedder hooks up all the supporting logics.

Thanks,

Jian
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Failing tests blocking commit queue

2010-03-11 Thread Jian Li
I will mark http/tests/local/send-sliced-dragged-file.html as Skipped on
mac-tiger since it frequently times out in a tiger machine.

On Thu, Mar 11, 2010 at 2:42 PM, Kenneth Russell k...@google.com wrote:

 Sorry to complain without going in and just fixing the issue, but it
 looks like the commit queue has been blocked for roughly 24 hours due
 to tests failing or timing out. A quick look points to these tests; if
 you've made changes in these areas recently, could you please take a
 look?

 transitions/change-values-during-transition.html

 compositing/masks/direct-image-mask.html

 fast/loader/api-test-new-window-data-load-base-url.html
 inspector/console-log-before-inspector-open.html
 http/tests/local/send-sliced-dragged-file.html

 Thanks,

 -Ken
 ___
 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] Question on FormData interface and implementation

2010-02-25 Thread Jian Li
Hi,

I am looking into the work to support FormData interface as defined in
XMLHttpRequest Level 2 (
http://dev.w3.org/2006/webapi/XMLHttpRequest-2/#formdata). To support the
new FormData interface, we need to add the FormData object that collides
with the name that has already existed. Currently we already have FormData
and FormDataElement that encapsulate the formalized data to send out. How
are we going to resolve the naming issue?

Approach 1: we can try to merge the current version of FormData with the new
functionalities in the to-be-added FormData. This means that the new version
will handle both raw key-value-pair FormData and formalized FormData. It
seems to be a little bit messy, IMHO.

Approach 2: we can rename the current version of FormData to something like
FormalizedFormData or FormSendingData that keeps all the current logic to
represent the formalized data to send out. We then use FormData for the new
FormData interface, that represent the raw key-value-pair list, just like
FormDataList. Indeed we will merge FormDataList into this new version of
FormData.

How do you guys think?

Thanks,

Jian
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Question on FormData interface and implementation

2010-02-25 Thread Jian Li
I like option 3 since it seems to be the one to involve far less changes.
However, people who read the code really need to get a good understanding of
differences between FormData and DOMFormData.


On Thu, Feb 25, 2010 at 4:07 PM, Michael Nordman micha...@google.comwrote:

 option 3: We could name any new classes backing the new scriptable object
 as DOMFormData (similar in sprirt to DOMWindow), and leave the existing
 FormData classes as they are.

 On Thu, Feb 25, 2010 at 3:31 PM, Jian Li jia...@chromium.org wrote:

 Hi,

 I am looking into the work to support FormData interface as defined in
 XMLHttpRequest Level 2 (
 http://dev.w3.org/2006/webapi/XMLHttpRequest-2/#formdata). To support the
 new FormData interface, we need to add the FormData object that collides
 with the name that has already existed. Currently we already have FormData
 and FormDataElement that encapsulate the formalized data to send out. How
 are we going to resolve the naming issue?

 Approach 1: we can try to merge the current version of FormData with the
 new functionalities in the to-be-added FormData. This means that the new
 version will handle both raw key-value-pair FormData and formalized
 FormData. It seems to be a little bit messy, IMHO.

 Approach 2: we can rename the current version of FormData to something
 like FormalizedFormData or FormSendingData that keeps all the current logic
 to represent the formalized data to send out. We then use FormData for the
 new FormData interface, that represent the raw key-value-pair list, just
 like FormDataList. Indeed we will merge FormDataList into this new version
 of FormData.

 How do you guys think?

 Thanks,

 Jian


 ___
 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] Blob.slice support

2010-02-19 Thread Jian Li
Hi,

I am working on Blob.slice support as defined in the File API (
http://www.w3.org/TR/FileAPI/). To make it work, we need to get the network
embedder layer to add the capability to send the file range. I plan to add
the following fields to class FormDataElement:

long long m_fileStart;
long long m_fileLength;
time_t m_fileModificationTime;

The individual platform needs to support the followings:
1) Checking if the underlying file has been changed by
comparing m_fileModificationTime against the modification time when the file
is opened for read. If different, throw an error. This is per the discussion
of how we are going to deal with the underlying file change for Blob (
http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0371.html).
2) Sending the file range denoted by m_fileStart and m_fileLength.

In addition, I am going to add ENABLE_BLOB_SLICE flag to control if
Blob.slice API should be exposed or not. When a platform implements the
necessary support to read the file range, ENABLE_BLOB_SLICE flag can then
been turned on.

I will make chromium platform and WebKit on mac platform to support the
above requirements in order to get Blob.slice work. Please let me know if
you have any questions.

Thanks,

Jian
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] The tree is on fire

2010-01-22 Thread Jian Li
Thanks dimich for fixing this debug-only test failure. The buildbot seems to
be improving a lot now.

Sorry for the failures caused by r53722. I have fixed all related failures
on Mac and Qt. The Gtk results seem not be updated for quite some time. So I
do not touch them. If there is anything else I need to address, please ping
me.

There is another show stopper caused by
http://trac.webkit.org/changeset/53740.


On Fri, Jan 22, 2010 at 5:03 PM, Eric Seidel e...@webkit.org wrote:

 I'm learning to email.

 On Fri, Jan 22, 2010 at 5:03 PM, Eric Seidel esei...@google.com wrote:
  https://bugs.webkit.org/show_bug.cgi?id=33948 also broke leopard.
 
  On Fri, Jan 22, 2010 at 4:34 PM, Maciej Stachowiak m...@apple.com
 wrote:
 
  Ever since this change:
 
  http://trac.webkit.org/changeset/53722
 
  The Leopard and SnowLeopard tests have been failing
 fast/dom/Window/window-property-descriptors.html.
 
  Ironically, it looks like that patch landed new results in an attempt to
 fix that test, but it looks to me like the new results are broken.
 
  Please fix ASAP.
 
  Regards,
  Maciej
 
  ___
  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] Legacy attributes in existing File interface

2010-01-15 Thread Jian Li
Hi,

I am in the process of implementing the new File API as in
http://www.w3.org/TR/FileAPI/. I have a question regarding legacy methods in
the existing File interface.

The existing File interface defines fileName and fileSize attributes. In the
new File API spec, they are called as name in File interface and size in
Blob interface. How are we going to address these legacy attributes? Do we
want to keep them side by side with the new attributes? Do we want to remove
them after certain period of time?

Thanks,

Jian
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


[webkit-dev] How to add a new interface for ObjC bindings?

2009-12-22 Thread Jian Li
Hi,

I am working on adding Blob interface based on the latest File API spec. I
have one question about the various kinds of bindings we need to put up for
this new interface. I got JSC and V8 bindings generated and built
successfully. I have some problem with ObjC bindings. What's the right
procedure to add a new interface for ObjC bindings? I could see DOMBlob.h
being created under Debug/DerivedSources/WebCore, but not under
Debug/WebCore.framework/PrivateHeaders and Debug/WebKit.framework/Headers as
other interfaces do. How could I change WebCore.xcodeproj to add the build
steps for these? Any other things I need to pay attention to?

In addition, where do we use COM bindings? Is it only used when building
WebKit under Windows?

Thanks,

Jian
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] How to add a new interface for ObjC bindings?

2009-12-22 Thread Jian Li
Thanks for all your information. Do you mean to add files into
MigrateHeaders.make as the following?
$(PRIVATE_HEADERS_DIR)/DOMBlob.h \
$(INTERNAL_HEADERS_DIR)/DOMBlobInternal.h \

What's the difference between adding into PRIVATE_HEADERS_DIR and adding
into PUBLIC_HEADERS_DIR? Blob interface is indeed the new superclass
introduced for the existing File interface per the File API spec. Since File
has already been added into PUBLIC_HEADERS_DIR, do we need to do the same
thing for Blob?

I still can't get the generated DOMBlob.h and DOMBlobInternal.h copied into
PrivateHeaders of WebCore.framework. From the build output, I can see that
PBXCp is called for DOMFile.h, but not for DOMBlob.h. Do I need to change
other script file or makefile? Or I should change WebCore.xcodeproj to add
the generated header files. If so, which group should I add to?


On Tue, Dec 22, 2009 at 4:04 PM, David Kilzer ddkil...@webkit.org wrote:

 All the magic for the Obj-C DOM headers happens in:

 WebCore/DerivedSources.make
 WebKit/mac/MigrateHeaders.make

 It should be added as a PrivateHeader first, if at all.  Someone else will
 have to address COM bindings since I don't know much about those.

 Dave


 *From:* Jian Li jia...@chromium.org
 *To:* webkit-dev@lists.webkit.org
 *Sent:* Tue, December 22, 2009 3:05:08 PM
 *Subject:* [webkit-dev] How to add a new interface for ObjC bindings?

 Hi,

 I am working on adding Blob interface based on the latest File API spec. I
 have one question about the various kinds of bindings we need to put up for
 this new interface. I got JSC and V8 bindings generated and built
 successfully. I have some problem with ObjC bindings. What's the right
 procedure to add a new interface for ObjC bindings? I could see DOMBlob.h
 being created under Debug/DerivedSources/WebCore, but not under
 Debug/WebCore.framework/PrivateHeaders and Debug/WebKit.framework/Headers as
 other interfaces do. How could I change WebCore.xcodeproj to add the build
 steps for these? Any other things I need to pay attention to?

 In addition, where do we use COM bindings? Is it only used when building
 WebKit under Windows?

 Thanks,

 Jian


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] [V8] It's time for V8Proxy to come to Jesus

2009-07-04 Thread Jian Li
FYI, we've also another WorkerContextExecutionProxy that acts like V8Proxy
in order to talk to V8 engine for everything needed in WorkerContext. When
we do refactoring for V8Proxy, we also need to make it be able to support
different execution context.

On Fri, Jul 3, 2009 at 12:23 PM, Adam Barth aba...@webkit.org wrote:

 If you're uninterested in the V8 bindings, you can skip this email.

 Clocking in at 3255 lines (plus a 682-line header file), V8Proxy is
 out of control.  Historically a bridge from the V8 bindings to the V8
 engine, V8Proxy is responsible for a number of tasks including:

 1) Creating new contexts
 2) Implementing security checks
 3) Supervising garbage collection
 4) Caching event listeners
 5) Executing scripts
 6) Converting between frames, contexts, and global objects
 7) Manging DOM wrappers
 8) etc, etc, etc

 I propose we separate these concerns into a number of distinct classes
 that have clear, understandable purposes before things get worse.

 Please let me know if you have any in-progress patches to V8Proxy.
 I'd like to lock that file sometime next week while I rip it apart and
 put it back together.

 Thanks,
 Adam

 P.S., FrameLoader: you've escaped for now, but don't think I'm not watching
 you.
 ___
 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] Any problem to use ThreadableLoader to load scripts in nested workers, instead of CachedResource?

2009-04-17 Thread Jian Li
To make script loading in nested worker work, I plan to change the use of
CachedResource machinery to ThreadableLoader, as in bug 25215 (
https://bugs.webkit.org/show_bug.cgi?id=25215).
Can anyone who is an expert on loading design advise if this switch has any
problem or not?

Thanks a lot,

Jian
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Propose some changes to WebKit implementation of HTML5 workers in order to run them in Chrome's worker process

2009-02-05 Thread Jian Li
Based on the initial refactoring of WorkerMessagingProxy class, I've updated
the abstractions as the following:

// A proxy to talk to the worker context.
// All calls to any methods should come from worker object thread.class
WorkerContextProxyBase {
public:
// Creator.
static WorkerContextProxy* create(const String scriptUrl, Worker*
worker);

// Terminates the worker context.
virtual void terminateWorkerContext() = 0;

// Posts the message to the worker context.
virtual void postMessageToWorkerContext(const String message) = 0;

// Has any pending activity?
virtual bool hasPendingActivity() const = 0;
};

// A proxy to talk to the worker object.
// All calls to any methods should come from worker context thread.
class WorkerObjectProxyBase {
public:
// Posts the message to the worker object.
virtual void postMessageToWorkerObject(const String message) = 0;

// Posts the exception to the worker object.
virtual void postExceptionToWorkerObject(const String errorMessage, int
lineNumber, const String sourceURL) = 0;

// Reports if there is pending activity in the worker context.
virtual void reportPendingActivity(bool hasPendingActivity) = 0;

// Called when the worker context is destroyed.
virtual void workerContextDestroyed() = 0;
};




On Mon, Feb 2, 2009 at 6:10 PM, Jian Li jia...@chromium.org wrote:

 The current WebKit implementation of HTML5 workers is based on cross-thread
 communication in single process. To make it work for Chrome, we need to run
 the workers in Chrome's worker process. Hence, we propose the following
 changes:

 MessagingWorkerProxy acts as the gateway between Worker and WorkerContext in
 order to exchange messages. This does not work well across process. To
 support both cross-thread and cross-process models, we propose splitting
 MessagingWorkerProxy into two pieces: WorkerContextProxy and
 WorkerObjectProxy.

 For WebKit, MessagingWorkerProxy can implement both WorkerContextProxy
  and WorkerObjectProxy, that communicate with each other via cross-thread
 task posting. Some changes need also to be made in DOM objects in order to
 put them in the right scope. For example, MessageWorkerTask.performTask can
 be moved to Worker object and MessageWorkerContextTask.performTask can be
 moved to WorkerContext object.

 For Chrome, the implementation of WorkerContextProxy uses IPC to
 communicate with the implementation of WorkerObjectProxy at the other end.

 Worker = WorkerContextProxy = ... = WorkParentProxy =
 WorkerContext

   WebKit: \--- in main thread  ---/   CTC \-- in worker thread
  -/
   (CTC: Cross-thread communication by posting task)

   Chrome: \- in renderer process -/   IPC \-- in worker process
 -/
   (IPC: Inter-process communication)


 The abstractions of WorkerContextProxy and WorkerObjectProxy are defined
 as the following:

 // A proxy to talk to the worker context.
 // All calls to any methods should come from main thread.
 class WorkerContextProxy {
 public:
   // Creator.
   static WorkerContextProxy* create();

   // Starts the worker context. Returns 0 if successful, error code
 otherwise.
   virtual int startContext(const String scriptUrl, Worker* worker) = 0;

   // Terminates the worker context.
   virtual void terminateContext() = 0;

   // Posts the message to the worker context.
   virtual void postMessageToContext(const String message) = 0;

   // Has any pending activity?
   virtual bool hasPendingActivity() = 0;
 };

 // A proxy to talk to the worker object.
 // All calls to any methods should come from worker thread.
 class WorkerObjectProxy {
 public:
   // Runs the script with the specified url.
   virtual bool run(const String scriptURL) = 0;

   // Posts the message to the worker object.
   virtual void postMessageToObject(const String message) = 0;

   // Posts the exception to the worker object.
   virtual void postExceptionToObject(const String errorMessage, int
 lineNumber, const String sourceURL) = 0;
 };



___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


[webkit-dev] Propose some changes to WebKit implementation of HTML5 workers in order to run them in Chrome's worker process

2009-02-02 Thread Jian Li
The current WebKit implementation of HTML5 workers is based on cross-thread
communication in single process. To make it work for Chrome, we need to run
the workers in Chrome's worker process. Hence, we propose the following
changes:

MessagingWorkerProxy acts as the gateway between Worker and WorkerContext in
order to exchange messages. This does not work well across process. To
support both cross-thread and cross-process models, we propose splitting
MessagingWorkerProxy into two pieces: WorkerContextProxy and
WorkerObjectProxy.

For WebKit, MessagingWorkerProxy can implement both WorkerContextProxy and
WorkerObjectProxy, that communicate with each other via cross-thread task
posting. Some changes need also to be made in DOM objects in order to put
them in the right scope. For example, MessageWorkerTask.performTask can be
moved to Worker object and MessageWorkerContextTask.performTask can be moved
to WorkerContext object.

For Chrome, the implementation of WorkerContextProxy uses IPC to communicate
with the implementation of WorkerObjectProxy at the other end.

Worker = WorkerContextProxy = ... = WorkParentProxy =
WorkerContext

  WebKit: \--- in main thread  ---/   CTC \-- in worker thread
 -/
  (CTC: Cross-thread communication by posting task)

  Chrome: \- in renderer process -/   IPC \-- in worker process
-/
  (IPC: Inter-process communication)


The abstractions of WorkerContextProxy and WorkerObjectProxy are defined as
the following:

// A proxy to talk to the worker context.
// All calls to any methods should come from main thread.
class WorkerContextProxy {
public:
  // Creator.
  static WorkerContextProxy* create();

  // Starts the worker context. Returns 0 if successful, error code
otherwise.
  virtual int startContext(const String scriptUrl, Worker* worker) = 0;

  // Terminates the worker context.
  virtual void terminateContext() = 0;

  // Posts the message to the worker context.
  virtual void postMessageToContext(const String message) = 0;

  // Has any pending activity?
  virtual bool hasPendingActivity() = 0;
};

// A proxy to talk to the worker object.
// All calls to any methods should come from worker thread.
class WorkerObjectProxy {
public:
  // Runs the script with the specified url.
  virtual bool run(const String scriptURL) = 0;

  // Posts the message to the worker object.
  virtual void postMessageToObject(const String message) = 0;

  // Posts the exception to the worker object.
  virtual void postExceptionToObject(const String errorMessage, int
lineNumber, const String sourceURL) = 0;
};
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev