Closed Bug 558908 Opened 10 years ago Closed 10 years ago

chrome://mochikit/content/chrome/toolkit/content/tests/chrome/test_autocomplete2.xul failing on Fedora unit tests


(Toolkit :: Autocomplete, defect)

Not set





(Reporter: armenzg, Assigned: mak)



(Keywords: intermittent-failure)


(3 files)

7311 ERROR TEST-UNEXPECTED-FAIL | chrome://mochikit/content/chrome/toolkit/content/tests/chrome/test_autocomplete2.xul | not nomatch and highlightNonMatches - should be black - got "rgb(26, 26, 26)", expected "rgb(0, 0, 0)"
7312 ERROR TEST-UNEXPECTED-FAIL | chrome://mochikit/content/chrome/toolkit/content/tests/chrome/test_autocomplete2.xul | not nomatch and not highlightNonMatches - should be black - got "rgb(26, 26, 26)", expected "rgb(0, 0, 0)"
7315 ERROR TEST-UNEXPECTED-FAIL | chrome://mochikit/content/chrome/toolkit/content/tests/chrome/test_autocomplete2.xul | nomatch and not highlightNonMatches - should be black - got "rgb(26, 26, 26)", expected "rgb(0, 0, 0)"
No longer blocks: fedora-oranges
Component: General → Autocomplete
OS: Mac OS X → Linux
Product: Core → Toolkit
QA Contact: general → autocomplete
Version: unspecified → Trunk
No longer blocks: fedora-oranges
CCing Neil, who reviewed the original test.
Hi Neil,
When could you have a chance to look into this?
This currently blocks me from fully enabling unit tests for Fedora.

Let me know if you need some info from the actual slaves.
sounds like default colors on this platform could be different from the old one? i think autocomplete defines hardcoded colors for certain status (nomatch and highlightNonMatches) and those PASS.
The test fails when we fallback to default, that could maybe be (tbd) -moz-fieldtext. thus the color comparison should be done with a getComputedValue in a not autocomplete textbox in the test window, or just check that we are not using special colors. Since the only special color defined here is "rgb(255, 0, 0)" changing tests to isnot "rgb(255, 0, 0)" could be enough.
Attached patch patch v1.0Splinter Review
something like this? Provided we are only interested in verifying the result is not highlighted.
Attachment #441051 - Flags: review?(enndeakin)
Why is this failing? What colour was being compared against before and what changed to make this test fail?
it was compared against black, that i guess was the moz-textfield color on CentOS, now we use Fedora too, i'm supposing Fedora could use rbg(26,26,26) for text fields (i don't have a Fedore dist at hand though)
Comment on attachment 441051 [details] [diff] [review]
patch v1.0


Perhaps Armen could confirm the text colour of textboxes. A screenshot would be ok too.
Attachment #441051 - Flags: review?(enndeakin) → review+
yep, good idea, waiting for a screenshot
Attached image fedora screenshot
looking at the screenshot that Armen showed me on IRC, the textfield color is not black for sure, it's rgb(32,32,32) though, not rgb(26,26,26), not sure about this difference, could be a variation due to a color correction profile.
But seems to confirm that this color is not an hardcoded black.
Attached image centos screenshot
Yep, CentOS fieldtext is black.
Assignee: nobody → mak77
Whiteboard: [orange] → [orange][has patch][can land]
Closed: 10 years ago
Resolution: --- → FIXED
Whiteboard: [orange][has patch][can land] → [orange]
Target Milestone: --- → mozilla1.9.3a5
Blocks: 438871
I suppose we need to land this test fix on 1.9.2 also?
We might not switch to unit tests on the minis for 1.9.1 and 1.9.2.

I will bring it up on the Tuesday meeting to do the final verification with everyone to know that it is fine. I don't want to add extra burden to back port all the fixes for the permanent oranges.
Whiteboard: [orange]
You need to log in before you can comment on or make changes to this bug.