640480 - HTML style attributes with #somebugs selector gives CSS warnings in Error Console

Status: RESOLVED FIXED

(bugzilla.mozilla.org :: General, defect)

Description

[John Holland]

User-Agent:       Mozilla/5.0 (Windows NT 5.1; rv:2.0) Gecko/20100101 Firefox/4.0
Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0) Gecko/20100101 Firefox/4.0

Examples:
Warning: Error in parsing value for 'white-space'.  Declaration dropped.
Source File: https://bugzilla.mozilla.org/skins/standard/global.css
Line: 294
...
Warning: Expected declaration but found '#somebugs'.  Skipped to next declaration.
Source File: https://bugzilla.mozilla.org/enter_bug.cgi?product=Firefox&format=guided
Line: 0
...
Warning: Error in parsing value for 'vertical-align'.  Declaration dropped.
Source File: https://bugzilla.mozilla.org/enter_bug.cgi?product=Firefox&format=guided
Line: 0

Reproducible: Always

Steps to Reproduce:
1. Open the Error Console.
2. Navigate to a Mozilla Firefox page.
3. If the Error Console is not empty, clear it.
4. Reload the same Mozilla Firefox page.
5. Observe the Error Console.
Actual Results:  
The Error Console displays a myriad of warning messages.

Expected Results:  
A blank Error Console ... as results from viewing my Web site biblekjv.com.

If the Firefox browser displays warnings in the Error Console for Mozilla pages, as indeed occurs, what does that say about the competence of Mozilla Firefox programmers? Correcting these warnings would greatly enhance the confidence that we have in Mozilla products.

Comment 1

[Mats Palmgren (inactive)]

I get CSS warnings when visiting http://www.google.com/ and 
http://www.microsoft.com/ and http://www.apple.com/ too...

In some cases these CSS warnings are unavoidable if you want to make
a stylesheet work well for browsers of various vendors and versions.
For example the Bugzilla white-space rule:

.bz_comment_text, .uneditable_textarea {
     font-family: monospace;
    /* Note that these must all be on separate lines or they stop
       working in Konqueror. */
     white-space: pre-wrap;      /* CSS 3 & 2.1 */
     white-space: -moz-pre-wrap; /* Gecko */
     white-space: -pre-wrap;     /* Opera 4-6 */
     white-space: -o-pre-wrap;   /* Opera 7 */
}

This was already reported in bug 423564.

The '#somebugs' error appears to be a typo and should be corrected in
the Bugzilla stylesheet, but this doesn't have anything to do with
the Firefox product.

I can't reproduce the 'vertical-align' warning.

So this bug is mostly invalid, since these warnings are expected in
most cases (see bug 433074 where we intend to suppress the subset of
warnings that comes from properties/values with *known* vendor
prefixes).

I'm morphing this bug to be about fixing the '#somebugs' selector error
in the Bugzilla product.

John, if you find more of these warnings, please report them to the
organization/project that is responsible for the stylesheet, it's not
a bug in the Firefox product.

Comment 2

[Mats Palmgren (inactive)]

Here's a snippet from the markup that causes the warning (note that there
multiple instances):
<td valign="top"><textarea name="comment" style="#somebugs { width: 100%; height: 500px }" rows="6" cols="80">

Comment 3

[:glob ✱]

Attachment: fix invalid style attribute on textareas

the problem is we're using INCLUDE instead of PROCESS to bring in the textarea block, which results in it reusing the style variable which was passed to the header block.

Comment 4

[David Lawrence [:dkl]]

Comment on attachment 518377 [details] [diff] [review]
fix invalid style attribute on textareas

Actually this did not oddly enough fix the problem for me. I removed cache and data/template/* and it still gave me the #somebugs errors. Once I played around some more I am not sure this is the proper solution. template/en/default/create/create.html.tmpl uses INCLUDE global/textarea.html.tmpl and not PROCESS and it is not a problem there. The issue is that global/textarea is IMO broken in that it includes the global 'style' value for each textarea created when it should not be. It should only use the 'style' value passed in directly. So this will need to be renamed to something else to eliminate confusion. Maybe a new upstream bug to fix. I propose we fix this by doing it this way.

=== added file 'skins/standard/guided.css'
--- skins/standard/guided.css   1970-01-01 00:00:00 +0000
+++ skins/standard/guided.css   2011-03-11 20:16:59 +0000
@@ -0,0 +1,1 @@
+#somebugs { width: 100%; height: 500px }

=== modified file 'template/en/default/bug/create/create-guided.html.tmpl'
--- template/en/default/bug/create/create-guided.html.tmpl      2011-01-24 21:09:09 +0000
+++ template/en/default/bug/create/create-guided.html.tmpl      2011-03-11 20:22:36 +0000
@@ -31,7 +31,7 @@
 [% PROCESS global/header.html.tmpl
    title = "Enter $terms.ABug"
    onload = "PutDescription()"
-   style = "#somebugs { width: 100%; height: 500px }"
+   style_urls = [ "skins/standard/guided.css" ]
  %]

This fixes it for me on my test instance. If this is acceptable, go ahead and check in for 3.6 and a similar fix for 4.0 and resolve this.

Dave

Comment 5

[:glob ✱]

> This fixes it for me on my test instance. If this is acceptable, go ahead and
> check in for 3.6 and a similar fix for 4.0 and resolve this.

yeah, that make much more sense.
committed.

thanks for letting us know john :)  note the fix won't be live until the next time we update bugzilla.mozilla.org.