Closed
Bug 1269336
Opened 8 years ago
Closed 7 years ago
Password fields look ugly in browser action's pop-up
Categories
(WebExtensions :: Frontend, defect, P5)
WebExtensions
Frontend
Tracking
(firefox46 unaffected, firefox47 unaffected, firefox48 fix-optional, firefox49 fix-optional)
RESOLVED
FIXED
Tracking | Status | |
---|---|---|
firefox46 | --- | unaffected |
firefox47 | --- | unaffected |
firefox48 | --- | fix-optional |
firefox49 | --- | fix-optional |
People
(Reporter: jwkbugzilla, Assigned: mstriemer)
References
Details
(Keywords: regression, Whiteboard: triaged)
Attachments
(3 files, 1 obsolete file)
Steps to reproduce: 1. Download attached extension. 2. Go to about:config and set xpinstall.signatures.required to false. 3. Open Add-ons Manager and install the extension from file. 4. Click the extension's icon in the toolbar (generic puzzle icon). Expected results: The pop-up shows up and the password field inside it looks nice (native or something like it). That's what you see in Chrome. Actual results: The password field is ugly - you get the 90ies look (2px inset). This is a regression from bug 1225633, it sets -moz-appearance:none for all input elements but only styles those with type="text" afterwards. So input elements with type="password", type="email" or without any type attribute whatsoever stay unstyled. This should really apply styles to all input elements, regardless of type attribute (which is allowed to be missing on a regular text field) - merely type="checkbox" and type="radio" should be treated as exceptions.
Updated•8 years ago
|
Assignee: nobody → bwinton
Whiteboard: triaged
Updated•8 years ago
|
status-firefox46:
--- → unaffected
status-firefox47:
--- → unaffected
status-firefox48:
--- → affected
Keywords: regression
OS: Unspecified → All
QA Contact: vasilica.mihasca
Hardware: Unspecified → All
Comment 1•8 years ago
|
||
Comment 2•8 years ago
|
||
This looks good to me now, was this fixed in bug 1269081 (see attachment).
Flags: needinfo?(trev.moz)
Reporter | ||
Comment 3•8 years ago
|
||
Yes, bug 1269081 fixed this for me, neither is bug 1269334 reproducible in the same way. I'm leaving both bugs open however, because the styles applied still have issues if the add-on author opts in. I replaced the test extension with one that has browser_style flag.
Attachment #8747691 -
Attachment is obsolete: true
Flags: needinfo?(trev.moz)
Comment 4•8 years ago
|
||
Resolved fixed, I guess. :)
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Comment 5•8 years ago
|
||
Oh, wait, after re-reading the comments, I'm re-opening it to handle the browser_style case.
Assignee: bwinton → nobody
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Updated•8 years ago
|
Updated•8 years ago
|
Component: WebExtensions: Untriaged → WebExtensions: Frontend
Priority: -- → P5
Updated•7 years ago
|
Assignee: nobody → mstriemer
Assignee | ||
Comment 6•7 years ago
|
||
So here's a screenshot of the extension updated to something that I could imagine an extension using. The inputs don't match what Firefox uses exactly, for example in about:preferences there is a slight border radius and the border changes colours instead of adding an outline. This is a modern web default though so I'm not sure how far we want to take this. If we want to support all the photon styles we should get a new bug for that I think. If you add the browser-style class to the input you do get the retro look, but just don't add the class and you're all good, it is only useful on some elements. Andy, is this good enough or do we want to revisit the styles that get applied for browser_styles?
Flags: needinfo?(amckay)
Assignee | ||
Comment 7•7 years ago
|
||
After some IRC discussion, this seems to be good enough.
Status: REOPENED → RESOLVED
Closed: 8 years ago → 7 years ago
Flags: needinfo?(amckay)
Resolution: --- → FIXED
Updated•6 years ago
|
Product: Toolkit → WebExtensions
You need to log in
before you can comment on or make changes to this bug.
Description
•