Closed Bug 159494 Opened 23 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: