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)
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)
Reporter | ||
Comment 1•17 years ago
|
||
Please help. This is killing us.
Comment 2•17 years ago
|
||
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?
Updated•17 years ago
|
Component: Software Update → General
OS: Windows 2000 → All
QA Contact: software.update → general
Hardware: PC → All
Updated•17 years ago
|
Version: unspecified → 2.0 Branch
Updated•17 years ago
|
Flags: blocking1.8.1.10?
Comment 3•17 years ago
|
||
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).
Comment 4•17 years ago
|
||
The regression range is between 2007091303-2007091403.
Updated•17 years ago
|
Keywords: regression
Comment 5•17 years ago
|
||
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?
Reporter | ||
Comment 6•17 years ago
|
||
2007-09-13 works... http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2007/09/2007-09-13-03-mozilla1.8/firefox-2.0.0.7pre.en-US.win32.installer.exe 2007-09-14 does not work... http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2007/09/2007-09-14-07-mozilla1.8/firefox-2.0.0.7pre.en-US.win32.installer.exe
Comment 7•17 years ago
|
||
> bz / dveditz: Is this supposed to be happening with the fix from bug 371360?
As designed, yes. One could argue the design is wrong....
Updated•17 years ago
|
Blocks: CVE-2007-1095
Reporter | ||
Comment 8•17 years ago
|
||
(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?
Comment 9•17 years ago
|
||
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.
Reporter | ||
Comment 10•17 years ago
|
||
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.
Comment 11•17 years ago
|
||
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.
Reporter | ||
Comment 12•17 years ago
|
||
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?
Comment 13•17 years ago
|
||
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...
Reporter | ||
Comment 14•17 years ago
|
||
onBeforeUnload produces the same failure.
Reporter | ||
Comment 15•17 years ago
|
||
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?
Comment 16•17 years ago
|
||
> 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?
Reporter | ||
Comment 17•17 years ago
|
||
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?
Reporter | ||
Comment 18•17 years ago
|
||
> 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.
Reporter | ||
Comment 19•17 years ago
|
||
You'll notice that there is a variable string that appears in the "GO" link..
Reporter | ||
Comment 20•17 years ago
|
||
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?
Comment 21•17 years ago
|
||
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.
Reporter | ||
Comment 22•17 years ago
|
||
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.
Comment 23•17 years ago
|
||
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.
Reporter | ||
Comment 24•17 years ago
|
||
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. ;)
Comment 25•17 years ago
|
||
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.
Comment 26•17 years ago
|
||
Bob, please take a look at bug 371360 comment 65. Would doing that fix your situation?
Reporter | ||
Comment 27•17 years ago
|
||
Yes, in theory that should work. We would need to see a build to test the theory.
Comment 28•17 years ago
|
||
(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> ---------------
Updated•17 years ago
|
Flags: blocking1.8.1.9?
Comment 30•16 years ago
|
||
should be fixed by 409888
Flags: wanted1.8.1.x+
Flags: blocking1.8.1.12?
Flags: blocking1.8.1.12+
Comment 31•16 years ago
|
||
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
Comment 32•16 years ago
|
||
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.
Description
•