1255656 - TEST-UNEXPECTED-PASS | /quirks-mode/hashless-hex-color.html | 1111111111...a (quirks) - expected FAIL with Visual Studio 2015

Status: RESOLVED FIXED

(Core :: CSS Parsing and Computation, defect)

Description

[Gregory Szorc [:gps]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=5c2a7b4e81d0 (PGO) and https://treeherder.mozilla.org/#/jobs?repo=try&revision=d67e4a1f3735 are both showing TEST-UNEXPECTED-PASS | /quirks-mode/hashless-hex-color.html | 1111111111...a (quirks) - expected FAIL with *some* Visual Studio 2015 build configurations.

The failure seems consistent. But it does depend on the build configuration.

Comment 1

[Gregory Szorc [:gps]]

Oh, I think the failure is consistent. For whatever reason, the failure sometimes occurs in W3 and other times in W5.

Comment 2

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

FWIW, this test is marked with

      if (os == "win") and (version == "6.2.9200") and (processor == "x86_64") and (bits == 64): FAIL
      if (os == "win") and (version == "5.1.2600") and (processor == "x86") and (bits == 32): FAIL
      if (os == "win") and (version == "6.1.7601") and (processor == "x86") and (bits == 32): FAIL
      if (os == "win") and (version == "10.0.10240") and (processor == "x86_64") and (bits == 64): FAIL

so possibly a bug in VS somewhere that this manages to hit?

It seems somewhat plausible to be in

6694       case eCSSToken_Dimension:
6695         if (tk->mIdent.Length() <= 6) {
6696           snprintf_literal(buffer, "%06.0f", tk->mNumber);
6697           nsAutoString temp;
6698           temp.AssignWithConversion(buffer);
6699           temp.Right(str, 6 - tk->mIdent.Length());
6700           str.Append(tk->mIdent);
6701         }

in CSSParserImpl::ParseColor.

Comment 3

[Intermittent Failures Robot]

20 automation job failures were associated with this bug in the last 7 days.

Repository breakdown:
* try: 20

Platform breakdown:
* windows7-32: 14
* windows8-64: 6

For more details, see:
https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1255656&startday=2016-03-07&endday=2016-03-13&tree=all

Comment 4

[Gregory Szorc [:gps]]

Ms2ger: this is one of the very few remaining blockers for landing VS2015. What do we need to do here? Can we disable this test as a temporary workaround?

Comment 5

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

Assuming the update fixes it everywhere, just remove the [1111111111...a (quirks)] block from testing/web-platform/meta/quirks-mode/hashless-hex-color.html.ini.

Comment 6

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

It looks like this test is the one that currently says:

  [1111111111...a (quirks)]
    expected:
      if not debug and (os == "win") and (version == "6.2.9200") and (processor == "x86_64") and (bits == 64): FAIL
      if not debug and (os == "win") and (version == "5.1.2600") and (processor == "x86") and (bits == 32): FAIL
      if not debug and (os == "win") and (version == "6.1.7601") and (processor == "x86") and (bits == 32): FAIL
      if debug and (os == "win") and (version == "5.1.2600") and (processor == "x86") and (bits == 32): FAIL
      if debug and (os == "win") and (version == "6.2.9200") and (processor == "x86_64") and (bits == 64): FAIL
      if debug and (os == "win") and (version == "6.1.7601") and (processor == "x86") and (bits == 32): FAIL
      if debug and (os == "win") and (version == "10.0.10240") and (processor == "x86_64") and (bits == 64): FAIL
      if not debug and (os == "win") and (version == "10.0.10240") and (processor == "x86_64") and (bits == 64): FAIL

which smells a lot like a workaround for a windows compiler bug!  Seems like those conditions just need adjusting appropriately to not trigger for VS2015 builds.

(Also, how did we end up with such specific conditions!?)

Comment 7

[Gregory Szorc [:gps]]

Attachment: MozReview Request: Bug 1255656 - Remove expected fail for 1111111111...a (quirks) test; r?Ms2ger

According to dbaron, the deleted block smells like a workaround for
a compiler bug which no longer reproduces in VS2015. This is the last
bug blocking the landing of VS2015. So remove the apparent workaround.

Review commit: https://reviewboard.mozilla.org/r/42205/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/42205/

Comment 8

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

Comment on attachment 8734394 [details]
MozReview Request: Bug 1255656 - Remove expected fail for 1111111111...a (quirks) test; r?Ms2ger

https://reviewboard.mozilla.org/r/42205/#review38775

LGTM, assuming it's pushed along with the compiler change.

Comment 9

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/f231263334d4

Comment 10

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/d1857ecc7da0

Comment 11

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/f231263334d4