Open orwant opened 9 years ago
My website suddenly stopped displaying the table data. Only the headers are displayed.
Dug in deeper and there seems to be a new inline style height="16px". I could only
replicate the issue on Windows Chrome. My mac Chrome/Safari are working properly.
I tried to override the new height style but then the column headers were not the same
width as the cells.
It has been working for like a 3 months and it stopped working today.
Does anyone have a quick fix for this issue???
Original issue reported on code.google.com by AndrewRinne74
on 2015-02-19 15:02:23
Having the same problem, heights specified in the options object were respected yesterday
and tables were scrolling, today the content is essentially "overflow:visible"
I can set overflow-y:scroll (or auto) but that doesn't lock the table headers and is
thus not an acceptable solution. Making that change is not allowed to our pages in
the production environment.
Original issue reported on code.google.com by john.b.ruddy
on 2015-02-19 15:11:21
Seeing the same issue here.
Original issue reported on code.google.com by chris@applauze.com
on 2015-02-19 15:53:55
Also having this problem. Tables not longer seem to set their own size automatically,
and instead are appearing either blank or much narrower than previously.
Started occurring around 4pm (GMT) today.
Original issue reported on code.google.com by jclarke@autumncapital.com
on 2015-02-19 17:46:32
In my case, automatic height is not working. Since yesterday tables has a lot of blank
space below the las row of the table.
Original issue reported on code.google.com by kerrivil
on 2015-02-19 19:38:54
We "solved" specifing the height of the table... in all our scripts.
But this was not necessary before.
table.draw(data, {showRowNumber: true, pageSize: 10, page: 'enable', height:200});
Original issue reported on code.google.com by meob63
on 2015-02-20 10:41:25
Hello All,
I am also facing the similar issue. All the tables were rendering properly in past.
However, the tables are not being displayed properly now.
Even if the table contains many rows, only the first row is appearing on the UI. When
I increased the table height from firebug, I was able to see all the rows.
After investigating, I found that the table container div is taking the height of parent
div and not adjusting it's height as per the number of rows, which is causing this
issue.
My code is not changed in the recent past and it was working perfectly fine. Appreciate
any kind of help.
I am using version 1 of visualization and observing issue on all major browsers (Safari,
Chrome, Firefox and IE)
Thanks!!
Original issue reported on code.google.com by sushil.wanjari
on 2015-02-20 14:34:38
I believe the general problem with the Table chart sizing is that people have been drawing
the table when the container was not visible, or 0 in width or height. If you explicitly
provide a width: '100%', or height: '100%', that might take care of your problem, but
perhaps not.
We can't investigate the problem further unless people provide us more details on cases
that are failing for them. Please provide a link to a page showing the problem, or
reproduce it in jsfiddle, or email me if you would prefer (dlaliberte@google.com).
Original issue reported on code.google.com by dlaliberte@google.com
on 2015-02-20 14:47:18
attached is a screen shot. I was able to fix the tables by changing the local CSS,
but tables that have multiple pages do not show until you click the numbers. Is there
a fix for this?
Original issue reported on code.google.com by erik.m.hoffman
on 2015-02-20 14:50:10
I have same problem. We run IE 8 in production. I my development Environment I run IE
11 and than it works well.
Is there a fix for this?
Original issue reported on code.google.com by mats.forsberg
on 2015-02-20 16:10:58
Here is a link with an example showing the issue I explained in my previous post:
http://kerrivil.myftp.name:8500/Prueba/table.php
Thanks.
Original issue reported on code.google.com by kerrivil
on 2015-02-20 17:29:19
Most table issues seem to have been addressed except that the draw height property using
IE (8, 9, 10, 11). Prior to the update, table height method set a hard limit to the
table height and added a vertical scrollbar if the returned data was larger. Will this
be addressed?
Original issue reported on code.google.com by jdenright
on 2015-02-20 17:32:38
kerrivil, that chart seems to look fine, given that you haven't specified any options,
and the div has a width of 1075px, and no height specified. If you want the whole
table, and thus the rows, to expand to fill the container, then it seems reasonable
to specify a height option.
jdenright, if there was a specific hard-coded limit for the table height previously,
that would seem to be too limiting and thus incorrect. Have you tried specifying a
height in your tables?
Original issue reported on code.google.com by dlaliberte@google.com
on 2015-02-20 18:39:11
I don't understand you. The previous behaviour of that same code was that the container
adjust it's height automatically to the table, showing all the rows.
Now the container acquires a height much greater that the height of the table, as you
can see with the border set to the container.
I don't want a fixed height, I want that the height was the necessary to fit the whole
table. What is supposed I have to put in the code to get that now?
Original issue reported on code.google.com by kerrivil
on 2015-02-20 19:19:52
I see what you are saying. The new behavior expands the div.top-level height to 100%,
which then expands your container which does not have a height. Thanks for clarifying
the situation.
Jean-Rémi has found a workaround that might work for your case as well:
https://groups.google.com/forum/#!topic/google-visualization-api/hLuH41grF2k
Original issue reported on code.google.com by dlaliberte@google.com
on 2015-02-20 20:09:18
(No text was entered with this change)
Original issue reported on code.google.com by dlaliberte@google.com
on 2015-02-20 20:09:45
(No text was entered with this change)
Original issue reported on code.google.com by dlaliberte@google.com
on 2015-02-20 20:10:15
dlalibe, I've attached before and after images showing why a hard coded table width
and height are desirable. I HAVE tried setting the table height, wrapping it in another
div with a height, and setting the style to have a pixel value and tried to set it
to inherit the height, all to no avail. Please advise.
table1.draw(data1, {width: 256, height: 125, is3D: true, allowHtml: true, 'cssClassNames':
cssClassNames});
Original issue reported on code.google.com by jdenright
on 2015-02-20 21:19:35
jdenright, thanks, but while the before and after images make it clear that something
about the sizing is wrong, it doesn't help us figure out what that is. It would help
enormously if you could point to your actual page, or email me a link (dlaliberte@google.com).
My guess is that you are setting a height on the containers, and the tables are not
being constrained by that height. I can see that now. This used to work even internally,
and I was expecting that it still worked.
We also have the opposite problem that if the container height is not specified, then
the table forces it to grow.
Original issue reported on code.google.com by dlaliberte@google.com
on 2015-02-20 21:58:11
Mr. LaLiberte,
Here's a link (and the code) to an example: https://www.btxair.com/xvizfail.html
If you load this in Chrome, it has a vertical scroll bar. If loaded in IE, no scroll.
<html>
<head>
<title>Accounting Summary</title>
<script type='text/javascript' src='https://www.google.com/jsapi'></script>
<script type='text/javascript'>
google.load('visualization', '1', {packages:['table']});
google.setOnLoadCallback(drawTable);
function drawTable() {
var data = new google.visualization.DataTable();
data.addColumn('string', 'Name');
data.addColumn('number', 'Salary');
data.addColumn('boolean', 'Full Time Employee');
data.addRows([
['Mike', {v: 10000, f: '$10,000'}, true],
['Jim', {v:8000, f: '$8,000'}, false],
['Alice', {v: 12500, f: '$12,500'}, true],
['Bob', {v: 7000, f: '$7,000'}, true]
]);
var table = new google.visualization.Table(document.getElementById('table_div'));
table.draw(data, {height: 80, showRowNumber: true});
}
</script>
</head>
<body id="summary_body">
<div id="table_div"></div>
</body>
</html>
Original issue reported on code.google.com by jdenright
on 2015-02-20 22:09:00
Mr. LaLiberte,
Call off the dogs. It looks like it's an IE compatability issue on our server itself.
I hope I didn't waste much of your time.
Original issue reported on code.google.com by jdenright
on 2015-02-20 22:51:32
Thanks, jdenright. I was still working on corralling in all the other constraints before
I got to the IE issues.
Original issue reported on code.google.com by dlaliberte@google.com
on 2015-02-20 23:05:12
We're facing a similiar problem since Friday:
Suddenly google-visualization-table content has a width of 0px set, hence the table
is not shown at all.
The problem occours in Google Cchrome.
Original issue reported on code.google.com by felix@eligned.com
on 2015-02-22 12:29:06
Facing several problems but only check and found it today, but not sure when did it
occurred.
First, Height of the table is 1px, does not show any rows, only the column headers.
Second, upon specifying a container height, I noticed that visualization table replicates
itself twice as seen with class "top-level" and "header" and has two headers with "header"
having a "hidden" table.
The problem occurs in Google Chrome, firefox and IE
Original issue reported on code.google.com by eddietancs
on 2015-02-22 13:43:15
eddietancs, the table replication has always been there when you specify a height that
causes vertical scrolling to enabled. This duplicate table to allow the header row
to be frozen. The two tables should be aligned with each other so you don't notice,
but problems surfaced in the latest release, mostly involving the width and height
of the chart and its container.
Due to the large number of combinations of features available in the Table chart, and
our lack of testing of cases we didn't anticipate, these errors ended up in the release.
Further complicating our problems, we were not able to rollback the release this time
around. I expect we will be able to fix all the problems in the next couple days,
though perhaps we will require some change in how options are used.
As a short term work around, you may be able to set the width and height options to
100% to get it to work as you expect. Or you may need to override the style of the
divs that contain the table, as mentioned above in comment #16.
Original issue reported on code.google.com by dlaliberte@google.com
on 2015-02-22 17:02:03
Hi, we are still experiencing this issue in production.. Do you have an indication when
it would be fixed, as we would prefer not to introduce the temporary workaround for
this. You mentioned the couple of days - it would be great to get an update if possible.
Thank you in advance!
Original issue reported on code.google.com by alexatl
on 2015-02-26 16:05:34
I believe I have everything working now. Just cleaning up, and then I can start the
rollout, which will take several hours, hopefully completing by this evening.
Original issue reported on code.google.com by dlaliberte@google.com
on 2015-02-26 16:28:02
I just got the same issue since this morning - all table widths set in the div container
are being ignored. Is there a workaround or what is the issue? We had absolutely no
change in the code and before it has been running for months without any issues. Thanks
for your help...
Original issue reported on code.google.com by ryanheld10
on 2015-02-27 09:11:59
After updating the options in a couple tables things seem to be back to normal.
Our tables with content taller than their specified height are scrolling correctly
again with fixed headers. I did have to specify "width: '100%' " to get some to stretch
to their full width, which was happening automatically before.
Thanks!
Original issue reported on code.google.com by john.b.ruddy
on 2015-02-27 14:47:40
Specifying { width: '100%' } to stretch the tables to the full width is what I had intended,
since it gives you the additional option of not stretching.
But there is more work to be done to make this new feature work in more cases, and
to allow the stretched table to dynamically update as you change the container size
without redrawing, as it used to.
Original issue reported on code.google.com by dlaliberte@google.com
on 2015-02-27 15:01:29
From my point of view now it works fine as expected.
Is the problem closed with yesterdy rollout?
Original issue reported on code.google.com by meob63
on 2015-02-27 16:21:59
Good to hear that the Table Chart works as expected for you. The update (of 1.0 only)
that finished rolling out late last evening should resolve most of the issues that
have been reported, without causing new issues I hope.
I'm not convinced it will work for all cases, however, as much as I would like it to
be so. There are a few more things I am fixing, and I won't be surprised to hear about
more issues, so I will leave this issue open since it has the most appropriate general
title and collection of table-related issues.
Original issue reported on code.google.com by dlaliberte@google.com
on 2015-02-27 17:04:48
Thanks a lot for the fix, it resolved the height issue for my tables.
However, here is the new issue that has been discovered:
If my table has many records so that pagination is enabled, then the links present
inside the first row of first page are not clickable. links work fine once I start
navigating through the pages.
Thanks in advance.
Original issue reported on code.google.com by sushil.wanjari
on 2015-03-03 08:44:19
Sushil, one other person has also reported a (very different) problem with pagination,
but so far, I have no way to reproduce the problem. Can you provide a link to your
page (or email to me: dlaliberte@google.com), or copy/paste enough code and data here
to reproduce the problem? Thanks.
Original issue reported on code.google.com by dlaliberte@google.com
on 2015-03-03 13:29:49
I think I got the issue. Somewhere in my code, I have done like:
To the parent "div" element of ".google-visualization-table-table", style is set as:
"padding-bottom':'30px'" to add some padding at teh bottom of each tables.
It was working fine previously, but after the recent issues with the table, the parent
div's padding is getting overlapped with the first row of the table (only when pagination
is present). When I disable this padding, everything works fine.
Original issue reported on code.google.com by sushil.wanjari
on 2015-03-04 09:14:09
Glad you got it working Sushil. Overriding the style of the table chart internal elements
is likely to cause problems down the road as we change the implementation, so it is
best to avoid doing that, or plan on updating your styles as needed.
Original issue reported on code.google.com by dlaliberte@google.com
on 2015-03-05 14:40:38
Hi, we are facing a similar issue. Our reports are working fine till some days back. Now no data is displayed in the table. Was there any recent rollout from google side? Temporarily I made a fix by setting height and width to 100%. I would like to know if there will be any fix for this issue from google or we should continue with that?
Yes there was a new version released a week ago. We would need more details about how you are drawing the table chart to tell if what you were seeing is as expected.
The earlier messages on this thread are regarding the version that was current at the time, aka v41, which was just replaced by v42. If you liked how v41 worked, then you might want to use the frozen v41, documented on https://google-developers.appspot.com/chart/interactive/docs/library_loading_enhancements
Hi,
Thanks for the reply. We are using following code for drawing the table.
table${id}.draw(data${id}, {showRowNumber: ${showRowNumber}, allowHtml:true, cssClassNames:cssClassNames,page:'enable',pageSize:pageSize});
Now i fixed it to
table${id}.draw(data${id}, {height:'100%',width:'100%',showRowNumber: ${showRowNumber}, allowHtml:true, cssClassNames:cssClassNames,page:'enable',pageSize:pageSize});
Thanks
Original issue reported on code.google.com by
meob63
on 2015-02-19 10:21:11