Re: [webkit-dev] Common build system (was Re: WebKit Wishes)

[Mark Rowe]

On 2013-02-03, at 21:20, Maciej Stachowiak  wrote:

> I should mention that there's a lot of interest right now at Apple in the 
> possibility of switching to Gyp. 

I’ve filed  to track initial 
work in getting gyp set up for the Mac build. I’m initially attempting to 
generate Xcode projects that closely match our existing projects in order to 
minimize unintentional changes in build behavior.

- Mark


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

Re: [webkit-dev] Constructors for DOM4 Events

[Kentaro Hara]

Now all DOM4 event constructors (UIEvent, FocusEvent, MouseEvent,
WheelEvent, CompositionEvent and KeyboardEvent) are implemented under
a DOM4_EVENTS_CONSTRUCTOR flag.

Currently the flag is enabled on Safari and Chromium. Please enable
the flag once your port wants to enable the feature.

Before:
  event=document.createEvent("MouseEvents");
  
event.initMouseEvent("click",true,false,null,0,0,0,0,0,false,false,false,false,0,null);

After:
  event = new MouseEvent("click", {bubbles: true});

Spec: https://dvcs.w3.org/hg/d4e/raw-file/tip/source_respec.htm
Bug: https://bugs.webkit.org/show_bug.cgi?id=67824



On Mon, Jan 14, 2013 at 8:38 AM, Sam Weinig  wrote:
> Seems fine to me.
>
> -Sam
>
> On Jan 10, 2013, at 6:36 AM, Kentaro Hara  wrote:
>
>> At TPAC there was no objection for DOM4 Event constructors (e.g. new
>> MouseEvent()).
>>
>> Now DOM4 Event constructors are on editor's draft:
>> http://html5labs.interoperabilitybridges.com/dom4events/
>> https://dvcs.w3.org/hg/d4e/raw-file/tip/source_respec.htm
>>
>> Given the above, I am planning to implement them in WebKit (without
>> any flag). If you have any concern, please let me know.
>>
>> Best Regards
>>
>>
>> On Mon, Oct 1, 2012 at 7:44 AM, Kentaro Hara  wrote:
 Since TPAC is less than a month away, I don't understand why we can't wait 
 for that discussion.
>>>
>>> Sounds reasonable. I'll wait for TPAC.
>>>
 I do support the idea in general, and I plan to be at TPAC and will 
 advocate for it.
>>>
>>> I'll be also going to TPAC. I would appreciate your support.
>>>
>>>
>>>
>>> On Mon, Oct 1, 2012 at 2:11 PM, Maciej Stachowiak  wrote:

 Since TPAC is less than a month away, I don't understand why we can't wait 
 for that discussion. I do support the idea in general, and I plan to be at 
 TPAC and will advocate for it.

 I understand that sometimes we need to move ahead of the spec. If there's 
 a reason not to wait a few extra weeks in this case, then please at least 
 use a prefix.

 Cheers,
 Maciej

 On Sep 30, 2012, at 6:32 PM, Kentaro Hara  wrote:

