1790752 - Bug 1718868 is back in FF 104 : Toolbox -> Passwordmanager

Status: UNCONFIRMED

(Toolkit :: Password Manager: Site Compatibility, defect, P3)

Description

[support]

Attachment: Bildschirmfoto vom 2022-09-14 10-16-44.png

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:104.0) Gecko/20100101 Firefox/104.0

Steps to reproduce:

focused an innocent input box in a pseudo <form>

Actual results:

the login credentials suggestion box popped up over the input field. See screenshot.

This is a regression of bug 1718868 fixed in FF 91.

That bug is divided in to problems: a) the credentials popupbox b) the subdomaininclude, which is just an option in the abount:config . We now talk about a) .

Expected results:

nothing, it's an input box.

Comment 1

[Daniel Bodea [:danibodea]]

I would like to confirm this issue, but I will need "an innocent input box in a pseudo <form>" to do so.
Could you provide us with a reduced test case to confirm it? Or the page where it was found to reproduce (if it's reachable online)?

Thank you!

Comment 2

[support]

there is one small problem.. the inputbox in question in NOT part of a FORM, it's solo. It's a single page app where all "form"-urls are build by js without any actual form.

As an update, it does not seem to happen everytime, the div with that specific input box is created.

Also, I can image a gitch, which can cause this. The usual usecase is:

1. Login via a FORM, but not a SUBMIT button. Instead a AJAX request is formed, used and than a location.href= "" redirect is executed.

2. After login, the app loads a base HTML frame with HTML, HEAD,BODY etc. and loads some divs with different ui overlays via AJAX, and in special case it loads one overlay with that input box. We use other input boxes at many other places, but those a normally loaded later.

I think, due to the none-usage of a real form-submit, that box, or any other box if presented, triggers the password-toolbox, because the DOM may not be in a consistent state, because the div with the form, has gone. We needed the form to be in the login overlay, because we wanted that passwordbox to come up, which it usually does not, when there is no form involved.

here is the element in question:

<input id=accountsearch0 onkeyup='if ( TastewarReturn(event) ) searchforaccounts(this,0)' class='hauptsuchmaske' value='Domainname' onfocus='if ( this.value="Domainname" ) this.value="";' onblur='if ( this.value=="" ) this.value="Domainname";'>

{In the Inspector-Tab FF does not display those single quotes ->'<- , it uses double-quotes ->"<- for the single ones. I really hope, that's just a display bug.}

There is nothing fancy about that specific element. It does not share any attributes with the ones inside the login form. It maybe just by accident, in the same index slot in the absolute input field listarray, if such one exists in FF at all.

What do you think?

A) do still need a pseudo form somewhere?
B) Do you consider the above glitch describtion as a possible one?

Comment 3

[Daniel Bodea [:danibodea]]

I have very little knowledge of js or generally, of development. I am QA and I attempt to reproduce the issue with the steps you provide in order to confirm the bug and, hopefully, move it along to developers faster for a fix.
I do need a reduced test case in order to do that or, possibly, some explanations as for a person with no knowledge of coding.

I have to mention that I attempted to create one by adding the above code line (and the other similar one in the bug mentioned in the summary) into a basic HTML page and loaded it into Firefox Release v104.0, but I could not observe the Password Manager drop-down to be displayed in a few tries. I could help confirm it and different platforms if some detailed steps to reproduce would be provided.

Thank you for your contribution!

Comment 4

[support]

for ff 105 i'm unable to reproduce it myself.

Comment 5

[Sergey Galich [:serg]]

:support can you make it <input type="search" ...> and let us know if it helps? This should prevent password manager from considering this input as part of multipage formless login form.

Comment 6

[support]

I will try, but as it's not reproducible atm

Comment 7

[Daniel Bodea [:danibodea]]

Based on the reporter's response, I'm closing this report as WORKSFORME.
If you see it reproduce again, please reopen this report and provide the requested information.

Thank you for your contribution!

Comment 8

[support]

REOPEN: >>> THE BUG IS BACK! <<<

Element: Input
Type: search
Version FF 134.0.1
OS: Fedora

Comment 9

[support]

Attachment: Bildschirmfoto vom 2025-02-07 09-22-53-cropped.png

Comment 10

[Martin Stránský [:stransky] (ni? me)]

Please use mozregression to find broken commit:
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Use_Mozregression_tool
Thanks.

Comment 11

[support]

I'm not sure, if we will find anything useful with that tool, the history of my firefox usage does not give any reason to believe that it will.

18.1.2025: FF 134 got installed
7.2.2025: I noticed this is happening again

Because i use this webtool on a daily basis, it must have been noticeable from the 18th of January till now, but it wasn't. It happend today for the first time in 2 years. My thought: a secondary component has been changed.

The issues stopped 2 years ago without revealing any reliable cause, so maybe, it never got fixed in the first place?!?! it could have been stopped, because something else changed.

After checking the update list, i see 3 candidates:

perl-Module-CoreList-1
passt-selinux-0 ( would have a SEL restorecon in the POST Script )
and libdav1d-1.5.0-2

which is a VideoLan Decoder for AV1 , which will be used by firefox. I don't think, that the code inside that lib will be responsible, i have something like "the changed component triggers a not so commonly used function, which sets an attribute to x, which then triggers the password box showup." in mind.

I think, we are more lucky here, as with that regression tool, which would require to copy the profile data before each start for a prolem that did not show up for 3 weeks. I tried that mozregression last time, without any success, so pls don't be mad about favoring a reason more in line with the timeline of events. 40 years of software dev gives you a nose for bugs ;)

Comment 12

[Martin Stránský [:stransky] (ni? me)]

You can use --profile-persistence=reuse to use the profile without copy and --profile arg to set profile for testing.