Opened 13 years ago

Closed 12 years ago

#1353 closed enhancement (wontfix)

[patch][cla] dojo.addOnLoad, Opera, script tags and AJAX

Reported by: attila.lendvai@… Owned by: James Burke
Priority: high Milestone: 0.9
Component: IO Version: 0.2
Keywords: opera addOnLoad ajax script Cc: attila.lendvai@…
Blocked By: Blocking:

Description

so, the situation is this:

opera decided to look for script tags and execute them when a node is added to the document.

when a dom fragment is received with ajax, with other browsers the user code must collect and execute script tags after called dojo.widget.createWidget(root-node). this is all fine, i walk the result after the dom fragments have been added to the doc.

now, with opera the script tags are executed when they get attached to the doc, so the ajax received widgets are not yet instantiated at that time. when some fragment is loaded with a full page load, adding stuff to dojo.addOnLoad() works as expected. but when the same fragment is ajax-received on opera, then dojo.addOnLoad()'s are executed too early, before the widgets are created.

my proposal is to add support to dojo.addOnLoad() that delays execution while a dojo.io.bind load handler is running.

hope this helps,

  • attila

Attachments (3)

opera-fix-for-onload.patch (1.9 KB) - added by attila.lendvai@… 13 years ago.
the fix
opera-fix-for-onload.2.patch (2.1 KB) - added by attila.lendvai@… 13 years ago.
the fix again with a small fix
call-onload-only-after-xmlhttp-requests-are-done.diff (1.8 KB) - added by attila.lendvai@… 13 years ago.
the patch against svn head at the time of writing

Download all attachments as: .zip

Change History (15)

comment:1 Changed 13 years ago by dylan

Component: CoreIO
Milestone: 0.5
Owner: changed from anonymous to alex

comment:2 Changed 13 years ago by James Burke

Cc: attila.lendvai@… added

It would be good to get more information, like what type of dojo.io.bind() request? Is it using XMLHttpTransport or ScriptSrcTransport?? Is this happening with which version of Opera? Any issue with Opera 8.x is unlikely to get fixed, since Opera 9 is now available.

But what is really needed is a test case. Attila, can you provide one? That would clear up all of the questions, and enable a fix.

comment:3 Changed 13 years ago by attila.lendvai@…

UPDATE: you may skip the rest of this message, i'll attach a patch that fixes it as described in the first comment. seems like fixing it was easier then providing a test-case.

hth,

  • attila

it's Opera/9.00 (X11; Linux i686; U; en)

i'm using XMLHttpTransport to transfer an xml to the client. there's a 'dom-replacements' node in that xml which has xmlns="http://www.w3.org/1999/xhtml" on it and it contains parts of the client dom tree that should be replaced. this fragment usually contains script tags that i need to explicitly eval on ff and ie _after_ i've instantiated the widgets. unfortunately opera eval's those script tags when they are attached to the document.

a testcase is a bit difficult because of the server side stuff, but i'll look at the dojo test cases and try to put together one that properly instantiates widgets on all other browsers than opera.

unfortunately my client side js is not trivial and it's compiled from lisp... cutting out stuff is not simple. but if we can meet on #dojo i can give you a link where you can test it in the real environment.

somtimes it's at http://ed101.dyndns.org:8080/ the 'A dojo TabContainer?' example. but it's my dev machine, not 24/7...

the symptom is that tab content is not loaded in opera, while it works in ie and ff (it's loaded with a js handler that gets the content with ajax). the setHandler call that sets up the tab content loading is in a dojo.addOnLoad(), and opera calls the script tag too early. if i can't find the wirget i log an error message. this error log only appears in opera.

Changed 13 years ago by attila.lendvai@…

Attachment: opera-fix-for-onload.patch added

the fix

Changed 13 years ago by attila.lendvai@…

the fix again with a small fix

comment:4 Changed 13 years ago by James Burke

Attila, thanks for the extra information. In order for us to consider a patch, you need to submit a CLA to the Dojo Foundation:

http://manual.dojotoolkit.org/WikiHome/DojoDotBook/Book53

Also, in order for us to verify the issue and fix, we'll need a test case. Perhaps if you can compare your situation against the widget tests here:

http://archive.dojotoolkit.org/nightly/tests/widget and perhaps this test if you are using TabContainer?: http://archive.dojotoolkit.org/nightly/tests/widget/test_TabContainer_lazyLoad.html

Are you including script tags with a src attribute, or script tags that have a script body (inlined script)? At first glance, I'm surprised this fix is needed, but I'm not sure how aggressively widgets have been tested in Opera.

I won't be on IRC today, but I might try to arrange something this week. Thanks for taking the time to hunt down the issue. I'll also ask another Dojo contributor, Fredrik Johansson, if this rings a bell for him. He noticed an issue with Konqueror involving widget instantiation and bind() calls before.

comment:5 Changed 13 years ago by mumme

I may be compleatly wrong, but I think that using a ContentPane? to grab ajax content and push your function to your *holder* contentPane.addOnLoad would do the trick here.

Or perhaps you could listen to widget.Parse or something to provide your own addOnWidgetCreated function.

It just seems to be a bit awkward to work around it in the way the patch suggests.

Then again I may be wrong, in that case please ignore me...

/ Fredrik

comment:6 Changed 13 years ago by attila.lendvai@…

I may be compleatly wrong, but I think that using a ContentPane?? to grab ajax content and push your function to your *holder* contentPane.addOnLoad would do the trick here.

the problem with this is that the script i need to delay is the very same that registers the handler that will download the content... and the parent tab-container is also loaded in an ajax request. (or could be i simply misunderstand what you mean)

Or perhaps you could listen to widget.Parse or something to provide your own addOnWidgetCreated function.

this sounds a lot more promising, and in fact for a moment i tough that it may work. but the problem is the same here: at the time the script tag is added to the document (and executed by opera), the widget itself does not exists yet, only the dom fragment that describes the widget. i can only call dojo.widget.create-widget when its dom fragment has been added to the document. or am i wrong here??? unfortunately i can't easily test it, but if it's legal to call it on detached dom nodes then that may also be a solution. i could simply have the widgets parsed first, and then add the dom chunk.

It just seems to be a bit awkward to work around it in the way the patch suggests. Then again I may be wrong, in that case please ignore me...

it was my first idea because the content is already rendered using add-on-load when the page is fully reloaded, and it works with all other browsers... and in fact it is not awkward but right the opposite for me... :) (delay calling scripts until the thing is loaded, where thing is not the entire page in this situation but an ajax request...)

  • attila

comment:7 Changed 13 years ago by Tom Trenka

In theory, if you have true DOM nodes that have been created you can operate on them--as long as you aren't relying on parent nodes to do part of your work. If you're using widgets that have auto-layout code in them, you'll probably break, but if not, it's a promising approach.

comment:8 Changed 13 years ago by attila.lendvai@…

well, this is actually part of a generic web framework (http://common-lisp.net/project/ucw/), so this should work with all kind of widgets without random limitations...

i hope this patch or something equivalent is accepted so we can claim full opera compatibility without funny surprises. other alternatives are to keep a patched version of dojo in ucw (hm, need to check the license deeper) or add an ucw.add-on-load with the proposed behaviour to the ucw js stack. the latter is not such a good idea, because i can not use try/finally there to clear the magic boolean flag...

keeping a copy of dojo in the ucw repo is also a good idea for making the life of the users easier e.g. while patches are transfered. i hope it's not against the license.

comment:9 Changed 13 years ago by attila.lendvai@…

fyi, i've got my cla filed.

i don't know what is the final verdict on this if there's any. i hope it'll be included eventually. i think it's a safe change that does not interfere with anything else.

it has no sideeffects at page load time, as it was mentioned in one of the answers, because it's the nth predicate which is, when called while the page has not been loaded yet, is not even reached.

  • attila

comment:10 Changed 13 years ago by dylan

Owner: changed from alex to James Burke
Summary: dojo.addOnLoad, Opera, script tags and AJAX[patch][cla] dojo.addOnLoad, Opera, script tags and AJAX

Changed 13 years ago by attila.lendvai@…

the patch against svn head at the time of writing

comment:13 Changed 12 years ago by guest

fyi, i'm succesfully using this change ever since then. ucw is ff, opera and ie compatible... :)

comment:14 Changed 12 years ago by James Burke

Resolution: wontfix
Status: newclosed

This sounds like whatever you want to load via dojo.io.bind really should be loaded as a module that you load via dojo.require(), using perhaps some nested dojo.addOnLoad() and doing selective parsing of the page for widgets. In any case, I'm uncomfortable doing this change to the core loader when the test case seems to involve widgets.

I'm sorry it took so long to get to this bug, and thank you for taking the time to do patches. However, I'm going to close this as wontfix. If you feel there is a valid use case for this, feel free to reopen and attach a test case I can run against the Dojo 0.9 code.

Note: See TracTickets for help on using tickets.