1770532 - In WebKit's bugzilla instance, the CC list's "Edit|Add..." autocomplete dropdown has an unexpectedly transparent background

Status: RESOLVED FIXED

(Core :: Layout: Form Controls, defect)

Description

[Daniel Holbert [:dholbert]]

STR:

1. Be logged in on WebKit's bugzilla instance, like e.g. https://bugs.webkit.org
2. Visit some bug report over there, like this one: https://bugs.webkit.org/show_bug.cgi?id=240744
3. Next to "CC List" at top right, click "Edit" and then type "a" into the "Add" textfield.

ACTUAL RESULTS:
The autocomplete-dropdown's text is superimposed/intermixed with the text in the multi-select pane below it (which it is supposed to cover up).

EXPECTED RESULTS:
The multiselect (and its text) should be fully obscured by the dropdown.

mozregression says this regressed from bug 1741776.

Comment 1

[Daniel Holbert [:dholbert]]

Attachment: testcase 1

This is surprisingly easy to trigger... I'm surprised we haven't had this bug reported yet.

This reduced testcase is just:

<style>
  .abspos {
    position: absolute;
    background-color: cyan;
    height: 300px;
    width: 300px;
  }
</style>
<div class="abspos"></div>
<select multiple="multiple">
  <option>This text shouldn't be visible.</option>
</select>

The abspos thing correctly paints in front of the option, but we incorrectly paint the option text in the foreground (in front of the abspos thing).

Comment 2

[Daniel Holbert [:dholbert]]

Calling this S3 given we've been shipping with it for a while with no reports yet (or at least, none that we connected to the regressing bug before this point)... But it looks pretty darn broken on WebKit's bugzilla instance, so (to the extent that web content hits it) it feels somewhere between S2 and S3.

Comment 3

[Daniel Holbert [:dholbert]]

Attachment: screenshot showing the bug (at https://bugs.webkit.org/show_bug.cgi?id=240744 per STR)

Comment 4

[Daniel Holbert [:dholbert]]

Attachment: testcase 2 (interoperable, doesn't show a bug; just here to explore/illustrate beahvior)

Here's a testcase like testcase 1, but with several divs that create stacking contexts after the abspos thing, instead of a multi-select element.

As shown here, the stacking contexts (from will-change:transform and opacity:0.9) do paint in front of their abspos predecessor; but the regular div paints behind it. This behavior is interoperable, and required by CSS's elaborate description of stacking contexts, I think.

So, our current behavior on testcase 1 (with the multi-select) is really a "correct" downstream result of us styling our option elements with will-change:transform in bug 1741776.

I think we didn't really intend for this will-change:transform styling to make a user-observable difference (outside of the fact that we did indeed want to contain positioned descendants, as described in bug 1741776). So, I suspect the eventual fix here might be to revert bug 1741776's fix and achieve the same outcome without forcing the option element to be a stacking context, perhaps?

(ni=emilio, in case he has any thoughts/ideas - thanks!)

Comment 5

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1741776

Comment 6

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1770532 - Ensure options in listbox selects are not stacking contexts by default. r=dholbert

We could have a different property or something but this seems
reasonable as well probably.

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/13e019e7fead
Ensure options in listbox selects are not stacking contexts by default. r=dholbert

Comment 8

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/34156 for changes under testing/web-platform/tests

Comment 9

[Marian-Vasile Laza]

https://hg.mozilla.org/mozilla-central/rev/13e019e7fead

Comment 10

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR merged by moz-wptsync-bot