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
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.
(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.
Created attachment 146028 [details] Source code as rendered into 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.
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?
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?
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.