> TL;DR: Would it be OK to implement constructors for DOM4 Events in
> WebKit without waiting for the spec?
>
>
> == Background ==
>
> Events should have constructors. 'new XXXEvent()' is much easier than
> 'e = document.createEvent(...); e.initXXXEvent(_a_lot_of_arguments_)'.
> We have already implemented constructors for a bunch of Events such as
> Event, CustomEvent, ProgressEvent, etc [5]. However, we have not yet
> implemented constructors for DOM4 Events (i.e. UIEvent, MouseEvent,
> KeyboardEvent, WheelEvent, TextEvent, CompositionEvent) because they
> are not yet speced.
>
> Recently PointerEvent was speced with [Constructor] [2]. Considering
> that PointerEvent inherits MouseEvent, now we want to support
> [Constructor] on MouseEvent
> too. In terms of implementation, it is possible to implement
> [Constructor] on PointerEvent without implementing [Constructor] on
> MouseEvent. However, implementing [Constructor] on both PointerEvent
> and MouseEvent would be best.
>
> == Rationale for implementing constructors for DOM4 Events ==
>
> I have been discussing this topic for one year, in www-dom@ [4] and a
> www.w3.org bug [3]. It looks like there is a consensus on introducing
> constructors for DOM4 Events. However, the spec is still a draft [1]
> and the www.w3.org bug [3] is marked as LATER. Last week I discussed
> the timeline of the spec with Jacob Rossi (a.k.a. a spec author of
> PointerEvent and DOM4 Events). According to him:
>
> - Their primary focus is on finishing DOM3 Events first.
> - With DOM3 Events in Candidate Recommendation, they are going to
> start working on the DOM4 Events. They will discuss it in TPAC.
> - They will introduce constructors to DOM4 Events.
>
> In summary, constructors for DOM4 Events are going to be speced, but
> it will take time. So I would like to implement them in WebKit a bit
> ahead of the spec (and thus implement PointerEvent constructors too).
> If you have any concern, please let me know.
>
>
> == References ==
> [1] The spec draft by Jacob Rossi:
> http://html5labs.interoperabilitybridges.com/dom4events/
>
> [2] The spec of Pointer Events:
> http://www.w3.org/Submission/pointer-events/
>
> [3] www.w3.org bug:
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=14051
>
> [4] Discussion on www-dom@:
> http://lists.w3.org/Archives/Public/www-dom/2011OctDec/0081.html
> http://lists.w3.org/Archives/Public/www-dom/2012JanMar/0025.html
>
> [5] WebKit bug:
> https://bugs.webkit.org/show_bug.cgi?id=67824
>
>
> --
> Kentaro Hara, Tokyo, Japan (http://haraken.info)
> ___
> webkit-dev mailing list
> w

Re: [webkit-dev] SerializedScriptValue: signed vs unsigned char

[Darin Adler]

On Feb 7, 2013, at 8:31 AM, Glenn Adams  wrote:

> Given Maciej and Adam's comments, you had best stay with unsigned char/uint_8 
> and convert any non-conforming usage to this pattern when needed.

Yes, I think that’s the right direction for WebKit.

-- Darin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] SerializedScriptValue: signed vs unsigned char

[Glenn Adams]

On Wed, Feb 6, 2013 at 5:35 PM, Alec Flett  wrote:

>
> Personally outside of WebKit I tend to see more "char*" as the common
> denominator for raw bytes.
>

I've been coding in C since around 1972, and I admit that in the early
days, char was used as a synonym for byte, however, that convention has
long been dropped in favor of unsigned char. See [1] for a nice discussion,
especially the second answer.

[1]
http://stackoverflow.com/questions/653336/should-a-buffer-of-bytes-be-signed-or-unsigned-char-buffer


>
> So far Benjamin objected, and then seems to have rescinded. Glenn, do you
> depend on SerializedScriptValue's current method signatures?
>

I personally alway use unsigned char/uint8_t for raw byte strings. However,
I don't have any dependency on SerializedScriptValue.

Given Maciej and Adam's comments, you had best stay with unsigned
char/uint_8 and convert any non-conforming usage to this pattern when
needed.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Can we remove Notification.show()?

[Claudio Saavedra]

On Thu, 2013-02-07 at 13:55 +0100, Andrew Wilson wrote:
> It should definitely not be necessary to call Notification.show(),
> although I have not removed that API since I am busy with some other
> tasks currently. What browser/WebKit revision are you using?

You're right. It's a fairly recent master, though I am implementing web
notifications support in the GTK+ port so I'm probably overlooking
something in there, my bad.

> What's the status of this? Apparently it is still necessary to
> call Notification.show() after a notification is created. Are
> you tracking this in a bug report?

Just noticed https://bugs.webkit.org/show_bug.cgi?id=108066 .

Claudio


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

Re: [webkit-dev] Can we remove Notification.show()?

[Andrew Wilson]

It should definitely not be necessary to call Notification.show(), although
I have not removed that API since I am busy with some other tasks
currently. What browser/WebKit revision are you using?

