Closed Bug 301534 Opened 19 years ago Closed 19 years ago

Some stylesheets sometimes inaccessible in 1.0.6 (UA detection/cache)

Categories

(addons.mozilla.org Graveyard :: Public Pages, defect)

Product:
addons.mozilla.org Graveyard
Component:
Public Pages
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: whoselist, Assigned: justdave)

References

(
URL
)

Details

Attachments

(4 files, 1 obsolete file)

full headers
28.93 KB, text/plain
Details
header diff
21.83 KB, text/plain
Details
Screenshot 1.0.6
99.35 KB, image/jpeg
Details
Screenshot IE
50.38 KB, image/jpeg
Details 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6

The page has four related stylesheets (ignoring
https://addons.mozilla.org/css/print.css ), but the public build of Fx 1.0.6
sometimes returns nothing (=Untitled) when accessing one or more of them, and
sometimes one of the stylesheets only contains the following one line:

<html><body></body></html>

Stylesheets:
https://addons.mozilla.org/css/cavendish/template.css
https://addons.mozilla.org/css/base/template.css
https://addons.mozilla.org/css/base/content.css
https://addons.mozilla.org/css/cavendish/content.css

The effect is a varying degree of failure to render the page correctly.
Extension pages are also affected, seemingly by a similar problem.

Reproducible: Sometimes

Steps to Reproduce:
1. Download and install Fx 1.0.6 from http://www.mozilla.org/products/firefox/
using new or old profile.
2. Open Fx and access https://addons.mozilla.org/extensions/?application=firefox

Actual Results:  
Page is sometimes rendered incorrectly, with different types of incorrectness.

Expected Results:  
Render page correctly

Discussed at http://forums.mozillazine.org/viewtopic.php?t=294590
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050718
Firefox/1.0+ ID:2005071806

This is most certainly a problem with the site, not firefox.
If this is only occuring on addons.mozilla.org then it is a problem with the
site which is know about.

Does it occur on any other sites?
Also discussed at

http://forums.mozillazine.org/viewtopic.php?t=295145
http://forums.mozillazine.org/viewtopic.php?t=295323
http://forums.mozillazine.org/viewtopic.php?t=294984

The problem seems to vary by build and browser, suggesting it is not the site.
This is a bit embarrassing - support pages for FF not rendering correctly. :(
Had 1.0.5 installed no probs with rendering or extensions.

Installed 1.0.6 over the top of existing install. Rendering probs of
intermittent nature on Mozilla Update page.

Went back to 1.0.5 everything fine again, until later today (22nd July) when
Mozilla Update went screwy again (have you been tweaking with Update page to try
and correct what is clearly a problem with the browser?)

Next installed British localised build of 1.0.6 and Update page renders fine!!
though don't get too excited, as I've just noticed that since installing 1.0.6
British build "http://www.uknova.com/" doesn't render correctly!!

If it helps, it has...

/* CREATE TABLE reports ( id int(10) unsigned NOT NULL auto_increment, addedby
int(10) unsigned NOT NULL default '0', votedfor int(10) unsigned NOT NULL
default '0', votedfor_xtra int(10) unsigned NOT NULL default '0', type
enum('torrent','user','forum','tc_comment') NOT NULL default 'torrent', reason
varchar(255) NOT NULL default '', dealtby int(10) unsigned NOT NULL default '0',
dealtwith tinyint(1) NOT NULL default '0', PRIMARY KEY (id) ) TYPE=MyISAM; */

near the top of the page?

Other than this, it seems to have all the right graphics, but not necessarily in
the right order!! ;)
(In reply to comment #5)
> Had 1.0.5 installed no probs with rendering or extensions.
> 
> Installed 1.0.6 over the top of existing install. Rendering probs of
> intermittent nature on Mozilla Update page.
> 
> Went back to 1.0.5 everything fine again, until later today (22nd July) when
> Mozilla Update went screwy again (have you been tweaking with Update page to try
> and correct what is clearly a problem with the browser?)
> 
> Next installed British localised build of 1.0.6 and Update page renders fine!!
> though don't get too excited, as I've just noticed that since installing 1.0.6
> British build "http://www.uknova.com/" doesn't render correctly!!
> 
> If it helps, it has...
> 
> /* CREATE TABLE reports ( id int(10) unsigned NOT NULL auto_increment, addedby
> int(10) unsigned NOT NULL default '0', votedfor int(10) unsigned NOT NULL
> default '0', votedfor_xtra int(10) unsigned NOT NULL default '0', type
> enum('torrent','user','forum','tc_comment') NOT NULL default 'torrent', reason
> varchar(255) NOT NULL default '', dealtby int(10) unsigned NOT NULL default '0',
> dealtwith tinyint(1) NOT NULL default '0', PRIMARY KEY (id) ) TYPE=MyISAM; */
> 
> near the top of the page?
> 
> Other than this, it seems to have all the right graphics, but not necessarily in
> the right order!! ;)

Once again, site issue. Firefox doesn't see any server-side language unless it
is accidentally sent by the server (which happens from untested coding on the
site's end).

Right now, umo is working just fine for me (both dp and 1.0.6 zip). It's a site
issue, not a browser issue.
@Aaron Have you followed the steps? Have you read the discussions? You are using
a zip build, which has been tested and seems not to have the issue. Can you
explain how, for some users, IE never has a rendering problem whereas the public
build of Fx seems always to, to one degree or another?

(1) Open page in Fx, public build. Rendered incorrectly.
(2) Immediately open in IE. Rendered correctly.
(3) Immediately open in Fx (cache cleared). Rendered incorrectly.

(I apologize for the mistake on the discussion listings-one of them is
discussing a different issue.)
Public 1.0.6 safe mode rendered http://www.uknova.com incorrectly once for me,
in the manner Hoca reported. I have otherwise been unable to replicate the
uknova problem and cannot tell if it is related in any way.
My experience with the rendering issue.  1st I am using a fresh load of WinXP
Pro/sp2 fully patched.  Firewall off.  I am behind a BEFSX41 router.  The only
other software installed is MS Anti-Spyware v615.  I am using this computer for
testing only.  This system initially had Fx 1.0.4 installed.  I then upgraded to
1.0.5 and then 1.0.6 when it was first released.  Got the public release version
from Mozilla.org.

Not long after installing I noticed the rendering problem on the site: 
https://addons.mozilla.org/extensions/?application=firefox/

After a few posts I noticed others were experiencing this as well.
I accomplished some testing as follows:

I loaded multiple versions of Fx onto this system to test that site out.  I
uninstalled each version completely including deleting appropriate folders and
clearing any registry entries.  And I also rebooted each time just in case.
As of noon July 22nd the rendering issue is still presenting itself.  What I
have determnined is that the said web site appears ok with Fx versions 1.04,
1.05 or a nightly build of 1.0.6 however the public release of 1.0.6(Gecko
20050716) is the only one that appears to have the rendering issue.  The
rendering issues I am seeing are the main page does not render correctly, at
least compared to the other versions.  It seems to change but it is never
totally correct.  A 2nd issue is when going to a page listing extensions I get
overlapping/formatting of text on the left side of the screen.  This one is
random and does not occur every time.  The 3rd issue is when viewing pages
showing extensions there are typically 2 icons listed with each xpi.  One shown
for Install and one shown for the applicable version of FireFox.  Some
extensions show a third icon for For Windows Only.  Ocasionally some or all of
these icons will not be displaying however a placeholder will be shown in place
of the icon.

I have verified these partially on another system without all the uninstalling
of older versions though.   
(In reply to comment #7)
> @Aaron Have you followed the steps? Have you read the discussions? You are using
> a zip build, which has been tested and seems not to have the issue. Can you
> explain how, for some users, IE never has a rendering problem whereas the public
> build of Fx seems always to, to one degree or another?
> 
> (1) Open page in Fx, public build. Rendered incorrectly.
> (2) Immediately open in IE. Rendered correctly.
> (3) Immediately open in Fx (cache cleared). Rendered incorrectly.
> 
> (I apologize for the mistake on the discussion listings-one of them is
> discussing a different issue.)

Just tested with 1.0.6 installed, WFM. I'll say this once again:

It is a site issue. I'm a web dev, so I know what went on here. This bug is
invalid. There were obvious CSS issues with umo at the time that the
mass-updating began. No major changes (if any) were made to the gecko rendering
engine from 1.0.4 to 1.0.6.
(In reply to comment #10)
> Just tested with 1.0.6 installed, WFM. I'll say this once again:
> 
> It is a site issue. I'm a web dev, so I know what went on here. This bug is
> invalid. There were obvious CSS issues with umo at the time that the
> mass-updating began. No major changes (if any) were made to the gecko rendering
> engine from 1.0.4 to 1.0.6.

I would be happy to have this be a site issue, but it is an ongoing problem (not
simply "at the time that the mass-updating began"; users are continuing to
report it on the forums and, fwiw, I personally experience failed rendering 100%
of the time with pb 1.0.6) with characteristics that have yet to be explained by
this, the most obvious answer.

If you can explain "what went on here," why the experience continues, most
importantly why users experience differences between builds and browsers on the
same computer at the same time, that would be much more helpful than (1) WFM and
(2) I am a web dev (who here isn't?), therefore (3) it is a site issue.

I know it's very likely that I (and others) are missing something here. I would
just like to know what it is. Show us how it can be a site issue, and I think
we'll all be happy.
Attached file header diff (obsolete) — 
This shows the header differences between 1.0.6's request to
addons.mozilla.org, and dp2's.

It leads me to believe that the browser sniffing is not properly working,
possibly because of the updated gecko version. Forced-refresh nearly renders
perfectly, with the exception of the RSS images.

Tested with a clean file, and it's time to eat some dirt here. It did NOT
render correctly the first time, but nearly did after a forced refresh.

However, I still think this is a site issue with browser sniffing. Have a look
at the header diff. The lines beginning with < shows the difference to dp2,
which has > on its diff lines. Basically, every line with a < shows what 1.0.6
has, and every line with > shows what dp2 has instead.

Will attach full headers following this.
Attached file full headers — 
First section is dp2, second is 1.0.6.

To clarify on header diff, take notice to the large chunks that dp2 is
receiving that 1.0.6 is not.
Attached file header diff — 
Less confusing diff (thanks gavin).
Attachment #190218 - Attachment is obsolete: true
Ok, reinstalled yet again. Working with

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716
Firefox/1.0.6 ID: 2005071605

I can reliably render the page incorrectly and correctly as follows using User
Agent Switcher 0.6.6.

Incorrect:
(1) Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716
Firefox/1.0.6 (Default)
(2) Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)

Correct:
(1) Mozilla/4.8 [en] (Windows NT 5.1; U)
(2) Opera/8.0 (Windows NT 5.1; U; en)
(3) Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)
Overriding the default UA string renders umo perfectly, so it is for sure not
1.0.6 itself. (go ahead, set general.useragent.override to something else, like
"wget/1.9.1") [Thanks to mook for pointing that out]

Can anyone please change this bug product to Update? This is 100% in my mind a
problem with umo.
And with the British build

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.7.10) Gecko/20050717
Firefox/1.0.6 ID: 2005071718

likewise, I can reliably render the page correctly and incorrectly with User
Agent Switcher.

The difference is that with this build, the default user agent renders the page
correctly.

Incorrect:
(1)Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)

Correct:
(2) Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.7.10) Gecko/20050717
Firefox/1.0.6 (Default)
(3) etc.
Just to confuse matters, though, I will throw in the recent report of one user
on the forums ( http://forums.mozillazine.org/viewtopic.php?t=294590&start=30 ).

"I've also experienced the same problems since updating to 1.0.6.

Thru testing I have been able to "fix" the problem, to replicate it, & "fix" it
again simply by changing Tools>Options>Advanced settings from their default
install configuration then setting them back again."

> What settings did you change?

"Accessibility
no boxes checked

Browsing
first two boxes checked

Software Update
just Firefox checked
----------------------------
Tools>Options>Web Features>Enable JavaScript>Advanced
first three boxes & last box checked"
Component: General → Web Site
Product: Firefox → Update
QA Contact: general → mozilla.update
Attached image Screenshot 1.0.6 — 
Sometimes it displays correctly however.
Attached image Screenshot IE — 
This is how it looks in Internet Explorer.
Assignee: nobody → polvi
And now with the same British build

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.7.10) Gecko/20050717
Firefox/1.0.6 ID: 2005071718

none of the five user agents (default, IE6, Netscape 4.8, Opera 8, Googlebot
2.1) render the RSS icons correctly, but the page is otherwise correct.

If the site code is being changed, it would be helpful to know that for
comparison. Regardless, this is the freakiest browser sniffing I've ever
seen--distinguishing between Fx build numbers!??--if that's what's going on.

Thanks Aaron for moving this forward.
*** Bug 301848 has been marked as a duplicate of this bug. ***
(In reply to comment #21)
> Regardless, this is the freakiest browser sniffing I've ever
> seen--distinguishing between Fx build numbers!??--if that's what'

There is some caching going on, and I think the cache serves up different data
to different user agents.  Maybe for the cache for some of the user agents, the
CSS file was broken.  We need to serve up different content to different
browsers so that when you click an extension, you see the latest version
compatible with your browser rather than some random other browser.
1. So umo is serving up extensions by localization (en-US vs. en-GB) or by build
(and 20050716 is being distinguished from 20050717!??) ?
2. If by build, why list, "Requires: blah blah" ?
3. What if a user is trying to download an extension using a different browser
than he/she wants to install it in? The Fx product page itself offers "other
systems and languages."

Build certainly seems to be involved here-a majority of the reporting users
evidence a difference between 1.0.5 and 1.0.6.

Maybe it's just me, but sniffing for build on umo seems absurd and a great waste
of time.

If a user is going to install a ext, they should (maybe) be able to read and
understand "Requires: blah blah"...

---
As commented above, the following two builds, differing only by localization and
16 vs. 17, render the page differently:

*Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716
Firefox/1.0.6

*Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.7.10) Gecko/20050717
Firefox/1.0.6
Has anyone seen this on anything other than Win32?  

