1778923 - Firefox sends mouseout events with a null relatedTarget when a select control opens

Status: NEW

(Core :: DOM: Events, defect, P3)

Description

[Jeff Muizelaar [:jrmuizel]]

From https://github.com/webcompat/web-bugs/issues/107135

Trying to select the quantity when doing a return doesn't work. The select box disappears as soon as you click it.

Comment 1

[Jeff Muizelaar [:jrmuizel]]

Attachment: A reduced test case that shows the problem

The original source code does something like:

                    if ((isMouseLeave || isClick) && $(".js-header .ar-header__search-input").val() != app.search.getSearchParams().q) {
                        if (!$("input:focus").length) {
                            $(".js-header .ar-header__search-input").val("").focus().blur()
                        }
                    }

Comment 2

[Jeff Muizelaar [:jrmuizel]]

Attachment: Reduced test case that avoids jquery

This test case clearly shows the difference. Firefox sends mouseout events with a null relatedTarget when the select control opens. Chrome and Safari do not.

Comment 3

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Smaug, do you have any ideas about this? (Edgar is in PTO now so that I ask you.)

Comment 4

[Olli Pettay [:smaug][[e-mail]]]

This is tricky one since the behavior Gecko has is more reasonable.

Comment 5

[Jeff Muizelaar [:jrmuizel]]

Can you explain why?

Is there any chance we could spec our behaviour or get the other browsers to switch?

Comment 6

[Jeff Muizelaar [:jrmuizel]]

Why is this only considered an S3?

Comment 7

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

(In reply to Jeff Muizelaar [:jrmuizel] from comment #6)

Why is this only considered an S3?

I thought about several things: how broken was the page ? According to my understanding from the webcompat report and QA testing, I didn't consider it "severely impaired" because for example, adding an item into cart still worked as expected. I didn't seem to find other duplicates of this mouseout behavior that was another factor that I didn't consider it "severely impaired". I also looked at the website ranking and compared the ranking of the sites with other triaged webcompat bugs . I could have mixed up ranking comparison or undervalued the impact. Please feel free to suggest the right severity. I also marked Webcompat Priority? to bring to the webcompat team's radar and see if there's something we can do with system addons (assuming it may take long to address the platform change per comment 4?).

Comment 8

[Ksenia Berezina [:ksenia]]

Setting Webcompat Priority as P2 since this is an important site, but not all users of the site are affected. Adding a ni for Tom to investigate a possible sitepatch

Comment 9

[Olli Pettay [:smaug][[e-mail]]]

edgar, you've looked into cross-process mouse enter/leave (in widget sense) code. Do you think we could do something for this case?

Comment 10

[Thomas Wisniewski [:twisniewski]]

Unfortunately I can't really study this on their live site, but running this code early on the page fixes the testcase (both with jQuery and without, by preventing the extra mouseout events from being seen by the page):

document.documentElement.addEventListener("mouseout", e => {
  if (!e.relatedTarget && e.target.nodeName === "SELECT") {
    e.stopPropagation();
  }
}, {capture:true});

If we think this site is still affected, we can try this. Dennis, you have the 126 intervention cycle.. what do you think?

Comment 11

[Dennis Schubert [:denschub]]

Sure, we can at least try. Filed bug 1890272 for that.

Comment 12

[Raul Bucata]

Verified this issue and still reproduces on Firefox Nightly based on test case. The drop-down fails to stay open.

Tested with:

Browser / Version: Firefox Nightly 128.0a1 (2024-05-29) (64-bit)
Operating System: Windows 10 PRO x64