In Chrome 26, I just opened the javascript console and typed "new
Notification('blah')" and it displayed a notification, so it doesn't seem
like show() is necessary in more recent versions of WebKit.


On Thu, Feb 7, 2013 at 1:51 PM, Claudio Saavedra wrote:

> On Mon, 2013-01-28 at 10:35 +0100, Andrew Wilson wrote:
> > So, we've recently landed some fixes to address permissions handling
> > for Notification.show(): http://trac.webkit.org/changeset/140927
> >
> > Turns out, the notifications specification does not have a show() API
> > (the notification is automatically shown from the constructor
> > -- http://notifications.spec.whatwg.org/#api). Does anyone have any
> > objections to moving the show() API under the
> > ENABLE_LEGACY_NOTIFICATIONS flag to bring us under compliance with the
> > spec?
>
> What's the status of this? Apparently it is still necessary to call
> Notification.show() after a notification is created. Are you tracking
> this in a bug report?
>
> Claudio
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Can we remove Notification.show()?

[Claudio Saavedra]

On Mon, 2013-01-28 at 10:35 +0100, Andrew Wilson wrote:
> So, we've recently landed some fixes to address permissions handling
> for Notification.show(): http://trac.webkit.org/changeset/140927
>
> Turns out, the notifications specification does not have a show() API
> (the notification is automatically shown from the constructor
> -- http://notifications.spec.whatwg.org/#api). Does anyone have any
> objections to moving the show() API under the
> ENABLE_LEGACY_NOTIFICATIONS flag to bring us under compliance with the
> spec?

What's the status of this? Apparently it is still necessary to call
Notification.show() after a notification is created. Are you tracking
this in a bug report?

Claudio

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

Re: [webkit-dev] Adding 'X-Content-Type-Options: nosniff' support for scripts.

[Mike West]

(resending from the correct address)

I just checked
http://philip.html5.org/tests/ie8/cases/content-type-nosniff.html in IE10,
and '
http://philip.html5.org/tests/ie8/cases/resources/script_as_text_plain_nosniff'
is blocked as expected. It looks like they resolved the issues they faced
without changing the behavior significantly.

-mike

-Mike


On Thu, Feb 7, 2013 at 10:17 AM, Mike West  wrote:

> I just checked
> http://philip.html5.org/tests/ie8/cases/content-type-nosniff.html in
> IE10, and '
> http://philip.html5.org/tests/ie8/cases/resources/script_as_text_plain_nosniff'
> is blocked as expected. It looks like they resolved the issues they faced
> without changing the behavior significantly.
>
> -mike
>
> --
> Mike West , Developer Advocate
> Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
> Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91
>
>
> On Wed, Feb 6, 2013 at 7:19 PM, Adam Barth  wrote:
>
>> We should check whether IE still have that behavior (i.e., in the
>> latest version of IE).  I remember them running into some
>> compatibility problems with that aspect of nosniff, and I'm not sure
>> if they resolved those issue via evangelism or by adopting our
>> behavior.
>>
>> Adam
>>
>>
>> On Wed, Feb 6, 2013 at 1:33 AM, Mike West  wrote:
>> > Continuing my trend of digging up old threads, I'd like to implement
>> support
>> > for 'X-Content-Type-Options: nosniff' when processing script, as
>> discussed
>> > way back in 2011:
>> > https://lists.webkit.org/pipermail/webkit-dev/2011-November/018557.html
>> .
>> >
>> > This should be a pretty small patch[1], but because support might
>> require
>> > work outside WebKit, I'll implement it behind an ENABLE_NOSNIFF flag[2].
>> >
>> > Thanks!
>> >
>> > [1]: https://bugs.webkit.org/show_bug.cgi?id=71851
>> > [2]: https://bugs.webkit.org/show_bug.cgi?id=109029
>> >
>> > -mike
>> >
>> > ___
>> > webkit-dev mailing list
>> > webkit-dev@lists.webkit.org
>> > https://lists.webkit.org/mailman/listinfo/webkit-dev
>> >
>>
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev