Red Hat Bugzilla – Bug 983429
Text in selects in new dashbuilder branding is not fully displayed
Last modified: 2014-08-06 16:10:43 EDT
Created attachment 772069 [details]
Text in selects
Description of problem:
The bug title says it all :)
See screenshot. The problem is very noticable in Firefox. It is not as visible in Google Chrome, but it is still quite annoying.
Version-Release number of selected component (if applicable):
Always in my environment (Fedora 19, Browsers: Firefox 22, Google chrome 28)
Steps to Reproduce:
1. Start dashbuilder and login with admin.
2. Navigate for example to workspace Showcase, page Sales Opportunities; Or go to General Configuration > Workspaces
The text in selects is not fully visible. This effect is very noticable on Firefox, less noticable (but still present) in Chrome.
The text in select should be fully visible.
This was a problem present in the first versions of the Dashbuilder RH branding. The latest one sent to the productization team fixed that. So I guess you are testing an out-of-date version. A couple of questions:
1.- Where did you get the branding assets?
2.- Did you forked the dashbuilder on a private git repo? If so, may I have access to it.
I'm not sure if prod team sees this, so adding "needinfo" to be sure.
I just tested with BPMS 6.0.0.ER1 - the issue is still present. Is this really an issue with prod incorrectly applying branding, or is there an issue with the branding itself?
Not sure, if anyone is looking into this issue anymore, but the problem is still present in BPMS 6.0.0.ER2
Created attachment 791673 [details]
Created attachment 791674 [details]
The attached files must be updated in the private product branch to apply updated branding to the following paths:
Please, contact Neus (firstname.lastname@example.org) for any support regarding this.
We can't commit directly to the private product branch.
The issue is still present in BPMS ER3.
Created attachment 797307 [details]
Issue still present in ER3 - see screenshot
I have done a pull request
To include he skin and envelope changes tha solves the style visualization.
Ok, verified with BPMS 6.0.0 ER4
I'm afraid we have a regression. The problem appeared again in ER5 - I attach a screenshot of how it currently looks.
The environment in the screenshot attached is: BPMS 6.0.0 ER5 deployed on EAP 6.1.1, browser firefox 17
Created attachment 830480 [details]
Problem appeared again in ER5
I have tested with Firefox and Chrome in a ER5 installation @ http://hp-dl380pg8-01.lab.eng.brq.redhat.com:8170/business-central/
and everything looks fine to me, at least in one of my laptops. I have tested with Firefox 23 and Chrome 31 with Fedora.
- Have you tried to delete browser cache to force CSS reload?
- Can you please confirm if that happens with any browser?
- Can you please try to login into the system above and see if you can see the error there?
Pedro I tried with the installation above and I still see the problem in my browser. I believe it will be primarily caused by Firefox 17 (Extended Support Version, that is distributed as a part of RHEL 6).
I also clened my browser cache and my zoom level is default (100%).
When trying with other browsers (chrome) it works correctly.
I checked with several of my colleagues and the results are:
1) Firefox 25 + Fedora 19 -> worked CORRECTLY
2) Firefox 18 + Fedora 16 -> issue PRESENT
3) Firefox 17 + Fedora 19 -> issue PRESENT
4) Firefox 17 + Fedora 19 -> issue PRESENT
So in the end it seems it might be issue specific only to combination of Fedora and firefox. Since Fedora is not supported, I will check if it works correctly on supported platforms and will close this issue.
Can you please confirm whether this BZ can be closed or need further review?
I am sorry, for raising false alarm. In the end it turned out, that on operating systems targeted by PRD the text in selects is displayed correctly after all.
The issue seems to be only present when using firefox (older versions like 17,18) on Fedora, which, based on PRD, is NOT to be supported. Most likely it will be caused by some font issue. So I guess there is currently no more action needed from the engineering -> setting status back to verified again.