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

RESOLVED WORKSFORME

Status

SeaMonkey
General
--
critical
RESOLVED WORKSFORME
14 years ago
12 years ago

People

(Reporter: Dan Walter, Unassigned)

Tracking

({hang})

Trunk
PowerPC
Mac OS X

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(3 attachments)

(Reporter)

Description

14 years ago
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.

Updated

14 years ago
Severity: blocker → critical
Keywords: hang

Comment 1

14 years ago
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
(Reporter)

Comment 3

14 years ago
(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.
(Reporter)

Comment 4

14 years ago
(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

Comment 6

14 years ago
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: stackwanted

Comment 7

14 years ago
Created attachment 145990 [details]
Sampler report on Firefox-Mac/2004-04-10 during hang
(Reporter)

Comment 8

14 years ago
(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


 
(Reporter)

Comment 9

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

Comment 10

14 years ago
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.
(Reporter)

Comment 11

14 years ago
Created attachment 146028 [details]
Source code as rendered into HTML

This is the source code requested.  DW
(Reporter)

Comment 12

14 years ago
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.

Comment 13

14 years ago
Created attachment 146041 [details]
HTML 4.0.1 Strict testcase

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?

Comment 16

14 years ago
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?

Comment 18

14 years ago
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...

Comment 21

14 years ago
Brendan: this was with the same Firefox build used for comment 13. I'll have a
look again tomorrow.

Comment 22

14 years ago
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

Comment 24

12 years ago
Is this still a problem on Mac?

Comment 25

12 years ago
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
Last Resolved: 12 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.