Bad UA string causes page to display virtually nothing.

VERIFIED INVALID

Status

()

VERIFIED INVALID
17 years ago
17 years ago

People

(Reporter: mrmazda, Assigned: dbaron)

Tracking

Trunk
Future
x86
All
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

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

Comment 1

17 years ago
Umm, the page looks just like it does in IE with build 2002061408-trunk/WinXP.
(Reporter)

Comment 2

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

Comment 3

17 years ago
bug 148399 was fixed later in the day after the build you have. Try with
something more recent... page looks fine to me.
(Reporter)

Comment 4

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

Comment 5

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

Comment 6

17 years ago
I don't see this at all on a current trunk build.

The page displays all content fine.
(Reporter)

Comment 7

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

Comment 8

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

Comment 9

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

Comment 10

17 years ago
I'm wondering if this page is sending two different versions of itself.

Next time you have the problem, save it to disk.
(Reporter)

Comment 11

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

Comment 12

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

Comment 13

17 years ago
garbage in garbage out?
Assignee: aruner → dbaron
Component: DOM Core → Style System
QA Contact: bclary → ian
Could someone summarize what the *bug* is?
(Reporter)

Comment 15

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

Comment 17

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

Comment 18

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

Comment 19

17 years ago
Is it sending a different CSS File?
(Reporter)

Comment 20

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

Comment 22

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

Comment 24

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