I have found a bug in Internet Explorer 8: table cells are changing their width for no apparent reason when the cell contents are changed. Following is a full repro case:
Also, this occurs randomly, it does not happen every time. Usually I can click around randomly and get it to occur within a few seconds, so it's often enough that it's a serious problem for what I'm trying to do. It also doesn't always manifest itself immediately. Sometimes a cell will *appear* to have the correct width, but clicking on a completely unrelated cell (meaning one that is not bordering the cell) will suddenly cause the other cell to shrink by 3px.
Anyone have any ideas?
- The bug occurs regardless of what type of content change occurs in the cell. I can insert a <span> or just change the text, and cells will randomly contract by 3px.
- Sometimes bugged cells will later reexpand and gain back the 3px they lost.
- Alert-ing the td width at various points shows that the 3px is lost in random places each time. Sometimes its when the value of the cell is cleared, sometimes its when the new value is set, sometimes its at some point *much* later than the cell's value was changed...
Anyone know where you can file an actual bug report for IE?
Sorry to continue to bump this topic, but further testing has revealed that a single CSS attribute is to blame: table-layout:fixed. Without this attribute, the table behaves as I would expect. With the attribute, I get the buggy behavior. Unfortunately, I *must* have table-layout:fixed, otherwise cells will expand to fit their contents, and I don't want that. So, Microsoft, where can I submit a bug report?
We have the same problem in IE8. Basically it boils down to having table-layout:fixed and padding on the cells. Here is a simple HTML that reproduces the problem. After opening it in the browser try selecting the text with mouse, after a few selections the cells start shrinking to the width with no padding and you can see the table background through.
Please take a look at the problem ASAP. As a major component development company we can no longer give our customers an answer like "This is a bug in IE8". A temporary workaround would be appreciated as well.
<%@ Page Language="C#" AutoEventWireup="true" CodeFile="TableBug.aspx.cs" Inherits="Default2" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
tbody.cellStyle > tr > td
border:Solid 1px Green;
padding:5px 8px 5px 8px;
<form id="form1" runat="server">
<table style="table-layout:fixed;background-color:Gray;width:100%;" border="0" cellpadding="0" cellspacing="0">
Can anybody help with this please?
To see how bad it is in the actual control please visit this sample's page and select text inside of the grid with mouse. It does appear to be IE8 bug as it is not reproducible in any other browser.
It does appear to be IE8 bug as it is not reproducible in any other browserI indeed don't see it in IE6. However I am not sure if I do the test properly. Can you precise if the bug doesn't hit IE7 or IE6? TIA,
Versailles, Fri 25 Sep 2009 23:06:35 +0200
Hi Alex, Start by validating your markup. http://validator.w3.org/check?verbose=1&uri=http%3a%2f%2fsamples.infragistics.com%2f2009.1%2fWebFeatureBrowser%2fcontents.aspx%3fshowCode%3dTrue&t=WebDataGrid%2fDataBinding%2fWebDataGridDataBind.aspx%7esrcview.aspx%3fpath%3d%7esrcview.aspx%3fpath%3dWebDataGrid%2fDataBinding%2fWebDataGridDataBind.src There are critical errors on that page that cause IE8 to fall back to Quirks mode. It is important that when you are testing your pages in IE8 that you first uncheck "Recover from rendering errors with Compatibility View" on the Advanced tab of Internet Options. Regards.
I do not see a "Recover from rendering errors with Compatibility View" option on the Advanced tab. I'm using IE 8 on Windows 7 x64.
I do not think the problem has to do with invalid markup. The stripped-down sample I posted in the first message validates with no errors, yet the bug shows up just fine.
Fortunately, I did find a solution to this bug: just install Chrome Frame! http://code.google.com/chrome/chromeframe/ I'm going to add a polite warning to liteGrid that urges people to either get a real browser or at the least install Chrome Frame.
I'm glad you wrote this up - I'm affected by the same problem.
I thought I'd let you know that pushing the browser into compatibility mode seems to fix the issue, at least for us. Unfortunately, in our case, doing so using the appropriate meta tag causes other problems, so we have to ask our users to manually select compatibility mode (another thing I'm not super-happy about).
Any ETA on a fix, Microsoft? It's dead easy to reproduce, and it's obviously a bug. I've put an example up at http://ziggyfoo.com/jqgrid/
Edit a few cells... it might not happen the first time, but it will happen eventually.
Unfortunately liteGrid makes use of some CSS 2.0 things that are broken when in compatibility view, so unfortunately that doesn't work for me. I'm considering adding a second layout provider to liteGrid that will render using div tags instead of table cells. I've seen other grids go that route to work around table bugs in IE.
As for a Microsoft response, I've basically given up on one. If there is a way for customers to report IE8 bugs, I can't find it, and they don't seem to be interested in replying in this forum. :(
I wish. Microsoft has not said a word to me about this bug, and I can't find anywhere to officially report it as a bug. Table rendering in IE8 in general is just absolutely junk. I've lost count of the number of rendering glitches I've seen when working with tables in IE8.It does give me hope though that you're getting errors using another Microsoft-supported product. Maybe try submitting it as a bug for that product and see if we can get someone to take notice?
Same problem with me also. Switching IE8 compatibility mode on/off seems to introduce a bug in cellspacing/cellpadding. Firefox and Safari render correctly, perhaps this is why these products now own 33% of the Browser market share.
The decision I have to make now is whether or not I attempt to code for the problem -- if i do a bunch of work around coding now, then Microsoft finally fix this bug, I'll have to go back and undo all the work around code. So, some indication from Microsoft would be appreciated.
Yes, this is a pretty obvious bug, but I have to admit, that as Microsoft release more software it seems their bugs are becoming more and more obvious affecting A LOT of companies and individuals -- this isn't a good thing.
Aaah, I just love NOT having any real standards to follow...
Same problem here: http://social.msdn.microsoft.com/Forums/en-US/iewebdevelopment/thread/dc123cbf-0816-42ca-bcd5-765e6c3238c0
Unfortunately we have upgraded to IE8 in our company :-((
And still no response from Microsoft. Guess I'll just post a warning about Microsoft's bug on all my web sites (I have many public ones not just internal corporate) and let the end user know that Firefox and Safari don't have this problem. I'm not going to code around the problem this time -- if Microsoft want more people to move away from IE they can continue to keep silent on this VERY obvious bug.
Yeah, I'm very frustrated by how Microsoft is handling IE8. The only official thing I've seen from them regarding the browser is how awesome it is. They ignore bug posts on the forums, do not provide any means for actually submitting a bug for review, and make no attempt to fix well-known bugs. At the very least, aren't there MS MVPs would should be monitoring the forums and providing us with some feedback??
And Microsoft wonder why their IE market share went from 92% to 67% and is dropping every quarter. I suppose the positive side is that when IE market share is so small, I'll no longer need to worry about it nor code work arounds for it. In the meantime I've added link to downloads/install of Firefox, Safari, Chrome on my sites - help the end user transition away from IE.
I'm planning on integrating something similar into liteGrid. When an optional module is used, the grid will display a small, dismissible warning about IE8 compatibility problems. It will suggest that users either install Firefox, Chrome, or the Chrome add-in for IE8.
- Printing is not yet implemented.
- Downloads initiated from Google Chrome Frame are downloaded, but neither the Google Chrome nor the host browser UI is displayed
Google Chrome Frame is as much a "work in progress" as IE8 is, the only difference is that Google is actually going to fix things in Google Chrome. How long will I have to wait before MS fixes table rendering? IE9, *maybe*? Between the two, I'd much rather use an unstable technology from Google than one from the IE development team.
How about providing your site address so we can monitor its visitation an uptake of the 50Mb GF uploads. It should be interesting to watch the mean visitation time drop off.
Who cares what you do with your site. For me suggesting a buggy browser addon for IE is irresponsible. At least now I know another question to ask users when they say "My IE downloads do not work" or "I cannot print from IE". To me these two known issues with Google Frame are show stoppers.
"Google Chrome Frame is as much a "work in progress" as IE8 is" - google - define SDLC
Chrome is licensed from Safari.
Here is the total validator report for a mashup of the code snippet you supplied.
Line 55, Column 30: NET-enabling start-tag requires SHORTTAG YES <col style="width: 100px;" />✉ The sequence <FOO /> can be interpreted in at least two different ways, depending on the DOCTYPE of the document. For HTML 4.01 Strict, the '/' terminates the tag <FOO (with an implied '>'). However, since many browsers don't interpret it this way, even in the presence of an HTML 4.01 Strict DOCTYPE, it is best to avoid it completely in pure HTML documents and reserve its use solely for those written in XHTML. Line 55, Column 31: character data is not allowed here <col style="width: 100px;" />✉ You have used character data somewhere it is not permitted to appear. Mistakes that can cause this error include: •putting text directly in the body of the document without wrapping it in a container element (such as a <p>aragraph</p>), or •forgetting to quote an attribute value (where characters such as "%" and "/" are common, but cannot appear without surrounding quotes), or •using XHTML-style self-closing tags (such as <meta ... />) in HTML 4.01 or earlier. To fix, remove the extra slash ('/') character. For more information about the reasons for this, see Empty elements in SGML, HTML, XML, and XHTML. Line 56, Column 30: NET-enabling start-tag requires SHORTTAG YES <col style="width: 100px;" />✉ The sequence <FOO /> can be interpreted in at least two different ways, depending on the DOCTYPE of the document. For HTML 4.01 Strict, the '/' terminates the tag <FOO (with an implied '>'). However, since many browsers don't interpret it this way, even in the presence of an HTML 4.01 Strict DOCTYPE, it is best to avoid it completely in pure HTML documents and reserve its use solely for those written in XHTML. Line 57, Column 30: NET-enabling start-tag requires SHORTTAG YES <col style="width: 100px;" />✉ The sequence <FOO /> can be interpreted in at least two different ways, depending on the DOCTYPE of the document. For HTML 4.01 Strict, the '/' terminates the tag <FOO (with an implied '>'). However, since many browsers don't interpret it this way, even in the presence of an HTML 4.01 Strict DOCTYPE, it is best to avoid it completely in pure HTML documents and reserve its use solely for those written in XHTML. Line 58, Column 29: NET-enabling start-tag requires SHORTTAG YES <col style="width: auto;" />✉ The sequence <FOO /> can be interpreted in at least two different ways, depending on the DOCTYPE of the document. For HTML 4.01 Strict, the '/' terminates the tag <FOO (with an implied '>'). However, since many browsers don't interpret it this way, even in the presence of an HTML 4.01 Strict DOCTYPE, it is best to avoid it completely in pure HTML documents and reserve its use solely for those written in XHTML.
You can view the MS IE Test Center Unit tests at http://samples.msdn.microsoft.com/ietestcenter/
You can view the W3C test suite (Unit tests) at http://www.w3.org/Style/CSS/Test/CSS2.1/20061011/
You can post MS's formal issue tracking system at connect.microsoft.com to view the outstanding issues with IE8 RTW/RTM
THE POINT IS
if you want to be heard by the IE Developers, submit a formal test case that clearly states and demostates the issue. Redmond is a big place. You will never be heard unless you go through the right channels. No-one at Redmond will act without formalities (they have to accunt for their paid time).
(Please note: this is a FORMAL issue tracking system. Any submissions you make should follow a documented test plan with (validated) publicly accessible examples.
Here is a listing of Issues submitted for colgroup
Here is the computed style from the FX Developer tool.
#buggedTable td, th (line 16)
Note the inclusion of white-space:nowrap;
FX, Safari and Opera all use a local stylesheet (User\FX\Style\html.css) to prime the DOM with default rules before the page is rendered.
- Proposed as answer by 13ace13 Saturday, October 24, 2009 3:02 PM
I'm quite the rookie, and found this blog when running into apparently the same issue with tables (which i thought was a png issue);
I found a solution for my particular issue by specifying image height and width for images inside tables, specifically the png's i used for the header and corners of the box (i know there are prob better ways, please be gentle).
Nevertheless, adding the exact dimensions of the images in the html (<img src="botrightcorn.png" alt="vec surfboards" width="100" height="267" />) allowed ie8 to render this page correctly: vecsurfboards.com
I actually ran the sample through the W3C validater and received no errors. I'm not sure why you got different output. Perhaps something was lost in the copy/paste (either by me posting it here or you copy/pasting it there). In any case, the bug is in IE, not the markup. Table cells randomly changing their width by doing nothing more than dragging a selection through the text is not something that markup should be able to cause in the first place. And the "no-wrap" style was intended. This table is meant to behave like a spreadsheet, so values that are wider than the column should be hidden.
Thanks for the link to Microsoft Connect, but there does not seem to be a way to submit new bugs, and in fact the description says that it's for the IE 8 beta. It sounds like it's read-only at this point: "The Internet Explorer 8 Feedback website on Microsoft Connect will remain open and we will not delete any of the previously submitted bugs." There is a link to post new bugs on the beta newgroups, so I'll give that route a try.
My frustration isn't just with the bug, it's that it took this long for anyone to say "ok, try submitting a bug report here." Everything about IE8 seems to be full of fail, including support.