Closed Bug 401611 Opened 17 years ago Closed 16 years ago

CGI Pages are failing in Firefox 2.0.0.8 (works fine in 2.0.0.7 and lower)

Categories

(Firefox :: General, defect)

2.0 Branch
defect
Not set
critical

Tracking

()

RESOLVED DUPLICATE of bug 409888

People

(Reporter: engineering, Unassigned)

References

()

Details

(Keywords: regression)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-GB; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.7
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-GB; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.7

<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 2.0.0.7 and 2.0.0.8 has caused our web pages to stop working.

<b><u>Example of the failure:</b></u>

--Goto http://www.cloverlick.com
--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

<b><u>Other facts:</b></u>

--the page/code works perfectly in <b><u>Firefox 2.0.0.7 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>15-Sep-2007 23:57</b></u>
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2.0.0.7-candidates/rc2/firefox-2.0.0.7.en-GB.win32.installer.exe

<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 2.0.0.9 and it fails as well.)

Please help.

Cloverlick

Reproducible: Always

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)
Actual Results:  
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 2.0.0.7 and lower.

Expected Results:  
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 2.0.0.7 now (downloaded from Mozilla's archive).  It works fine.  It's definitely something in 2.0.0.8+ (2.0.0.9 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:1.8.1.7) Gecko/2007091417 Firefox/2.0.0.7.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking1.8.1.9?
Component: Software Update → General
OS: Windows 2000 → All
QA Contact: software.update → general
Hardware: PC → All
Version: unspecified → 2.0 Branch
Flags: blocking1.8.1.10?
The 2.0.0.7-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
  http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2007/
in directories like
  http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2007/09/2007-09-01-04-mozilla1.8/

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 2.0.0.7pre in filenames, it's a result of 2.0.0.7 being 2.0.0.6 + the Quicktime media-link fix, and nightly version got of sync).
The regression range is between 2007091303-2007091403. 
Keywords: regression
This is due to bug 371360 and the site's use of onUnload:
onUnload="processDivs(document.forms.queue0form,{});document.forms.queue0form.submit();"

bz / dveditz: Is this supposed to be happening with the fix from bug 371360?
> 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
    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...

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...

http://core.quixsupport.com

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 2.0.0.7.

> 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 2.0.0.7.
> 
> > 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.
> 

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:1.8.1.9) Gecko/20071025 Firefox/2.0.0.9
Works in: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.6) 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.
Sample code:
-------------------
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<HTML LANG=en>
 <HEAD>
 <TITLE>Standard Course Features</TITLE>
<link rel="stylesheet" href="../contemporary.css" type="text/css">
</HEAD>
<BODY onUnload="send()"> 
<SCRIPT language="javascript"><!-- 
// To inform that we have completed this page.
function send()
{
   // 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);
   document.test.submit();
   return void(0);
}
// -->
</script>
<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">
</FORM>
<DIV onClick="send()">Click here to send the form</DIV>
</body>
</html>
---------------
Flags: blocking1.8.1.9?
Depends on: 409888
should be fixed by 409888
Flags: wanted1.8.1.x+
Flags: blocking1.8.1.12?
Flags: blocking1.8.1.12+
Looks like the fix for this is going into bug 409888
Status: NEW → RESOLVED
Closed: 16 years ago
Flags: wanted1.8.1.x+
Flags: blocking1.8.1.12+
Resolution: --- → DUPLICATE
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...
You need to log in before you can comment on or make changes to this bug.