User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20051111 Firefox/1.5 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20051111 Firefox/1.5 Bugzilla would benefit from shipping with multiple skins. Currently there are many things that cannot be styled because we are single skinned. Adding a second skin would help us keep an eye on styleability. Reproducible: Always Steps to Reproduce: Actual Results: Bugzilla only ships with the standard skin and a custom directory for tweeking the standard. Expected Results: Maintain 2 so that it's obvious how well the skins are working.

Excellent idea.

this looks like a dupe of bug 259723

Minimal skin selection infrastructure. Might be useful to spur further development in this direction. Plus, it makes it easy for developers to keep pages working accross skins. Usage: o In the skins dir, create a subdir and put CSS files in there o Add the subdir to the skins param o View a bug o Using your browser's style sheet selector, select the alternate skin I'll attach a global.css file which is almost exactly the one from bug 259723. The patch here contains some changes of bug 264511 to make the bug 259723 skin work in a basic way. Even without an additional skin directory, you can select whether to use the CSS files in the custom directory or not (by default you do). Known issues: - Generates warnings for missing style sheets - Param is misplaced in l10n - Skin selection gets lost accross pages - Skins can't be named freely (a-z only, no white space)

A skin to go with it, taken from bug 259723 with minor tweaks. Works best with show_bug.cgi.

Here's a link for that. http://landfill.bugzilla.org/skins/show_bug.cgi?id=300 This is the first step. I don't want to see this bit-rot.

I would say that this is one of the most important bugs we have -- UI is one of the most common complaints. That second UI looks great.

i like this. lots. the only thing that confuses me about this is the parameter. i expected it to set the default skin to the one specified instead of adding it to the list of available skins. perhaps it's a good idea to add a new params category "user interface" or similar, and change the function of the param to allow the admin to select the default css (from a list) with an additional checkbox to control if the user can choose alternatives.

*** Bug 259723 has been marked as a duplicate of this bug. ***

(In reply to comment #7) > the only thing that confuses me about this is the parameter. i expected it to > set the default skin to the one specified instead of adding it to the list of > available skins. I think even better than this, make it a User Setting. That way admins can set a default, and users can pick whichever one they prefer for themselves.

Comment on attachment 207562 [details] Second skin >body { > background-color: #c8c8c8; > font-family: Helvetica, Arial, Geneva; Need a ", sans-serif" at the end, there. > padding-left: 40px; > padding-right: 40px; It's really better to use em if you can, instead of px. "px" means different things on different monitors, where as "em" scales nicely with your font size, even on IE. In general, I prefer to use "em" everywhere instead of "px." It's supported in all browsers. >#banner { > text-align: center; > width: 100%; > background: #313F5E; > border: 1px solid #273554; Nit: It would be nice if some of these colors had little comments next to them sort of describing the color. > border-bottom-width: 0px; Why not just "border-bottom: none"? >#banner a { > color: #fff; > text-decoration: none; >} That might cause problems on some browsers, because you didn't say a:link, a:visited, a:hover, and a:active. I'm not certain, though. >#header { > clear: both; > background-color: #929BB1; > border: 1px solid #747E93; > border-bottom-width: 0px; > color: #000; Nit: I usually just say "color: black" for that -- I think it's more readable. >hr { > border-color: #969696; > border-style: dashed; > border-width: 1px; Nit: Usually I do "border: 1px dashed #969696" for that. >#bugzilla-body th { > font-size: 9pt; I usually prefer to use relative font sizes, in em or percent, since it's more cross-browser/cross-platform/cross-machine compatible. >.bz_comment_hilite pre { > background-color: lightgreen; "lightgreen" technically isn't a standards-compliant part of CSS. Probably better to just use the hex notation and add a comment next to it saying that it's "lightgreen." >#links-actions, #links-edit, #links-saved { > display: table-row; >} "display: table-row" doesn't mean anything in IE. Is that okay? Same for any of the other "table-" display types. >td.unselected_tab { > border-top: 1px solid #000000 !important; > border-left: 1px solid #000000 !important; > border-right: 1px solid #000000 !important; >} Nit: You could make it "body table td.unselected_tab" instead of using the !important, if you just want to override some other style. In general though, this looks great! :-)

Comment on attachment 207561 [details] [diff] [review] Patch And I think that this is an r- on the way the param works, although I haven't looked at the patch in too much depth.

Ok, here's the plan as I see it... Bugzilla templates aren't ready yet for real skinning. Why? There's a lot of hardcoded stuff in there. There is still (afaik) td/th trouble. There are id and class attributes missing all over the place. We need more div tags. And there's probably more trouble we aren't currently aware of. I think what we should do with this bug is add skinning in a semi-hidden way, along the lines of the implementation proposed here. (Rationale: don't have people start ripping us apart for skins and skinability deficiencies.) I can fix the CSS remarks for an initial checkin, and I can add a UI params category, too. We can then, perhaps during the course of a release cycle, consolidate the three things that need to work together: Bugzilla HTML, the standard Bugzilla skin, and the secondary Bugzilla skin. When we're feeling good about this, we alter the param behaviour (and placing), and we add a user pref for skin selection. How's this sound? We need to find a way to give credit to Mike who set up the skin. And we need to find a name.

(In reply to comment #12) > Ok, here's the plan as I see it... > That's pretty much what I wanted when I filed this bug.

Note that--per the Bugzilla CSS plan--support for multiple skins should work as follows: --- Installation admins can install third-party skins by adding them to the skins/ directory and then adding their name to the "skins" parameter. Skins can be either single CSS files (skins/<name>.css) or directories of files (skins/<name>/) with the same directory/file structure as the default skin. Multiple skins show up as alternate stylesheets, and users can switch to them via their browser's standard mechanism for switching between alternate stylesheets. Bugzilla uses the standard skin by default. Admins can make Bugzilla use a third-party skin by default via the "default_skin" parameter. Multiple skins appear to the user as alternate stylesheets. Bugzilla populates the list of alternate stylesheets with the contents of the "skins" parameter, excluding the current default skin. header.html.tmpl generates persistent stylesheet tags for customizations, preferred stylesheet tags for the default skin, and alternate stylesheet tags for other skins. Pages thus take on the default style, as modified by custom styles, until the user selects an alternate style, whereupon they take on the alternate style, as modified by custom styles. More on persistent, preferred, and alternate stylesheets: http://www.w3.org/TR/html4/present/styles.html#h-14.3.1 http://www.alistapart.com/articles/alternate/ ---

We've been aiming this high for a long time now, and it turned out to be too high. Please let's break this down into smaller steps. [Oh, and I'd favour using the database (e.g. a user pref) every time over cookies for making skin selection persistent accross pages. But please, in order not to squander this chance to make some progress, let's keep this discussion for follow-up bugs.]

We have about a month until the trunk re-opens anyhow, which is when this will be able to go in. I think it's worth re-working the way the skin system works to be based on a user-pref. If there are bugs, we'll have the whole 2.24 release cycle to test it. If we leave it as Alternate Stylesheets, it'll just be a hidden feature, and we'll have to change off the param eventually anyhow, which from history we know we're not-so-likely to do (that is, once code is in the tree, it's much less likely to change).

(In reply to comment #16) > We have about a month until the trunk re-opens anyhow, which is when this will > be able to go in. I think it's worth re-working the way the skin system works > to be based on a user-pref. > Great idea but that's a separate bug. These UI enhancements never go anywhere because we don't have a starting point. Create another bug to fix the way the skin system works. And let this one pass warts & all. > If there are bugs, we'll have the whole 2.24 release cycle to test it. If we Right. So approve this and commit it ASAP. > leave it as Alternate Stylesheets, it'll just be a hidden feature, and we'll > have to change off the param eventually anyhow, Leaving it as an Alternate Stylesheet will allow others to work on different parts of this; so instead of having one large problem we have several small ones. (Which fits nicely into the way Bugzilla development works.) > which from history we know we're not-so-likely to do (that is, once code is in the tree, it's much less likely to change). no comment.

I'm all for incremental development. I agree that would be fine. I'd be fine with reviewing the skin itself and not approving the patch, for this bug.

(In reply to comment #18) > I'm all for incremental development. I agree that would be fine. > > I'd be fine with reviewing the skin itself and not approving the patch, for > this bug. > I can't complain about making forward progress on this, and if splitting it is the only way... I've opened bug# 322693. For wurblzap's patch. This bug is now strictly the skin itself.

Heavy morphing -- let's handle the skin in (reopened) bug 259723, and let's use this bug to pave the path to it. This mostly means HTML and CSS tweaks to templates, and as such covers the most basic essentials of bug 264511.

Changes to HTML and CSS so that the simple alternative skin of bug 259723 may work.

Comment on attachment 211459 [details] [diff] [review] Patch I haven't taken a close look at this yet, but I do note that it doesn't apply cleanly to the tip anymore. Sorry about the delay in review. Can you attach an updated patch?

will someone please commit the CSS part of this ?

Unrotted and updated. Works with attachment 240550 [details] (extract to skins/contrib).

Unrotted and filtering issue fixed.

Comment on attachment 241236 [details] [diff] [review] Patch 1.2 >+#footer #useful-links li { >+ padding-bottom: 0.8ex; >+} We should probably be using the child selector instead of the descendant selector anywhere we can for performance, although that's probably a different bug, since it looks like we're currently using the descendant selector everywhere. >- #header >- { >+ #header { I often find "next line open bracket" code harder to read than "same line open bracket" code, and the latter is also more consistent with our Perl and JS code, so this is a welcome change. >- h2 = filtered_login >+ header_sub = filtered_login "header_sub" should probably be "subheader" instead (analogous to title -> subtitle). >- <b>Description:</b><br> >+ <b><label for="description">Description</label>:</b><br> Here and elsewhere, shouldn't <b> (and other such tags like <em>) be moved into CSS? > if (checkbox.checked) { >- text_elem.parentNode.className='bz_private'; >+ comment_elem.className = comment_elem.className.concat(' bz_private'); You should probably check to make sure it isn't already there (even though it shouldn't be) before adding this class. >- text_elem.parentNode.className=''; >+ comment_elem.className = >+ comment_elem.className.replace(/\s*bz_private\s*/, ''); If "bz_private" is between two other classes (f.e. "foo bz_private bar"), this code will run them together into a single different class ("foobar"), breaking whatever styles hang off those classes. A simple solution is just to remove "bz_private" without removing any space around it, since extra space between classes is harmless. A more robust solution would be to split the class string into an array, filter that array to remove "bz_private", then join them into a space-separated string again. >+ <th align="left"> Here and elsewhere, shouldn't align="left" be moved into the CSS? >- h1 = "Template constructed" >+ header = "Template constructed" ... >- h1 = title >+ header = title ... > [% title = "$title for $terms.bug $bug_id" >- h1 = "$h1 for $terms.bug <a href=\"show_bug.cgi?id=$bug_id\">$bug_id</a>" >- h2 = filtered_desc >+ header = "$header for $terms.bug <a href=\"show_bug.cgi?id=$bug_id\">$bug_id</a>" >+ header_sub = filtered_desc ... >- title = "Dependency tree for $terms.Bug $bugid" >- h1 = "Dependency tree for >- <a href=\"show_bug.cgi?id=$bugid\">$terms.Bug $bugid</a>" >+ title = "Dependency tree for $terms.Bug $bugid" >+ header = "Dependency tree for >+ <a href=\"show_bug.cgi?id=$bugid\">$terms.Bug $bugid</a>" Not this bug, but I wonder if we should just automatically generate titles from headers by stripping out HTML. > javascript_urls = ["js/expanding-tree.js"] >- style_urls = ["skins/standard/dependency-tree.css"] >- h2 = filtered_desc >+ style_urls = ["skins/standard/dependency-tree.css"] >+ header_sub = filtered_desc > %] Lining things up is a nice addition to this patch. You might also indent these variables two additional spaces to distinguish them from the PROCESS tag they modify. >+ <!--[if IE]> >+ <link href="skins/standard/IE-fixes.css" >+ rel="[% 'alternate ' IF user_skin %]stylesheet" >+ title="[% setting_descs.standard FILTER html %]" >+ type="text/css"> >+ <![endif]--> I'm not familiar with this syntax. Can you explain it (perhaps adding a comment to this file)? >- <td class="tab"><a href="[% tab.link FILTER html %]">[% tab.label FILTER html %]</a></td> >+ <td onClick="document.location='[% tab.link FILTER html %]'"><a href="[% tab.link FILTER html %]">[% tab.label FILTER html %]</a></td> This is a great fix. To make it even better, use CSS to change the mouse pointer to a "hand" (i.e. indicating a clickable area) when it hovers over the tabs both here and in bug lists. >- <td class="tab spacer">&nbsp;</td> >- </tr> >- </table> >-</center> >+ <td class="spacer">&nbsp;</td> Perhaps not this bug, but can we instead use padding or margin instead a non-breaking space to create the desired effect? >+ [% ' <li><span class="separator">| </span><a href="editparams.cgi">Parameters</a></li>' _ >+ ' <li><span class="separator">| </span><a href="editsettings.cgi">User Preferences</a></li>' You could simplify this code by using the :before pseudo-element with a content: property set to "| " for these list items instead of <span class="separator"| </span>. Of course you'd have to nullify that rule for :before:first-child. >- <tr class="bz_[% bug.bug_severity FILTER css_class_quote -%] >+ <tr class="bz_bugline >+ bz_[% bug.bug_severity FILTER css_class_quote -%] "bz_bugitem" is probably a more intuitive name for this class, since this row is part of a bug list, and lists generally have items. >+ <a name="buglink" href="show_bug.cgi?id=[% bug.bug_id %]">[% bug.bug_id %]</a> According to the HTML 4.01 spec on the "name" attribute, "The value of this attribute must be a unique anchor name. The scope of this name is the current document. Note that this attribute shares the same name space as the id attribute." So these anchor names need to be unique. Probably "bug_nnn", where "nnn" is the bug number, would work well (and also allow users to link to a specific item in the bug list, a bonus). "bnnn" might work even better, since it's analogous to the way we anchor comments in bug reports. Thanks for doing all this work! It looks like a bunch of very valuable fixes.

:before, content, :first-child, and the child selector don't work in IE6.

Thanks for the review, Myk! In the following, I silently skip any comments regarding something that's not possible per comment 27. (In reply to comment #26) > >- h2 = filtered_login > >+ header_sub = filtered_login > > "header_sub" should probably be "subheader" instead (analogous to title -> > subtitle). Ok, I don't mind -- done. > >- <b>Description:</b><br> > >+ <b><label for="description">Description</label>:</b><br> > > Here and elsewhere, shouldn't <b> (and other such tags like <em>) be moved into > CSS? I wholeheartedly agree. I found that many places like this in need of a treatment that I deemed the whole of this out of scope of this bug. Chances are I'll address this some time. > > if (checkbox.checked) { > >- text_elem.parentNode.className='bz_private'; > >+ comment_elem.className = comment_elem.className.concat(' bz_private'); > > You should probably check to make sure it isn't already there (even though it > shouldn't be) before adding this class. Done. > >- text_elem.parentNode.className=''; > >+ comment_elem.className = > >+ comment_elem.className.replace(/\s*bz_private\s*/, ''); > > If "bz_private" is between two other classes (f.e. "foo bz_private bar"), this > code will run them together into a single different class ("foobar"), breaking > whatever styles hang off those classes. Fixed. (In a medium-thorough way.) > >+ <th align="left"> > > Here and elsewhere, shouldn't align="left" be moved into the CSS? Yes. This belongs with <b>, <em> and friends. > Lining things up is a nice addition to this patch. You might also indent these > variables two additional spaces to distinguish them from the PROCESS tag they > modify. The two-char indent seems to be quite common. I don't think I should change this in this bug. > >+ <!--[if IE]> > >+ <link href="skins/standard/IE-fixes.css" > >+ rel="[% 'alternate ' IF user_skin %]stylesheet" > >+ title="[% setting_descs.standard FILTER html %]" > >+ type="text/css"> > >+ <![endif]--> > > I'm not familiar with this syntax. Can you explain it (perhaps adding a > comment to this file)? Done. > >- <td class="tab"><a href="[% tab.link FILTER html %]">[% tab.label FILTER html %]</a></td> > >+ <td onClick="document.location='[% tab.link FILTER html %]'"><a href="[% tab.link FILTER html %]">[% tab.label FILTER html %]</a></td> > > This is a great fix. To make it even better, use CSS to change the mouse > pointer to a "hand" (i.e. indicating a clickable area) when it hovers over the > tabs both here and in bug lists. Done. > >- <td class="tab spacer">&nbsp;</td> > >- </tr> > >- </table> > >-</center> > >+ <td class="spacer">&nbsp;</td> > > Perhaps not this bug, but can we instead use padding or margin instead a > non-breaking space to create the desired effect? This may be possible, but I'm really reluctant to invest much time in this at this time. > >- <tr class="bz_[% bug.bug_severity FILTER css_class_quote -%] > >+ <tr class="bz_bugline > >+ bz_[% bug.bug_severity FILTER css_class_quote -%] > > "bz_bugitem" is probably a more intuitive name for this class, since this row > is part of a bug list, and lists generally have items. Done. > >+ <a name="buglink" href="show_bug.cgi?id=[% bug.bug_id %]">[% bug.bug_id %]</a> > > So these anchor names need to be unique. Probably "bug_nnn", where "nnn" is > the bug number, would work well (and also allow users to link to a specific > item in the bug list, a bonus). "bnnn" might work even better, since it's > analogous to the way we anchor comments in bug reports. Done in the "bnnn" kind of way.

Comment on attachment 241482 [details] [diff] [review] Patch 1.3 >+ if (! comment_elem.className.match('bz_private')) { >+ comment_elem.className = comment_elem.className.concat(' bz_private'); >+ } Nit: (!comment_elem.className.match('bz_private')) (no space between ! and "comment", per convention) Otherwise this looks great. r=myk Thanks for seeing this through to completion!

(In reply to comment #29) > Nit: (!comment_elem.className.match('bz_private')) > (no space between ! and "comment", per convention) Done. Thanks for the reviews, Myk. Now we can think about checking a second skin in -- see bug 259723. RCS file: /cvsroot/mozilla/webtools/bugzilla/skins/standard/IE-fixes.css,v done Checking in skins/standard/IE-fixes.css; /cvsroot/mozilla/webtools/bugzilla/skins/standard/IE-fixes.css,v <-- IE-fixes.css initial revision: 1.1 done Checking in skins/standard/buglist.css; /cvsroot/mozilla/webtools/bugzilla/skins/standard/buglist.css,v <-- buglist.css new revision: 1.10; previous revision: 1.9 done Checking in skins/standard/global.css; /cvsroot/mozilla/webtools/bugzilla/skins/standard/global.css,v <-- global.css new revision: 1.25; previous revision: 1.24 done Checking in template/en/default/filterexceptions.pl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/filterexceptions.pl,v <-- filterexceptions.pl new revision: 1.83; previous revision: 1.82 done Checking in template/en/default/index.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/index.html.tmpl,v <-- index.html.tmpl new revision: 1.32; previous revision: 1.31 done Checking in template/en/default/account/prefs/prefs.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/account/prefs/prefs.html.tmpl,v <-- prefs.html.tmpl new revision: 1.24; previous revision: 1.23 done Checking in template/en/default/admin/sudo.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/admin/sudo.html.tmpl,v <-- sudo.html.tmpl new revision: 1.5; previous revision: 1.4 done Checking in template/en/default/admin/components/create.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/admin/components/create.html.tmpl,v <-- create.html.tmpl new revision: 1.10; previous revision: 1.9 done Checking in template/en/default/admin/fieldvalues/create.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/admin/fieldvalues/create.html.tmpl,v <-- create.html.tmpl new revision: 1.5; previous revision: 1.4 done Checking in template/en/default/admin/groups/create.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/admin/groups/create.html.tmpl,v <-- create.html.tmpl new revision: 1.8; previous revision: 1.7 done Checking in template/en/default/admin/groups/list.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/admin/groups/list.html.tmpl,v <-- list.html.tmpl new revision: 1.9; previous revision: 1.8 done Checking in template/en/default/admin/keywords/create.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/admin/keywords/create.html.tmpl,v <-- create.html.tmpl new revision: 1.8; previous revision: 1.7 done Checking in template/en/default/admin/milestones/create.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/admin/milestones/create.html.tmpl,v <-- create.html.tmpl new revision: 1.6; previous revision: 1.5 done Checking in template/en/default/admin/products/edit-common.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/admin/products/edit-common.html.tmpl,v <-- edit-common.html.tmpl new revision: 1.7; previous revision: 1.6 done Checking in template/en/default/admin/settings/edit.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/admin/settings/edit.html.tmpl,v <-- edit.html.tmpl new revision: 1.7; previous revision: 1.6 done Checking in template/en/default/admin/versions/create.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/admin/versions/create.html.tmpl,v <-- create.html.tmpl new revision: 1.5; previous revision: 1.4 done Checking in template/en/default/attachment/create.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/attachment/create.html.tmpl,v <-- create.html.tmpl new revision: 1.30; previous revision: 1.29 done Checking in template/en/default/attachment/diff-header.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/attachment/diff-header.html.tmpl,v <-- diff-header.html.tmpl new revision: 1.15; previous revision: 1.14 done Checking in template/en/default/attachment/edit.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/attachment/edit.html.tmpl,v <-- edit.html.tmpl new revision: 1.38; previous revision: 1.37 done Checking in template/en/default/attachment/show-multiple.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/attachment/show-multiple.html.tmpl,v <-- show-multiple.html.tmpl new revision: 1.21; previous revision: 1.20 done Checking in template/en/default/bug/comments.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/comments.html.tmpl,v <-- comments.html.tmpl new revision: 1.28; previous revision: 1.27 done Checking in template/en/default/bug/dependency-graph.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/dependency-graph.html.tmpl,v <-- dependency-graph.html.tmpl new revision: 1.12; previous revision: 1.11 done Checking in template/en/default/bug/dependency-tree.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/dependency-tree.html.tmpl,v <-- dependency-tree.html.tmpl new revision: 1.24; previous revision: 1.23 done Checking in template/en/default/bug/edit.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/edit.html.tmpl,v <-- edit.html.tmpl new revision: 1.86; previous revision: 1.85 done Checking in template/en/default/bug/knob.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/knob.html.tmpl,v <-- knob.html.tmpl new revision: 1.25; previous revision: 1.24 done Checking in template/en/default/bug/show.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/show.html.tmpl,v <-- show.html.tmpl new revision: 1.16; previous revision: 1.15 done Checking in template/en/default/bug/summarize-time.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/summarize-time.html.tmpl,v <-- summarize-time.html.tmpl new revision: 1.7; previous revision: 1.6 done Checking in template/en/default/bug/activity/show.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/activity/show.html.tmpl,v <-- show.html.tmpl new revision: 1.8; previous revision: 1.7 done Checking in template/en/default/bug/create/make-template.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/create/make-template.html.tmpl,v <-- make-template.html.tmpl new revision: 1.9; previous revision: 1.8 done Checking in template/en/default/bug/votes/list-for-bug.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/votes/list-for-bug.html.tmpl,v <-- list-for-bug.html.tmpl new revision: 1.11; previous revision: 1.10 done Checking in template/en/default/bug/votes/list-for-user.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/votes/list-for-user.html.tmpl,v <-- list-for-user.html.tmpl new revision: 1.25; previous revision: 1.24 done Checking in template/en/default/global/choose-classification.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/global/choose-classification.html.tmpl,v <-- choose-classification.html.tmpl new revision: 1.8; previous revision: 1.7 done Checking in template/en/default/global/choose-product.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/global/choose-product.html.tmpl,v <-- choose-product.html.tmpl new revision: 1.16; previous revision: 1.15 done Checking in template/en/default/global/common-links.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/global/common-links.html.tmpl,v <-- common-links.html.tmpl new revision: 1.4; previous revision: 1.3 done Checking in template/en/default/global/footer.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/global/footer.html.tmpl,v <-- footer.html.tmpl new revision: 1.13; previous revision: 1.12 done Checking in template/en/default/global/header.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/global/header.html.tmpl,v <-- header.html.tmpl new revision: 1.48; previous revision: 1.47 done Checking in template/en/default/global/per-bug-queries.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/global/per-bug-queries.html.tmpl,v <-- per-bug-queries.html.tmpl new revision: 1.6; previous revision: 1.5 done Checking in template/en/default/global/tabs.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/global/tabs.html.tmpl,v <-- tabs.html.tmpl new revision: 1.3; previous revision: 1.2 done Checking in template/en/default/global/useful-links.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/global/useful-links.html.tmpl,v <-- useful-links.html.tmpl new revision: 1.49; previous revision: 1.48 done Checking in template/en/default/list/quips.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/list/quips.html.tmpl,v <-- quips.html.tmpl new revision: 1.19; previous revision: 1.18 done Checking in template/en/default/list/table.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/list/table.html.tmpl,v <-- table.html.tmpl new revision: 1.31; previous revision: 1.30 done Checking in template/en/default/reports/chart.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/reports/chart.html.tmpl,v <-- chart.html.tmpl new revision: 1.3; previous revision: 1.2 done Checking in template/en/default/reports/edit-series.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/reports/edit-series.html.tmpl,v <-- edit-series.html.tmpl new revision: 1.6; previous revision: 1.5 done Checking in template/en/default/reports/report.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/reports/report.html.tmpl,v <-- report.html.tmpl new revision: 1.12; previous revision: 1.11 done Checking in template/en/default/search/search-advanced.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/search/search-advanced.html.tmpl,v <-- search-advanced.html.tmpl new revision: 1.27; previous revision: 1.26 done Checking in template/en/default/search/search-specific.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/search/search-specific.html.tmpl,v <-- search-specific.html.tmpl new revision: 1.17; previous revision: 1.16 done Checking in template/en/default/search/tabs.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/search/tabs.html.tmpl,v <-- tabs.html.tmpl new revision: 1.6; previous revision: 1.5 done