Prepare Bugzilla to ship with at least 2 skins

RESOLVED FIXED in Bugzilla 3.0

Status

()

P1
enhancement
RESOLVED FIXED
13 years ago
3 years ago

People

(Reporter: pjdemarco, Assigned: Wurblzap)

Tracking

2.20
Bugzilla 3.0
Dependency tree / graph
Bug Flags:
approval +

Details

(URL)

Attachments

(1 attachment, 5 obsolete attachments)

(Reporter)

Description

13 years ago
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.
(Assignee)

Comment 1

13 years ago
Excellent idea.
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 2

13 years ago
this looks like a dupe of bug 259723
(Assignee)

Comment 3

13 years ago
Created attachment 207561 [details] [diff] [review]
Patch

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)
Assignee: myk → wurblzap
Status: NEW → ASSIGNED
Attachment #207561 - Flags: review?
(Assignee)

Comment 4

13 years ago
Created attachment 207562 [details]
Second skin

A skin to go with it, taken from bug 259723 with minor tweaks. Works best with show_bug.cgi.
Attachment #207562 - Flags: review?
(Assignee)

Updated

13 years ago
Target Milestone: --- → Bugzilla 2.24
(Reporter)

Comment 5

13 years ago
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.

Comment 6

13 years ago
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.
Priority: -- → P1
Version: unspecified → 2.20
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. ***

Comment 9

13 years ago
(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 10

13 years ago
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 11

13 years ago
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.
Attachment #207561 - Flags: review? → review-
(Assignee)

Comment 12

13 years ago
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.
(Reporter)

Comment 13

13 years ago
(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/
---
(Assignee)

Comment 15

13 years ago
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.]

Comment 16

13 years ago
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).
(Reporter)

Comment 17

13 years ago
(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.
(Reporter)

Updated

13 years ago

Comment 18

13 years ago
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.
(Reporter)

Updated

13 years ago
Blocks: 322693
(Reporter)

Comment 19

13 years ago
(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.
(Assignee)

Updated

13 years ago
No longer blocks: 322693
Depends on: 322693
(Assignee)

Updated

13 years ago
Depends on: 259723
(Assignee)

Comment 20

13 years ago
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.
Blocks: 259723
No longer depends on: 259723
Summary: Bugzilla needs to ship with at least 2 skins → Prepare Bugzilla to ship with at least 2 skins
(Assignee)

Comment 21

13 years ago
Created attachment 211459 [details] [diff] [review]
Patch

Changes to HTML and CSS so that the simple alternative skin of bug 259723 may work.
Attachment #207561 - Attachment is obsolete: true
Attachment #207562 - Attachment is obsolete: true
Attachment #211459 - Flags: review?(myk)
Attachment #207562 - Flags: review?
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?
Attachment #211459 - Flags: review?(myk) → review-

Updated

13 years ago
Blocks: 330700
(Assignee)

Updated

13 years ago
Depends on: 330555
(Reporter)

Comment 23

12 years ago
will someone please commit the CSS part of this ?
(Assignee)

Comment 24

12 years ago
Created attachment 240551 [details] [diff] [review]
Patch 1.1

Unrotted and updated. Works with attachment 240550 [details] (extract to skins/contrib).
Attachment #211459 - Attachment is obsolete: true
Attachment #240551 - Flags: review?(myk)
(Assignee)

Updated

12 years ago
Blocks: 313450
(Assignee)

Comment 25

12 years ago
Created attachment 241236 [details] [diff] [review]
Patch 1.2

Unrotted and filtering issue fixed.
Attachment #240551 - Attachment is obsolete: true
Attachment #241236 - Flags: review?(myk)
Attachment #240551 - Flags: review?(myk)
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.
Attachment #241236 - Flags: review?(myk) → review-

Comment 27

12 years ago
:before, content, :first-child, and the child selector don't work in IE6.
(Assignee)

Comment 28

12 years ago
Created attachment 241482 [details] [diff] [review]
Patch 1.3

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.
Attachment #241236 - Attachment is obsolete: true
Attachment #241482 - Flags: review?(myk)
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!
Attachment #241482 - Flags: review?(myk) → review+
(Assignee)

Updated

12 years ago
Flags: approval?
Flags: approval? → approval+
(Assignee)

Comment 30

12 years ago
(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
Status: ASSIGNED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
Blocks: 346448

Updated

12 years ago
Blocks: 357396

Updated

12 years ago
Blocks: 270737

Updated

3 years ago
Blocks: 1250114
You need to log in before you can comment on or make changes to this bug.