[IPython-dev] Javascript Ordering Semantics Issue in Notebook with Widget Registration

Andrew Gibiansky andrew.gibiansky at gmail.com
Sat May 17 13:29:21 EDT 2014


After digging around in the frontend JS source for a while, I found a
solution. Instead of sending a display_data with mimetype text/html and an
embedded script tag, just send two display_data messages, one with mimetype
application/javascript (with required JS) which must be executed before the
comm_open and another with mimetype text/html (with required HTML to be
inserted, if any).

This fixes the issue I have. However, it's still a bit strange that Chrome
and FF do the original thing differently, but looks like there's an easy
workaround.


On Sat, May 17, 2014 at 7:54 AM, MinRK <benjaminrk at gmail.com> wrote:

> I think there's some async things that Firefox does that other browsers do
> not. If I recall, Jon has faced this before, dealing with event sequences
> on Firefox, so he might have an idea.
>
> Jon, any idea what to do here?
>
>
> On Fri, May 16, 2014 at 11:37 PM, Andrew Gibiansky <
> andrew.gibiansky at gmail.com> wrote:
>
>> Hey guys,
>>
>> I'm running into a little bit of a Javascript code execution issue, and
>> am unsure whether I am doing something wrong in my architecture, or if
>> perhaps IPython should somehow mitigate the bugs I'm getting.
>>
>> Basically, here's the setup: for IHaskell, extension authors who want to
>> be able to display their data as widgets must create a way to register
>> those widgets. The first time those widgets are created, they must also be
>> registered in the JS on the notebook frontend. However, this is done in the
>> same series of messages as the comm_open. So here's the crux:
>>
>> The way that the widgets are registered is by adding a <script> tag to
>> the DOM. However, though the DOM is added, I *think* the comm_open
>> message is parsed *before* the <script> in the DOM is executed.  Note
>> that this *only* happens in firefox. In Chrome, the <script> tag is
>> added, the DOM is executed, and *then* the comm_open is processed. By
>> the time comm_open is processed in Chrome (not in firefox), the <script>
>> has been run so the widget is registered. In firefox, the comm_open is
>> processed before the script tag was run, so the widget is unregistered.
>>
>> So here's my question:
>>
>> Would it be possible to *force* all DOM added as a result of message
>> handling to be parsed and script tags in it to be executed before the next
>> message is handled? Perhaps this could be done by using $(blah).load(...)
>> on everything that is added to an output area? Or something?
>>
>> Anyway, I am confused, and not sure how to fix this, and whether or not
>> it's an issue with my code. The one requirement is that when the widget
>> object is evaluated is the first time that the relevant widget is
>> registered (if it is necessary); that is, that when the kernel sees the
>> widget, it first sends a display_data to which has some scripts to register
>> the widget, and then opens the comm via comm_open.
>>
>> -- Andrew Gibiansky
>>
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>
>>
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20140517/7e6eb065/attachment.html>


More information about the IPython-dev mailing list