Bottom Button Border is missing on FF 7.0, 8.0, 9.0

[GoogleCodeExporter]

The bottom border is missing on all stretch buttons (see image).

   public void onModuleLoad()
   {
       final IButton sb1 = new IButton("Bottom Border missing on FF 7.0, 8.0, 9.0");  
       sb1.setWidth(250);
       sb1.setShowRollOver(true);  
       sb1.setShowDisabled(true);  
       sb1.setShowDown(true);

       HLayout hLayout = new HLayout();  
       hLayout.setMembersMargin(20);  
       hLayout.addMember(sb1);  

       VLayout layout = new VLayout();  
       layout.setAutoHeight();  
       layout.setMembersMargin(30);  
       layout.addMember(hLayout);  
       layout.draw();
   }

Original issue reported on code.google.com by u.stuerz...@gmail.com on 27 Dec 2011 at 4:32

Attachments:

• [Button Error.PNG](https://storage.googleapis.com/google-code-attachments/smartgwt/issue-644/comment-0/Button Error.PNG)

[GoogleCodeExporter]

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

• Changed state: Invalid

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

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:

• test.zip
• CapUI.gwt.xml

[GoogleCodeExporter]

Original comment by u.stuerz...@gmail.com on 28 Dec 2011 at 9:19

Attachments:

• CapUI.zip

[GoogleCodeExporter]

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

[GoogleCodeExporter]

css removed, still not working.

Thanks

Original comment by enrico.b...@gmail.com on 29 Dec 2011 at 12:43

Attachments:

• ui-ff-bug.zip

[GoogleCodeExporter]

Any new recomondations?

BR Ulrich

Original comment by u.stuerz...@gmail.com on 3 Jan 2012 at 8:14

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

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

[GoogleCodeExporter]

Nothing?

Original comment by ilja.her...@gmail.com on 13 Jan 2012 at 1:36

[GoogleCodeExporter]

Still no valid test case.

Original comment by smartgwt...@gmail.com on 13 Jan 2012 at 11:44

[GoogleCodeExporter]

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

[GoogleCodeExporter]

Not reproducible with HTML5 doctype either.  We tried this long since.

Original comment by smartgwt...@gmail.com on 6 Mar 2012 at 5:44

[GoogleCodeExporter]

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

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

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

• Changed state: Fixed

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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