Opened 11 years ago

Closed 11 years ago

#8944 closed defect (wontfix)

IE7 Form submit loading feedback broken

Reported by: Sanjay Madhavan Owned by:
Priority: high Milestone: tbd
Component: Dijit Version: 1.3.0b3
Keywords: Cc:
Blocked By: Blocking:

Description (last modified by bill)

I have a simple jsp page which uses standard HTML form submission. This page has a form that takes a couple of inputs and when submitted returns a file generated on the server to the browser.

This page was working perfectly till i added a couple of Dojo TitlePanes? and popup Dialogs to improve the visual aspects of the page.

The page still works fine under Firefox 3.0.7 but on IE7 it has broken the loading notification of the page.

This page on submission will cause a file to be returned from the server to the browser.

Clicking the submit button on IE7 sometimes works normally where the browser shows the loading indicator and then the browser opens the popup to open the file as expected. Till the file popup is displayed the browser shows the loading indicator as expected.

More often clicking the submit button causes a very quick loading indicator on IE7 and then it says Done on the status bar with no further feedback till the file pops up.

The problem is fairly random where clicking submit many times works sometimes and many times the form submission works without any browser feedback.

The dojo widgets used are:

<link href="../web/resources/dojo-release-1.3.0b3/dijit/themes/soria/soria.css" rel='stylesheet' type='text/css'/>
<link href="../web/resources/dojo-release-1.3.0b3/dojo/resources/dojo.css" rel='stylesheet' type='text/css'/>

<script src="../web/resources/dojo-release-1.3.0b3/dojo/dojo.js" type="text/javascript" encoding='UTF-8' djConfig="parseOnLoad: true"></script>
<script type="text/javascript" encoding='UTF-8'> dojo.require("dojo.parser");</script>
      <script type="text/javascript">
        dojo.require("dojo.parser");
        dojo.require("dijit.TitlePane");
        dojo.require("dijit.Dialog");
      </script>

If I remove the dojo code the page submission works correctly again as expected.

Does Dojo hook into the form submission even when I have not requested it explicitly on the page?

I am puzzled why form submission should be broken since this page is NOT using any async code and is just plain vanilla html forms with a few dojo widgets sprinkled on top.

Any ideas?

/sanjay

Attachments (2)

ie7.html (803 bytes) - added by bill 11 years ago.
make sibling of dijit/ and dojo/ directories
hover.html (408 bytes) - added by bill 11 years ago.
test case showing div:hover doesn't work on IE6 or IE7

Download all attachments as: .zip

Change History (16)

comment:1 Changed 11 years ago by bill

Component: GeneralDijit
Description: modified (diff)
Owner: anonymous deleted

Hmm, I don't have any ideas offhand (dojo isn't hooking into form submission AFAICT), and without a test case it seems impossible to track down.

So the form submit is actually loading a new page? And yet dojo from the previous page still has some effect somehow?

comment:2 Changed 11 years ago by Sanjay Madhavan

I updated Dojo to 1.3.0rc1 just to see if there were any changes. It did not make any difference.

To be very clear the form submit in this case does not load a new page since the response of the form submit returns a multi part file that causes the browser to popup the file open dialog. But in any case I have found that is not relevant to the problem.

I was able to find a 100% reproducible test case and I now feel it is related to some of the event handlers dojo registers for a mouse over event.

I was able to repeat my test and as long as I left my mouse pointer over the submit button the form worked as expected in IE7. If however as soon as I clicked the Submit button (but before the form post response was received from the server) I moved the mouse over a dojo TitlePane? the loading/progress indicator of IE7 was immediately lost and the IE7 browser acted like the post was complete though the response was still being processed on the server and would popup as expected when completed after a few seconds.

So the test case would be as follows:- a) Have a button on a page that would cause a form submission using a standard html submit button. Make the form action take at least a 5-10 seconds to execute to allow the problem to be demonstrated. b) Wrap the button with a Dojo TitlePane?

A minimal Test case is provided below.

<html>

<head>

<link href="../web/resources/dojo-release-1.3.0rc1/dijit/themes/soria/soria.css" rel='stylesheet' type='text/css'/> <link href="../web/resources/dojo-release-1.3.0rc1/dojo/resources/dojo.css" rel='stylesheet' type='text/css'/>

<script src="../web/resources/dojo-release-1.3.0rc1/dojo/dojo.js" type="text/javascript" encoding='UTF-8' djConfig="parseOnLoad: true"></script> <script type="text/javascript" encoding='UTF-8'> dojo.require("dojo.parser");</script>

<script type="text/javascript">

dojo.require("dojo.parser"); dojo.require("dijit.TitlePane?"); dojo.require("dijit.Dialog");

</script>

</head> <body class="soria">

<form method='post' action='mytestaction'>

<div id='downloadPane' dojoType="dijit.TitlePane?" title="Download Report" open='true'>

<input type="submit" Value="Run" title="Some long running task">

</div>

</form>

</body>

</html>

c) On IE7 Click the submit button and leave the mouse cursor over the form button. The loading indicator will show it is being loaded as expected till the form submit response is received. d) On IE7 Click the submit button and this time move the mouse cursor over the Dojo Title pane as soon as the submit is clicked. On IE7 the loading indicator immediately shows complete.

I hope the above sample would help you track the problem and come up with a solution before 1.3 goes live.

Thanks

/sanjay

comment:3 Changed 11 years ago by Sanjay Madhavan

An additional hint as to where the problem may lie is that if you remove the style class="soria" from the body tag the problem goes away though the TitlePane? looks too basic then.

comment:4 Changed 11 years ago by Sanjay Madhavan

I updated Dojo to 1.3.0rc2 and the test case above still shows the same problem.

comment:5 in reply to:  1 Changed 11 years ago by Sanjay Madhavan

Replying to bill:

Hmm, I don't have any ideas offhand (dojo isn't hooking into form submission AFAICT), and without a test case it seems impossible to track down.

So the form submit is actually loading a new page? And yet dojo from the previous page still has some effect somehow?

Just checking if you were able to reproduce the problem with the test case I provided in this ticket?

/sanjay

comment:6 Changed 11 years ago by bill

I tried the attached testcase (BTW please attach test cases using "attach file" button).

When moving the cursor over the title bar, the form still submits correctly, it's just that the rotating circle turns back into the E icon. Is that what the issue is?

Changed 11 years ago by bill

Attachment: ie7.html added

make sibling of dijit/ and dojo/ directories

comment:7 Changed 11 years ago by Sanjay Madhavan

When moving the cursor over the title bar, the form still submits correctly, it's just that the rotating circle turns back into the E icon. Is that what the issue is?

Yes.

The form does submit but the user feedback that the form has been submitted and that the browser is waiting for a response is lost. The form loading progress bar in the status bar (bottom of the browser) of IE7 also gets reset causing the user to think the browser has completed the action when in actual fact the browser is still waiting for the response from the server.

This usually causes the average user to think that he did not click the submit button properly and they usually attempt to resubmit the form.

This is a pretty major usability issue for our application. I do hope you can track down the problem and find a solution.

Thanks

/sanjay

comment:8 Changed 11 years ago by bill

I doubt we'll be able to find a solution to that. Why don't you make something like the loading screen for themeTester.html etc, except in reverse? You could use DialogUnderlay to gray out the screen to show that processing was going on.

comment:9 Changed 11 years ago by Sanjay Madhavan

problem is this page is a standard jsp page using standard form submit and on a successful submit it returns a file directly to the browser.

So refactoring the page to use an ajax submit with enable/disable of a dialog busy indicator would be tricky since control would normally go directly to the browser popup file dialog.

As a matter of interest have you any inkling what is going on here?

Why would just hovering over a TitlePane? cause the loading indicator to break.

I dont need any hover help on the TitlePane? would turning of any events on those panes help?

Any pointers to the code you think might be the cause would be useful and I would try to find a workaround myself.

Thanks /sanjay

comment:10 Changed 11 years ago by bill

I assume it is the hover implementation. Since CSS's :hover and :active only work on <a> and <button> on IE6 (and IE7 too IIRC), we implement the hover effect for the TitlePane title bar in javascript. See source:dijit/trunk/TitlePane.js#L178.

So I guess as a workaround you could do anything from simply disabling the hover effect altogether, or reimplementing it using CSS (and either switch the title bar markup from a <div> to an <a>, or give up on that effect for IE)... or you could do something more complmicated like disabling all event handlers on all widgets whenever the page is about to be submitted.

Changed 11 years ago by bill

Attachment: hover.html added

test case showing div:hover doesn't work on IE6 or IE7

comment:11 Changed 11 years ago by Sanjay Madhavan

I decided to disable the hover for TitlePane? on IE. The code I used was as follows:

    // workaround for dojo TitlePane hover bug on IE
    dojo.addOnLoad(function(){
     	if (dojo.isIE) {
    		var f=dojo.query("[class=dijitTitlePane]");
			for (var i=0;i<f.length;i++) {
				var div=dijit.byId(f[i].id);
				div._onTitleEnter=function() {};
  			  	div._onTitleLeave=function() {};
				}
		 	}
		});

comment:12 Changed 11 years ago by bill

And that solved the problem, right?

comment:13 Changed 11 years ago by Sanjay Madhavan

yes. That did solve the problem on IE7.

FF was never an issue so the workaround is only setup for IE

Thanks

/sanjay

comment:14 Changed 11 years ago by bill

Resolution: wontfix
Status: newclosed

OK, glad you were able to work around the problem.

I'm going to close this ticket for now as I don't know a better way to fix this (other than the workaround listed). I could theoretically make hooks on page-unload to disable all mouse handlers but it seems like too big a change at this point, unless/until we get more complaints on this issue.

Note: See TracTickets for help on using tickets.