Closed Bug 240310 Opened 20 years ago Closed 19 years ago

Browser hangs when trying to load a page containing 71 or more <select > tags with onkeyup=javascript:myfunction().

Categories

(SeaMonkey :: General, defect)

Product:
SeaMonkey
Component:
General
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: Daniel.Walter, Unassigned)

References

(
URL
)

Details

(Keywords: hang)

Attachments

(3 files)

Sampler report on Firefox-Mac/2004-04-10 during hang
6.26 KB, text/plain
Details
Source code as rendered into HTML
61.23 KB, text/html
Details
HTML 4.0.1 Strict testcase
2.42 KB, text/html
Details 
User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.0.3705; .NET CLR 1.1.4322)
Build Identifier: Mozilla/5.0 (Macintosh; U;PPC Mac OS X Mach-O; en-US; rv:1.6) Gecko20040113

Trying to load a page containing 71 or more of the following statements.
<select name="q1" onkeyup="javascript:FindNextFocus(1);">
	<option value="9"></option>
	<option value="0">0</option>
	<option value="1">1</option>
	<option value="2">2</option>
</select>
The page loads (all items display), but the cursor displays as "semi-busy" 
with arrow and rotating wheel pointer.  No javascript will fire from this 
page.  I cannot view the source in this case.  I have to force quit Mozilla.

Page loads just fine and behaves properly (function code fires off) when the 
page contains between 1 and 70 select tags.

Reproducible: Always
Steps to Reproduce:
1.www.web-link.org, go to demo, go to key enter a form.
2.Make up any id you wish, and assign a gender. Select CBCL with "problem 
items only".
3.After the demographics page (you must enter an age between 6 and 18), the 
problem items page is supposed to load.  If it loads ok, select the "Back" 
navigation button, then select "Next" from the demographics page again.  Page 
should hang by this point.

Actual Results:  
After clicking Next on the demographics page, the next url appears in the 
address bar, mouse pointer goes into a waiting state, no page loads.

Expected Results:  
Loaded the page cbc_probs_10.asp, with fully functional Cancel, Back, and Next 
navigation buttons.

We settled on Mozilla to recommend to our customers to resolve another issue.  
This bug makes our product unusable and frustrates our customers.
Severity: blocker → critical
Keywords: hang
Reporter indicated Mac, so FYI: WFM on Firefox 0.8 Windows XP Pro.
C'mon, this needs to be diagnosed before being dumped on the JS engine.

/be
Assignee: general → nobody
Component: JavaScript Engine → Browser-General
Keywords: stackwanted
(In reply to comment #2)
> C'mon, this needs to be diagnosed before being dumped on the JS engine.
> /be

Brendan:  Let me know if you can replicate the behavior.  I'm not sure which 
area to post this bug in.  It seems to be a problem with resolving the HTML 
that is sent to the browser, so perhaps the JavaScript section is not quite 
the right forum.  BESIDES BITCHING ABOUT IT, CAN YOU TEST IT AND SUGGEST THE 
CORRECT PLACE TO POST IT.

Please do not reply unless you have something inquisitive or productive to add 
to the conversation.

(In reply to comment #2)
> C'mon, this needs to be diagnosed before being dumped on the JS engine.
> /be

Brendan:  Let me know if you can replicate the behavior.  I'm not sure which 
area to post this bug in.  It seems to be a problem with resolving the HTML 
that is sent to the browser, so perhaps the JavaScript section is not quite 
the right forum.  BESIDES BITCHING ABOUT IT, CAN YOU TEST IT AND SUGGEST THE 
CORRECT PLACE TO POST IT.

Please do not reply unless you have something inquisitive or productive to add 
to the conversation.

Dan: I'm sorry there's a bug biting your app here.  But in bugzilla, there has
to be a two-way street, as Mozilla volunteers don't just diagnose misfiled bugs
without pushing back on people who misfile.  Your filing bugs in the wrong
component can and does wastes others' time.  It's not a crime, or the end of the
world, but basic fairness suggests that you shouldn't expect me to give you a
free lunch without any back-talk, any more than I would you.

If I can point out that you used the wrong component, maybe you won't next time,
and that'll save some number of people who watch js bugs some time, and actually
evem get the bug to the right people sooner.

Escalating bitchiness (I didn't use ALL CAPS as you did; my comment wasn't meant
to be bitchy, but I'm sorry if it came off that way) is not helpful, especially
if you are attempting to lecture me not to bitch ;-).

Somewhat more productive part:

Here's a hint for future reference: JS errors can usually be isolated from HTML
or other bugs.  If you can't find a pure-JS testcase, and don't have any better
candidate, then start the bug at Product: Browser, Component: Browser-General.

Even more productive part:

Strict warnings include this one, which seems bad but might be benign:

JavaScript strict warning:
https://www.web-link.org/CLIN/ke_forms2.asp?verification=0&verifypage= line 184:
reference to undefined property k.toString
                                                                                
After the strict warnings, I get a ton of these:

WARNING: empty damage rect: update caller to avoid fcn call overhead, file
nsFrame.cpp, line 2540

Cc'ing others who might know what these mean. They may be peculiar to Linux, not
relevant to the reporter if not on Mac.

And finally:

Document https://www.web-link.org/CLIN/ke_forms2_process.asp loaded successfully 

I can't reproduce a hang.  I'm testing on Fedora Core 1 Linux.

Looking at the
https://www.web-link.org/CLIN/ke_cbc_probs10.asp?verification=0&verifypage=
source, I see this head and body open tag:

<head>
        <title>ASEBA Web-Link</title>
                                                                                
        <link rel="stylesheet" type="text/css" href="INCLUDE/ADMWeb.css">
</head>
                                                                                
<body leftmargin="0" topmargin="0" bottommargin="0" rightmargin="0"
marginheight="0" marginwidth="0" onload="javascript:ResetControls();">

Nit: The "javascript: is a useless label, it looks like someone may have thought
onload's attribute value should be a javascript: URL.

ResetControls is a function that sets the selectedIndex property of 120 select
objects' options arrays to 0.

Did you find that if you have 71 or more of those selects, you hang?  Or was it
the case that you also were testing with onload calling ResetControls, which set
however options.selectedIndex = 0 for however many selects there were?  If you
can take out the guts of ResetControls, and test around the 70 and 71 apparent
threshold, that would help sort out whether this is purely a matter of 71 or
more select objects, or that many *plus* the onload-time code to zero all their
options.selectedIndex properties.

Cc'ing Asa, who may be able to find other Mac testers who can try to reproduce.
Obviously, a reproduced hang and a stack backtrace would be ideal.

/be
Confirmed using Firefox-Mac/2004-04-10. Not a typical application hang; menus
and widgets are accessible, but have no effect. Application partially responds
to Quit command; windows close but app remains running until Force-Quit.

Sampler report forthcoming. If someone will attach the source I'll try to reduce.
URL: http://www.web-link.org - log into de... → http://www.web-link.org/
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: stackwanted
(In reply to comment #5)
Brendan:  Sorry for blowing my stack - we're trying to develop a work-around 
while we wait for some Bugzilla resolution, mucho stress time over here.

The hang happens with document https://www.web-
link.org/CLIN/ke_cbc_probs10.asp?verification=0&verifypage=

You asked "Did you find that if you have 71 or more of those selects, you 
hang?"  The answer is yes.  I didn't touch the reset controls function.  As 
part of our workaround development I experimented with this.  The page still 
loads even though it refers to form controls that are not defined on the 
form.  For prudence sake, I have made the number of items in ResetControls 
match the number of items on the form.  So I guess your comment "If you
can take out the guts of ResetControls, and test around the 70 and 71 apparent
threshold, that would help sort out whether this is purely a matter of 71 or
more select objects, or that many *plus* the onload-time code to zero all their
options.selectedIndex properties." can be answered as "this is purely a matter 
of 71 or more select objects" (since setting properties for 120 when only 70 
exist still allows the page to load).

You wrote:
"Document https://www.web-link.org/CLIN/ke_forms2_process.asp loaded 
successfully 
I can't reproduce a hang.  I'm testing on Fedora Core 1 Linux."  This page 
doesn't have a problem per se.  The redirect to ke_cbc_pros10.asp is the 
problem, since that is the page that won't load.

I can't quite follow your other comments (save for the javascript: being a 
useless label - this is probably a case of moving the function call from one 
event to another) about the strict warnings etc., so I guess I can't help with 
more info on that.

Again, I apologize for the undeserved rant!

Dan


 

(In reply to comment #6)
Greg:  Do you need the source as rendered into HTML, or the original ASP page?
Dan

The HTML source as delivered to the client, Dan. I presume you can reproduce the
problem with just that rather than the ASP original, since the browser doesn't
care what it was before it was HTML.
This is the source code requested.  DW
Greg:
I posted the source as an attachment.
Dan

(In reply to comment #6)
> Confirmed using Firefox-Mac/2004-04-10. Not a typical application hang; menus
> and widgets are accessible, but have no effect. Application partially 
responds
> to Quit command; windows close but app remains running until Force-Quit.
> Sampler report forthcoming. If someone will attach the source I'll try to 
reduce.


This is a weird one. During reduction I first converted the source to valid and
well-formed HTML 4. Then further reduced to the following HTML structure:

form>table>tr>td>table+align=right>tr>td>select*50

Reducing the number of SELECTs below 50 resolved the hang. However, I quickly
discovered that changing the DOCTYPE to transitional or removing it entirely
also resolved the hang. Naturally, the original HTML source Dan provided is not
at all HTML 4.0.1 Strict; indeed, it is invalid and malformed.

In any event, the hang behavior observed is still the same. Perhaps this will
suffice for the time being.
Boris may be able to shed light based on Greg's excellent reduction work.

/be
Unfortunately, I can't reproduce the problem (debug and optimized builds on
Linux, the former from a completely clean tree).

Greg, do you have access to any non-Mac systems to test whether this is Mac-only?
Tested Mozilla-Win/1.6 using Virtual PC, and my testcase doesn't hang it. But
then, I gathered from comment 1 and comment 5 that this only hangs Mac.
Ah, ok.  Greg, is your Mac build using native theming for those form controls? 
Does setting -moz-appearance to "none" at
http://lxr.mozilla.org/seamonkey/source/layout/html/document/src/mac/platform-forms.css#72
(it should just be a platform-forms.css file in the bundle, not even in a jar)
help the situation?
Where in the app bundle would I find that file?

Okay, odd. Today Firefox doesn't hang on my testcase, but Mozilla 1.7b still
does. Camino does not, nor does it hang on the reporter's URL.

(Dan, one workaround you could suggest to your Mac users for the time being is
to use Camino 0.7.)

Neither Firefox nor Mozilla are using native controls for my testcase. Mozilla
definitely not, since it's using the Modern theme.
Greg: 1.8a trunk has been open only since Monday afternoon PDT, any chance you
can narrow down when things started working, so we can look at bonsai?

/be
> Where in the app bundle would I find that file?

On Linux, it's in res/platform-forms.css (inside the general mozilla dir).

> Mozilla definitely not, since it's using the Modern theme.

Theme doesn't affect nsITheme-based form control rendering...
Brendan: this was with the same Firefox build used for comment 13. I'll have a
look again tomorrow.
Okay, today this hangs Mozilla-Mac/2004041406 and Firefox-Mac/20040410. It still
does not hang Camino, so maybe this does have something to do with XPFE SELECT
widgets (since Camino uses Aqua widgets).

Re: comment 20; changing to -moz-appearance: none; resolved the hang. Reverting
to -moz-appearance: menulist; *did not reintroduce the hang*. Subsequent
retesting of original HTML attachment 146028 [details] still did cause hang, though, with
both none and menulist. (Then, the original HTML had SELECTs with SIZE greater
than 1, anyway.)

A weird problem. I think my reduction may be flawed.
The original HTML attached to this bug has only selects of size=1, no?

I just looked through the combobox code, and nothing there is mac-specific...
maybe it's doing something that somehow only triggers problems on mac?
Product: Browser → Seamonkey
Is this still a problem on Mac?
Both HTML testcases WFM using FF 1.5 on Mac, resolving wFM.

Dan Walter, if you can still reproduce this bug, please reopen it and provide the details about which build you're using.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: