User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-GB; rv:18.104.22.168) Gecko/20070914 Firefox/22.214.171.124
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-GB; rv:126.96.36.199) Gecko/20070914 Firefox/188.8.131.52
<b><u>This was originally posted under http://forums.mozillazine.org/viewtopic.php?t=595019 and http://forums.mozillazine.org/viewtopic.php?t=597653...</b></u>
Something between 184.108.40.206 and 220.127.116.11 has caused our web pages to stop working.
<b><u>Example of the failure:</b></u>
--Find the three black LOGIN buttons in the lower right hand corner
--Click the MIDDLE login button and open the user window
--Enter any username/password (we use "asdf" and "asdf")
--It SHOULD give you a login ERROR message (the CGI should refresh when it rolls back around to the page)
It doesn't matter what the username/password is... it SHOULD give you an error message stating that the combo is wrong... or in the usual case, allow you to log in.
Our team, along with the help from others in this forum, know what is <b><u>NOT</b></u> the problem:
--it is <b><u>NOT</b></u> the server
--it is <b><u>NOT</b></u> the code
--the page/code works perfectly in <b><u>Firefox 18.104.22.168 and lower</b></u>
--the page/code works perfectly in all versions of IE
On the advice of someone in this forum, we back-tracked the Firefox Nightly Build updates...
The last working build with our page above (using the exact example above) was:
<b><u>Whatever change was made immediately following the complete EXE build on September 15, 2007 is causing our page and software to fail in Firefox.</b></u>
(For those that are curious, we also tried 22.214.171.124 and it fails as well.)
Steps to Reproduce:
1. Goto http://www.cloverlick.com
2. Find the three black LOGIN buttons in the lower right hand corner
3. Click the MIDDLE login button and open the user window
4. Enter any username/password (we use "asdf" and "asdf")
5. It SHOULD give you a login ERROR message (the CGI should refresh when it rolls back around to the page)
Page goes no where. Not sure if it's a cache issue, an exten. issue, a JS issue... We simply don't know. It works in every other browser and in Firefox 126.96.36.199 and lower.
It SHOULD give you an error message stating that the combo is wrong... or in the usual case, allow you to log in. Regardless of what is entered for Username and Password... SOMETHING should happen... and error message... continued login... etc...
We're using 188.8.131.52 now (downloaded from Mozilla's archive). It works fine. It's definitely something in 184.108.40.206+ (220.127.116.11 fails too)
Please help. This is killing us.
confirming, I see the error the reporter describes using PPC mac using both 2008 and 2009.
I see the login failed message using Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:18.104.22.168) Gecko/2007091417 Firefox/22.214.171.124.
The 126.96.36.199-candidates/rc2/ build is the same as the release version, so that doesn't add any information. If you're willing to look at the true nightly builds that might help determine which change caused this. They can be found in
in directories like
The key thing to look for is -mozilla1.8 at the end of the directory. Maybe a binary search would be most efficient. If you find the last build that works, and the first that doesn't work, then please copy the useragents for both from Help > About Mozilla Firefox and post them here.
(Please ignore confusing versions like 188.8.131.52pre in filenames, it's a result of 184.108.40.206 being 220.127.116.11 + the Quicktime media-link fix, and nightly version got of sync).
The regression range is between 2007091303-2007091403.
This is due to bug 371360 and the site's use of onUnload:
bz / dveditz: Is this supposed to be happening with the fix from bug 371360?
2007-09-14 does not work...
> bz / dveditz: Is this supposed to be happening with the fix from bug 371360?
As designed, yes. One could argue the design is wrong....
(In reply to comment #7)
> > bz / dveditz: Is this supposed to be happening with the fix from bug 371360?
> As designed, yes. One could argue the design is wrong....
So? Now what?
Does the "submit in unload" pattern work in Opera or Safari? See also bug 371360 comment 53 through bug 371360 comment 63.
To be honest, I'm not sure why the page in question is using onunload instead of onsubmit. Is there a reason? As I said in comment 371360 the problem is that the code pattern being used is indistinguishable from an attack on the user.
The page in question is not the issue, as much as the usage of our code. This page does not use onUnload tag, per se. However, the dynamic CGI shell that houses this page does use the onUnload, so that the server can tell when a customer has closed a chat window, or an employee has closed their interface, subsequently "logging them out."
We appreciate the "security" elements you're trying to establish... but as in all cases like this, we should have the ability to manually set the browser accordingly, or manually relax the provision if necessary.
Simply "killing" the onUnload tag is unacceptable.
No one's killed it. The only thing that changed is that in a window's unload you're not allowed to start another load in that same window. You can do loads in other windows, for example, if you need to communicate to a server.
I'm not saying the situation is ideal. Just that I don't see a solution that protects the users from existing security exploits while still allowing the use case in question. If we find such a solution, I'll be very happy.
This is bad. This is very bad.
Our software is designed to be user simple. That means a very simple, single page progression that walks our customers and clients through the form. The "page" reloads dynamic data into the existing url.
We can't be the only ones doing this? And having the same problem?
What do we do?
I'm not sure how to reconcile comment 12 with comment 10's claim that unload is being used to track windows being closed.
That all said, one solution that springs to mind is using the onbeforeunload handler instead of onunload...
onBeforeUnload produces the same failure.
I think I understand better now. Pursuant Comment #11, you haven't "killed" the tag. You're simply not allowing page to advance to the new CGI page.
The onUnload is actually propagating data back to the server correctly...Firefox is not allowing the page to advance in sequence, as it always has before.
How? Why? And how do we fix this?
> onBeforeUnload produces the same failure.
Odd. Are you canceling the existing unload when you start the new load?
> Firefox is not allowing the page to advance in sequence
The change we made to unload behavior was to disallow starting a new load during unload. What that means is that in the code in comment 5 the submit() call can't start a new load.
Now there are two situations when unload fires:
1) The window is being closed. Starting a new load in that same window makes
2) The window is being navigated from page A to page B and page A is about to
be torn down.
You're in case 2, right? And you're trying to use the unload handler to load some page C instead of page B? The simple solution would be to be loading page C to start with...
Or am I completely misunderstanding the situation here?
Ok. Now I'm not sure of anything. We completely removed the onUnload scripting. And we're still getting the same failure.
(And we greatly appreciate your help btw... we're just very frustrated)
I've setup a Beta...
1. Click the THIRD button from the left (in the Visitors window)
2. Enter any USERNAME/PASSWORD combo. It SHOULD give you a message saying "Unauthorized User" on postback.
No onUnload protocol is present.
Could the "onUnload issue" not be the problem?
CGI Postback issue?
> Now there are two situations when unload fires:
> 1) The window is being closed. Starting a new load in that same window makes
> no sense.
> 2) The window is being navigated from page A to page B and page A is about to
> be torn down.
> You're in case 2, right? And you're trying to use the unload handler to load
> some page C instead of page B? The simple solution would be to be loading page
> C to start with...
Sorry..we crossed with that last post..
Yes... #2 kind of... it's not that simple ... (and this gets down to the meat of the issue....)
Our server doesn't return "B" or "C"... it determines, based on the input whether or not it should return "C, D, E, F... through ZZZ" All of which is variable, based on field inputs.
This form is obviously pretty simple... however, many of the internal forms are not. However it's all the same shell and engine.
You'll notice that there is a variable string that appears in the "GO" link..
So... for argument's sake...
Our link says "Page B"...
But our form postback says "Page C"...
The link actuates the form processing, which is carried out onUnload.
And as of September 14, Firefox won't allow the form to postback anything other than the link to "Page B."
Am I understanding this correctly?
OK. So in that testcase without unload, I don't see an "Unauthorized User" message... even when using a build without the patch for bug 371360. For example, I don't see that message with Firefox 18.104.22.168.
> But our form postback says "Page C"...
Meaning what? This is the action of the form?
> The link actuates the form processing, which is carried out onUnload.
Why not just have the image submit the form to start with? In any case..
> And as of September 14, Firefox won't allow the form to postback anything
> other than the link to "Page B."
As of 9/14 Firefox won't allow code running in onunload to perform any navigation. So it's not that it won't allow the form to submit to "Page B". It won't allow the form to submit at all, if the submit() call is in the unload handler.
Which means anyone using CGI, forms, streaming DIVs, dynamic DIVs, iFrames or standard frames in combination with "onUnload" to direct (navigate) content in those "windows" now has broken software until they rewrite all of their code to be link specific.
Which in our case, will take hundreds of man-hours to modify, in an effort to cater to the 12.6% of our users that utilize Firefox, vs the 81.2% that use IE.
I'm not sure what you mean by "link specific". And I'm still not quite sure I understand the use cases for doing a load from an onunload handler. That seems like a very odd (very late) place to start the load... If you want to do some action in response to a click on a link, why not just make it an onclick handler?
I must be missing something; it'd be good to figure out what that something is.
And again, the current state of things is imperfect. I'd love to enable real-life use cases without opening up security/privacy holes. The question is how to do that. IE's approach seems to be to not worry about the security holes.
With our software... the link contains variables in the STRING... and the FORM contains variables input from the user.
The combination of the STRING variables and the FORM input guide the system..
...specifically the post-back..
The link is dynamically generated by the server (obviously)... and the form fields collect the data from the user.
Clicking the link sends the STRING variables to the server...
Exiting the page (onUnload) sends the FORM variables to the server...
onClick has never been effective at sending both. (At least the ways we've tried it)
If someone can tell use how to combine the two... we're all ears. ;)
One option is to put the "string" variables in the form's action URI, assuming you are doing a POST. This is a quite commonly used technique.
That's assuming you need to keep the separate from the form data. If you don't, you can just use hidden inputs to send along the non-user-generated data.
Bob, please take a look at bug 371360 comment 65. Would doing that fix your situation?
Yes, in theory that should work. We would need to see a build to test the theory.
(In reply to comment #21)
> OK. So in that testcase without unload, I don't see an "Unauthorized User"
> message... even when using a build without the patch for bug 371360. For
> example, I don't see that message with Firefox 22.214.171.124.
> > But our form postback says "Page C"...
> Meaning what? This is the action of the form?
> > The link actuates the form processing, which is carried out onUnload.
> Why not just have the image submit the form to start with? In any case..
> > And as of September 14, Firefox won't allow the form to postback anything
> > other than the link to "Page B."
> As of 9/14 Firefox won't allow code running in onunload to perform any
> navigation. So it's not that it won't allow the form to submit to "Page B".
> It won't allow the form to submit at all, if the submit() call is in the unload
I'm seeing that without any navigation occurring, the document.form.submit is simply failing if it is in an unLoad. I use this to report how long someone has been on a page. The result is piped to a different frame.
Fails in: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:126.96.36.199) Gecko/20071025 Firefox/188.8.131.52
Works in: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:184.108.40.206) Gecko/20070802 SeaMonkey/1.1.4
but only if the target window has already been opened. If the target window has not yet been opened, the document.form.submit fails.
In IE, and in older versions of FF/Mozilla, this worked even if the target window had not yet been opened.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<TITLE>Standard Course Features</TITLE>
<link rel="stylesheet" href="../contemporary.css" type="text/css">
// To inform that we have completed this page.
// Now we assemble the AICC strings for putPath
var newdata="some data about how long";
newdata += "more data";
document.test.aicc_data.value = newdata;
document.test.session_id.value = "jackid";
document.test.command.value = "PutPath";
alert('before submit '+document.test.action);
<FORM NAME="test" ACTION="http://localhost/scripts/aiccproc.exe" method="POST" TARGET="returns" ENCTYPE="application/x-www-form-urlencoded">
<INPUT TYPE="HIDDEN" NAME="command" VALUE="PutPath">
<INPUT TYPE="HIDDEN" NAME="version" VALUE="2.0">
<INPUT TYPE="HIDDEN" NAME="session_id">
<INPUT TYPE="HIDDEN" NAME="aicc_data">
<DIV onClick="send()">Click here to send the form</DIV>
*** Bug 404728 has been marked as a duplicate of this bug. ***
should be fixed by 409888
Looks like the fix for this is going into bug 409888
*** This bug has been marked as a duplicate of bug 409888 ***
Bob, could you possibly confirm whether tomorrow's trunk nightly fixes the problem you were seeing? We'd like to make sure that the patch for bug 409888 does what it needs to before pushing it to the branch...