Closed Bug 159494 Opened 22 years ago Closed 22 years ago

support.microsoft.com - Microsoft Knowledge Base articles overlapping text

Categories

(Tech Evangelism Graveyard :: English US, defect, P3)

Product:
Tech Evangelism Graveyard
Component:
English US
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: kepa_online, Assigned: susiew)

References

(
URL
)

Details

(Keywords: testcase, Whiteboard: mostfreq READ COMMENT 92 BEFORE POSTING)

Attachments

(5 files)

reduced testcase
2.45 KB, text/html
Details
Rendering with Internet Explorer 5.01
2.64 KB, image/png
Details
Testcase #2
444 bytes, text/html
Details
MS page for Mozilla displays in IE6
163.85 KB, image/jpeg
Details
MS page for Mozilla displays in IE6
163.85 KB, image/jpeg
Details 
The URL http://support.microsoft.com/default.aspx?scid=kb;EN-US;q317949 does not
get rendered properly in either mozilla 1.0 or 1.1 beta.

Below the text "Socket Sharing Creates Data Loss When Listen and Accept Occur on
Different Processes", the following text is overlayed when it shouldn't be (it
is also displayed in green!):

<quote>
"
The information in this article applies to:

* Microsoft Windows XP Home Edition
* Microsoft Windows XP Professional
"
</quote>

This occurred on Windows XP as a client O/S.  The page looked fine in IE.
*** Bug 159495 has been marked as a duplicate of this bug. ***
the page shows up roughly the same in my msie5 and mozilla 1.1b
(green and overlapping list items in msie5 and moz1.1b)

the list items are green because of the following code in
KBArticle.css:

  .KBPUBV1 LI { margin-left: -0.5em; margin-bottom: 0; }
  .KBPUBV1 UL LI { line-height: 120%; margin-bottom: -1%; margin-left: -0.3em;
color: Green; }
  .KBPUBV1 UL UL LI { font-size: 90%; }
  .KBPUBV1 UL UL { font-size: 90%; margin-bottom: 1%; margin-top: 0em;}
  .KBPUBV1 OL LI { line-height: 120%; margin-bottom: -1%; margin-left: -0.2em;
color: Red; }

  .KBPUBV1 .appliesto UL {  margin-top: -1em; }
  .KBPUBV1 .appliesto UL UL {  margin-top: -0.2em; margin-bottom: -0.1em; }
  .KBPUBV1 .appliesto UL LI { margin-top: 0em; margin-bottom: 0em;  margin-left:
-0.5em;}

note that both .KBPUBV1 *** and .KBPUBV1 .appliesto *** rules
apply to the list item.

I suspect that the overlapping is due to the negative margins.
Attached file reduced testcase — 

    
    

    
  
*** Bug 159555 has been marked as a duplicate of this bug. ***
Status: UNCONFIRMED → NEW
Ever confirmed: true

    
    

    
  
*** Bug 159848 has been marked as a duplicate of this bug. ***

    
    

    
  
Again, isn't it evangelism issue?
Alias: microsoft
OS: Windows XP → All

    
    

    
  
From dup bug 159555: this bug also happens in IE 5 for Mac, so it's at least
partly a site problem.  Why is this bug suddenly getting many dups -- did the
site change or did Mozilla change?

    
    

    
  
I beleive they revamped their site. I remember seeing a message saying something
like "Welcome to a renewed version of our side, hope you'll enjoy it, etc" but I
can't find where.


    
  
Priority: -- → P3

    
    

    
  
I think this should be Tech Evangelism bug. Change back
to browser/layout if you disagree.
Assignee: attinasi → doron
Component: Layout → US General
Product: Browser → Tech Evangelism
QA Contact: petersen → zach
Version: other → unspecified

    
    

    
  
*** Bug 160558 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 160684 has been marked as a duplicate of this bug. ***

    
    

    
  
This may be a tactic by MS to invalidate Mozilla. Please see my comments under
bug 160684

    
    

    
  
*** Bug 160120 has been marked as a duplicate of this bug. ***

    
    

    
  
Note that this problem affects *every article* in the Knowledge Base, not just
the single article mentioned.  See for example:
http://support.microsoft.com/default.aspx?scid=kb;[LN];Q305098

Could someone change the summary text?

I do not get the green text problem mentioned in the original report - has the
CSS been updated since this problem was reported?

I think the basic problem is caused by the negative margin-top rule on the UL
element.  That is:
  .KBPUBV1 .appliesto UL {  margin-top: -1em; }

The same problem occurs slightly with IE 5.01 (see the following attachment from
the URL referenced earlier).  To some extent, it is an evang issue, but I'm
confused as to why it does not cause problems for IE5.5/6.

Can someone with IE5.5 or 6 produce a reduced testcase so that we can check
whether this is an evang issue?

    
  
Summary: Microsoft Knowledge Base Page for Apache Issue Messed Up → Microsoft Knowledge Base articles overlapping text
Hardware: PC → All
Summary: Microsoft Knowledge Base articles overlapping text → support.microsoft.com - Microsoft Knowledge Base articles overlapping text

    
    

    
  
*** Bug 160807 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 160996 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 161264 has been marked as a duplicate of this bug. ***

    
    

    
  
Note that the site is using useragent sniffing to serve very different CSS 
source to MSIE and Mozilla (and the HTML source is *slightly* different, too).  
That's why it works fine in MSIE, not because of browser compatibility issues.  
It appears to serve one set of source to MSIE (possibly different for different 
versions?), and one set for everything else (including Mozilla).

If you override your useragent so that you pretend to be MSIE, the main content 
of the page renders fine, although the pulldown menus are screwed up.

If you get MSIE (5.5) to load the source that is served to Mozilla, it exhibits 
the same problems as Mozilla does.

The CSS is complex enough that I couldn't identify exactly what part is causing 
the problems, but things like the following section of kbarticle.css look 
suspicious:

Served if UA is unrecognised (including Mozilla):
.KBPUBV1 .appliesto UL {  margin-top: -1em; }
.KBPUBV1 .appliesto UL UL {  margin-top: -0.2em; margin-bottom: -0.1em; }
.KBPUBV1 .appliesto UL LI { margin-top: 0em; margin-bottom: 0em;  margin-left: -
0.5em;}

Served if UA is "Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)":
.KBPUBV1 .appliesto UL {  margin-top: 0.5em;}
.KBPUBV1 .appliesto UL UL { font-size: 97%; margin-top: 0em; margin-bottom: 
0.5em; }
.KBPUBV1 .appliesto UL LI { margin-top: 0em; margin-bottom: 0em; }

Specifically, the negative margin-top on the UL element looks like it might be 
the problem we're seeing.

This really is an evang issue, not a CSS one.

    
    

    
  
I am no html expert, but 
is negative margin top semantically allowed?
If so, then it is MS that should be blamed to
service css file which would produced illegible
layout.

But if, say, negative margin top is not
likely to be allowed in the sense that
the standard says nothing about it, but
our "common sense" would preclude such a value,
then we probably check it and pretend that the margin
is, at worst, zero.

