110310 - CGI script believes some posted form data is invalid[form sub]

Status: VERIFIED INVALID

(Core :: DOM: Core & HTML, defect)

Description

[Frank Burleigh]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.5+)
Gecko/20011115
BuildID:    2001111503

This is a customized commercial library automation system that lets library
patrons explore the library collections.  A graphical button lets the user
"drill in" on a holding.  Apparently the backend CGI script does usually like
the posted data it receives when this button is clicked.

Reproducible: Always
Steps to Reproduce:
1. visit the url (bypasses search pages that don't seem needed)
2. click "browse" among the graphics buttons near the top (also includes
Keyword, Advanced, Exact...)
3. type "cq weekly" in the Enter terms box.
4. select "ALL" from the Select Libraries dropdown list
5. click the Periodical Title graphical button.  Should get back a page of
linked results
6. find and click CQ Weekly Reports, should get back a page of 3 results.
7. click on any of the "Display" graphics 
8. Should get a result page claiming an invalid CGI request type

(also for a fun time, turn on the checkbox before clicking the display button. 
That seems to send the browser or backend system or both into an endless loop. ;-)

Also tested Netscape 6.2, which I'd given to one of our Law librarians as a test
to help determine whether NS can be deployed yet.

The librarians tell me that not *every* item fails, but it seems all on this
page do.  I've examined the page source and see that it isn't good stuff.  I've
asked one of the librarians to report those problems to the team that maintains
this system.  Still, our problem is that NS4.x "works" as does IE, so from their
point of view Netscape 6.2 "is broken" and we still can't deploy it.

Comment 1

[Ashley Bischoff (blog at handcoding.com)]

Hmm, I don't see a "Browse" button on that page.. Am I just missing it?

Comment 2

[Frank Burleigh]

It's on the third red horz bar down.  It is about the center (horz) of the page
to the right of Keyword, Advanced, etc.  The page comes up ready to accept a
Keyword, so the work Keyword is in red with the Advanced, Browse, etc buttons
being more white or silver.

Comment 3

[Alexandru Savulov]

when i click on (display) i get a javascript error: location.split is not a
function. that explains why no data is posted.

Please use the Javascript console when debugging (Tasks/Tools/JavaScript Console).

(not sure but isn't location.split a DHTML function?)

Comment 4

[Alexandru Savulov]

is not a DHTML function (my mistake) sorry

Comment 5

[Christian Schmidt]

The problem seems to be that a variable with the name "location" is declared.

The behaviour can be reproduced by a page containing the following script:

<script language="text/javascript">
var location;
location = 'abc.html';
</script>

The author of the script appearently wants to override the variable 
name "location" in the local scope. However, this fails (I don't know if this 
is the correct behaviour or not according to the spec), so "location" still 
refers to the location object. "location = 'abc.html'" is an alias 
for "location.href = 'abc.html'", so the above example redirects the user to 
abc.html.

On the site mentioned by the reporter, instead of 'abc.html' a string 
containing spaces etc. is used. This probably confuses the CGI script, since 
the string is never meant to represent an URL though it is used as one by 
Mozilla.

I suggest that someone with detailed knowledge about the ECMAScript 
specification determines whether this is a bug in Mozilla or in the site.

Comment 6

[Fabian Guisset]

Dup of bug 110230.
See also bug 101276.

*** This bug has been marked as a duplicate of 110230 ***

Comment 7

[Frank Burleigh]

I see the javascript error in the js console but I do not see "location" on the
page containing the several "display" buttons (I viewed the source and searched
within--I do see references to this.location and an IE bug, however, in the
comments).  Is there a page between the submission page and the page proclaiming
the "invalid CGI request type?"  If so, how are you seeing it?

Comment 8

[Fabian Guisset]

I think the call to location.split is on the server-side javascript.
Unfortunately we don't seem to have access, or I can't figure out how to access,
this script file.
Error: location.split is not a function
Source File: http://www.iucat.iu.edu/uhtbin/cgisirsi/pVdhsm9YGG/3428032/9
Line: 416
Anyway I'm pretty sure the problem is that you expect location to be a string,
because strings do have a split method. However location is not a string, but it
is converted to a string if you assign its value to a variable.
A way to fix it would be do it this way:
var loc = location;
loc.split(...);
instead of 
location.split(...)

Hope this helps.

N.B: if there is still a problem after fixing the location.split problem, please
reopen the bug, thanks.

Comment 9

[Frank Burleigh]

As JST suggests in bug 110230, I'd like to leave this bug open until its
similarity to bug 110230 can be made explicit beyond speculation.  The
intellectual problem I'm having is the lack of access to the source code: I'd
like someone to explain how the browser is running code that we can't see?  I
grant that that's just what it looks like...

Let me note also that I don't have access to this code, it isn't mine.  To get
it changed even for test is likely to be difficult--they will say it works fine
in NS4 and IE, what's the problem?  That's where we are, I think.  I'll try on
Monday...

That is why I've asked for chapter/verse from the ecma standard--that will help
me get their attention. ;-)

Thanks.

Comment 10

[Christian Schmidt]

The reason that you cannot see the code that is causing the trouble is that you 
are redirected as soon as the code is interpreted (i.e. even before the page 
has loaded). To see the source, navigate to the page using Netscape 4 or IE and 
then view source.

Fabian: this has nothing to do with server-side Javascript. Errors from 
server-side Javascript would never appear in Mozilla's (client-side) Javascript 
console.

Frank: I think the paragraph, you are looking for, is 
http://www.mozilla.org/js/language/E262-3.pdf 10.1.3, third bullet.

Comment 11

[Boris Zbarsky [:bzbarsky]]

setting status to NEW and dependency....

Comment 12

[Frank Burleigh]

The caretakers of the code this bug is about have changed their variable naming
from 'location' to something else, and now things are better.  This means to me
that this was never a moz bug, as several had said, but a problem in the client
js coding.  I also don't see that there's any relation to bug 110230.  So I'm
marking this invalid.  Thanks to all for the help in evangelizing correct JS.

Comment 13

[Vladimir Ermakov]

verifying