Opened 11 years ago

Closed 11 years ago

#5432 closed defect (wontfix)

option for _loader to not clobber onload

Reported by: Dustin Machi Owned by: James Burke
Priority: high Milestone: 1.1
Component: Core Version: 1.0
Keywords: Cc: josh@…
Blocked By: Blocking:

Description

For some circumstances it would be useful to include dojo on a page where we we can't control whehter it uses an onload= handler or other thing that mess either it or dojo up as far as onload is concerned. I discussed with alex and he suggested that we could put an option in to use the safar model for all browsers (poll to see if the doc is ready) taht would avoid this issue. Note that this isnt' meant to replace the exisitng method, but rather only as away around it for specific use these specific use cases.

Change History (21)

comment:1 Changed 11 years ago by Dustin Machi

Cc: josh@… added

comment:2 Changed 11 years ago by guest

I have had this problem specifically with editarea: http://www.cdolivet.net/editarea/ The best I have is the following:

<script language="javascript" type="text/javascript" src="/editarea/edit_area/edit_area_compressor.php?plugins"></script>
<script language="javascript" type="text/javascript">
	editAreaLoader.init({
		id: "template_content",
		syntax: "html",
		max_undo: 50,
		allow_toggle: false,
		language: "en",
		toolbar: "search, go_to_line, fullscreen, |, undo, redo, |, select_font, |, change_smooth_selection, highlight, reset_highlight",
		start_highlight: true
	});
</script>

<style type="text/css">
	@import "/dojo1/dojo/resources/dojo.css";
	@import "/dojo1/dijit/themes/tundra/tundra.css";
	html, body, #mainDiv { 
		height: 100%; 
		width: 100%; 
		margin: 0; 
		padding: 0;
		border: 0;
	}
</style>

<script type="text/javascript" src="/dojo1/dojo/dojo.js"
	djConfig="parseOnLoad: true"></script>

This yeilds 404's on dojo's parser.js on about 50% of loads with Firefox.

Josh

comment:3 Changed 11 years ago by James Burke

Talked to dmachi a bit in IRC. What about the following:

If djConfig.noOnLoad = true, then do not register domcontentloaded/onload callbacks, and instead execute any dojo.addOnLoad() call immediately at the end of dojo.js.

Also have the ability to "bake in" the noOnLoad setting into a built dojo.js so the end user does not have to worry about setting up this feature if using your special build.

comment:4 Changed 11 years ago by guest

jburke:

Sounds good - if you need any testing, just let me know.

Josh (on the CC)

comment:5 Changed 11 years ago by James Burke

Owner: changed from anonymous to James Burke

comment:6 Changed 11 years ago by Dustin Machi

Hey james that was a better description that you gave from when we spoke and one point that i didnt' quite get. Does this mean that our addOnLoads() could potentially fire before document is loaded?

What you are describing sounds like it just pushes the stuff that would have been addOnLoaded()d to the end of dojo.js as opposed to taking the khtml/safari approach of not attaching to the eventhandlers and instead polling to see if the onload is done.

I think, but might need to think more that your suggestion will work in my case, though i'm not sure if it will cover all or even josh's since his needs to be able to do gui stuff.

comment:7 Changed 11 years ago by guest

James - here is a demo that has the 404 problem:

http://usnl.intrcomm.net/pb/editor/wizard/jburke.php

For me - currently about every other refresh yeilds a 404 - when it works you should have a tree on the left and the editarea stuff on the textarea in the right bottom.

Let me know if you have questions,

Josh

comment:8 Changed 11 years ago by guest

Forgot to mention - the 404 appears most often using firefox 2. It seems to work fine with IE6. I've had people who've tested this say they always get a 404 - I usually have one every other refresh, doubt it helps to know that, but you never know...

comment:9 Changed 11 years ago by bill

This looks the same as the delayMozLoadingFix flag from the old days ([6559]).

comment:10 Changed 11 years ago by James Burke

Hmm, seems like we are talking about 3 different things in here:

1) an onload clobbering that dmachi is talking about. 2) Josh seeing a 404 for parser.js on the test page above 3) Bill mentioning delayMozLoadingFix, I think as a reference to the kind of behavior I thought this ticket was shooting for: something that does not register an onload handler because dojo may be added to the page after page load (and therefore useless if we wait for onload to fire before doing our initialization).

1) dmachi: it seems like you are saying that by registering with onload, we clobber someone else. However, I thought we did this in a way that we use the "safe" addEventListener syntax or a separate polling/script tag that triggered our dojo._loadInit() callback. So we should not clobber anyone else. I thought there was an issue where someone might register window.onload or set body onload="" that might clobber us. Are you saying we need a solution for that case? I think this use case is different than what I thought this bug was about (allowing dojo to be added to the DOM after page load, but still have us initialize correctly. In that scenario, we do not need to detect for "page onload" because we are assuming it has already happened. I'm not sure I trust the polling approaches for detecting onload yet, at least the one used for IE. It seemed like a newer find, and I was waiting for more real-world experience before leveraging it. I'm also not sure what we would test for in Firefox. Were you seeing issues in a specific browser?

2) Josh, for your issue, I see sometimes when I reload the page, I get a 404 for this URL: http://usnl.intrcomm.net/pb/editor/wizard/undefined./parser.js That is *not* the correct path to the file (notice the undefined part). Looking into it more, it looks like dojo.baseUrl is undefined in that case, and that causes the problem. What is not clear is why yet dojo.baseUrl is undefined. I'll have to look at that some more. dojo.baseUrl should be set while dojo.js is being executed. It will get all script tags in the document, search for one that has a src with dojo.js in it, then extract the baseUrl from that src path. Any weird things you are doing with djConfig.baseUrl or dojo.baseUrl?

3) Bill, the idea behind what I thought this ticket was for (do not register onload handlers because the page is already loaded) is similar to the delayMozLoadingFix, but I was also needing a way to trigger "every loaded" path after dojo.js is loaded. So I was thinking of using the same djConfig trigger at the end of dojo.js to trigger the "everything loaded" path immediately.

comment:11 Changed 11 years ago by James Burke

Josh: if you move the script tag for /editarea/edit_area/edit_area_compressor.php?plugins after the dojo.js script tag, does that help things?

My current guess is that the edit area code is doing some document.write work that may clobber some things. No hard proof of anything yet though.

comment:12 Changed 11 years ago by Dustin Machi

1) dmachi: it seems like you are saying that by registering with onload....

  • I'm not sure that we are clobbering anything, but I think you are right that we get clobbered with the onload getting added. The point is that I won't be able to control whether that happens or not and am trying to find a way to make dojo startup after the page has loaded, but not be affect by other people's code. However, I am not trying to add functionality i just wanted a way to force the polling approach to avoid the situation. No I just expect that the code will be put on pages that it cannot be controlled as towhether there is onload in there. Alex had pointed me at the polling approach and suggested an option to force that to happen, that was my primary goal.

2)Josh, for your issue, I see somteimes when I relaod the page....

Yes this is exactly the issue. But I was unable to get it working. We went in an manually disabled the code that that software uses to figure its own "onload" type functinality and that made the dojo code work. We tried to replace their code with a dojo.addOnLoad() but that didnt' seem to work. I'm not sure exactly where the problem is in that, but I suggested this ticket because I think what it is i'm looking for would also happen to solve this particualr issue.

3) Bill, the idea behind....

I'm not sure what that one did, but it sounds like delayMozLoadingFix does what i'm looking for, just polls until ready.

Now just as a caveat to all this, I don't follow the addOnLoad() and when it happens type messages and whatnot all that closely. I don't really know what all is involved in making it all tick cross platform. The particular code i'm working on now will be fine just doing your original suggestion, but that is primarily because I don't do any dom work or manipulation. For an error like Josh's, I'm not sure that will be the case, but of course I could be wrong on that.

comment:13 in reply to:  11 Changed 11 years ago by guest

Replying to jburke:

2) Josh, for your issue, I see sometimes when I reload the page, I get a 404 for this URL: http://usnl.intrcomm.net/pb/editor/wizard/undefined./parser.js That is *not* the correct path to the file (notice the undefined part). Looking into it more, it looks like dojo.baseUrl is undefined in that case, and that causes the problem. What is not clear is why yet dojo.baseUrl is undefined. I'll have to look at that some more. dojo.baseUrl should be set while dojo.js is being executed. It will get all script tags in the document, search for one that has a src with dojo.js in it, then extract the baseUrl from that src path. Any weird things you are doing with djConfig.baseUrl or dojo.baseUrl?

