[webkit-dev] feature proposal: restricting window.blur/focus
Hey, Firefox restricts the use of window.blur() and window.focus() (by default). window.blur() is just doing nothing, and window.focus() only works if the caller is running in the same window. Should we implement similar rules for WebKit? The purpose of this is to make pop-unders more difficult to achieve. I think this can be implemented in such a way the the chrome implementation which is doing the actual focusing/bluring anyway has enough information to let each port control what they want to do. wdyt? -jochen ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] RegExp on JSStaticFunction
I will try it.
Thanks.
El 3 de abril de 2012 18:46, Geoffrey Garen gga...@apple.com escribió:
JavaScript doesn't have a concept of intercept any method invocation.
However, it does have a concept of intercept any property access. I
believe you could accomplish what you want by implementing a catch-all
JSObjectGetPropertyCallback that created the necessary function objects on
the fly, and cached them.
Geoff
On Apr 3, 2012, at 1:02 AM, Iker Perez de Albeniz wrote:
Hi,
I have estarted a personal project and i am new on wbkit development. I
have a question about the posibility of using regular expression on
JSStaticFunction struct name.. so i can resolve every methos of a class
with an unique funcrtion..
My idea is to hace a fucntion that conects to a socket where the core
of the class is available.. so i can do something like..
static JSValueRef myclass_mymethod(JSContextRef context,
JSObjectRef function,
JSObjectRef thisObject,
size_t argumentCount,
const JSValueRef arguments[],
JSValueRef *exception)
{
// get the name of the funcion called
//open a socket and call to a REST service
}
static const JSStaticFunction class_staticfuncs[] ={
{ .*, myclass_mymethod, kJSPropertyAttributeReadOnly },
{ NULL, NULL, 0 }
};
The idea is to create a bridge betwing JS and a core accesible via
sockets/Json..
Regards.
___
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] Adding Encrypted Media Extensions
Last I saw, there hadn't been any attempt to actually define how the content is encrypted. Has that changed? If it hasn't how do we get interoperable implementations? The only way for this spec to not break the openness of video and audio is for the encryption algorithm to be completely defined in the spec. --Oliver On Apr 4, 2012, at 9:55 AM, David Dorwin wrote: Hi WebKit! I plan to add the Encrypted Media Extensions to the media elements. The extensions allow web applications using audio and video to control key exchange. The extensions will be behind the ENCRYPTED_MEDIA feature define. The feature is tracked as https://bugs.webkit.org/show_bug.cgi?id=82968. Implementation will be based on the draft proposal at http://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html, which was published jointly by Google, Microsoft, and Netflix [1]. It appears a Media Task Force will be taking this on to produce a Working Draft [2]. Having an implementation will allow us to include implementation experience in the development of the draft. As described in the proposal, several new methods and events are added to HTMLMediaElement and a new keySystem parameter and attribute are added to canPlayType() and HTMLSourceElement, respectively. As with much of the media stack, most of the functionality will be implemented within the various ports. ENCRYPTED_MEDIA will be enabled for the Chromium port and covered by its buildbot. Regards, David [1] http://lists.w3.org/Archives/Public/public-html/2012Feb/0273.html [2] http://lists.w3.org/Archives/Public/public-html/2012Apr/0007.html ___ 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] feature proposal: restricting window.blur/focus
I am all for this change, but a not insubstantial part of that is my general hate for anything other than me ever changing the focused window and/or element. --Oliver On Apr 4, 2012, at 1:31 AM, Jochen Eisinger wrote: Hey, Firefox restricts the use of window.blur() and window.focus() (by default). window.blur() is just doing nothing, and window.focus() only works if the caller is running in the same window. Should we implement similar rules for WebKit? The purpose of this is to make pop-unders more difficult to achieve. I think this can be implemented in such a way the the chrome implementation which is doing the actual focusing/bluring anyway has enough information to let each port control what they want to do. wdyt? -jochen ___ 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] feature proposal: restricting window.blur/focus
Matching Firefox behavior likely means that we won't have to worry about breaking sites. We may have to worry about breaking Chrome Extensions or other browser-specific content. -Darin On Wed, Apr 4, 2012 at 1:31 AM, Jochen Eisinger joc...@chromium.org wrote: Hey, Firefox restricts the use of window.blur() and window.focus() (by default). window.blur() is just doing nothing, and window.focus() only works if the caller is running in the same window. Should we implement similar rules for WebKit? The purpose of this is to make pop-unders more difficult to achieve. I think this can be implemented in such a way the the chrome implementation which is doing the actual focusing/bluring anyway has enough information to let each port control what they want to do. wdyt? -jochen ___ 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] feature proposal: restricting window.blur/focus
On Wed, Apr 4, 2012 at 7:53 PM, Darin Fisher da...@chromium.org wrote: Matching Firefox behavior likely means that we won't have to worry about breaking sites. We may have to worry about breaking Chrome Extensions or other browser-specific content. We could add a method to ChromeClient that would enable an embedder to override the restriction under certain circumstances -jochen -Darin On Wed, Apr 4, 2012 at 1:31 AM, Jochen Eisinger joc...@chromium.orgwrote: Hey, Firefox restricts the use of window.blur() and window.focus() (by default). window.blur() is just doing nothing, and window.focus() only works if the caller is running in the same window. Should we implement similar rules for WebKit? The purpose of this is to make pop-unders more difficult to achieve. I think this can be implemented in such a way the the chrome implementation which is doing the actual focusing/bluring anyway has enough information to let each port control what they want to do. wdyt? -jochen ___ 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] feature proposal: restricting window.blur/focus
On Wed, Apr 4, 2012 at 10:58 AM, Jochen Eisinger joc...@chromium.orgwrote: On Wed, Apr 4, 2012 at 7:53 PM, Darin Fisher da...@chromium.org wrote: Matching Firefox behavior likely means that we won't have to worry about breaking sites. We may have to worry about breaking Chrome Extensions or other browser-specific content. We could add a method to ChromeClient that would enable an embedder to override the restriction under certain circumstances Or, perhaps something like UserGestureIndicator. I'm not sure which is better. -Darin -jochen -Darin On Wed, Apr 4, 2012 at 1:31 AM, Jochen Eisinger joc...@chromium.orgwrote: Hey, Firefox restricts the use of window.blur() and window.focus() (by default). window.blur() is just doing nothing, and window.focus() only works if the caller is running in the same window. Should we implement similar rules for WebKit? The purpose of this is to make pop-unders more difficult to achieve. I think this can be implemented in such a way the the chrome implementation which is doing the actual focusing/bluring anyway has enough information to let each port control what they want to do. wdyt? -jochen ___ 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] feature proposal: restricting window.blur/focus
On Wed, Apr 4, 2012 at 8:01 PM, Darin Fisher da...@chromium.org wrote: On Wed, Apr 4, 2012 at 10:58 AM, Jochen Eisinger joc...@chromium.orgwrote: On Wed, Apr 4, 2012 at 7:53 PM, Darin Fisher da...@chromium.org wrote: Matching Firefox behavior likely means that we won't have to worry about breaking sites. We may have to worry about breaking Chrome Extensions or other browser-specific content. We could add a method to ChromeClient that would enable an embedder to override the restriction under certain circumstances Or, perhaps something like UserGestureIndicator. I'm not sure which is better. Not sure I understand? Are you suggesting to allowing focusing/blurring in response to a user action? I think that's undesirable, as the site that wants to pop-under a window probably stole a click to be able to run window.open already. -jochen -Darin -jochen -Darin On Wed, Apr 4, 2012 at 1:31 AM, Jochen Eisinger joc...@chromium.orgwrote: Hey, Firefox restricts the use of window.blur() and window.focus() (by default). window.blur() is just doing nothing, and window.focus() only works if the caller is running in the same window. Should we implement similar rules for WebKit? The purpose of this is to make pop-unders more difficult to achieve. I think this can be implemented in such a way the the chrome implementation which is doing the actual focusing/bluring anyway has enough information to let each port control what they want to do. wdyt? -jochen ___ 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] feature proposal: restricting window.blur/focus
On Wed, Apr 4, 2012 at 11:17 AM, Jochen Eisinger joc...@chromium.orgwrote: On Wed, Apr 4, 2012 at 8:01 PM, Darin Fisher da...@chromium.org wrote: On Wed, Apr 4, 2012 at 10:58 AM, Jochen Eisinger joc...@chromium.orgwrote: On Wed, Apr 4, 2012 at 7:53 PM, Darin Fisher da...@chromium.org wrote: Matching Firefox behavior likely means that we won't have to worry about breaking sites. We may have to worry about breaking Chrome Extensions or other browser-specific content. We could add a method to ChromeClient that would enable an embedder to override the restriction under certain circumstances Or, perhaps something like UserGestureIndicator. I'm not sure which is better. Not sure I understand? Are you suggesting to allowing focusing/blurring in response to a user action? I think that's undesirable, as the site that wants to pop-under a window probably stole a click to be able to run window.open already. No, no... sorry for being unclear. I meant that you could have a global state variable (allow focusing / blurring) that gets controlled by a scoped helper class. This is an alternative to having a ChromeClient callback. -Darin -jochen -Darin -jochen -Darin On Wed, Apr 4, 2012 at 1:31 AM, Jochen Eisinger joc...@chromium.orgwrote: Hey, Firefox restricts the use of window.blur() and window.focus() (by default). window.blur() is just doing nothing, and window.focus() only works if the caller is running in the same window. Should we implement similar rules for WebKit? The purpose of this is to make pop-unders more difficult to achieve. I think this can be implemented in such a way the the chrome implementation which is doing the actual focusing/bluring anyway has enough information to let each port control what they want to do. wdyt? -jochen ___ 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] Adding Encrypted Media Extensions
The content should be encrypted as defined by the container format and independent of the key system or the proposed extensions. For MP4, this is defined by ISO BMFF (Common Encryption). The WebM definition is being developed. Those individual specs should ensure that implementations of each container are interoperable without needing to specify container-specific information in the Encrypted Media Extensions draft. David On Wed, Apr 4, 2012 at 10:37 AM, Oliver Hunt oli...@apple.com wrote: Last I saw, there hadn't been any attempt to actually define how the content is encrypted. Has that changed? If it hasn't how do we get interoperable implementations? The only way for this spec to not break the openness of video and audio is for the encryption algorithm to be completely defined in the spec. --Oliver On Apr 4, 2012, at 9:55 AM, David Dorwin wrote: Hi WebKit! I plan to add the Encrypted Media Extensions to the media elements. The extensions allow web applications using audio and video to control key exchange. The extensions will be behind the ENCRYPTED_MEDIA feature define. The feature is tracked as https://bugs.webkit.org/show_bug.cgi?id=82968. Implementation will be based on the draft proposal at http://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html, which was published jointly by Google, Microsoft, and Netflix [1]. It appears a Media Task Force will be taking this on to produce a Working Draft [2]. Having an implementation will allow us to include implementation experience in the development of the draft. As described in the proposal, several new methods and events are added to HTMLMediaElement and a new keySystem parameter and attribute are added to canPlayType() and HTMLSourceElement, respectively. As with much of the media stack, most of the functionality will be implemented within the various ports. ENCRYPTED_MEDIA will be enabled for the Chromium port and covered by its buildbot. Regards, David [1] http://lists.w3.org/Archives/Public/public-html/2012Feb/0273.html [2] http://lists.w3.org/Archives/Public/public-html/2012Apr/0007.html ___ 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
