Closed Bug 152077 Opened 22 years ago Closed 22 years ago

Bad UA string causes page to display virtually nothing.

Categories

(Core :: CSS Parsing and Computation, defect)

Product:
Core
Component:
CSS Parsing and Computation
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED INVALID
Milestone:
Future

People

(Reporter: mrmazda, Assigned: dbaron)

References

(
URL
)

Details

Attachments

(1 file)

OS/2 screenshot of subject URL
6.08 KB, image/png
Details 
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.
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
Closed: 22 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.

Attachment

General

Creator:
Created:
Updated:
Size: