Closed Bug 1443385 Opened 8 years ago Closed 8 years ago

Invisible auto-complete of text input fields on add-on preference page

Categories

(WebExtensions :: General, defect)

Product:
WebExtensions
Component:
General
Version:
58 Branch
Platform:
x86_64
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: mozilla.org, Unassigned)

Details

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:58.0) Gecko/20100101 Firefox/58.0 Build ID: 20180207210535 Steps to reproduce: 1. Install https://addons.mozilla.org/firefox/addon/insecure-links-highlighter/ 2. Go to the preferences page for the add-on 3. Change the "Border color" value from "red" to for example "rede" 4. Press Enter to see an error message about the value being invalid 5. Press Backspace to remove the last "e" 6. Press Enter Actual results: The field value is automatically changed back to "rede", the previously entered value, before submission. Expected results: The field value should never change from whatever the user entered until after submission. Alternatively, if autocomplete should be enabled on add-on preference pages then the dialogue showing the alternative autocomplete options should show up. I don't believe this is caused by the add-on for three reasons: 1. One work-around is to press Escape after modifying the field but before pressing Enter, *as if* an auto-complete dialogue had shown up. 2. autocomplete="off" on the input field also works, but should not be necessary. 3. Typing in other values, for example "redb", pressing Enter, and changing the value back to "red" it still changes to "rede".
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:58.0) Gecko/20100101 Firefox/58.0 20180206200532 I can't reproduce this.
Has Regression Range: --- → irrelevant
Has STR: --- → yes
Component: Untriaged → Form Manager
Product: Firefox → Toolkit
Interesting, I can't reproduce it on Windows 7 either. Verified 100% reproducible only on Linux.
Tested on two virtually identical Arch Linux machines now, and it's reproducible on both with a new profile. On one of these machines it was reproducible with my normal profile. On the other one it was not reproducible on my normal profile, but it was reproducible when I created a new profile. I'm not 100% certain I tried with a new profile on Windows 7, so I'll test that as well.
OS: Unspecified → Linux
Hardware: Unspecified → x86_64
Do the web extension / AOM code call .reset on the form or something? Moving to web extensions for now since it's not clear what the cause is.
Component: Form Manager → WebExtensions: Untriaged
It probably has something to do with the fact that options browsers are still non-remote on Linux.
Product: Toolkit → WebExtensions
Can you reproduce this after setting extensions.webextensions.remote = true and reloading the add-on?
Flags: needinfo?(victor.engmark)
Component: Untriaged → General
Can't reproduce even with extensions.webextensions.remote = false on 61.0.1, so this can be closed. Thank you!
Flags: needinfo?(victor.engmark)
Status: UNCONFIRMED → RESOLVED
Closed: 8 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.