Closed GoogleCodeExporter closed 9 years ago
Not reproducible for us using the attached code against the SmartGWT 3.0
release, and the standard Enterprise skin.
This may be due to some invalid skin modifications or external stylesheets
perhaps?
Marking invalid. If you believe you have a reproducible case, please make sure
you have no skin modifications, let us know the SmartGWT release version, and
show us the gwt.xml file (so we can verify what skin is being loaded), and the
bootstrap file (so we can verify there's no external css etc).
Also verify you can reproduce after clearing browser cache and reloading and
please note any other information that might effect display (browser zoom
level, etc)
Original comment by smartgwt...@gmail.com
on 27 Dec 2011 at 6:15
[deleted comment]
OK, but for us this is quitefrustrating, since this error still occurs on our
app. For a better understanding please find attached the generated source as
well as the gwt.xml
Original comment by u.stuerz...@gmail.com
on 28 Dec 2011 at 9:04
Attachments:
You're loading your own CSS styles. Let us know if you can produce a test case
suggesting this is a framework problem (currently your test case does not
suggest this).
Original comment by smartgwt...@gmail.com
on 28 Dec 2011 at 9:06
css removed, still not working.
Thanks
Original comment by enrico.b...@gmail.com
on 29 Dec 2011 at 12:43
Attachments:
Any new recomondations?
BR Ulrich
Original comment by u.stuerz...@gmail.com
on 3 Jan 2012 at 8:14
[deleted comment]
OK,
setting "OVERFLOW:-moz-scrollbars-none;" to "OVERFLOW:visible;" would only
addess the symptoms but not the problem.
To resolve the problem the inline style of the table element holding the button
has to be corrected. Firebug showed "<table cellspacing="0" cellpadding="0"
border="0" style="font-size: 1px;">" which results to a total height of 23px
whereas the element has by definition only a height of 22px and therefore the
canvas is 1 pixel too narrow.
Long story short the style="font-size: 1px;" has to be corrected to
style="font-size: 0px;"
BR Ulrich
Original comment by u.stuerz...@gmail.com
on 3 Jan 2012 at 2:26
font-size:1px should not lead to a 24px cell. This suggests you have some kind
of special configuration for your browser which forces larger fonts, which
would explain why only you see this issue.
Original comment by char...@isomorphic.com
on 3 Jan 2012 at 6:57
Well, it does and no we have no special configuration. We use FF as it comes
out of the box. I even uninstalled the whole application, deleted all folders
and reinstalled from scratch but the problem remains on all computers (6
different devices).
So from my perspective it looks quite like an framework issue. We did all you
asked:
- disabled custom CSS
- checked browser settings
- reset cache and cookies
and the problem still exists.
This is a big problem for us: We are developing an application which is widely
used within our organisation (8 countries with a few houndred users). One
reason for us to use smartGWT was due its independence to browsers and
therefore to avoid such problems. So we need a fix here and soon. We want to go
live within the next few weeks.
BR Ulrich
Original comment by u.stuerz...@gmail.com
on 4 Jan 2012 at 7:37
Hi,
another thing I was able to verify. I created a new project as described here
http://www.javacodegeeks.com/2010/06/getting-started-smartgwt-gwt-interfaces.htm
l and the same problem occurs.
So from my point of view it has nothing to do with project settings or CSS
config. It is a bug in the framework.
Maybe the reason you are not able to verify this is that you use the EE version
and not free version of smartGWT.
BR Ulrich
Original comment by u.stuerz...@gmail.com
on 4 Jan 2012 at 12:47
Once again, the problem is not reproducible in either version of the framework,
and you are reporting that for you, font-size:1px produces a 24px cell. That's
not normal despite your assertions of running on stock Firefox (where the
problem does not occur).
You could get this to happen if you were applying a CSS style that added a
great deal of padding to all table cells, or if you were zoomed, or if you had
configured your browser to use larger fonts.
Original comment by smartgwt...@gmail.com
on 4 Jan 2012 at 10:31
Hi,
you say you cannot reproduce this problem. So could you please so kind and
provide me your Firefox 8 settings. So we can either confirm that is a browser
setting problem or not.
Concerning the zoom: As far as I know the zoom should have no effect at all or
the whole framework would not be applicable in terms of accessibility. But
nevertheless we don't have the zoom option in place.
Thank you very much Ulrich
Original comment by u.stuerz...@gmail.com
on 5 Jan 2012 at 9:42
Concerning your hypothesis that the padding or css might be a reason for this,
I can tell you for sure it isn't. Because when you have a look at the tutorial
I refered to in comment 12, you will see it just uses bare standard settings
without any modifications (e.g. css or padding).
BR Ulrich
Original comment by u.stuerz...@gmail.com
on 5 Jan 2012 at 3:18
Except that it actually does not happen with stock Firefox. Again, 1px font
will not lead to a 24px cell in a normal Firefox installation. You can use
Firebug to see where the additional space is coming from.
Original comment by smartgwt...@gmail.com
on 5 Jan 2012 at 8:30
Ok, we are running in circles here. Let me summarise this:
1) we are using stock FF. I personally installed all three versions from
scratch and if you use the HTML dump provided in comment 6 the error is easy to
reproduce
2) we disabled all custom CSS settings. I even created a new project using a
tutorial which has no CSS custom settings at all (see comment 12) and again the
error occurred.
3) the padding we used in our example was the same you use in your showcase.
4) I used firebug to track down the problem to the table element in comment 9.
This table element seems to create the visible canvas. IT IS AUTOMATICALLY
GENERATED BY SMARTGWT. There are no means to override the inline CSS
definitions that produce that problem.
5) Since you are not able to reproduce this bug which can be achieved within
our dev team on six different machines independently from personal settings, my
guess is you either have not used standard settings or you used a wrong version
(WINDOWS 7 x64, FF 7 / 8 / 9). Windows is important since only here this
problem occurs (I just verified that shortly ago).
So My suggestion to you is that we both try the HTML dump using exactly the
same FF version on windows 7 x64. If you like I provide a package for windows
for you or you share your distribution. My version would be in German...
BR Ulrich
Original comment by u.stuerz...@gmail.com
on 5 Jan 2012 at 9:21
Again, this does not reproduce on a stock install, including Windows 7 x64.
Have you tried on any machines that are not set for the German locale?
Are you perhaps configuring all these machines for large fonts at the OS level?
Original comment by smartgwt...@gmail.com
on 5 Jan 2012 at 9:38
No, I can reproduce this problem even on my private PC and on my wife's PC,
which are not even on the corp network and have totally different settings. We
even tried the English FF and guess what, yes error was reproduced again.
The German locale setting on OS level should have no effect such as this.
Because if it would, well see my comment on accessibility at the end of the
next section.
Forget about the large font setting because on one hand this does not affect
the bug (I tried with IE and there are no probs at all) and on the other hand
we are not blind, so we use standard system sizes. And again if this would
cause the error, you would be in big trouble since this would make your
framework not usable due to accessibility requirements which are given by law
in nearly every western country (e.g. see section 508 of the 1988 Amendments to
the Rehabilitation Act for the US). So if you say this can cause such a problem
then better fix it sooner than later ;-)
So please consider my offer on we both using the same browser. I would really
like to use your distribution to see everything working out just fine.
BR Ulrich
Original comment by u.stuerz...@gmail.com
on 6 Jan 2012 at 11:05
One last time: this problem is not reproducible for us in a standard
environment on a standard Firefox browser, with the version you specified, on
the OS you specified.
If this were a real framework problem we would have hundreds of reports by now.
We don't.
We don't know what's special about your project files, but we will not be
investigating what's going wrong in a "test case" produced by using the browser
Save As.. feature which saves *obfuscated code* - that's useless.
To file a real and valid bug report, take the helloworld project, modify it
minimally, and show how this problem can be reproduced. In doing so you will
most likely discover how your project is special and solve your problem.
Original comment by smartgwt...@gmail.com
on 7 Jan 2012 at 12:17
Hi again,
I am sorry that this gets on your nerves but for me it is essential to solve
this problem. So obviously something is really wrong with our project when you
say you can't reprodusce the problem and we say we can't find any configuration
errors I would like to follow your recomondation. To be sure that all is
configured properly, I would like to ask you a big favour: Is it by any chance
possible to get an eclipse-ready configured hello world project from you which
is verified by you to work fine on Firefox 7, 8, and 9 within your environment?
I know this sounds lazy but the reason for this is, we already started off
using one of your showcase examples and another external tutorial obviously we
did something wrong in both approaches. So the easiest way to get around that
would be to get a ready project for copmparison. Furthermore we would avoid to
discuss in circles pushing the problem to and fro.
Thanks very much for your help and br
Ulrich
Original comment by u.stuerz...@gmail.com
on 9 Jan 2012 at 8:09
There is a "helloworld" sample project and setup instructions are in the Google
Code project.
Original comment by smartgwt...@gmail.com
on 10 Jan 2012 at 12:29
[deleted comment]
[deleted comment]
We're having exactly the same issue here. It only occurs in Firefox (tested
with v8), while it's absolutely fine in IE9 and Chrome16. Strangly it's only
present on 3 out of 4 test systems. The only obvious difference between them is
that the one where it looks fine is an XP system while the others are Win7
systems. Note, that we're still using SmartGWT 2.5. Our hope was that it'll be
solved with the next version, which (reading this discussion) apparently wasn't.
Original comment by ilja.her...@gmail.com
on 10 Jan 2012 at 1:24
Nothing?
Original comment by ilja.her...@gmail.com
on 13 Jan 2012 at 1:36
Still no valid test case.
Original comment by smartgwt...@gmail.com
on 13 Jan 2012 at 11:44
OK after a lot of testing I found the issue. When you generate your smartGWT
using maven it creates in your *.html server start page a html doctype
declaration. This causes FF to produce the problem.
To fix it just remove that tag <!doctype html> and see to it that the page
starts with <html>
...
BR Uli
Original comment by u.stuerz...@gmail.com
on 6 Mar 2012 at 1:37
Not reproducible with HTML5 doctype either. We tried this long since.
Original comment by smartgwt...@gmail.com
on 6 Mar 2012 at 5:44
Well, I'm having this issue too. So, now you have 3 reports. I'm using SmartGWT
LGPL 03/03/2012 nightly. I'm using FF 8 on Win 7 64-bit. It works file on
Chrome (latest version), IE 8, 9 and even 10.
I stumbled upon this page searching for "SmartGWT Firefox button bottom border
missing" on Google.
I also have <!doctype html> setting. I'll try it from a Windows XP machine
running a different version of Firefox in the evening. I'll also try to test
with a new application (and the latest nightly) and posts the results here.
Original comment by yourtube...@gmail.com
on 25 Apr 2012 at 8:48
[deleted comment]
[deleted comment]
These comments all seem to indicate that there is some OS-level setting that
leads to this problem - most likely a high-DPI screen causing a larger font
size to be used by default.
We still have not seen it on our end but we are making a change to
conditionally modify the generated HTML as suggested in this thread (changing
the specified font-size to zero px) in the effected browsers (Firefox with
HTML5 doctype).
From all the information we have it sounds like this will resolve the issue.
The change will be made in the 3.1d branch and will show up as of the May 2nd
(or greater) nightly build.
Original comment by smartgwt...@gmail.com
on 1 May 2012 at 6:44
Thank you.
This is the thread I created in SmartGWT forum (for anyone following this
issue):
http://forums.smartclient.com/showthread.php?s=a389a507c314700de0861a9ac37ce8ee&
t=21945
I'll try out the May 2nd nightly and let you know the result. If you can tell
me how to verify OS level DPI setting on Windows 7, I can verify that as well
and post the details here.
Thanks again.
Original comment by yourtube...@gmail.com
on 1 May 2012 at 6:54
I've added the following lines to my css file to work around this issue in 3.0:
div.stretchImgButton>div>table {
font-size: 0px !important;
}
div.stretchImgButtonOver>div>table {
font-size: 0px !important;
}
This works for me, your mileage may vary.
Original comment by avand...@gmail.com
on 14 May 2012 at 7:07
Fix from comment 35 works for me.
My configuration: SmartGWT 2.4, FF 15.0.1, Win7 64-bit
Original comment by dawid.ch...@gmail.com
on 27 Oct 2012 at 4:24
I still had this issue after trying every trick mentioned here, or upgrading to
3.1 (which was breaking more stuff.)
Setting a negative margin fixed the issue for me: straight in the code:
button.setMargin(-1);
I guess just setting margin-bottom: -1px; via CSS will work too.
Fixes the rendering in Firefox, without breaking it in Chrome, how sweet..
Original comment by ericdedi...@gmail.com
on 14 Jun 2013 at 6:25
Original issue reported on code.google.com by
u.stuerz...@gmail.com
on 27 Dec 2011 at 4:32Attachments: