1911251 - digitalocean.com - The fields can't be completed after scrolling the page

Status: NEW

(Web Compatibility :: Site Reports, defect, P2)

Description

[railioaie]

Environment:
Operating System: macOS
Firefox version: Firefox Nightly 130.0a1 (2024-08-01) / Firefox Release 128.0.3

Preconditions:
Clean profile

Steps to reproduce:

1. Navigate on https://www.digitalocean.com/careers/position/apply?gh_jid=4385190
2. Do not scroll, wait for form to load
3. Without scrolling, click on the first field
4. Observe it can be interacted with
5. Scroll down, click on another field
6. Observe it cannot be interacted with
7. Scroll back to top, click on the first field
8. Observe it can be interacted with

Expected Behavior:
The fileds can be completed as expected

Actual Behavior:
The fields can't be completed after scrolling the page

Notes:

• Reproduces regardless of the status of ETP
• Reproduces in Firefox Nightly, Firefox Release
• Does not reproduce in Chrome

Comment 1

[Jeff Muizelaar [:jrmuizel]]

An updated URL: https://www.digitalocean.com/careers/position/apply?gh_jid=6174451

Comment 2

[Ksenia Berezina [:ksenia]]

This is likely the same issue as observed in bug1857865

Comment 3

[Alexandre Poirot [:ochameau]]

This doesn't seem to be related to JavaScript.

Hiding the <ul> element of the top navbar whose selector is ul.Navigationstyles__StyledNavigationList-sc-16d688r-2.lgNUwG seems to make the problem go away.
You can see that by evaluating the following js in your console:
$("ul.Navigationstyles__StyledNavigationList-sc-16d688r-2.lgNUwG").style.display = "none"

It makes no sense to me as this <ul> element doesn't do anything special and feel very disconnected from the <iframe>.

Interestingly, this bug around mouse events also impacts DevTools.
When using the inspector's node picker, we are also missing mousemove event to be fired within the iframe.
When using the node picker, without scrolling, you can hover elements within the iframe. After scrolling you can't and the whole iframe is selected instead.

Comment 4

[Alexandre Poirot [:ochameau]]

Actually, it relates to all the $$(".hJbnLp") elements.
These are the menu shown when hovering "Products, Solutions, ..." menus.

Here is their default CSS rules:

.hJbnLp {
    display: block;
    height: auto;
    top: 100%;
    transition: opacity 300ms ease-in-out 300ms;
    border: 1px solid red;
    background: red;
    clip-path: polygon(0px 0px, 100% 0px, 100% 0%, 0px 0%);
    opacity: 0;
}

These elements are overlapping the <iframe>, but are otherwise made invisible thanks to their clip-path which is having a 100% width, but a 0 height.
When hovering the menu they are made visible thanks to clip-path: polygon(0px 0px, 100% 0px, 100% 100%, 0px 100%); and opacity: 1.

For some reason this clip-path trick doesn't prevent event from being captured/oriented to these hidden elements instead of the actually displayed iframe element.
Surprisingly, removing the opacity: 0 and let it be 1 by default also fix the issue... Is there some interference between empty clip-path and 0 opacity?

Comment 5

[Alexandre Poirot [:ochameau]]

Here is a minimal test case:
data:text/html,<div style="position: absolute;left: 0px;top: 0px;width: 100%; height: 100%; z-index: 100; clip-path: polygon(0px 0px, 100% 0px, 100% 0%, 0px 0%); opacity: 0;"></div><iframe src="http://techno-barje.fr/fission/input"></iframe>

Clicking in the iframe's input doesn't work in Firefox, while it works in Chrome.

It looks like it has to be a cross origin/remote iframe. Using a data URI for the iframe doesn't reproduce the issue.

Comment 6

[Hsin-Yi Tsai (she/her) away [:hsinyi]]

Unfortunately, I verify that the expecting fix for bug 1857865, which are the patches in bug 1889406, doesn't seem to resolve this case.
More diagnosis is still needed.

Comment 7

[Sean Feng [:sefeng]]

This seems like a hit-testing issue. nsFocusManager::SetFocusInner is called with the iframe element rather than the <input>.

Emilio, does it ring any bell? Thanks

Comment 8

[Emilio Cobos Álvarez (:emilio)]

So I can't repro the issue in one of the digitalocean forms anymore, but I can repro using comment 5, it seems clip-path is not accounted for properly on APZ.

Comment 9

[Emilio Cobos Álvarez (:emilio)]

Filed bug 1923513 to track this on the APZ side.