As mentioned above, changing your UA from 1.0.6 to 1.0.5 makes it work.  

This is a highly visible issue.
Severity: normal → critical
Summary: Some stylesheets sometimes inaccessible in 1.0.6 → Some stylesheets sometimes inaccessible in 1.0.6 (UA detection/cache)
(In reply to comment #24)
> 1. So umo is serving up extensions by localization (en-US vs. en-GB) or by build
> (and 20050716 is being distinguished from 20050717!??) ?
Looks like both, based on your localization test.

> 2. If by build, why list, "Requires: blah blah" ?
I don't like the way we do it either, and we should be changing that for UMO2.0.
 There are ways to view incompatible extensions, in which case it's good to
display this.

> 3. What if a user is trying to download an extension using a different browser
> than he/she wants to install it in? The Fx product page itself offers "other
> systems and languages."
That's a problem right now with the way we do it.  It probably won't be fixed
until UMO 2.0.

> Build certainly seems to be involved here-a majority of the reporting users
> evidence a difference between 1.0.5 and 1.0.6.
> 
> Maybe it's just me, but sniffing for build on umo seems absurd and a great waste
> of time.
Patches are welcome.  Make sure the normal case of (user visits site, and wants
to get latest compatible version without knowing what his browser is) works.  

> If a user is going to install a ext, they should (maybe) be able to read and
> understand "Requires: blah blah"...
I'd rather not expect the user knows his version number.  Way too many people
used to run "Windows 97" for me to believe we won't have the same problem. 
Having "Requires 1.0+" mean Deer Park (alphas of 1.1/1.5) instead of 1.0.x is
confusing even to people who know what version they're using.
Thx ... Workaround is valid for 1.0.6 : about:config, NEW, String,
general.useragent.override,fakeentry and MOZILLA UPDATE now renders completely.
The sniffing for the UA that is causing this problem is probably the proxy
cache.  We don't have UA logic for stylesheets at the application level.

UA sniffing at the app level is a different bug.
(In reply to comment #26)
> I'd rather not expect the user knows his version number.  Way too many people
> used to run "Windows 97" for me to believe we won't have the same problem. 
> Having "Requires 1.0+" mean Deer Park (alphas of 1.1/1.5) instead of 1.0.x is
> confusing even to people who know what version they're using.

Ok, that makes sense. I *have* been rejected by an extension info page for
incompatibility in the past and remember it because it was so annoying-I knew
the site was incorrect. So we'll look forward to umo 2.

In this case, though, it's not 1.0.5 vs. 1.0.6 we're really talking about (i.e.,
version). Users have reported here differences between same versions, same
localization, different build. See the rather thorough test described in comment
#9. So we're talking about somebody splitting hairs, something like described in
my US vs GB: 20050716 vs 20050717. If there's sniffing going on, it ought to be
for the version number, not the build.

Sniffing was perhaps tied for the most obvious answer to this problem, but it
seemed so absurd when looking at what the site was making a distinction between:
build, not version. Ergo, file it under Firefox. I'm glad to be corrected.
I feel pretty confident that this is a server issue. We are running patched
httpd 2.1.6 for this... and it does odd things like seg fault. 

Working with apache devs for a solution....
Assignee: polvi → justdave
I feel pretty confident that this is a server issue. We are running patched
httpd 2.1.6 for this... and it does odd things like seg fault. 

Working with apache devs for a solution....
Assignee: justdave → justdave
https://addons.mozilla.org/css/base/template.css
This css and others as well are sometimes empty when loaded from Firefox, so the
pages doesn't reder well. When you load this css from IE, you will see that
stylesheets are there.
*** Bug 301795 has been marked as a duplicate of this bug. ***
This is most likely a bug in the 304 revalidation in httpd.

Work Around patch:

http://people.apache.org/~pquerna/304.patch
* Mozilla/5.0 (Windows; U; Windows NT 5.1; it-IT; rv:1.7.10) Gecko/20050717
Firefox/1.0.6 renders UMO in a wrong way

* Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8b4) Gecko/20050724
Firefox/1.0+ renders UMO in the right way

After reading all the above comment IMHO the problem isn't on the server side
but it's due to Firefox.
*** Bug 302008 has been marked as a duplicate of this bug. ***
its a bloody server side caching bug.


If you fetch certian urls with certian user-agents, they will come back with a
length of 0, causing these rendering bugs.
I've been having non-stylesheet issues, too
PLEASE stop commenting in this bug if you are not providing any helpful information.

Yes, we know it's a server-side issue. There's no need for confirmation about
what builds are being affected, or whether or not it's even firefox. The problem
is known, a solution seems to be known, so unless you have any helpful comments
to add, please don't add any! Thank you.
*** Bug 302106 has been marked as a duplicate of this bug. ***
(In reply to comment #34)
> This is most likely a bug in the 304 revalidation in httpd.
> 
> Work Around patch:
> 
> http://people.apache.org/~pquerna/304.patch

This patch has been deployed on all three proxies.
Almost, kinda fixed.

Running 1.0.4 on Windows XP and tried going to 
https://pfs.mozilla.org/plugins/.  Had to control refresh to get the CSS to 
download.  Everything was downloading correctly, except the Mac 
(https://pfs.mozilla.org/images/macosx_icon.png/) and Windows 
(https://pfs.mozilla.org/images/windows_icon.png) icons on the page.  The Tux 
icon (https://pfs.mozilla.org/images/linux_icon.png) comes through fine.  I 
tried typing in the URL directly into the address bar for the icons, and 
nothing will come up for the Mac and Windows ones, no error or otherwise.  The 
page just remains the same after loading.  Going into IE, everything comes 
through fine, icons and all.

So, I cleaned my cache, renavigated to the page, and it came up worse.  Looked 
like even less CSS was coming through.  The whole top navigation was all text, 
tho I could see the table like formatting of the various plugins.

So, I cleaned my cache again, renavigated to the site, and I'm back to where I 
was before, the page rendering fine except for the windows and mac images not 
coming through.
*** Bug 302179 has been marked as a duplicate of this bug. ***
*** Bug 302140 has been marked as a duplicate of this bug. ***
It has occurred here on the deer park alpha 1 build in linux, site css doesn't
appear to get parsed at all.


Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b2) Gecko/20050531 Firefox/1.0+

system:
2.6.11-1.14.inotify.0.22_FC3
kde 3.4
Dave -

Now that you've moved servers, this is resolved, right?
should be, yes.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
*** Bug 294752 has been marked as a duplicate of this bug. ***
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: