Open Bug 1730729 Opened 3 years ago Updated 3 years ago

Hovering rendering is Intermittent in a web component

Categories

(Core :: Graphics, defect, P4)

Firefox 93
x86_64
macOS
defect

Tracking

()

Tracking Status
firefox93 --- affected

People

(Reporter: jachin.rupe, Unassigned, NeedInfo)

References

(Blocks 1 open bug)

Details

(Keywords: correctness)

Attachments

(1 file)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:93.0) Gecko/20100101 Firefox/93.0

Steps to reproduce:

I have a video that hopefully show's what happens, but when I move my mouse over an element, triggering it's hover state, sometimes it renders correctly, but sometimes it's blank.

The details are a little complicated, I've got a web component, inside of another web component. I can provide more details if you need them.

Actual results:

When moving the mouse (like a normal user) the problem is Intermittent, however when I use the Developer tools to trigger the hover state it seems to always work.

Expected results:

My hover css should just work.

I can't tell if the video got attached. Let me know if I need to attach it again.

The Bugbug bot thinks this bug should belong to the 'Core::Graphics' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Component: Untriaged → Graphics
Product: Firefox → Core

Can you provide a link to a testcase?

Flags: needinfo?(jachin.rupe)

I don't really have one. I ran into this in kind of a complicated situation. I started working on a small example that demonstrates the issue... but I haven't succeeded yet. I'm kinda stabbing in the dark here since I don't really know what could be contributing to it. My top guesses right now are...

  • The parent element is position: absolute.
  • The parent is brought in and out of visibility and has other translations applied to it
  • The way the custom elements are styles with a mix of shadow and light DOM element.
  • It's managed by a virtual dom (via the Elm Runtime)

But it might not be any of those things.

S4 until we have a testcase.

Severity: -- → S4
Priority: -- → P4

(In reply to jachin.rupe from comment #5)

I don't really have one. I ran into this in kind of a complicated situation. I started working on a small example that demonstrates the issue... but I haven't succeeded yet. I'm kinda stabbing in the dark here since I don't really know what could be contributing to it. My top guesses right now are...

  • The parent element is position: absolute.
  • The parent is brought in and out of visibility and has other translations applied to it
  • The way the custom elements are styles with a mix of shadow and light DOM element.
  • It's managed by a virtual dom (via the Elm Runtime)

But it might not be any of those things.

It doesn't need to be a simple testcase, just something that we can access in order to debug the issue, it can be a full and complicated webpage.

If that's not possible you could try running https://mozilla.github.io/mozregression/ on your local testcase to see what might have regressed it, if indeed it is a regression.

Blocks: wr-mac
Keywords: correctness
OS: Unspecified → macOS
Hardware: Unspecified → x86_64
See Also: → 1730075
See Also: → 1730516

The bug has a release status flag that shows some version of Firefox is affected, thus it will be considered confirmed.

Status: UNCONFIRMED → NEW
Ever confirmed: true
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: