1600815 - Select/Option dropdown closes randomly when opening dropdown

Status: RESOLVED DUPLICATE of bug 1430892

(Core :: Widget: Cocoa, defect, P2)

Description

[silasvv]

Attachment: bugReport.mp4

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36

Steps to reproduce:

Summary:
The issue is with Select/Option dropdowns on a HTML form displayed through a PHP file. Upon clicking the dropdown to open, the dropdown will open but also immediately close. The dropdown can still be operated via arrow keys and by holding down a click and moving about the list that way. The behavior is not consistent and will happen at random.

This is an issue that seems to be isolated to my machine. Although all my coworkers don't seem to be experiencing the issue, I am a developer and need to find out the ultimate cause of the problem if possible to make sure nobody else is impacted and hopefully get Firefox working properly with my machine as well.

Troubleshooting:
I've uninstalled and reinstalled Firefox, started Firefox in Safe Mode, tried regular Firefox in 70 branch, updated my machine, etc. I've checked that the PHP renders into valid HTML and tried to make sure all my variables are accounted for. Issues with JavaScript and CSS have been eliminated since I've disconnected all those files and the issue is still present.

Additional Info/Theories:
I've searched through support forums and cannot find much information about this issue. There are some mentions of similar issues but nothing that seems to explain this. With all the JS & CSS deleted and HTML validated, I think this eliminates the chance of the issue being found within the code. This leaves 1) my machine, 2) the browser 3) the server, or 4) WordPress. Being that all my coworkers and all other browsers are working fine, I would chalk this up to a mixture of machine configuration (possible outright the OS) and the browser itself.

Browser: Firefox Developer Edition 71.0b12 (64-bit)
OS: macOS Catalina 10.15.1 (19B88)
URL: I have to keep this private since this is a business project; will disclose to support team privately if requested. Form code below.

PHP/HTML form:

        $form_block = "<FORM class=\"contactForm container\" id=\"contact\" METHOD=\"POST\" enctype=\"multipart/form-data\" ACTION=\"[>>REDACTED<<]\" >
        <p><strong>Name:</strong><br /><input type=\"text\" name=\"customerName\" aria-label=\"name input\" value=\"$_POST[customerName]\" size=30 /></p>
        <p><strong>Subject:</strong><br /><select aria-label=\"subject dropdown\" name=\"customerSubject\">
        <option value=\"General question\">General questions</option>
        <option value=\"Request services\">Request services</option>
        <option value=\"Schedule training\">Schedule training</option>
        <option value=\"Explain a policy\">Explain a policy</option>
        <option value=\"Report a concern\">Report a concern</option>
        <option value=\"Miscellaneous request\">Other</option>
        </select></p>
        <p><strong>Email: <span style='color:#E60000;'>* Required</span></strong><br />
        <input type=\"text\" name=\"email\" aria-label=\"email input\" value=\"$_POST[email]\" size=30 /></p>
        <p><strong>Phone:</strong><br /><input type=\"text\" name=\"phone\" aria-label=\"phone input\" value=\"$_POST[phone]\" size=30 /></p>
        <p><strong>Department:</strong><br />
        <input type=\"text\" name=\"department\" aria-label=\"department input\" value=\"$_POST[department]\" size=30 /></p>
        <p class=\"messageArea\"><strong>Message: <span style='color:#E60000;'>* Required</span></strong><br />
        <textarea name=\"message\" aria-label=\"message input\" cols=100 rows=5>$_POST[message]</textarea><br />
        </p>
        <p><input type=\"file\" name=\"attachment\" accept=\"audio/*,video/*,image/*\" aria-label=\"file attachment\" /></p>
        <div class=\"g-recaptcha\" data-sitekey=\"[>>REDACTED<<]\"></div>
        <input type=\"hidden\" name=\"[>>REDACTED<<]\" value=\"[>>REDACTED<<]\" aria-label=\"hidden input\" />
        <p><input type=\"submit\" name=\"submit\" value=\"Submit\" aria-label=\"submit button\" /></p>
        </FORM>";

        echo "$form_block";

Actual results:

The dropdown opens and immediately closes. This happens at random and sometimes the dropdown will work as expected. I can still operate the dropdown via arrows and by holding down the mouse and moving it about the options that way.

Nobody else, including coworkers also on macOS Catalina, seem to be experiencing the issue.

Expected results:

The dropdown should open and stay open until an option is clicked.

Comment 1

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

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Comment 2

[Emilio Cobos Álvarez [:emilio]]

Could you attach the page as HTML, with all the CSS involved? Otherwise it is not really actionable.

Thanks!

Comment 3

[silasvv]

Attachment: HTML as rendered by Firefox

(In reply to Emilio Cobos Álvarez (:emilio) from comment #2)
> Could you attach the page as HTML, with all the CSS involved? Otherwise it is not really actionable.
> 
> Thanks!

Hello Emilio, 

Correction on something. -- WP has nothing to do with it. The PHP files are being published statically via WebDAV. 

Here is the full HTML as rendered by Firefox. No CSS & no JS on the page as you will see.

Comment 4

[silasvv]

Attachment: Video showing bug occurring with only HTML, along with version numbers

Comment 5

[Emilio Cobos Álvarez [:emilio]]

Thanks! I cannot reproduce this on Linux, so it seems it might be a mac-specific bug, moving to the right component so the right people see it...

Two questions:

• Do you have a multi-monitor setup by chance?
• Did this work in the past?

Comment 6

[silasvv]

Emilio,

For what it is worth, my coworkers could not reproduce on any of their devices, some of which include macs on Catalina. Either I got unlucky while trying to reproduce the bug with them, or only very small percentage of the population is impacted by this.

-Do you have a multi-monitor setup by chance?
-Yes, (2x) 27" LG 27mu88w in addition to the native laptop display
-Did this work in the past?
-Yes, I developed this website roughly 6 months ago and did thorough cross-browser and device compatibility testing. I also do weekly testing, which is how I found this problem. Not saying that I would definitively have caught the issue, but I think it is probably an issue that started in the last 2 or so months.

Comment 7

[Emilio Cobos Álvarez [:emilio]]

Thank you, it's good to know it doesn't affect all mac users. The multi-monitor setup was because of bug 1391627... But this looks much more severe.

Sorry for asking even more of you, but if you had the time (it's totally fine to say no of course), given this is hard to reproduce, is there any chance you could run mozregression to see what change broke it? That may be the easiest way to figure out a fix for this.

Otherwise is there any chance of having an screenshot of your screen configuration, just in case it is relevant? Thanks so much for reporting it again (and sorry I can't repro this :/).

Comment 8

[silasvv]

Emilio,

Thank you for tipping me off to Mozregression. It truly looks like an awesome tool but I don't think I can justify giving the application admin access with work data on my box.

I will attach a screenshot of screen configuration for you. That being said, I unplugged the extra monitors, restarted the computer, and could reproduce the bug just the same.

Comment 9

[silasvv]

Attachment: Display Settings

Comment 10

[Stephen A Pohl [:spohl] (OOO until 3/13)]

This seems like a duplicate of bug 1591041. Reporter, could you confirm?

(In reply to silasvv from comment #8)

Thank you for tipping me off to Mozregression. It truly looks like an awesome tool but I don't think I can justify giving the application admin access with work data on my box.

A regression point would be incredibly helpful to have. If anyone else can reproduce reliably, getting a regression range would be the fastest way to getting this bug fixed.

Comment 11

[Emilio Cobos Álvarez [:emilio]]

Why does it need admin access? It definitely doesn't on Linux. Maybe it's only the gui? I can use it from the terminal as follows:

$ pip2 install --user mozregression
$ mozregression --launch 20191202220401

Comment 12

[Emilio Cobos Álvarez [:emilio]]

Ah, probably it is the sudo for the installation command? mozregression doesn't use the admin access, that only installs the tool in a global directory rather than local. Probably the commands above work just fine in mac too.

Comment 13

[silasvv]

Emilio,
Thank you for the commands. I'll keep researching and reconsider downloading the tool.

Stephen,
It doesn't seem to be the same issue as that bug; moving or not moving doesn't affect the behavior I am experiencing. The behavior happens either way at random.

As a side note, I can hold down a click and then the dropdown works as expected. Arrow keys also work just fine.

Comment 14

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

The priority flag is not set for this bug.
:spohl, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 15

[Paul]

I have been having a very similar problem and have narrowed it down with Mozregression.

It works as expected in the 2019-10-12 00:08:38.627000 release but is broken from this point forward:

app_name: firefox
build_date: 2019-10-12 00:37:53.513000
build_file: C:\Users\user.name.mozilla\mozregression\persist\c42855b477b1-shippable--autoland--target.zip
build_type: inbound
build_url: https://queue.taskcluster.net/v1/task/dn8pPZoXQSKXSDBeQczmdQ/runs/0/artifacts/public%2Fbuild%2Ftarget.zip
changeset: c42855b477b170876a13ae32a60032d06698814c
pushlog_url: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=d7e83d739e267950277d621e71b1736c390a8569&tochange=c42855b477b170876a13ae32a60032d06698814c
repo_name: autoland
repo_url: https://hg.mozilla.org/integration/autoland
task_id: dn8pPZoXQSKXSDBeQczmdQ

Some additional points:

• This doesn't break when you are at the very top of the page (i.e. haven't scrolled)
• In my case, the form (and body) has a display: table style and the autocomplete div has a display: block style. If I change them to be the same (either both a table or both a block) it works as expected.

Unable to post the url here but can provide if someone from the team messages me.

Comment 16

[Paul]

Attachment: mozregression.log

Here is the mozregression log that narrowed the issue down to being introduced by the following:

app_name: firefox
build_date: 2019-10-12 00:08:38.627000
build_file: C:\Users\user.name.mozilla\mozregression\persist\d7e83d739e26-shippable--autoland--target.zip
build_type: inbound
build_url: https://queue.taskcluster.net/v1/task/Ak6vBpZtS7G9ijMay2ffeQ/runs/0/artifacts/public%2Fbuild%2Ftarget.zip
changeset: d7e83d739e267950277d621e71b1736c390a8569
pushlog_url: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=d7e83d739e267950277d621e71b1736c390a8569&tochange=6f876f24a948c758146f87733a9895722b441c6a
repo_name: autoland
repo_url: https://hg.mozilla.org/integration/autoland
task_id: Ak6vBpZtS7G9ijMay2ffeQ

Comment 17

[Emilio Cobos Álvarez [:emilio]]

Do you have a test-case for that Paul? That sounds more likely to be bug 1440506.

Comment 18

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

Bugbug thinks this bug is a regression, but please revert this change in case of error.

Comment 19

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

Redirect a needinfo that is pending on an inactive user to the triage owner.
:spohl, since the bug has high priority, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 20

[Jonathan Watt [:jwatt]]

silasvv, does this bug still occur for you?