Can you provide a reproduction URI?

http://23.228.231.35/SigoQA/Login.aspx   User and password = demo

Using the per-revision bisect providing the bisect results,
Good build:54.0.2788.0(Revision: 403706).
Bad build: 54.0.2790.0 (Revision:404030).

You are probably looking for a change made after 403843 (known good), but no later than 403844 (first known bad).

CHANGELOG URL:
---------------
https://chromium.googlesource.com/chromium/src/+log/53feaa41b65987c69f54da1152d50f45e04deaac..a46d892723fe86a7f49113c46e3c40c2343724ce


@alancutter - Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner.

The inline z-index values appear to be different in Firefox vs Chrome.

There are two elements of interest here:
 - The #ext-gen20 element that holds the main form content of the page.
 - The #Menu10 element that holds the menu that appears on mouse over, this one should appear on top of #ext-gen20.

In Firefox:
 - #ext-gen20 has z-index set to 9000.
 - #Menu20 has z-index set to 15005.

In Chrome:
 - #ext-gen20 has z-index set to 9000.
 - #Menu20 has z-index set to 5.

I suspect this is due to the change in getComputedStyle() behaviour caused by https://codereview.chromium.org/2047283002 where the test case:

https://jsfiddle.net/0h1b4pzu/
This should be 10:
<div id="target" style="z-index: 10"></div>
<script>
target.textContent = getComputedStyle(target).zIndex;
</script>

went from "auto" to "0". In Firefox it outputs "10" as expected.
The form framework probably had a workaround for Chrome returning "auto" that no longer works when Chrome returns "0" instead.

Submitted behavioural revert patch: https://codereview.chromium.org/2439663002
Confirmed that the menus appear on hover with this change.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/664d4716b91e01c779a77702e9f219c2744724e0

commit 664d4716b91e01c779a77702e9f219c2744724e0
Author: alancutter <alancutter@chromium.org>
Date: Fri Oct 21 02:18:56 2016

Return "auto" for computed z-index on non-stacking-context element

Following https://codereview.chromium.org/2047283002 we were returning
"0" for getComputedStyle(element).zIndex for elements that were not
stacking contexts. Previously we would return "auto". Both behaviours
are incorrect.

This patch reverts the change in getComputedStyle() behaviour back
to "auto".

BUG= 656681 

Review-Url: https://chromiumcodereview.appspot.com/2439663002
Cr-Commit-Position: refs/heads/master@{#426690}

[modify] https://crrev.com/664d4716b91e01c779a77702e9f219c2744724e0/third_party/WebKit/LayoutTests/fast/css/getComputedStyle/getComputedStyle-zIndex-non-auto-expected.txt
[modify] https://crrev.com/664d4716b91e01c779a77702e9f219c2744724e0/third_party/WebKit/Source/core/css/ComputedStyleCSSValueMapping.cpp

Merge request fix for beta and stable added.

Could the original filer of the issue please give an estimate of the number of users impacted by this bug?

[Automated comment] Request affecting a post-stable build (M54), manual review required.

Your change meets the bar and is auto-approved for M55 (branch: 2883)

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/f22b7f69fd74027b685047b3f06dab55a0b69a04

commit f22b7f69fd74027b685047b3f06dab55a0b69a04
Author: Alan Cutter <alancutter@chromium.org>
Date: Mon Oct 24 23:59:50 2016

Return "auto" for computed z-index on non-stacking-context element

Following https://codereview.chromium.org/2047283002 we were returning
"0" for getComputedStyle(element).zIndex for elements that were not
stacking contexts. Previously we would return "auto". Both behaviours
are incorrect.

This patch reverts the change in getComputedStyle() behaviour back
to "auto".

BUG= 656681 

Review-Url: https://chromiumcodereview.appspot.com/2439663002
Cr-Commit-Position: refs/heads/master@{#426690}
(cherry picked from commit 664d4716b91e01c779a77702e9f219c2744724e0)

Review URL: https://codereview.chromium.org/2450583002 .

Cr-Commit-Position: refs/branch-heads/2883@{#270}
Cr-Branched-From: 614d31daee2f61b0180df403a8ad43f20b9f6dd7-refs/heads/master@{#423768}

[modify] https://crrev.com/f22b7f69fd74027b685047b3f06dab55a0b69a04/third_party/WebKit/LayoutTests/fast/css/getComputedStyle/getComputedStyle-zIndex-non-auto-expected.txt
[modify] https://crrev.com/f22b7f69fd74027b685047b3f06dab55a0b69a04/third_party/WebKit/Source/core/css/ComputedStyleCSSValueMapping.cpp

Verified the issue on windows 10, Ubuntu 14.04 and Mac 10.11.6 using chrome beta version #55.0.2883.28 as per the comment #0

Observed that the fix is working as expected.

Attaching screen cast for reference

Hence, adding the verified labels.

Deleted: 656681.ogv 917 KB

	656681.ogv 917 KB View Download

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/f22b7f69fd74027b685047b3f06dab55a0b69a04

commit f22b7f69fd74027b685047b3f06dab55a0b69a04
Author: Alan Cutter <alancutter@chromium.org>
Date: Mon Oct 24 23:59:50 2016

Return "auto" for computed z-index on non-stacking-context element

Following https://codereview.chromium.org/2047283002 we were returning
"0" for getComputedStyle(element).zIndex for elements that were not
stacking contexts. Previously we would return "auto". Both behaviours
are incorrect.

This patch reverts the change in getComputedStyle() behaviour back
to "auto".

BUG= 656681 

Review-Url: https://chromiumcodereview.appspot.com/2439663002
Cr-Commit-Position: refs/heads/master@{#426690}
(cherry picked from commit 664d4716b91e01c779a77702e9f219c2744724e0)

Review URL: https://codereview.chromium.org/2450583002 .

Cr-Commit-Position: refs/branch-heads/2883@{#270}
Cr-Branched-From: 614d31daee2f61b0180df403a8ad43f20b9f6dd7-refs/heads/master@{#423768}

[modify] https://crrev.com/f22b7f69fd74027b685047b3f06dab55a0b69a04/third_party/WebKit/LayoutTests/fast/css/getComputedStyle/getComputedStyle-zIndex-non-auto-expected.txt
[modify] https://crrev.com/f22b7f69fd74027b685047b3f06dab55a0b69a04/third_party/WebKit/Source/core/css/ComputedStyleCSSValueMapping.cpp

Thank you for your attention.
When will be available the new version?

This fix has already been merged to M55 which will be released to stable in early December. The request to merge to current stable (M54) is still under review.

 Issue 669657  has been merged into this issue.

This bug is affecting other UI frameworks as well (see  issue 669657 ).
Please review the merge request for M55.

Sorry, meant to say "Please review the merge request for M54".

I had created the duplicate  issue 669657  which affected the Ext.Net UI Framework.  I just tested this in latest Chrome release, and it appears to be fixed in Version 55.0.2883.75 m.  

Thanks for getting this merged in so fast!

Ah, 55 has gone stable already so I guess the merge to 54 is no longer needed.