James - yes - noticed that 404 path. Nothing strange with djConfig - I tried all sorts of incantations of baseUrl - no change. My dojo load should be in the html source - currently not setting baseUrl.

I tried to move the editarea js include after dojo - yeilds different results - does not get a 404 but the editor does not appear over the textarea (or in place of?):

http://usnl.intrcomm.net/pb/editor/wizard/jburke2.php

The textarea should look similar to those here:

http://www.cdolivet.net/editarea/editarea/exemples/exemple_full.html

Fow what it's worth, you can look at the edit area loader (and the suggestions dmachi made for me) here:

http://usnl.intrcomm.net/editarea/edit_area/edit_area_loader.js

Thanks for looking into this.

Josh

comment:14 in reply to:  11 Changed 11 years ago by guest

Replying to jburke:

Josh: if you move the script tag for /editarea/edit_area/edit_area_compressor.php?plugins after the dojo.js script tag, does that help things?

My current guess is that the edit area code is doing some document.write work that may clobber some things. No hard proof of anything yet though.

James, I've moved the two js includes and the dojo css around every possible way I can think of - the current one is the only incantation that seems to parse all the dojo widgets and has the full editarea widget working - but at the cost of working 1/2 the time in FF.

Also - on the edit_area_loader.js URL I sent in the previous reply, search for "dojo" to see what we tried.

Thanks,

Josh

comment:15 Changed 11 years ago by James Burke

Josh: there seems to be something weird with the timing of the document.writes that happen in the edit area JS request and some sort of race condition when Firefox has rendered the DOM. On the refresh case in FF, when the dojo code tries to get the script element that has dojo.js, it does not exist yet in the DOM, so the dojo.baseUrl configuration fails.

I'm thinking you could avoid the issue by setting djConfig.baseUrl explicitly to "/dojo1/dojo/". I would also define the djConfig object in a separate script block above the script tag for dojo.js. I think that should get it working.

I do not believe this issue to be related to registering onload callbacks, since this code is executing while dojo.js is being evaluated (before page has finished loading).

We still need to work out what we want for the "load dojo after page load" and "how to protect ourselves if other code does bad things to onload".

comment:16 in reply to:  15 Changed 11 years ago by guest

Replying to jburke:

I'm thinking you could avoid the issue by setting djConfig.baseUrl explicitly to "/dojo1/dojo/". I would also define the djConfig object in a separate script block above the script tag for dojo.js. I think that should get it working.

James - I modified the dojo load as suggested on this url:

http://usnl.intrcomm.net/pb/editor/wizard/jburke2.php

Can you check the source? I think I did as you asked but still errors - though slightly different ones it seems. And this time every load fails with a 404 on parser.js.

Thanks,

Josh

comment:17 Changed 11 years ago by James Burke

Josh, when defining djConfig in script, it should be an object. So try this:

djConfig = { parseOnLoad: true, baseUrl: "/dojo1/dojo/" };

comment:18 Changed 11 years ago by guest

Thanks James - I made the change here:

http://usnl.intrcomm.net/pb/editor/wizard/jburke2.php

Behavior seems the same - the 404's are gone, but the editor does not work either. :( Any other ideas?

Thanks!

Josh

comment:19 Changed 11 years ago by James Burke

Josh: go ahead and put the edit_area_compressor.php script tag and its following configuration script block before dojo.js and before the djConfig block to see if that works now.

comment:20 in reply to:  19 Changed 11 years ago by guest

Replying to jburke:

Josh: go ahead and put the edit_area_compressor.php script tag and its following configuration script block before dojo.js and before the djConfig block to see if that works now.

Excellent! Seems to have done it, at least I can't get any more 404's and the editor is functional.

Thanks for your help!

Josh

comment:21 Changed 11 years ago by James Burke

Resolution: wontfix
Status: newclosed

After thinking about this more, I think we should be fine now if someone clobbers window.onload: with Firefox 3, we now use DOMContentLoaded or an approximation of it on other browsers, so I do not think we should have an issue if someone else clobbers onload.

I did add support for loading Dojo after page load, #5887. While this does not directly speak to someone clobbering onload, at least Dojo can now be loaded after page load, if that is needed to avoid some sorts of conflicts.

Note: See TracTickets for help on using tickets.