Closed Bug 1600773 Opened 5 years ago Closed 4 years ago

there is no cursor hover feedback for tab bar scroll buttons

Categories

(Core :: CSS Parsing and Computation, defect, P2)

72 Branch
defect

Tracking

()

VERIFIED FIXED
mozilla73
Tracking Status
firefox-esr68 --- unaffected
firefox71 --- wontfix
firefox72 --- verified
firefox73 --- verified

People

(Reporter: billdillensrevenge, Assigned: emilio)

References

(Regression)

Details

(Keywords: regression)

Attachments

(3 files)

Attached image tbsabhf.png

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:72.0) Gecko/20100101 Firefox/72.0

Steps to reproduce:

Open tabs until the scroll buttons appear in the tab bar. Now hover the cursor over the scroll arrows and observe there is no hover feedback. There should be hover feedback for the tab bar scroll buttons. Repro'd in Nightly 72.0a1 (2019-12-02) as well as Beta 71.0 (see attached screenshot, red arrows pointing to the buttons that have no hover feedback)

Status: UNCONFIRMED → NEW
Has Regression Range: --- → yes
Has STR: --- → yes
Component: Untriaged → XUL Widgets
Ever confirmed: true
Flags: needinfo?(bgrinstead)
Keywords: regression
Product: Firefox → Toolkit
Regressed by: 1514926

Emilio, should these two :hover rules be working? https://searchfox.org/mozilla-central/rev/04d8e7629354bab9e6a285183e763410860c5006/browser/themes/shared/toolbarbuttons.inc.css#178-179.

I expect so based on https://drafts.csswg.org/css-shadow-parts/#part:

The shadow-part pseudo-elements can take additional pseudo-classes after them, such as x-button::part(label):hover, but never match the structural pseudo-classes or any other pseudo-classes that match based on tree information rather than local element information.

If I test with a content test case like:

data:text/html,<style>
      my-element::part(inner):hover { background: red; }
    </style>
    <script>
      customElements.define(
        "my-element", class extends HTMLElement {
          constructor() {
            super();
            this.attachShadow({ mode: "open" });
            this.shadowRoot.innerHTML = "<span part='inner'>a</span>";
          }
        }
      );
    </script>
    <my-element></my-element>

then the hover rule doesn't apply, but if I change the selector to my-element:hover::part(inner) then it does (of course, it's not the desired behavior but it does work just as a sanity check).

Flags: needinfo?(bgrinstead) → needinfo?(emilio)

Yes it should, it's a silly bug.

Assignee: nobody → emilio
Blocks: 1505489
Flags: needinfo?(emilio)
Attached file testcase

If you uncomment the rule inside the shadow root, then it works.

I was going to send a test for :focus via wpt, but then realized it was
probably not spec-compliant with the new rules people want to follow for
:focus, so I filed https://github.com/w3c/csswg-drafts/issues/4555 instead.

Testing :hover / :active via wpt looked quite a bit of a hassle.

BTW, this works on Linux, is this bug mac/win only or something?

Component: XUL Widgets → CSS Parsing and Computation
Priority: -- → P2
Product: Toolkit → Core

(In reply to Emilio Cobos Álvarez (:emilio) from comment #6)

BTW, this works on Linux, is this bug mac/win only or something?

my laptop is on Windows 10 v1903, sorry I don't have access to and macs or linux machines

(In reply to Emilio Cobos Álvarez (:emilio) from comment #6)

BTW, this works on Linux, is this bug mac/win only or something?

I can reproduce the reported problem and the reduced cases in Comment 2 / Comment 4 on OSX.

Hi,

This issue is also reproducible on latest Nightly 73.0a1 (2019-12-02), so I will update the flag accordingly.

Comment on attachment 9113097 [details]
Bug 1600773 - Invalidate shadow part pseudo-class styles correctly. r=heycam

Beta/Release Uplift Approval Request

  • User impact if declined: see comment 0
  • Is this code covered by automated tests?: Yes
  • Has the fix been verified in Nightly?: Yes
  • Needs manual test from QE?: Yes
  • If yes, steps to reproduce: comment 0
  • List of other uplifts needed: none
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): Invalidates ::part() pseudo rules more often.
  • String changes made/needed: none
Attachment #9113097 - Flags: approval-mozilla-beta?
Flags: qe-verify+
Pushed by ealvarez@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/dc7693501534
Invalidate shadow part pseudo-class styles correctly. r=heycam
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla73
QA Whiteboard: [qa-triaged]

Verified - fixed on latest Nightly 73.0a1 (2019-12-09) (Build id: 20191209215019) on Mac OS 10.14 and Windows 10.

Comment on attachment 9113097 [details]
Bug 1600773 - Invalidate shadow part pseudo-class styles correctly. r=heycam

stylo regression introduced in 71. verified in nightly, adds test. approved for 72.0b5

Attachment #9113097 - Flags: approval-mozilla-beta? → approval-mozilla-beta+

Verified - fixed on latest Beta 72.0b5 (Build id: 20191210160808) on Mac OS 10.14 and Windows 10.

Status: RESOLVED → VERIFIED
QA Whiteboard: [qa-triaged]
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: