Closed Bug 21013 Opened 25 years ago Closed 25 years ago

Can't submit bugzilla query

Categories

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

Product:
Core
Component:
DOM: Core & HTML
Type:
defect

Tracking

()

Status:
VERIFIED DUPLICATE of bug 24033

People

(Reporter: biswapesh_chatterjee, Assigned: rpotts)

References

(
URL
)

Details

Attachments

(5 files)

fix for today's form submission bug
1021 bytes, text/html
Details
test case
106 bytes, text/html
Details
oops, real test case
144 bytes, text/html
Details
Dr. Watson crash log (two of them for the same incident)
40.81 KB, text/plain
Details
Clicking on the link in this HTML document will either crash mozilla or make it go into infinite loop.
618 bytes, text/html
Details 
System: Build 1999120608 on WinNT SP5
Overview: Mozilla goes into an infinite loop while executing query in bugzilla
under certain circumstances.
Test Case: Go to http://bugzilla.mozilla.org/query.cgi . Keeping all fields to
their default values, enter the string 'menu' in the field labeled 'Summary:'
and press 'Submit Query'. Keep NT task manager on.
Expected Result: The query results should be fetched.
Actual Result:
1) The following message starts appearing in an endless loop:
<<<
WARNING - table cell content max element width 1073751079 greater than desired
width 1073741824
>>>
2) The CPU Usage shoots to 100% and stays there till the browser is killed.
3) The page fills up with garbage.
4) The memory usage keeps on increasing.

Other info: This problem does not occur in M11, IE5, NS4.x, etc.
The bug occurs even if you write 'scroll' instead of 'menu'. I think it can be
generalized for any query that returns a lot of bugs, but I'm not sure. Bug
remains with Dec. 12 build, except that the warnings about table size does not
show in the console window.
Assignee: karnaze → pollmann
I am not seeing an infinite loop but the query is not doing anything and reports
an "Error: Can't load ...". Reassigning to Eric.
I'm pretty sure that the current day failure to submit is a different bug from
that originally reported, and the original bug may still be lurking behind it.
I tried a query with last night's build and got this message:

url=(url+big query string)

data=(big query string)
DocLoaderFactory: Unable to create ContentViewer for command=view,
content-type=multipart/x-mixed-replace
Error: Can't load: (url+big query string)

Still looking at this.
Adding Rick to the CC list.
Summary: Infinite loop while executing query in bugzilla → Can't submit bugzilla query
The failure to submit a bugzilla query in today's build appears to be related to
Norris's checking yesterday to verify the security of a URL load.  I traced
through nsFormFrame::OnSubmit and we are bailing right in the new code:

 618       if (NS_FAILED(result) ||
 619           NS_FAILED(result = NS_NewURI(getter_AddRefs(actionURL), href)) ||
 620           NS_FAILED(result = securityManager->CheckLoadURI(docURL,
actionURL)))
 621       {
 622         return result;
 623       }
 624     }

result is not NS_OK here.  Anyone know why?  This failure is hiding yesterday's
bug even.  :S
Adding Judson to CC.
NS_NewURI is returning a failure code here.
The url is relative, "buglist.cgi" and the baseURI passed to NewURI is null,
this causes NS_ERROR_MALFORMED_URI in nsIOService::NewURI.  I'm looking into why
baseURI is null...
I'm attaching a 1 line fix for that bug, but I'm still seeing the "can't create
ContentViewer"...
*** Bug 21875 has been marked as a duplicate of this bug. ***
This fix will allow pages with forms with actions that are relative url's to
submit.  Unfortunately we will still have problems on the test URL because of
the contentViewer problem.  Would anyone like to review my first patch so we can
move on to the next problem?  Thanks.  :)
Attached file test case — 

    
    

    
  

      
      
      
      

        Attached file
          
        oops, real test case
        — 
      

    


  

    
  
Assignee: pollmann → rpotts
Status: ASSIGNED → NEW

    
    

    
  
To verify the code fix, view the test case above labeled "opps, real test case".

Before the bug fix, clicking "submit" has not effect.
After the bug fix, clicking "Submit Query" has the effect of returning to this
bug report.
I'm checking in this fix, but leaving the bug open to track the contentViewer
problem.  Reassigning to rpotts, though I don't know if he's the right guy?

    
    

    
  
Checked in the first fix.

    
  
Summary: Can't submit bugzilla query → [DOGFOOD] Can't submit bugzilla query

    
    

    
  
hey eric,
I've just pulled you fix and it fixes bugzilla for me!!  I don't see the "unable
to create content-viewer" error message...

Are you the only one seeing this message?

-- rick

    
    

    
  
*** Bug 21934 has been marked as a duplicate of this bug. ***

    
  
Target Milestone: M12

    
    

    
  
Boldly putting on M12 radar

    
  
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED

    
    

    
  
this should be marked resolved, just seeing that the fix was checked in

    
  
Whiteboard: [PDT+]

    
    

    
  
Putting on PDT+ radar.  Should this reopen, it is definitely dogfood for QA :-)

    
    

    
  
Rick, I am able to run bugzilla queries without seeing the "content-viewer"
message now.  Looks like this bug is all fixed now to me!  Thanks.  Now if only
typing in a textarea wasn't causing page downs this would really be bugzilla
dogfood.  :)

    
  
Status: RESOLVED → REOPENED

    
    

    
  
This is occurring again in 19991217 build (WinNT SP5) - Let me give you the
full URL:
http://bugzilla.mozilla.org/buglist.cgi?
bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&email1=&emailtype1=substr
ing&emailassigned_to1=1&email2=&emailtype2=substring&emailreporter2=1&changedin=
&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&short_desc=menu&short_desc_type
=substring&long_desc=&long_desc_type=substring&bug_file_loc=&bug_file_loc_type=s
ubstring&status_whiteboard=&status_whiteboard_type=substring&cmdtype=doit&newque
ryname=&order=%22Importance%22&form_name=query
(Remove spaces and all which may have crept in due to form submission).
What is happening is I get a plain text list of the bug numbers at the top of
the page and then the mozilla.org GIF image (red dragon and all) a couple of
times. Then the app hangs. The CPU usage shoots to 100% and stays there (it has
remained there all the time I've been writing this report). The Mozilla.exe
process becomes 'Not responding', the memory usage keeps increasing and this
message comes in an infinite loop on the console window:
WARNING - table cell content max element width 1073741884 greater than desired w
idth 1073741824
I have the bugzilla cookie set.
This does not happen in IE5/Nav4.x/M11 - so there is no problem with the bug-
list.cgi script.
Another thing: I ran the same query with a simple cgi in the local web server
using mozilla and it runs fine. So the problem is not with the URL itself.
Can't think of any other detail (BTW the query is still running, mozilla is
still 'Not Responding', the table messages still appearing on the console
window and the CPU usage is still 100% as I finish writing this. It has been
about 5 minutes since I submitted the URL.

Re-opening this.

    
  
Resolution: FIXED → ---

    
    

    
  
I was able to submit Bugzilla query forms using the 12/17 opt comm bits on
Win98, but even the simplest query does not work in the debug build I just
finished. I had to switch to 4.7 to commit these changes to this bug. clearing
fixed resolution.

    
    

    
  
Finally ! Got mozilla to crash so that I could get the crash dump. This time
there was no 'table...' message loop in the concole window - I was using a
different computer which did not have my cookie set - so this is not a cookie
problem either. This is what I got on my mozilla window upto the point it
crashed (Unfortunately I could not get a print screen - will try it later). The
query was just the word 'menu' in the summary field - the other fields were all
default; and as I said before, no cookies.
<<<
Set-Cookie:
BUGLIST=19588:9333:16722.....etc.
<The Mozilla Image>
Bugzilla version 2.8
>>>
The above got repeated with minor variations (Such as the date stamp comming
once and the mozilla image being a bit shorter, etc) till it crashed.

    
    

    
  
If you look at the attached crfash log, you will see that they crashed at
identical points, namely at the function NS_NewCSSNameSpaceRule. Any help from
that ?

    
    

    
  
Very interesting: The browser *does not* crash if your bugzilla cookie is set -
it goes on an infinite loop instead with the table warning as below:
<<
WARNING - table cell content max element width 1073748829 greater than desired w
idth 1073741824
>>
That is why I was unable to get it to crash from my machine. I set my cookie
from this machine and was able to duplicate the behaviour of my m/c (namely no
crash, infinite loop, 100% CPU, infinite 'table..' error lop, the works.

    
    

    
  
Sorry  - ignore the last message - it just crashed at the same point with the
cookie set - so no go there.

    
  
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → WORKSFORME

    
    

    
  
This does not crash or infinite loop for me with today's build.  Fresh Win32
Clobber and Linux Depend builds from around noon today.  Marking WORKSFORME
because I don't know who fixed it.  Anyone still seeing this?

    
  
Status: RESOLVED → REOPENED

    
    

    
  
I'm seeing this with 1999122208 WinNT over 28.8K dialup (which may be a
factor). I've loaded the same HTML content from disk, and while it is a large
table, it loads from disk without any error.

This was noted in a message to n.p.m.general last night, and I could get it to
happen easily last night. However, oddly, this morning, at first, I couldn't
duplicate it.

When it does happen, the HTTP cookie header is displayed across the top of the
canvas. Note also that the query is generating a cookie of ~4K in size (which
is the minimum RFC requirement on cookie size, but in practice is the maximum
"in the wild" size of cookies, no?)

Speculating that this was networking related, and _may_ be timing sensitive, I
started an ftp download with Nav4.x to contend for my modem bandwidth. *Then*
I could duplicate this _twice_ this morning (it's hard to consistently
duplicate, but it is definitely there -- which, I know, sucks).

When the bug does occur:
 -- the cookie header displayed across the top of the screen,
 -- CPU -> 100%, memory starts going up,
 -- and, finally a crash [which occurs in NS_NewCSSNameSpaceRule, but that's a
    consequence of the Set-Cookie: mishandle, not the root cause (IMHO ;-)]

    
  
Resolution: WORKSFORME → ---
Target Milestone: M12

    
    

    
  
Clearing resolution, and target milestone (M12 has passed). Oh, and Happy
Holidays!

    
    

    
  
*** Bug 22334 has been marked as a duplicate of this bug. ***

    
    

    
  
Comments by mozilla-bugzilla@devin.com on bug #22334 (12/21/99):

 | M12 often hangs when displaying a bug list produced by Bugzilla's
 | buglist.cgi.  It may hang silently, or may rapidly (and eternally, AFAICT)
 | output errors of the form "WARNING - table cell content max element width
 | 1073741884 greater than desired width 1073741824", where the latter number
 | remains constant and the former may vary somewhat.  Layout in the browser
 | at this point contains black rectangles where images or tables would be
 | expected, above each of which is a Set-Cookie header, e.g. "Set-Cookie:
 | BUGLIST=18374:11586:...".  UI will not respond or redraw itself past that
 | point.  Screenshot at http://www.devin.com/cruft/hung-mozilla.jpeg if it's
 | useful.
 |
 | Bug may be reproduced by going to bugzilla via personal toolbar, then to
 | "Search existing bug reports."  Enter something in the "query" blank and
 | submit the form.

    
  
Target Milestone: M13

    
    

    
  
*** Bug 22039 has been marked as a duplicate of this bug. ***

    
  
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → WORKSFORME

    
    

    
  
This is working now.  Marking Resolved/WorksForMe.  paulmac to supply re-test
data.

    
    

    
  
bug 22039 has an URL that still causes the bug - which is clearly not working.

    
  
Resolution: WORKSFORME → ---
Summary: [DOGFOOD] Can't submit bugzilla query → Can't submit bugzilla query
Whiteboard: [PDT+]

    
    

    
  
John, I can't reproduce this using the test case in this bug or in bug 22039 on
Linux, win98, or winnt. Have you tried on a clean profile?

    
  
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → WORKSFORME

    
    

    
  
alright. I wiped my profile on 2000011311 on winNT and it worked fine. sorry for
the reopen spam that's an odd profile problem.

    
    

    
  
Marking VERIFIED WORKSFORME on:
- Linux6 2000-02-01-10 Commercial build
- Win98 2000-02-01-08 Commercial build
- MacOS86 2000-02-01-09 Commercial build

Status: RESOLVED → VERIFIED

    
    

    
  
*** Bug 24226 has been marked as a duplicate of this bug. ***

    
    

    
  
I'm getting this *yet again* on nightly build 20000208 on WinNT. Very 
frustrating. Just type something very common in the description field 
like 'java' or 'menu', which is sure to return a lot of entries, and submit.

Status: VERIFIED → REOPENED
Resolution: WORKSFORME → ---

    
    

    
  
I'm unable to reproduce this using a tip build...


    
    

    
  
I am unable to repro this on a 02/12/99 build on winnt sp5

    
    

    
  
After an out-of-band exchange with paulmac (jan14), after this bug had
been closed, I filed this problem again with a new summary as bug #24033

So far, no one within Netscape has been able to reproduce this
behaviour, but at least six people outside your network have seen
this behaviour. (This suggests (to me) that connection speed and/or
round-trip latency may be a factor).

I think the key thing in all the reports of the this bug is that the
HTTP 'Set-cookie:' header is somehow put into the content sink -- see
http://bugzilla.mozilla.org/showattachment.cgi?attach_id=4272 -- which
should never happen (please correct me if this is an untrue statement). 

So, somewhere between necko, the parser and the content sink, the
wrong thing happens. (Perhaps the other critical condition is the
(near maximum) size of the cookie and/or the absolute size of the HTML
content returned for the query).

I'm going to mark this bug as a duplicate of bug #24033 (as it is a
dup). Of course, we still need a way to reproduce this, as it can't be
fixed otherwise. 

(Using win95 2000-02-10-14 I can't actually reproduce now, but I'm
always having some flaky service from my ISP right now so I can't
count this failure to reproduce as equal to no more problems.)

*** This bug has been marked as a duplicate of 24033 ***
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → DUPLICATE

    
    

    
  
note that I can't repro the problem and I am outside the firewall (though I am 
on a T1 connection).

    
    

    
  
I haven't seen this bug in a while, but it doesn't have anything to do with bug
24033. I've seen both of these bugs - seperately. If someone wants to reopen
(assuming it's still happening for them) go right ahead.

Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---

    
    

    
  
jelwell: did you intend to reopen this bug? (your comments indicate otherwise).

At any rate, this *is* the same bug as bug 24033 (which I opened as a 
'successor' to this bug after it was closed (see my Feb 13 comment above)). 

It sucks that this is difficult to duplicate, but there is a lurking problem
in the handoff necko->parser->content sink. It's better to focus the effort
in one place. Re-marking DUPL of bug 24033.

    
    

    
  
Duh! Now marking as a DUPL.

*** This bug has been marked as a duplicate of 24033 ***
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → DUPLICATE

    
    

    
  
If someone reopened it, I don't think it was me. Or at least I hadn't intended 
too.

    
    

    
  
Marking VERIFIED DUPLICATE on:
- Linux6 2000-02-17-08 Commercial build
- MacOS9 2000-02-16-16 Mozilla build
- Win98 2000-02-16-16 Commercial build


Status: RESOLVED → VERIFIED
Component: HTML: Form Submission → DOM: Core & HTML

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: