looks like the table is getting closed out too soon. this was part of bug report 1686

All fixed with last (big) update to parsing engine.

installing myself as QA Contact for sevaral bugs at once

Nope. this page is still buggy. There is at least one other quicken bug bouncing around that I will check into. It may be two descriptions of the same phenomena. I've changed the Platform/OS field to reflect that this bug IS cross-platform. WinNT 99032 MacOS 99032 Linux 99033

housekeeping cc list

Setting all current Open Critical and Major to M3

Jan -- please ask your folks to be a bit more specific. This report is a pretty clear example of how some bug reports are just too vague (while to be fair, others are pretty terrific).

Will do..

Clearing Fixed resolution and assigning to beppe to ensure more info. beppe, please assign back to rickg when noting the reproducible case. Thanks!

This bug is valid for all three platforms as of the Feb-08 builds. I've changed the platform and OS fields to reflect that this bug is on ALL 3 platforms. What is the bug? Well, I'll elaborate on what the original reporter, buster@netscape.com was getting at. 1) Go to www.quicken.com. This page is a good testbed for multiply-nested tables in multiple rows. All of the content except the ad banner and logo in the top left is contained in one big table. All of the other content is within tables that are nested in the rows of the original large table. This setup is of course mostly invisible. The page SHOULD appear to basically be in a three column format(even though the real structure is nested rows), with many links in the left column and then content and charts in the second and third column. 2) What you actually see is all the links from the left-hand table layed out properly, but then all the other content follows BELOW that. It appears that the table row that should contain the rest of the content is getting closed out so it is being layed out at the start of the next row (of the large encompassing table). It is basically failing to nest everything after the first nested table. reassigning to rickg as per previous request changing summary field to include more info and provide funky things to query on

Actually the "problem" here is quicken.com and their handling of "Mozilla/5.0". 1) Quicken.com is returning *broken* HTML when presented with the user agent "Mozilla/5.0 [en] (Win95; I)", and that HTML is *equally* broken for NGLayout, Netscape 4.5 and for MSIE 4.0. 2) I confirmed that Quicken is spewing two different sets of HTML by using lwp-request to pass different user agent string in GET to get the different output (5.0 vs. 4.5). The 4.5 HTML loaded from disk into nglayout displays without error. I also used lwp-request to get IE4 and IE5 versions of the HTML, and nglayout can display these pages perfectly (the only difference in the HTML is the use/non-use of IFRAMES) 3) If the user agent for NGLayout is set to "Mozilla/4.5 ..." then the layout is 100% OK (ignoring a known bug with the display of '•'). (I modified netlib.dll to get the 4.5 string in place; what is the env variable to do this anyways?) I think this is FIXED.

I was using build Feb 06 win95 non-debug, by the way.

seems like it would be useful to share this information with the webmasters over at quicken. Do we have someone in place to do that? A marketing person, maybe?

marking as VERIFIED. It seems that the only remaining problems are with the way Quicken is serving the HTML.

The issues that 3jrgm@qlink.queensu.ca so rightly raised can now be tracked at http://bugzilla.mozilla.org/show_bug.cgi?id=3688 (servers sending broken HTML based on mozilla/5.0 user agent)

Reopening bug and assigning to self to evangelize and track fix.

NEVER MIND, I now see that as of 7 June in M6 build, the bug no longer occurs; quicken must have fixed the problem on their side. Reclosing. Sorry!

VERIFIED for 1999060708 builds on MacOS, RHLinux, and WinNT