1153530 - Dropdown list text colour issue with HWA enabled

Status: RESOLVED DUPLICATE of bug 1153609

(Core :: Graphics, defect)

Description

[kkovacev]

Attachment: Images (note position of vertical scrollbar)

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:37.0) Gecko/20100101 Firefox/37.0
Build ID: 20150328224110

Steps to reproduce:

Created modal dialog with jQuery UI with "UI Lightness" theme.


Actual results:

When window vertical scrollbar is in start position text colour of dropdown lists are wrong. In my example it is white instead of black. When scrollbar is moved down text colour is changed from white to black as it should be. When scrollbar is moved to top position colour is again changed to white.


Expected results:

Text colour of dropdown list should not change with movement of scrollbar.
Problem does not exist in Linux version. Also it does not exist in 36 branch.

Comment 1

[Loic]

Attachment: i1.jpg

Please, make your images directly viewable from the bug report.

Comment 2

[Loic]

Attachment: i2.jpg

Comment 3

[Loic]

And we need a minimal testcase, please.

Comment 4

[kkovacev]

I have tried to simulate this issue on my laptop (Ubuntu 14.04 + Windows 7 x86 in vBox) without success.
Everything is OK in this combination.
Original issue is occurring on my friend's laptop which is not at my disposal at the moment.
On that laptop I have remotely reinstalled FF 37.0.1 and FF 36.0.4 several times and problem is always visible with FF 37 version.
In few days I will have more info about HW/OS on that problematic laptop.

BR

Comment 5

[maikl]

Hello, I have the same problem here:

I use Selects with jquery class "ui-widget-content".
This class adds a background property: 
url("images/ui-bg_highlight-soft_100_eeeeee_1x100.png") repeat-x scroll 50% top #eee;
color: #333;

(the url background is almost white)

The texts appears in white color and I can't read the text (before the 37 update they appear in #333 color) 
If I remove with firebug this css rule all the texts become #333 again and I see the contents.
It only happens with Selects, not Inputs.

The same page works fine in Chrome. I checked in distinct Win7 systems with the last Firefox update.

If I get more information I will post here.

Thank you.

Comment 6

[Loic]

(In reply to kkovacev from comment #4)

> On that laptop I have remotely reinstalled FF 37.0.1 and FF 36.0.4 several
> times and problem is always visible with FF 37 version.
> In few days I will have more info about HW/OS on that problematic laptop.
> 
> BR

I think the issue is here, it's related to the OS/Hardware, probably because it's remote.
Can your friend test Firefox natively on his computer?

Comment 7

[maikl]

Attachment: Text color changing: 1 - Text not visible (in white)

Comment 8

[maikl]

Attachment: Text color changing: 2 - Text normal after disable background rule

Comment 9

[kkovacev]

Hi,

I did not manage to see my friend with laptop but I have tested the same scenario on my old desktop (Intel® Core™2 Duo CPU E6750 @ 2.66GHz × 2 + GeForce 8800 GT/PCIe/SSE2) and the same issue exists.
So remote desktop connection is not an issue. Also, nVidia is not an issue because I am sure that my friend's laptop has intel graphics card.
I will try to make small example on public page so that you can see problem for yourself by end of the week.

BR

Comment 10

[kkovacev]

I have played with Inspector and CSS...

When these rules are disabled:
.ui-corner-all, .ui-corner-top, .ui-corner-left, .ui-corner-tl {
    border-top-left-radius: 4px;
}
.ui-corner-all, .ui-corner-bottom, .ui-corner-left, .ui-corner-bl {
    border-bottom-left-radius: 4px;
}
wierd color behavior does not exist.
Also when I do zoom in with FF (CTRL & +) problem disappear.
Hope this helps.

BR

Comment 11

[Loic]

could you attach a testcase as HTML file, please.

Comment 12

[kkovacev]

Attachment: bug-example-page.zip

Hi,

Attached you can find example page with described bug.
Unfortunately it was not possible to make everything with one html file because jQuery and jQueryUI are used.
Just to remind you, problem is visible on Windows 7 machines. Try to change size of FF window and scroll up and down you will see it for sure.

BR

Comment 13

[Loic]

I'm not able to reproduce the issue with FF37 on Win 7, the 1st item in the dropdown list is always black, whatever is the vertical scrollbra is up or down.

Sounds Linux issue.

Comment 14

[kkovacev]

Attachment: Native Windows 7 x64 with FF 37 (scroll bar up)

Native Windows 7 x64 with FF 37 (scroll bar up)

Comment 15

[kkovacev]

Attachment: Native Windows 7 x64 with FF 37 (scroll bar moved)

Native Windows 7 x64 with FF 37 (scroll bar moved)

Comment 16

[kkovacev]

Attachment: Native Ubuntu 14.04 64 bit with FF 37 (scroll bar up)

Native Ubuntu 14.04 64 bit with FF 37 (scroll bar up)

Comment 17

[kkovacev]

Attachment: Native Ubuntu 14.04 64 bit with FF 37 (scroll bar moved)

Native Ubuntu 14.04 64 bit with FF 37 (scroll bar moved)

Comment 18

[kkovacev]

As you can see from previous comments with images native Windows with FF 37 has this issue.
On Ubuntu everything behaves as it should.
Also if you run Windows inside virtual machine you will not see this issue.

BR

Comment 19

[kkovacev]

And just to note IE 9+, Chrome, FF 36 does not have this issue.
So problem definitively is introduced with FF 37.

Comment 20

[Loic]

I see you're using a localhost to open the testcase. Are you able to repro the issue if you open directly the file "test.html" (file:///) in the location bar?

Comment 21

[kkovacev]

Attachment: test.html directly opened in FF

Yes, problem exist if I directly open test.html in FF.

Comment 22

[Loic]

Still not able to repro it.

Are you able to repro it in safe mode?
https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode

Comment 23

[Loic]

Ok, I found the STR.
My screen resolution was 125% in Win 7, if I go back to 100%, I'm able to reproduce the issue with HWA enabled.
If I disable HWA (still at 100%), I can't reproduce it.

Try with HWA disabled, it should be normal:
https://support.mozilla.org/en-US/kb/forum-response-disable-hardware-acceleration (restart FF to apply)

Comment 24

[kkovacev]

In safe mode everything is OK.

Comment 25

[Loic]

(In reply to kkovacev from comment #24)
> In safe mode everything is OK.

That confirms my STR, because HWA is disabled in safe mode.

Comment 26

[Loic]

Regression range:
good=2014-10-01
bad=2014-10-02
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=14665b1de5ee&tochange=2399d1ae89e9

the suspected bug is probably due to D2D 1.1, maybe bug Bug 1075621.

Comment 27

[Alice0775 White]

Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=165c3fd176ec&tochange=d954ed24e795

triggered by: Bug 902952


Regression window with force enable d2d1.1:

user_pref("gfx.canvas.azure.backends", "direct2d1.1,direct2d,skia,cairo");
user_pref("gfx.content.azure.backends", "direct2d1.1,direct2d,cairo");
user_pref("gfx.direct2d.use1_1", true);

https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=3749c4d4e76b&tochange=8e28464849fa

Via local build:
Last good: 20e97c8496e4
First bad: 7b9201731195

triggered by: 7b9201731195	Matt Woodrow — Bug 1046550 - Part 3: Use Direct2D 1.1 when preffed on. r=bas


I think that Bug 902952 should be backed out.

Comment 28

[Alice0775 White]

[Tracking Requested - why for this release]:

Comment 29

[Alice0775 White]

[Tracking Requested - why for this release]:

Comment 30

[Loic]

Bas, why when the OS resolution in Windows is set to > 100%, the bug doesn't appear even if D2D1.1 and HWA are enabled?

Comment 31

[Lawrence Mandel [:lmandel] (use needinfo)]

Tracking user visible regression.

Comment 33

[Sylvestre Ledru [:Sylvestre]]

Too late for 38 but we could take a patch for 39.

Comment 34

[Liz Henry (:lizzard) (relman/hg->git project)]

Marking wontfix for 39. 

By the way Loic --  your finding the STR on this was pretty awesome!

Comment 35

[Bas Schouten (:bas.schouten)]

When I open the test HTML I don't seem to see any text boxes in general.

Comment 36

[Loic]

(In reply to Bas Schouten (:bas.schouten) from comment #35)
> When I open the test HTML I don't seem to see any text boxes in general.

Unzip the testcase https://bugzilla.mozilla.org/attachment.cgi?id=8594077 and load test.html. 
Then click on "Open Master Dialog" > "Open Slave Dialog" then click on a drop-down list.

Comment 37

[Bas Schouten (:bas.schouten)]

Now I get it. I can reproduce this issue and will fix it.

Comment 38

[Bas Schouten (:bas.schouten)]

Not reproducible on nightly, turns out to be a dupe of bug 1153609 as far as I can tell.

Comment 39

[Kate Glazko]

Updating the status flags to match the duplicate, bug 115309.