Javascript and WebCore

[Alexander Cohen-3]

Hello,

I've been looking into having WebCore support another scripting  
language other than Javascript. By going through the code, it seems  
pretty doable. Then i got to  inline scripts on event handlers and  
that's where it became a bit more complicated. It seems like  
JSEventListeners are mixed into normal HTML parsing which makes it  
really hard to actually add anything without either refactoring that  
complete section or just hacking it right into it ( checking for the  
type of script and dispatching to the right class ).

I most probably missed something somewhere, i'm pretty new to WebKit/
WebCore. Is there anything i should look at in order to make this a  
bit simpler.

thx

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

[Darin Adler]

On Oct 23, 2009, at 6:27 AM, Alexander Cohen wrote:

> I've been looking into having WebCore support another scripting  
> language other than Javascript. By going through the code, it seems  
> pretty doable. Then i got to  inline scripts on event handlers and  
> that's where it became a bit more complicated. It seems like  
> JSEventListeners are mixed into normal HTML parsing which makes it  
> really hard to actually add anything without either refactoring that  
> complete section or just hacking it right into it ( checking for the  
> type of script and dispatching to the right class ).

Because of the many hooks added by Google engineers to replace  
WebKit’s own JavaScript engine with their V8 project in Google builds,  
there are already hooks to substitute a different engine every single  
place WebKit interacts with the JavaScript engine, so that should not  
be a problem.

Your question seems to be less about implementation, and more about  
the design. You mention checking the type of script, but how would you  
do that? The syntax is onload="<script>" and the script language is  
JavaScript. In other places in the syntax, such as in script elements,  
the script language is explicit, but in these older legacy places it’s  
not.

Once you decide what you’re trying to do, perhaps I can help you with  
the “how” question. But generally this seems to be a challenging  
project, and I probably won’t be able to help much.

     -- Darin

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

[Alexander Cohen-3]

On Oct 25, 2009, at 2:48 PM, Darin Adler wrote:

> On Oct 23, 2009, at 6:27 AM, Alexander Cohen wrote:
>
>> I've been looking into having WebCore support another scripting  
>> language other than Javascript. By going through the code, it seems  
>> pretty doable. Then i got to  inline scripts on event handlers and  
>> that's where it became a bit more complicated. It seems like  
>> JSEventListeners are mixed into normal HTML parsing which makes it  
>> really hard to actually add anything without either refactoring  
>> that complete section or just hacking it right into it ( checking  
>> for the type of script and dispatching to the right class ).
>
> Because of the many hooks added by Google engineers to replace  
> WebKit’s own JavaScript engine with their V8 project in Google  
> builds, there are already hooks to substitute a different engine  
> every single place WebKit interacts with the JavaScript engine, so  
> that should not be a problem.
>
> Your question seems to be less about implementation, and more about  
> the design. You mention checking the type of script, but how would  
> you do that? The syntax is onload="<script>" and the script language  
> is JavaScript. In other places in the syntax, such as in script  
> elements, the script language is explicit, but in these older legacy  
> places it’s not.
>
> Once you decide what you’re trying to do, perhaps I can help you  
> with the “how” question. But generally this seems to be a  
> challenging project, and I probably won’t be able to help much.

The hooks added by Google seems more to replace and not to add a  
scripting language. My goal is to add a scripting language. Up to now,  
i've been able to implement it pretty nicely in the <script> tag by  
using either the language or the type attribute. I've got a good part  
of the bindings working and can easily interact with the DOM just like  
i would in javascript.

In the events of a tag, i needed to add checks to see what type of  
script was being called. A lot if not all of the time, we will usually  
find a "javascript:" in the event code so i can also look there for my  
defined scripting language and call into the right code. My problem  
lies there mostly. At that point, it seems to be "understood" that it  
is javascript that will be run. At that point in the code, a function  
is called that returns a subclass of an EventListener  
( JSLazyEventListener ). That's also something i need to change in  
order for those functions to return just an EventListener so i can  
hook into my own subclass of EventListener. That is where i am right  
now, subclassing the EventListener.

The project is challenging but that's the whole point. I think i  
understand how i need to do it. I just wanted to ping the list and see  
if anyone had any tips or maybe even some sort of document describing  
the flow of function calls.

thx

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

[Maciej Stachowiak]

On Oct 25, 2009, at 2:01 PM, Alexander Cohen wrote:

In the events of a tag, i needed to add checks to see what type of script was being called. A lot if not all of the time, we will usually find a "javascript:" in the event code so i can also look there for my defined scripting language and call into the right code.

Attribute event listeners do not usually have "javascript:" in them. Here is an example from Google's home page:

<a href="http://images.google.com/imghp?hl=en&tab=wi" onclick=gbar.qs(this) class=gb1>Images</a>

Notice that the onclick value doesn't start with javascript:. You are probably thinking of javascript: URLs in links, like this:

<a href="javascript:callSomething()">

You could invent a new URL scheme that runs your scripting language instead of JavaScript, but I don't think there is anything you can do about onclick handlers, unless you're willing to break compatibility with existing Web content.

Regards,

Maciej

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

[Alexander Cohen-3]

On Oct 25, 2009, at 5:23 PM, Maciej Stachowiak wrote:

On Oct 25, 2009, at 2:01 PM, Alexander Cohen wrote:

In the events of a tag, i needed to add checks to see what type of script was being called. A lot if not all of the time, we will usually find a "javascript:" in the event code so i can also look there for my defined scripting language and call into the right code.

Attribute event listeners do not usually have "javascript:" in them. Here is an example from Google's home page:

<a href="http://images.google.com/imghp?hl=en&tab=wi" onclick=gbar.qs(this) class=gb1>Images</a>

Notice that the onclick value doesn't start with javascript:. You are probably thinking of javascript: URLs in links, like this:

<a href="javascript:callSomething()">

You could invent a new URL scheme that runs your scripting language instead of JavaScript, but I don't think there is anything you can do about onclick handlers, unless you're willing to break compatibility with existing Web content.

You're right. But this does give an opportunity for my scripting language to get through since executing mine as javascript will probably result in an error. I can definitely catch that and check for another language.

Just by curiosity, would it be bad to do something like this (notice the "newscriptinglang:" in the onload ):

<a href="http://images.google.com/imghp?hl=en&tab=wi" onclick=newscriptinglang:gbar.qs(this) class=gb1>Images</a

thx

AC

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

[Maciej Stachowiak]

On Oct 25, 2009, at 2:36 PM, Alexander Cohen wrote:

On Oct 25, 2009, at 5:23 PM, Maciej Stachowiak wrote:

On Oct 25, 2009, at 2:01 PM, Alexander Cohen wrote:

In the events of a tag, i needed to add checks to see what type of script was being called. A lot if not all of the time, we will usually find a "javascript:" in the event code so i can also look there for my defined scripting language and call into the right code.

Attribute event listeners do not usually have "javascript:" in them. Here is an example from Google's home page:

<a href="http://images.google.com/imghp?hl=en&tab=wi" onclick=gbar.qs(this) class=gb1>Images</a>

Notice that the onclick value doesn't start with javascript:. You are probably thinking of javascript: URLs in links, like this:

<a href="javascript:callSomething()">

You could invent a new URL scheme that runs your scripting language instead of JavaScript, but I don't think there is anything you can do about onclick handlers, unless you're willing to break compatibility with existing Web content.

You're right. But this does give an opportunity for my scripting language to get through since executing mine as javascript will probably result in an error. I can definitely catch that and check for another language.

I think that would be fragile, especially if polyglot or near-polyglot programs are possible. Unfortunately, inline event listeners were never designed with the idea of multiple scripting languages in mind. Fortunately, you can add event listeners just fine using code in a <script> element, so you don't lose much by not supporting them for a new scripting language.

Just by curiosity, would it be bad to do something like this (notice the "newscriptinglang:" in the onload ):

<a href="http://images.google.com/imghp?hl=en&tab=wi" onclick=newscriptinglang:gbar.qs(this) class=gb1>Images</a

That onclick handler is a valid JavaScript program, "newscriptlanglang:" is interpreted as a goto label. Whether there is Web content out there accidentally doing that, I don't know.

If you really want to come up with something, then I think your best bet would be to declare the scripting language for event listeners using an explicit mechanism. One possible way is to define a meta keyword so you could say <meta name="event-listener-language" content="application/x-fooscript">. That has the downside of being global for the whole document, so you would not be able to mix inline event listeners in both languages. It has the benefit that you won't misinterpret any existing Web content, but the downside that Web pages using the new scripting language may fail in mysterious ways (instead of just not running their scripts).

Regards,

Maceij

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

[Alexander Cohen-3]

On Oct 25, 2009, at 7:09 PM, Maciej Stachowiak wrote:

On Oct 25, 2009, at 2:36 PM, Alexander Cohen wrote:

On Oct 25, 2009, at 5:23 PM, Maciej Stachowiak wrote:

On Oct 25, 2009, at 2:01 PM, Alexander Cohen wrote:

In the events of a tag, i needed to add checks to see what type of script was being called. A lot if not all of the time, we will usually find a "javascript:" in the event code so i can also look there for my defined scripting language and call into the right code.

Attribute event listeners do not usually have "javascript:" in them. Here is an example from Google's home page:

<a href="http://images.google.com/imghp?hl=en&tab=wi" onclick=gbar.qs(this) class=gb1>Images</a>

Notice that the onclick value doesn't start with javascript:. You are probably thinking of javascript: URLs in links, like this:

<a href="javascript:callSomething()">

You could invent a new URL scheme that runs your scripting language instead of JavaScript, but I don't think there is anything you can do about onclick handlers, unless you're willing to break compatibility with existing Web content.

You're right. But this does give an opportunity for my scripting language to get through since executing mine as javascript will probably result in an error. I can definitely catch that and check for another language.

I think that would be fragile, especially if polyglot or near-polyglot programs are possible. Unfortunately, inline event listeners were never designed with the idea of multiple scripting languages in mind. Fortunately, you can add event listeners just fine using code in a <script> element, so you don't lose much by not supporting them for a new scripting language.

Agreed that it could be fragile. Fortunately, at least for the time being, i'm just working on a proof of concept and it does make the transition easier from javascript to another scripting language. I'm also learning a lot about WebCore this way which is really nice but not relevant to our current discussion. :)

Just by curiosity, would it be bad to do something like this (notice the "newscriptinglang:" in the onload ):

<a href="http://images.google.com/imghp?hl=en&tab=wi" onclick=newscriptinglang:gbar.qs(this) class=gb1>Images</a

That onclick handler is a valid JavaScript program, "newscriptlanglang:" is interpreted as a goto label. Whether there is Web content out there accidentally doing that, I don't know.

So i would actually need to look at the event handler code scheme before it gets directly passed on to javascript. I could check for my scripting language scheme and handle it if needed. I do how see this could be a problem if a developer had a goto statement that was the same as the name of my scripting language, but the possibility of that is very low, for now.

thx

AC

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

[Maciej Stachowiak]

On Oct 25, 2009, at 4:30 PM, Alexander Cohen wrote:

Just by curiosity, would it be bad to do something like this (notice the "newscriptinglang:" in the onload ):

<a href="http://images.google.com/imghp?hl=en&tab=wi" onclick=newscriptinglang:gbar.qs(this) class=gb1>Images</a

That onclick handler is a valid JavaScript program, "newscriptlanglang:" is interpreted as a goto label. Whether there is Web content out there accidentally doing that, I don't know.

So i would actually need to look at the event handler code scheme before it gets directly passed on to javascript. I could check for my scripting language scheme and handle it if needed. I do how see this could be a problem if a developer had a goto statement that was the same as the name of my scripting language, but the possibility of that is very low, for now.

Using a meta keyword to declare the event handler scripting language globally would not have this problem, or at least it would be much less likely. It would also make event listeners using your scripting language look nicer. So I continue to recommend that approach. Up to you though.

Regards,

Maciej

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

[Alexander Cohen-3]

On Oct 25, 2009, at 8:52 PM, Maciej Stachowiak wrote:

On Oct 25, 2009, at 4:30 PM, Alexander Cohen wrote:

Just by curiosity, would it be bad to do something like this (notice the "newscriptinglang:" in the onload ):

<a href="http://images.google.com/imghp?hl=en&tab=wi" onclick=newscriptinglang:gbar.qs(this) class=gb1>Images</a

That onclick handler is a valid JavaScript program, "newscriptlanglang:" is interpreted as a goto label. Whether there is Web content out there accidentally doing that, I don't know.

So i would actually need to look at the event handler code scheme before it gets directly passed on to javascript. I could check for my scripting language scheme and handle it if needed. I do how see this could be a problem if a developer had a goto statement that was the same as the name of my scripting language, but the possibility of that is very low, for now.

Using a meta keyword to declare the event handler scripting language globally would not have this problem, or at least it would be much less likely. It would also make event listeners using your scripting language look nicer. So I continue to recommend that approach. Up to you though.

I will definitely look into using the meta keyword, it seems like a great option.

thx again for your input, much appreciated.

AC

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

[Brent Fulgham-2]

On Oct 25, 2009, at 4:09 PM, Maciej Stachowiak wrote:

> If you really want to come up with something, then I think your best  
> bet would be to declare the scripting language for event listeners  
> using an explicit mechanism. One possible way is to define a meta  
> keyword so you could say <meta name="event-listener-language"  
> content="application/x-fooscript">. That has the downside of being  
> global for the whole document, so you would not be able to mix  
> inline event listeners in both languages. It has the benefit that  
> you won't misinterpret any existing Web content, but the downside  
> that Web pages using the new scripting language may fail in  
> mysterious ways (instead of just not running their scripts).

I think this is the approach taken by the Titanium project (http://www.appcelerator.com/appcelerator-platform/titanium-architecture/ 
), which allows development using Python, PHP, Ruby, etc.  See for  
example the snippets on their 'codestrong' development site (http://www.codestrong.com/titanium/tutorials/hello-world/?rev=21 
), with constructs like:

<script type="text/javascript"> ... javascript stuff ... </script>
<script type="text/python"> ... python stuff ... </script>

It looks like these can be used to define event listeners as well as  
preparing display content.

There are some core Titanium developers who hang out on IRC and the  
mailing lists who could probably provide better details.

They apparently have some patches to WebKit they will be submitting  
formally at some point (though they are all available in their git  
repository) that provide the language-agnostic support.

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