That is, we should stick to the practice of
defensive programming in the face of stupid user data error.
(Maybe a error message to a suitable place (stderr on
unix, or some debug window) would be nice if
we take such defensive action.

(By the way, someone's mention that
the all the kb articles are affected probably is true.
I could not read some KB articles using mozilla at all.
There are probably character set recognition issues as well.
I wasn't quite sure where the problem lies, and
the URL I reported in q161264 was
a minor annoyance in comparison to some of the
pages totally illegible.
I thought we should fix minor annoyance first to
see exactly where the cause of the problem is likely to 
be.

I think we now know that the CSS is partly to blame.
It is a start.

BTW, netscape 4.77 under linux can render the page
without problem. (Maybe because it doesn't support CSS?)


    
    

    
  
There is nothing wrong with a negative margin-top value.  Although it is 
slightly bizarre, it's perfectly legal.  I don't think there's much we can do 
to fix this directly, as we're rendering exactly what is asked of us.

NN4 can't really be considered to support CSS at all, so I'm not too surprised 
that it renders the page ok.

If you are experiencing other problems with some of the knowledgebase articles 
(i.e., something other than overlapping text), please report them in a new bug.

    
    

    
  
*** Bug 161769 has been marked as a duplicate of this bug. ***

    
    

    
  

      
      
      
      

        Attached file
          
        Testcase #2
        — 
      

    


  

    
    

    
  
A 1% margin resulting in half a line-height does not seem correct to me.
Reassigning to Layout for further triage.
Assignee: doron → attinasi
Component: US General → Layout
Keywords: testcase
Product: Tech Evangelism → Browser
QA Contact: zach → petersen
Version: unspecified → other

    
    

    
  
The margin behaviour seems correct, as far as I can tell...

http://www.w3.org/TR/2002/WD-CSS21-20020802/box.html#propdef-margin-bottom
"The percentage is calculated with respect to the width of the generated box's
containing block. This is true for 'margin-top' and 'margin-bottom', except in
the page context, where percentages refer to page box height."

When I remove the negative margin in your testcase the box expands by ~23px. At
my resolution 1% would be just less than 8px. Multiply that by the three <li>
elements that the negative margin affects and it seems about right.

    
    

    
  
Sorry this is getting a little off the technical angle.

From the URL:

http://www.w3.org/TR/2002/WD-CSS21-20020802/box.html#value-def-margin-width

"Negative values for margin properties are allowed, but there may be
implementation-specific limits. "


OK, so it is allowed.

(But, then since the URL also admits that
there are implementation-specific limits, maybe
the mozilla developers can write code to 
ignore negative margin and pretend it is
zero in the spirit of defensive programming against
stupid/sinister user input errors.)

The big question here is WHY does Microsoft serve
ccs with such parameters known or
acknowledged to have implementation-specific limits
some cases.
I can't see a good reason here.

To give the benefit of doubt, MS might
simply have screwed up by not checking
the less often used css contents.
(But then I don't quite understand WHY
they need to differentiate browsers to serve
the pages.)

But a cynic might think this is a way to
discourage the use of Mozilla on Windows platform.
And frankly speaking, it is in effect.

I noticed the recent post mentioned tech evangelism
angle for solving this problem of accessing MS knowledge base.
(Presumably to ask MS to fix this problem.)
I have no idea if such asking has any immediate feedback.


Maybe someone reading this and living USA
might want to write to the attorneys of
the still litigating remaining states
in the anti-trust case against MS and explain
the potential predatory action still practiced
to crash the competition, namely Mozilla in this case.
(Or write to the reporters of the favorite
trade journals, etc..)

Once MS lawyers hear of the problem, they
will literally FORCE the web admin of
the knowledge base to solve the problem
IMMEDIATELY, I think.

If I know the contacts, I might write something
myself, but
people living in USA probably have better idea
who to contact, etc..

Just a thought.

PS: About a few pages totally illegible in my 
mozilla browser that I mentioned, I tried to access the
problematic pages (about the disk size limit of win98se fdisk.exe) again just to
make sure the problem still remains
before filing a separate bug case.

To my surprise, the page is now rendered correctly.
I tried a few character coding setting, and saw a 
different behavior than I saw the other day (only about
a week ago or so.)
So as some have reported the CSS and the page contents
may have been frequently updated in the last few weeks.


    
    

    
  
This is evang, not layout.  We're doing the right thing here, just not what was
intended.  chiaki, if you think that this is a Microsoft anti-Mozilla thing,
then feel free to discuss it in the newsgroups, but not in this bug.

hyatt's comment in duplicate bug 160807 comment 4 is relevant:
> MSIE has known bugs with negative margins.  Percentage margins (even vertical
> ones) are percentages of the width of the containing block -- notice that as
> you narrow the browser window, the spacing becomes less bad.

It also explains why they are serving different markup and CSS.  As Microsoft
fix the bugs in their implementation, and transition to a standards-based way of
doing things (DOM, CSS) they still need to support the older browsers.

The problem here (I suspect) is that they simply haven't updated their
browser-sniffing code to deal with Mozilla, so it's running as 'default'. 
Unfortunately the default case is probably IE4.  They probably have not even
tested the markup they are producing using Mozilla.

Note that as of this writing, things seem to be changing yet again at
support.microsoft.com.  Using Mozilla, I currently get two copies of each
knowledgebase article side-by-side in a two-column layout, although the
rendering of each appears correct (actually, it appears to be unstyled).

    
    

    
  
Aha, now I got it. It's 1% of the WIDTH of the containing block and not the
height as I first thought.

Back to Evang.
Assignee: attinasi → susiew
Component: Layout → US General
Product: Browser → Tech Evangelism
QA Contact: petersen → zach
Version: other → unspecified

    
    

    
  
accepting
Status: NEW → ASSIGNED

    
    

    
  
In case it helps, when Mozilla loads an article, the following CSS file is used:
  http://support.microsoft.com/common/css/GN/en-us/down-other/KBArticle.css

When MSIE loads it (5.5sp2 here), the following version is used:
  http://support.microsoft.com/common/css/GN/en-us/standard/KBArticle.css

This second one has "margin-bottom: 0em" for the problem items, rather than
-1em, which is causing problems.  I wonder which legacy browser would need the
negative margins to display correctly?

    
    

    
  
*** Bug 162685 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 163170 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 163219 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 163385 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 164262 has been marked as a duplicate of this bug. ***

    
  
Whiteboard: mostfreq

    
    

    
  
*** Bug 164536 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 165443 has been marked as a duplicate of this bug. ***

    
    

    
  
Does anyone mind if I fill out a feed back summary with microsoft regarding this
issue?

    
    

    
  
As already stated this KB sites use bad browser sniffing. If you mask Mozilla as
Netscape6 the pages render correctly! They don't detect other Gecko based
browsers. Here and on other sites (Bug 105731) they support Netscape 6.x (quit
sure not 7.0 because of the changed UA).

Try it with these preferences
user_pref("general.useragent.vendor", "Netscape6");
user_pref("general.useragent.vendorSub", "6.5");

MS should be asked to review their browser detection.

    
    

    
  
> Does anyone mind if I fill out a feed back summary with microsoft regarding
> this issue?

Please do so.

    
    

    
  
Feed back summary was submitted today, I await their response.

    
    

    
  
*** Bug 165670 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 165677 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 165882 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 166729 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 167106 has been marked as a duplicate of this bug. ***

    
    

    
  
Since Mozilla has the View/Use Style menu, is it possible to create an
alternative (user) style sheet that would show up and can be applied to pages
like this (or to disable CSS altogether)? It would at least be a workaround
until Microsoft fixes their CSS. Disabling CSS or blocking
http://support.microsoft.com/common/css/GN/ could also help.

    
    

    
  
Dan Mellem said:
>Disabling CSS or blocking
>http://support.microsoft.com/common/css/GN/ could also help.

With this hint, I experimented with a filtering proxy so
that support.microsoft.com/common/css/GN (and ULRs below it)
is blocked.
[I was not sure what would happen if a stylesheet CSS is
not available. So this experiment.]

Voila. Now I can read the page without the nagging problem.

So either make it easy to switch one's identiy from
a pull down menu, i.e., not editing the preference
as was suggested in a previous post, but make it doable with
pull down men and a dialog.:
>Try it with these preferences
>user_pref("general.useragent.vendor", "Netscape6");
>user_pref("general.useragent.vendorSub", "6.5");

or make it easy to block a URL for css (and for that
matter any pages below the directory a la many
blocking/filtering proxy a la junkbuster, etc.???)

I know the latter would make mozilla a bloatware, but
when a large software vendor with many user base
won't fix the problems discussed here (and
I suspect that such errors may occur from time
to time, human nature being what it is. I won't be
surprised if someone at companies like Sun, IBM, HP, etc.. may make similar
errors. Hopefully such mistakes
are corrected soon.),
it may be wise to build such counter-measures/work-around
in Mozilla in advance.

I know the approaches I mention here are kludges, 
but a kludge is better
than not being able to read an important page with
preferred browser...

At least, we already have image blocker (image manager
under tools menu) in
mozilla, and so the code for selectively blocking the css
is already there, I suspect.









    
    

    
  
See bug 32372

    
    

    
  
*** Bug 167534 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 167609 has been marked as a duplicate of this bug. ***

    
  
Blocks: MS

    
    

    
  
*** Bug 167189 has been marked as a duplicate of this bug. ***

    
    

    
  
The issue is now filed at Microsoft. As with all websites, hearing from
customers encountering this problem will increase its priority in getting fixed,
so feel free to email them feedback (no need to give them the technical solution).

    
    

    
  
*** Bug 168222 has been marked as a duplicate of this bug. ***

    
    

    
  
Regarding comment #48 a pulldown exists for changing ua strings. See
http://uabar.mozdev.org/source.html
It's a great tool. Click Install xpi here to install it.



    
    

    
  
*** Bug 168542 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 168826 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 168661 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 169007 has been marked as a duplicate of this bug. ***

    
    

    
  
I've found another workaround to view the content on these pages - use print
preview. While the page isn't perfect, the text doesn't overlap nearly as bad so
it's readable.

    
    

    
  
Dan, you have the same effect if you resize your browser window. Reduce the
*width* (and not the height as one might think) and most of the overlapping text
will be visible (that what the preview does actually).

    
    

    
  
As a workaround to view the pages, I put together a simple bookmarklet.  It
might be useful to some people while we wait for MS to fix their website:

javascript:(function(){var nodelist=document.getElementsByTagName("LINK");var
length=nodelist.length;for(var i=0;i<length;i++){var
el=nodelist[i];if(el.rel=='stylesheet'&&el.href.search('/down-other/KBArticle.css')>-1){el.href=el.href.replace('/down-other/','/standard/');}}})();

It will point the stylesheet link for KBArticle.css to the version in the
standard/ directory, rather than the down-other/ directory (which seems to be
where it seems to point mozilla browsers).  This is enough to make the page
readable.  Changing the other stylesheet links make the page less readable, as
they are designed to work with the HTML sent to IE (everything works fine if you
pretend to be IE, as has already been pointed out).

    
    

    
  
James: *Excellent* bookmarklet. Thanks a lot!

    
    

    
  
*** Bug 169281 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 169673 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 170046 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 170894 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 169605 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 170920 has been marked as a duplicate of this bug. ***

    
    

    
  
Another page that displays improperly (not M$)
MySQL adding transaction support to open-source database
http://www.infoworld.com/articles/hn/xml/02/09/20/020920hnmysql.xml


    
    

    
  
This is an *evangelism* bug. 

Please do not mix bug reports for different websites into 1 evangelism bug, as
you would with a browser layout issue. Please file a separate bug. Thanks.

    
    

    
  
*** Bug 171415 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 171456 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 171541 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 171709 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 171723 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 172578 has been marked as a duplicate of this bug. ***

    
    

    
  
As I menioned in #26,
we can set internal implementation specific
limits to the negative margin value .

>From the URL:
>
>http://www.w3.org/TR/2002/WD-CSS21-20020802/box.html#value-d>ef-margin-width
>
>"Negative values for margin properties are allowed, but >there may be
>implementation-specific limits. "

>OK, so it is allowed.

>(But, then since the URL also admits that
>there are implementation-specific limits, maybe
>the mozilla developers can write code to 
>ignore negative margin and pretend it is
>zero in the spirit of defensive programming against
>stupid/sinister user input errors.)

We probably just should allow margin value down to -1
and anything below this value should
be handled as -1.

Trying to block CSS is tricky as mentioned
in the comment #49.

The Java applet approach is also a kludge, I think.
Although we know that this works for MS site now, 
I stop to ponder
phow a distributor or sysadmin tells their customers
a screwed up image is caused by bad CSS with negative margin  and disable it by
using JavaApplet? Yes, we know this works
for MS now, but there can be many more in the future.

So my conclusion is we should simply set the arbitrary
implementation-specific limit value for the negative
margin to minus one (0 probably is better IMHO) and
forget about blocking CSS and/or user-level kludges.

Then we can do away with these many bug reports as well.
(The sheer number of bug reports
also tells us that figuring out the
cause of mis-rendering problem in similar cases would
be difficult on user/sysadmin side indeed, doesn't it?)

BTW, what happened to evangelazing MS so that
they would use PC CSS?



    
    

    
  
*** Bug 172992 has been marked as a duplicate of this bug. ***

    
    

    
  
> We probably just should allow margin value down to -1
> and anything below this value should
> be handled as -1.

-1 what? Pixels, ems, percent?  The problem here is that we're getting passed a 
margin-top of -1em, so that wouldn't solve the problem anyway.

We should *not* put an arbitary implementation limit on this property just to 
fix *one site*.  There are good reasons to use negative margins (especially to 
work around some IE browser bugs).

> Then we can do away with these many bug reports as well.

... and get flooded with another set.  Just because we *can* do something 
doesn't mean that we *should*.

> BTW, what happened to evangelazing MS so that they would use PC CSS?

I guess you mean 'correct' CSS.  Good question.
This bug is assigned to susiew - perhaps she could comment on the current 
status?

    
    

    
  
I submitted a feedback summary with microsoft but have yet to hear back from them.

    
    

    
  
I am trying to get the latest status.

    
  
Blocks: majorbugs

    
    

    
  
The KB pages render properly when Mozilla UA spoofs Netscape 6 (or 6.2) but
incorrectly when it spoofs Netscape 7! It seems the UA detection is even worse
than we thought :-(

    
    

    
  
*** Bug 174598 has been marked as a duplicate of this bug. ***

    
    

    
  
I'm seeing the same effect on <http://www.catswithhands.com/>
the scrolling banner about 1in below the top "Welcome to the Cats With Hands
website" also has text larger than the banner height.  Is this the same bug?

    
    

    
  
This is an evangelism issue - not a Mozilla bug.  By definition, only one site 
can be followed per evangelism bug.  So, no, it's not the same. Open a new 
evangelism bug for the "catswithhands" site.  (You might want to refer back to 
this bug, however, in your comments so as to easily determine what that site's 
problem is.)

    
    

    
  
I think it is not a problem of different CSS for IE or other browser.
The sites: http://support.microsoft.com/default.aspx?scid=kb;EN-US;q317949
works fine with Linux Konquer and OPERA 6.0 !!

AND: it is not evangelism issue - its a Mozi bug to display the bigest Technical
Website. Microsoft dont change this for Netscape, Mozilla or other browser.
If you get an anwser for this from MS it is like this: "Sorry, this site is
optimize for IExplorer!"
If Mozi dont fix this - user can only use IE or Opera for this site.

    
    

    
  
in response to comment 87, no this is not a Mozilla bug.  The site uses user
agent sniffing, and will deliver one of two designs (labeled "down-other" or
"standard").  It sends the "down-other" design to mozilla, and the "standard"
one to IE.  The "down-other" design does not render correctly in mozilla, while
the "standard" design renders correctly.

Therefore, it is an evangelism issue (to try and get Microsoft to fix its user
agent sniffing to support Mozilla).

    
    

    
  
*** Bug 176962 has been marked as a duplicate of this bug. ***

    
    

    
  
I don't understand all these cute terms used to try to cover egomania on the
part of Moz designers and aficionados.  Whatever you guys think you're game is,
you're out of your gourds to figure that -- where AOL/Netscape has made a
browser (4.x) that gives a perfectly usable Web page from whatever you wish to
label a screwup in page design by MS, AOL's archenemy -- MS and the rest of the
world are going drop everything and design their Web pages and everything else
in such ways that they will always play perfectly in Moz, something thrown
together by a bunch of carried-away brilliant egomaniacs, which keeps getting
more and more problems that Netscape 4.x never had and very few advantages over
it.  What's the point of this whole effort anyhow???  These pages are nearly
useless as rendered by Moz, while they have no problems whatsoever when rendered
by Netscape 4.79 and apparently most other common browsers.  If Netscape could
build a very decent browser that perfectly displays MS's pages, without
clobbering MS in court, is the way to go for a bunch of self-righteous wizards,
without even a company to pay for lawyers, that of pretending what they have is
GODzilla, not Mozilla, and refusing to leave in their Netscape-originated
browser whatever allowed MS's important pages to be very useful -- and instead,
displaying on their browser unreadable overprinted garbage and shouting that the
problem is not BUGS in THEIR kluged-up remnants of what was handed them?  YOU
GOT BUGS!  Get busy and swat them!  You should back way up and head off in a
different direction.  Shut down BUGzilla, which a gross waste of effort and
talent, and use a few dozen of your designers part time to use your work product
on the real world for an hour a day.  You'll end up with something that deals
with the real world much faster that way.

Ray

    
    

    
  
Just read additional comments from raych@znet.com and would not get quite so
emotional, but generally agree with the sentiments expressed. I started using
Mozilla because scripting problems in Internet Explorer 6, supplied with my new
laptop, prevented me printing web pages. 'Luckily' my computer magazine's cover
disk this month included a copy of Mozilla so I installed that. Great, until I
ran into this overlapping text problem with Microsoft and tried to report the
bug. Slightly relieved to find I was not alone but quickly decided that with
Mozilla I was way out of my depth so, in desperation, downloaded Netscape, which
is working well. I started in 'electronic data processing' only 40 years ago and
have run the full gamut from mainframes to micros and office automation but
obviously have learned nothing in that time - other than the fact that one
spends more time fixing the hardware and software than doing any useful work,
but, as raych@znet.com implies, when there is a good alternative available, who
needs Mozilla? My magazine editor will be left in no doubt as to my feelings
about distributing bug-ridden software to an unsuspecting readership. 

    
    

    
  
For the benefit of those unable to understand why we can't 'fix' this bug:

Microsoft's site contains logic on the server-side that boils down to (roughly):
   IF browser is mozilla THEN make text overlap.

Now, it's not quite that simple, but the problem is:
a. We don't want to change what the browser reports itself as (for example, by
pretending to be IE by default).
b. We cannot tell that 'make text overlap' isn't what the author wanted.  If we
disable the functionality that's causing the text to overlap, we'll break a ton
of other sites.

Microsoft's site is deliberately asking the browser to do something that looks
bad, and we do it.

If you visit with IE, they don't ask the browser to overlap the text.  If you
visit with Mozilla set up to pretend to be IE, everything looks fine as well.

It is up to Microsoft to fix this bug, and there is *no* realistic way for us to
change anything in Mozilla to fix it.  Netscape have staff assigned to this bug,
but all they (or anyone) can do is to chase Microsoft to fix their problem.
Whiteboard: mostfreq → mostfreq READ COMMENT 92 BEFORE POSTING

    
    

    
  
*** Bug 177087 has been marked as a duplicate of this bug. ***

    
    

    
  
Here's both a proof that it's Microsoft's fault and a workaround for those using
Mozilla.

Download Proxomitron (for Windows, http://proxomitron.cjb.net/, I'm sure there's
plenty of equivalents for other operating systems - I also show a second
workaround at the bottom).  Set up a Header rule like this:

HTTP Header: User-Agent:IE
URL Match: *microsoft.com*
Header Value Match: *
Replacement text: Mozilla/4.0 (compatible; MSIE 6.0; Bite me Microsoft)

Make sure the box is checked for "Out" and apply the changes.

Set Mozilla to use Proxomitron as a proxy.  Now everytime you use Mozilla to go
to an MS site it will automatically switch the agent to IE and you'll get the
"right" version of the site.  Proxomitron does a lot of other stuff so if you
just want the header change, uncheck all the other rules and uncheck all the
rules under the Web page button.


This is really the better way to handle badly written pages that you need to use
but can't get corrected by the author.

Oh, I also said this was a proof about how MS got it wrong.  You can show this
by changing the above line to:
Replacement text: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2b)
Gecko/20021016

This is the one Mozilla uses (1.2b specifically).  Now point IE to use
Proxomitron as a proxy.  Load the Microsoft webpage.  You'll see that it chokes
on the bad margins just like Mozilla does.


If you don't want to install something like Proxomitron, download the
Preferences Toolbar from http://www.xulplanet.com/downloads/prefbar/
This lets you change your User Agent on the fly.  You can change it to IE when
you browse the MS pages and change it back afterwards.

    
    

    
  
If Microsoft will not fix this, I think this should be reported to the antitrust
people in Washington as another example of driving competing browsers out of the
market.

They might get action where we cannot.

But thanks for the neat toolbar link!

    
    

    
  
*** Bug 177385 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 177497 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 177776 has been marked as a duplicate of this bug. ***

    
    

    
  
Re comment #94 *please* do not change your UA string to be IE. In doing so you
are perpetuating the lack of Mozilla support on the net by proving that there
are little to no visitors with Mozilla UA strings. This is what causes sites
like Microsoft and others to drag their feet in making Mozilla compatibility a
priority.

Instead use this, or a similar one that contains Netscape 6 in the UA string: 
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011022
Netscape6/6.2

This is my favorite ua string switching tool: http://uabar.mozdev.org/source.html



    
    

    
  
Here is a web form for complaining about this bug:
http://register.microsoft.com/mswish/suggestion.asp

    
    

    
  
*** Bug 178568 has been marked as a duplicate of this bug. ***

    
    

    
  
Microsoft has looked at the issue but I don't yet have an ETA on when it will be
fixed. I will keep trying, but as I mentioned before getting Gecko traffic and
customer complaints to them will be the real incentive for them to make this fix
a high priority (as is the case with other sites as well). I feel your pain...

    
    

    
  
*** Bug 178652 has been marked as a duplicate of this bug. ***

    
    

    
  
I used the form at http://register.microsoft.com/contactus30/feedback.asp

Although I spent quite a while phrasing the problem in 'plain english', the 
response I got was a generic 'we need more information' form letter (no more 
specific than that).  I was unimpressed.

susie - do you know (or can you find out) where the best place to send feedback 
would be, so we can make sure it gets to the people who need to see it?

Just an observation on your previous comment - Microsoft's knowledgebase isn't 
getting much Gecko traffic *because* their site doesn't display properly.  I'm 
hardly going to visit it with Mozilla every time I need to look something up, 
given that I know it's unreadable.

Now, complaints are another matter, of course; we can send lots of those...

    
    

    
  
Yes I'll try to find out.
Please see comment #99

Changing your user agent string to Netscape 6 will not hurt your user experience
on other sites and in fact may even improve it as one of our most common
evangelism problems is sites detecting Netscpae 6 instead of just Netscape or
just Gecko. So while this is a slight inconvenience, it does fix the problem on
this site for you temporarily so you don't have to use another browser. 

    
    

    
  
*** Bug 178857 has been marked as a duplicate of this bug. ***

    
    

    
  
I sent the following to http://register.microsoft.com/mswish/suggestion.asp
**
The Knowledge Base article pages
(http://support.microsoft.com/default.aspx?scid=kb;en-us;Q326489 for example)
are presenting a somewhat misconfigured stylesheet to the Mozilla browser.
Please correct this. Mozilla is fully capable of using the same stylesheet that
IE 6 uses for these pages. See
http://bugzilla.mozilla.org/show_bug.cgi?id=159494 for more information
regarding this issue.
**
...and got the following response:
**
Hello,
 
I understand you are having difficulties with Mozilla. This product is not a
Microsoft product, so we may be unable to assist you with this. Since our
Support Professionals are not trained to troubleshoot issues with Mozilla, we
feel that your question would be best addressed by Mozilla's technical support.
 
Thank you for contacting Microsoft.
 
Ruth
Microsoft Online Customer Representative 
**
Hmm, maybe I should try http://register.microsoft.com/contactus30/feedback.asp
too... :)

    
    

    
  
Put the following in your userContent.css and it will correct the problem.  This
will only work until MS changes their CSS, though.  It was originally posted on
MozillaZine for KBPUBV1, but it appears MS has moved on to KBPUBV2.  

( over-riding
http://support.microsoft.com/common/css/GN/en-us/down-other/KBArticleV2.css )

/* Fix for MSKB articles, to stop the overlapping text. */
.KBPUBV1 LI,
.KBPUBV1 OL LI,
.KBPUBV1 UL LI,
.KBPUBV1 UL UL,
.KBPUBV1 UL UL LI,
.KBPUBV1 .appliesto,
.KBPUBV1 .appliesto UL,
.KBPUBV1 .appliesto UL UL,
.KBPUBV1 .appliesto UL LI,
.KBPUBV1 .postappliesto,
.KBPUBV1 .postappliesto UL,
.KBPUBV1 .postappliesto UL UL,
.KBPUBV1 .postappliesto UL LI,
.KBPUBV2 LI,
.KBPUBV2 OL LI,
.KBPUBV2 UL LI,
.KBPUBV2 UL UL,
.KBPUBV2 UL UL LI,
.KBPUBV2 .appliesto,
.KBPUBV2 .appliesto UL,
.KBPUBV2 .appliesto UL UL,
.KBPUBV2 .appliesto UL LI,
.KBPUBV2 .postappliesto,
.KBPUBV2 .postappliesto UL,
.KBPUBV2 .postappliesto UL UL,
.KBPUBV2 .postappliesto UL LI {
    margin: 5px !important;
}


    
    

    
  
*** Bug 159680 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 159808 has been marked as a duplicate of this bug. ***

    
    

    
  
Today, I tried to send them a message via
http://support.microsoft.com/default.aspx?scid=fh;EN-US;FEEDBACK . But I keep
getting this message, when clicking "Send Feedback" : 

This service is currently not available. We are aware of this issue and are
working to resolve it as quickly as possible.

But it works well in Opera...

    
    

    
  
I have sent the follow to http://register.microsoft.com/contactus30/feedback.asp

I have included this for two reasons. One to show that we need to contact MS
about this issue.  Two to show an easy way to reproduce the problem created by
MicroSoft.  When/If I get a responce from MS I will post it.


You are displaying WEB pages wrong for non Microsoft browsers.  When I set the
“User Agent” of the IE browser to something other than MSIE the pages are
displayed wrong.  If the “User Agent” is MSIE then the pages are displayed
right.  Why does this happen?

Here is how to change the “User Agent”

Edit the registry
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet
Settings\5.0\User Agent]

Add a string called “Version”  with a value of “rv:1.0rc2” (or just about
anything that is not MSIE)

Use this page for an example

http://support.microsoft.com/default.aspx?scid=kb;EN-US;q272623

You will see that the page is displayed wrong for only the reason that the “User
Agent” Version string does not contain “MSIE”.

Thanks in advance for you Help.

    
    

    
  
I left feedback at http://register.microsoft.com/contactus30/feedback.asp and
received the following reply.

     Hello, 
    
     We are aware of this issue and have filed a bug on it. 
      If you have further inquiries and concerns, feel free
     to send us mail again. 
  
     Sincerely,    
    
     Eddie    
     Microsoft.com Customer Support

It's not exactly a solution, or the promise of one, but acknowledgement is a
step in the right direction.

    
    

    
  
*** Bug 181575 has been marked as a duplicate of this bug. ***

    
    

    
  
Regarding comment #62 (http://bugzilla.mozilla.org/show_bug.cgi?id=159494#c62):

It seems at least
http://support.microsoft.com/default.aspx?scid=KB;en-us;q104641 now use
KBArticleV2.css instead of KBArticle.css.

Anyone know if this is new or if it's been there for a while?

    
    

    
  
I left feedback to MS and they replyed that "This is a known bug on our site. We
are aware of it and have a fix in the schedule."

    
    

    
  
I received one of the surveys from MS asking how I thought of their web pages. I
mentioned this problem as well in the usability section.

    
    

    
  
Alan,

Does the fix you describe for the Microsoft KB articles mess up any other
non-Microsoft web pages?

    
    

    
  
*** Bug 182943 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 183478 has been marked as a duplicate of this bug. ***

    
    

    
  
This overlapping text behavior does not appear in Netscape 6.2.x and seems 
isolated to <OL> and <UL> tags.

    
    

    
  
Yes, the problem is exclusively about lists. That's why the workaround in
comment  108 plays only with lists elements.

    
    

    
  
Dennis, CC'ing you to see further comments.

It's because the site does UA detection to send different CSS to different
browsers.  It recognises Netscape in the UA string, but not Mozilla or Gecko.

Then it points Mozilla to the stylesheet at
http://support.microsoft.com/common/css/GN/en-us/down-other/KBArticleV2.css
which has stuff like this:
.KBPUBV2 .appliesto UL {  margin-top: -1em; }

And that creates the overlap.


    
    

    
  
1) ".KBPUBV1 .appliesto UL {  margin-top: -1em; }" << this causes one of the
problems (the first block). Sounds rather logical to me, that this gives an
overlap. (happenes in konqueror 3.0.3, Opera 6.11 and Amaya 7.0 too!)

Dennis, are you in the position to remove this rule (or does it do anything
usefull to any browser..?!)

2) ".KBPUBV1 UL LI { margin-bottom: -1%; }" << (and same with OL in it) this is
the second problem - why gives this a 100% overlap? (doesn't happen in any of
the browsers listed on 1). Maybe a real Mozilla-Bug?

    
    

    
  
Dennis: I checked with both a recent Mozilla build and Netscape 7.0 that the
wrong layout is server to Mozilla/Netscape *unless* I spoof the User Agent
string to Netscape 6* (using Bob Clary's User Agent Override utility
http://mozilla-evangelism.bclary.com/sidebars/)

This means the support.microsoft.com server server wrong CSS to all
Mozilla/Netscape browsers (including Netscape 7.*) except Netscape 6.*. 

    
    

    
  


  
Save the HTML file from Mozilla to a file and then load it from IE6,
IE6 displays the same bad result.

    
    

    
  


  
Save the HTML from Mozilla to a file and then load it from IE6,
IE6 displays the same bad result.

    
    

    
  
Re: Comment 124
> 2) ".KBPUBV1 UL LI { margin-bottom: -1%; }" << (and same with OL in it) this
> is the second problem - why gives this a 100% overlap? (doesn't happen in any
> of the browsers listed on 1). Maybe a real Mozilla-Bug?

See comment 25, comment 28.

The 1% is calculated (correctly) with respect to the WIDTH of the containing
block (the client area, in this case). This is the rule that causes LI items to
overlap each other. You'll notice that if you change the width of the browser
window, the overlap changes.

    
    

    
  
A fix for this issue is currently being tested, and will be deployed soon.

    
    

    
  
Alan's comment #108, using userContent.css to override the bad CSS, works well.

But if you're in Windows you may struggle to get userContent.css to work as I
did.  If you're finding it ignores what you put in, try putting userContent.css
into:

\Documents and Settings\YOUR_LOGIN_NAME\Application
Data\Mozilla\Profiles\default\SOME_RANDOM_STRING.slt\chrome

Or, possibly:

\Documents and Settings\YOUR_LOGIN_NAME\Application
Data\Mozilla\Profiles\default\SOME_RANDOM_STRING.slt\US\chrome

I haven't tried that but noticed that's where the userContent-example.css is
located.

    
    

    
  
*** Bug 184512 has been marked as a duplicate of this bug. ***
Keywords: evang500

    
    

    
  
Fixed?

    
    

    
  
Looks like it is.

Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED

    
    

    
  
Verified FIXED
Status: RESOLVED → VERIFIED

    
    

    
  
I can't beleive it! There ARE sentient beings at Microsoft! And it took only
JUST months for them to fix the issue! Cheers!!!

Confirmed fixed 2002121408/win98

    
    

    
  
Updates no longer required.

    
  
No longer blocks: majorbugs
Product: Tech Evangelism → Tech Evangelism Graveyard

    
    

    
  
I'm going to remove the alias to make it easier to search for Microsoft.
Alias: microsoft

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: