background-color property on focused INPUT elements does not work

RESOLVED DUPLICATE of bug 433885

Status

()

Core
General
RESOLVED DUPLICATE of bug 433885
10 years ago
10 years ago

People

(Reporter: Timwi, Unassigned)

Tracking

({regression, testcase})

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

340 bytes, text/html
Details
(Reporter)

Description

10 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9b2) Gecko/2007121120 Firefox/3.0b2
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9b2) Gecko/2007121120 Firefox/3.0b2

In my userContent.css, I have the following line:

form input:focus { background-color: #ff8 !important; outline: 2px solid red !important; color: black !important; }

This worked perfectly in Firefox 2. In Firefox 3 beta 2, the background-property is suddenly ignored.

Reproducible: Always

Actual Results:  
Background of input fields still white.

Expected Results:  
Background should turn yellow when focused, according to the CSS rule.
(Reporter)

Comment 1

10 years ago
Still a problem in Firefox 3 beta 3.

Comment 2

10 years ago
What kind of input field do you want to style? Does is work in Beta 4? If not, could you provide a testcase that exposes the problem?

I can at least style input elements of type text and password without any problems in the latest nightlies.
(Reporter)

Comment 3

10 years ago
It works in Beta 4, but it didn't work in Beta 3, which was current when I submitted this.

You may want to find the relevant bug where this was fixed for Beta 4, and mark this as a duplicate.

Comment 4

10 years ago
I'll do it the easy way. Thanks for reporting.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → WORKSFORME
(Reporter)

Comment 5

10 years ago
Problem reoccurs in Firefox 3 RC1. I'll attach a testcase.
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
(Reporter)

Comment 6

10 years ago
Created attachment 321604 [details]
Testcase
(Reporter)

Comment 7

10 years ago
Please take this opportunity to ponder the more general problem here. The bug was reported against Beta 3. Nobody ever investigated the bug. Just because it didn't occur in Beta 4 it was thought that the bug somehow disappeared. This is a mistake. If the bug was fixed, then there should be another bug entry which contains the actual fix. If there is no such actual fix, then the bug has NOT been fixed and is very likely to reoccur.

I'm mentioning this because I'm seeing this all over BugZilla. Bugs keep getting closed as if they'd been fixed when they haven't. If the bug demonstrably occurs in an older version, the bug should be investigated and fixed properly to ensure that it will not reappear.
(Reporter)

Updated

10 years ago
Flags: blocking-firefox3?
Keywords: regression, testcase

Comment 8

10 years ago
This is WFM on both Vista and XP using your test case using RC1 (tried with both Classic and non-Classic).

> I'm mentioning this because I'm seeing this all over BugZilla. Bugs keep
> getting closed as if they'd been fixed when they haven't. If the bug
> demonstrably occurs in an older version, the bug should be investigated and
> fixed properly to ensure that it will not reappear.
> 

RESOLVED FIXED should really only be used if the fix was done in the bug itself or if a link could be provided to the bug that fixed it (assuming that DUPLICATE wasn't a better resolution).  If a problem just went away and nobody is sure what caused it to go away, WORKSFORME is the correct resolution, and from this bug's history, it looks like that was what was used.  Nobody has the time to go through and investigate the cause & fix of every WORKSFORME bug as you suggest--it simply isn't an efficient use of time.  If this bug matters a lot to you, you can try to investigate it yourself: find a regression range using the archive of nightly builds and narrow down the breakage to a day.  And there is also the option to reopen WORKSFORME bugs that no longer work, which you have just used.  I don't see what the problem is.
(Reporter)

Updated

10 years ago
Summary: background-color property on INPUT elements does not work → background-color property on focused INPUT elements does not work
(Reporter)

Comment 9

10 years ago
== More information about the bug ==

Given Kai Liu's WFM, I investigated more on a clean profile and I discovered that it works when viewing just the testcase.

The problem occurs when there is a CSS instruction in the chrome/userContent.css file.


== Minimalistic Steps To Reproduce ==

* Add the following line to your userContent.css:
    form input:focus { background-color: #ff8 !important; }

* Observe that it doesn't work by focusing any textbox on any website
* Open the attached testcase
* Observe that it STILL doesn't do anything, even the testcase has an
  additional explicit CSS rule in it

So it seems that the background-color rule in the userContent.css causes the bug.

Comment 10

10 years ago
The cause of this is somewhat similar to the problem in bug 419973, which I see that another one of your bugs has been duped to.

What's going on here is this:

* By default, Gecko renders form elements using "native" widgets that looks like standard text boxes and buttons on the operating system.  When using native widgets, borders and backgrounds set by the CSS are ignored.

* For HTML form elements, if Gecko detects that a background or border has been set by the author CSS, it will automatically drop the native rendering so that the background or border could be overridden by the page author.

* userChrome.css, however, is not author CSS.  It's user CSS.  And when userChrome.css has the "!important" flag set, it will override the author CSS, so that, to the browser, the author CSS is no longer applicable, and the browser will no longer automatically drop the native rendering as a result.  If you are using either agent CSS or user CSS, the native rendering needs to be explicitly dropped using "-moz-appearance: none" because the automatic dropping of that only happens for author CSS.

So if you are going to be overriding your author CSS with user CSS, then you must explicitly drop the native rendering in the user CSS because it's not automatic for the user CSS.  But keep in mind with the "!important" flag set, your user CSS will take precedence over your author CSS, so even if there wasn't the problem of having to drop the native rendering, you still wouldn't get the #ff0 set in your author CSS--you'll get the #ff8 that was set in your user CSS instead.

In any case, this isn't really a bug; everything is working as expected.
Whiteboard: [invalid?]
(Reporter)

Comment 11

10 years ago
> In any case, this isn't really a bug; everything is working as expected.

What? You've explained the bug in great length and then you say "everything is working as expected"? Clearly, expected behaviour is for native rendering to be dropped whenever there's a background or border rule, irrespective of whether it's in author CSS, user CSS, or anywhere else. (I don't even see how I was supposed to discover "-moz-appearance" except by filing this bug here. Anyone who runs into the same situation as I did here will see this as a bug and file it again.)

Comment 12

10 years ago
(In reply to comment #11)
> Clearly, expected behaviour is for native rendering to be
> dropped whenever there's a background or border rule, irrespective of whether
> it's in author CSS, user CSS
>
Well, "expected behavior" depends on what you are expecting.  Not having the native rendering automatically drop does serve a real, useful purpose: CSS rules are often used to provide a basic fallback styling in the event that native rendering, for one reason or another, is unavailable, and in that case, you don't want the CSS to override the native rendering unless it has to; this is very important for agent CSS (though, I admit, not so much for user CSS).

> Anyone who runs into the same situation as I
> did here will see this as a bug and file it again.)
> 
Not necessarily.  Not many people use userContent.css, and even fewer use it to style form controls, especially since it would override author form styling and could make websites look weird.  The first step that they take would be to specify a color using userContent.css with !important and notice that it's not working, at which point, they would probably ask why it's not working for userContent.css, and hopefully, they will find out about -moz-appearance.  If they ignore the fact that userContent.css has not worked and just left in the userContent.css override, then and only then would they hit the problem of author styles being overridden by non-working user styles.  I don't think many people will be running into your situation.

In any case, I'm not the one who made this decision, nor was I in any way involved in the decision.  I'm simply explaining what the situation is (don't shoot the messenger :P).  Not having user CSS automatically override the native rendering is indeed the "expected" behavior in the sense that it was a deliberate change in design that was made for Firefox 3 (see bug 240117 comment 3).  Maybe documenting this change to the behavior of userContent.css somewhere (perhaps in userContent-example.css?) could help...

Updated

10 years ago
Component: General → General
Flags: blocking-firefox3?
Product: Firefox → Core
QA Contact: general → general

Comment 13

10 years ago
Does the following have something to do with this bug?


	PostPosted: Jun Wed 4th 2008 11:04pm     
phiw13 wrote:
What happens is that those sites have styled the form controls (away from the default look-and-feel). In that case, the background and foreground colours will fall back to the colours you have chosen. But I don't understand fully when you say that you can't read what you typed in those input boxes. The foreground-colour of your choice should apply to those form-controls (and override anything the site may have set, and I assume you have chosen a colour (for 'text') that contrasts well with your choice of background-colour.


ahh I thought it had something to do with style sheets, but I"m not a developer so thanks for clearing that up.

I have the background set so it's the lightest possible grey (Have an eye issue) and the text is black. I have the box
"Allow pages to choose their own colors, instead of my selections above" unchecked so the background should default to grey and the text to black, as I selected.
Now in yahoo mail the compose box comes up grey as it should, but for some reason typed text goes to grey as well (instead of the black I selected). Not sure why they both default to the same color, when I have them selected different? Firefox 2 didn't do this, does anyone else have insight on this? thanks

Comment 14

10 years ago
My problem lies in the second two paragraphs above, sorry about the double post. 

Updated

10 years ago
Status: UNCONFIRMED → RESOLVED
Last Resolved: 10 years ago10 years ago
Resolution: --- → DUPLICATE
Whiteboard: [invalid?]
Duplicate of bug: 433885
You need to log in before you can comment on or make changes to this bug.