2002061408 trunk, both OS/2 and windoze. I submitted this URL previously in http://bugzilla.mozilla.org/show_bug.cgi?id=138742#c3 as an example of that bug's behavior. Now this very large subject page displays only just a bit at the very bottom. Since I know virtually nothing about JS I know no way to figure out why.
Umm, the page looks just like it does in IE with build 2002061408-trunk/WinXP.
Created attachment 87818 [details] OS/2 screenshot of subject URL IE 6.0.2600.000; 55736-518-0950142-04417; Q321232 on W2K 5.00.2195 SP2 displays the page just fine, while trunk 2002061408 W2K and OS/2 4.5 do not.
bug 148399 was fixed later in the day after the build you have. Try with something more recent... page looks fine to me.
Using OS/2 2002061708 trunk, nothing has improved. Screenshot would be exactly the same as before, shades of Netscape 4 and missing table close tags. I suspected that maybe this might be a HOSTS file related problem. I removed three instances of the word "homestead" from the HOSTS file, saved, exited Mozilla, restarted Mozilla, then reloaded the subject page, but found no improvement. There was a minor change, as at the top of a page previously was a broken image outline that after the HOSTS file edit was converted to more whitespace. Next I tried eliminating the HOSTS file entirely, but no improvement. Then I remembered in W2K I had no HOSTS file.
I narrowed the problem down, but don't know what to make of what I found. I saved as HTML and opened, finding the result no different. Then I opened the file for edit and discovered many instances such as the following: <DIV style="margin-top: -7368px; margin-left: 0px"> <DIV style="margin-top: 5742px; margin-left: 600px"> <DIV style="margin-top: 53px; margin-left: 208px"> <DIV style="margin-top: 330px; margin-left: 27px"> <DIV style="margin-top: 1767px; margin-left: 546px"> There were many other variations of pixel combinations, but the negatives and the four digit sizes really bothered me, so I started converting tags with either a four digit size, or a negative, to simply "<DIV>". After doing a large quantity of such edits I reloaded the page, and found that there was now much content showing. Obviously these pixel sizes are very fubar, but Mozilla should do better validity checking so as to ignore any pixel size out of some reasonable range, or negative.
I don't see this at all on a current trunk build. The page displays all content fine.
Using the exact same machine (K6/2-400) and the exact same network connection (third PC with modem running RedHat 6.2 as router) as previously reported using W2K, a fresh Mandrake Linux 8.2 install's Mozilla 0.9.8 20020204 has no problem displaying the page. Rebooting that machine into W2K (2002061408 trunk) results, as previously reported, in the exact same problem as my main OS/2 machine (K6/2-550), now on 2002061708 trunk. I'm on 26K pots, so I can't willy nilly go downloading additional builds for the infrequently used OS's. The Mandrake/W2K machine is i586, so I don't see an appropriate trunk build for Linux for download. My previous attempts to upgrade Mozilla from any Mandrake distro's Mozilla build were all failures. Today's OS/2 trunk is due in less than an hour, but after the lack of behavior change since I filed this bug I think I sure could use suggestions other than trying other builds. I thought sure the comment 5 screwball pixel sizes were the problem, at least in part?
I've finally managed to upgrade Mandrake's Mozilla to the Cooker 1.0 release, which reports, puzzlingly, as (X11; U; Linux i586; en-US; rv:1.0.0) Gecko/00200205 (sic). Result is what appears to be a correctly rendered page, same as using 0.9.8.
On the same box as Mandrake 8.2 and Mozilla 1.0 release build that does display the page properly, I've rebooted into W2K and installed 1.0.0 20020530. This also fails to display any more than the little bit in the screenshot.
I'm wondering if this page is sending two different versions of itself. Next time you have the problem, save it to disk.
You have a spy looking inside my window? It loads fine using OS/2 2002060216 (1.0 release). I saved page to disk, then tried to load that. That failed with a modal dialog "cannot locate file:///G:/TMP/index~ns4.html". More details after I try today's OS/2 trunk build.
Also displays OK in OS/2 trunk 2002061908, and now W2K 1.0 2002053012, but I found the problem. The file saved to disk was the same whether displayed properly or not. The problem is Mozilla's handling of the results of bogus UA string(s) fed to the server. Cause would have been spotted early if the Bugzilla 2.17 upgrade hadn't happened, as 2.17 currently does not display the found UA strings on the input form. From user.js: user_pref("general.useragent.override","Nutscrape/0.9 [en] (CP/M; U; 8 bit)"); user_pref("general.useragent.vendor", "Nutscrape"); user_pref("general.useragent.vendorSub", "0.9"); Removing these lines from user.js and prefs.js is the solution to the reported behavior. But, all the above appears to point out (I could be wrong, as the software that created the page produces dismal code) that Mozilla is mishandling page content when there is a UA ID problem. It may be the fault of the Mozilla user that a bad UA override string is supplied to the server, but that shouldn't make Mozilla display a mostly blank page. Changing summary to include cause. Changing product from evang to browser.
Component: US Ecommerce → DOM Core
Product: Tech Evangelism → Browser
Summary: Large page displays virtually nothing. → Bad UA string causes page to display virtually nothing.
Target Milestone: --- → Future
Version: unspecified → other
garbage in garbage out?
Assignee: aruner → dbaron
Component: DOM Core → Style System
QA Contact: bclary → ian
Could someone summarize what the *bug* is?
Hidden prefs allow the user to specify his own UA string. When a user does this it can result in Mozilla displaying little to none of the page content, even though the server serves up the same page regardless of what UA string is presented.
Is the server giving us garbarge when you change your UA string, or is it sending back exactly the same thing?
In comment 12 I wrote "The file saved to disk was the same whether displayed properly or not." IOW, I saved the file both ways (HTML only), 85598 bytes each. Comp said they matched.
Big differences if I do a save as html complete. If anyone is interested, I can zip up either the good or the bad or both and attach to this bug.
Is it sending a different CSS File?
No. The differences are in the .html names and sizes and the page counter gif. All other gifs and jpgs have the same byte counts, and the one shared .js file also has the same byte count.
The page has JS that looks at the userAgent and does different things based on what the value is. In particular, if the useragent is not recognized it never moves all that stuff over into the visible area...
Status: UNCONFIRMED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → INVALID
I understand the software that made the page is garbage. What I don't understand is why it is OK for Mozilla to accept a 90K+ HTML page and display virtually nothing, which is what marking this invalid amounts to. Behavior on the page is what I expect from 4.x, not Mozilla. (BTW, I'm JS ignorant.)
It's ok to display nothing because that is precisely what the page author has asked Mozilla to display. If the page were 90K of HTML comments we would also display nothing, for precisely the same reason. Does that make sense?
Better sense, yes, thank you, though I wish I had the ability to confirm that the page author has in fact asked that virtually none of his code be displayed. Maybe instead of invalid this should be converted to an evangelism bug directed at homestead? Scratch that. Bug 152749 seems to cover homestead already.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.