Closed Bug 426660 Opened 16 years ago Closed 16 years ago

Allow Firefox themes to change based on the OS theme

Categories

(Core :: CSS Parsing and Computation, defect, P2)

All
Windows XP
defect

Tracking

()

VERIFIED FIXED
mozilla1.9

People

(Reporter: faaborg, Assigned: ehsan.akhgari)

References

Details

(Keywords: dev-doc-complete)

Attachments

(1 file, 3 obsolete files)

It would be really useful for us to be able to do different things in a Firefox theme depending on what OS theme the user is currently using.  Some examples:

-Vista: Glossy toolbar background for Vista Aero, but not for Vista classic.

-OS X: Grey focus ring around the location bar instead of a blue ring when the user has the graphite appearance selected.

-Using extracted system colors for everything in the event that we detect the user has a third party OS theme (and we can not anticipate things like the background color that text will appear on).

Ideally we would be able to create all of these alternate states for the Firefox theme using css, for instance:

foo:-moz-system-metric(windows-third-party-theme) {
   color: grayText;
}

Since Windows does not expose the name of the current theme being used (at least I'm pretty sure this is the case), I guess we will have to infer it by looking at the set of extracted system colors.
This seems like a really bad way to do this. That said, uxtheme does provide a function GetCurrentThemeName that does exactly this.
(In reply to comment #1)
> This seems like a really bad way to do this. That said, uxtheme does provide a
> function GetCurrentThemeName that does exactly this.

Huh. http://msdn2.microsoft.com/en-us/library/bb773365(VS.85).aspx indeed shows that we can get that information.

Sure, that's a much better way of doing it. Can we then set and expose a parameter much like we're doing in bug 425598 so that theme-based CSS could act accordingly?
Do we know what the default theme names and values are for XP and Vista?
OS: All → Windows XP
> -Vista: Glossy toolbar background for Vista Aero, but not for Vista classic.

GetCurrentThemeName won't differentiate between these two. (It'll fail if classic is enabled.) It also won't differentiate between basic and standard, both will return the path of the areo style sheet. There are some ways around this using desktop composition apis, not sure how reliable those methods are though.
I assumed that he meant Glossy for Aero themes. Non-glossy with classic. In which case, getCurrentThemeName should return null(?) if its classic (theming isn't enabled), the path to Aero if its one of the Aero derivatives (all of which use similar looking toolbox styles, glass areas excluded), and something else if its something else. I've never played with it though, so I could be way off base.

This has been morphed into a Windows XP bug though? Is the Vista and OSX stuff irrelevant in here?
> getCurrentThemeName should return null(?)

actually it just fails with a com error, "element not found."  

> the path to Aero if its one of the Aero derivatives (all of
> which use similar looking toolbox styles, glass areas excluded), and something
> else if its something else.

yes, that's correct.
>This has been morphed into a Windows XP bug though? Is the Vista and OSX stuff
>irrelevant in here?

Perhaps we should create a spin off bug for OS X.

These are the groups of themes on Windows where we might make different design decisions:

Vista
-Aero/Vista Basic
-Standard/Classic
-High Contrast (#1/#2/white/black)
-Something else (probably a third party theme)

XP
-Luna (Blue, Silver, Olive)
-Standard/Classic
-High Contrast (#1/#2/white/black)
-Something else (third party theme, alternate standard theme (like Brick), or official Microsoft theme like royale or the zune one)

I can also see us potentially doing different work in the future based on the particular Luna theme (blue, silver or olive), so it would be nice to be able to tell the difference between those as well, in addition to just if the user has a Luna based theme or not.

I'm listing the high contrast themes here because there is two ways to get windows into high contrast mode, through the accessibility options (which triggers our accessibility pref), and by just selecting a high contrast theme.  In the later case, our accessibility pref does not get turned on.  It would be nice to be able to select on eMetric_UseAccessibilityTheme or a the presence of a high contrast theme.
(In reply to comment #5)
> I assumed that he meant Glossy for Aero themes. Non-glossy with classic. In
> which case, getCurrentThemeName should return null(?) if its classic (theming

That's correct - you're totally *on* base. :)

This is an all-supported-versions-of-Windows bug - there's just no way in Bugzilla to say "Windows XP and Vista" :(

(In reply to comment #7)
> These are the groups of themes on Windows where we might make different design
> decisions:

Let's keep this bug simple: what we need to know is whether the user is using the *default theme* or not.

For Vista, I would define the default theme as Aero Glass or Aero Basic.
For XP, I would define the default theme as Luna or Royale (for XP Media Edition)

Anything else (including "Windows Classic") would be considered "non default".

If the default theme is in use, then -moz-system-metric(windows-default-theme) would evaluate to true.

> I can also see us potentially doing different work in the future based on the
> particular Luna theme (blue, silver or olive), so it would be nice to be able
> to tell the difference between those as well, in addition to just if the user
> has a Luna based theme or not.

I think that would complicate the implementation a little, as well as potentially complicating the way the metrics would have to be reported. To keep this bug moving forward quickly, and since we don't really have a burning need for that right now, let's either spin this off or keep it in the backs of our heads as a "future" for now, OK?

> I'm listing the high contrast themes here because there is two ways to get
> windows into high contrast mode, through the accessibility options (which
> triggers our accessibility pref), and by just selecting a high contrast theme. 
> In the later case, our accessibility pref does not get turned on.  It would be
> nice to be able to select on eMetric_UseAccessibilityTheme or a the presence of
> a high contrast theme.

Agreed, same comment as above about having this as a "future", though.
>For XP, I would define the default theme as Luna or Royale (for XP Media
>Edition)

Clarified on irc, where luna = blue, silver or olive.
Nominating to pick up wanted, this would be very nice to have for theme changes for this release.
Flags: blocking-firefox3?
In fact, it would be more useful than bug 425598.
This wouldn't be exposed to anything in the content area right?  It would be
bad if all of those "Your the 1,000,000th visitor!!!" pop-up dialog boxes with
a windows classic look actually started to match the user's OS theme.
> For Vista, I would define the default theme as Aero Glass or Aero Basic.

> > It also won't differentiate between basic and standard,

You're right about that, I lumped "Windows Standard" in with "Vista Basic" and "Windows Aero". "Windows Aero" and "Windows Vista Basic" will point to an aero stylesheet. Classic / Standard / high contrast color schemes will cause  GetCurrentThemeName to fail. 
Blocks: 426000
Taking over...  I'll post a patch shortly.
Assignee: nobody → ehsan.akhgari
Attached patch Patch (v1) (obsolete) — Splinter Review
I decided not to implement this as a Windows specific pseudo-class, since we already have a mechanism to select stylesheets based on the OS, and this could potentially be useful to other platforms as well.  With this patch applied, :-moz-system-metric(os-default-theme) is selected if the user has activated the default theme of the OS.  This patch handles Windows XP, 2K3 and Vista, and provides stubs for implementation on other platforms.

Requesting review from dbaron on the layout/style part (which should be fairly trivial to review) and also pavlov on the widget part.

I'll attach a page which can be used to test this patch right away.

(In reply to comment #12)
> This wouldn't be exposed to anything in the content area right?  It would be
> bad if all of those "Your the 1,000,000th visitor!!!" pop-up dialog boxes with
> a windows classic look actually started to match the user's OS theme.

I don't know how to make this not be exposed to the content.  -moz-system-metric is already available to content as well.
Attachment #313577 - Flags: superreview?(pavlov)
Attachment #313577 - Flags: review?(pavlov)
Attachment #313577 - Flags: review?(dbaron)
Comment on attachment 313577 [details] [diff] [review]
Patch (v1)

Codewise this looks fine.
Attachment #313577 - Flags: review?(pavlov) → review+
Comment on attachment 313577 [details] [diff] [review]
Patch (v1)

dbaron, can you sr this? note especially comment 12
Attachment #313577 - Flags: superreview?(pavlov)
Attachment #313577 - Flags: superreview?(dbaron)
Attachment #313577 - Flags: review?(dbaron)
Attachment #313577 - Flags: approval1.9?
Status: NEW → ASSIGNED
Component: Theme → Style System (CSS)
Flags: blocking-firefox3?
Product: Firefox → Core
QA Contact: theme → style-system
Flags: blocking1.9?
(Blocking: this is a much better way to get section 508 compliance, IMO, and we decided to block on bug 425598 for the same reason)
Flags: blocking1.9? → blocking1.9+
Priority: -- → P2
Codewise it looks fine, but this does expose it to content (which I don't think we want), and I'm not sure how useful this will really be.  Condensing all theme choices into a boolean (and *without* having any OS-version-switching along with it) doesn't seem like it will let you do a whole lot -- at least not a whole lot that really works for the vast majority of users.

Is the real deficiency here a lack of values of -moz-appearance and system colors?

It also seems *way* too late to be taking new features.
(In reply to comment #12)
> This wouldn't be exposed to anything in the content area right?  It would be
> bad if all of those "Your the 1,000,000th visitor!!!" pop-up dialog boxes with
> a windows classic look actually started to match the user's OS theme.
> 

In practice, quite a lot of this (the "not windows classic" part) can already be gleaned from the user agent string (being that the larger portion of users use the default theme for their OS), so if this was desired it could most likely already be done for the most part (albeit using a bit of JavaScript.)

I think the fact that they're not doing it now is simply laziness, and I doubt that any css changes would make an effect there (especially considering those are almost always images, not styled HTML.)

I also seem to recall that some of the properties in css3-ui, and similar, would probably also be very useful in accomplishing the same trickery (regardless of the decision here...) and that's definitely intended for the content area afaict.

Just my humble opinion.

-[Unknown]
Flags: blocking1.9+ → blocking1.9?
Comment on attachment 313577 [details] [diff] [review]
Patch (v1)

please re-request approval once reviews are completed.
Attachment #313577 - Flags: approval1.9?
Guys, it seems to me that this change is REALLY late.  I'll defer the blocking decision to others.
I'm happy to minus this.
Flags: blocking1.9? → blocking1.9-
So I'm trying to weigh the benefits of this feature (which doesn't really seem generally applicable, particularly on platforms where there are, say, more than two common themes) against the cost of all future widget backend implementors trying to figure out "What the heck am I supposed to return for this value?" and the cost of future platform users trying to understand when they should use this vs. other features for adapting to system appearance (and the potential costs of their making the wrong choice).

Providing an API returning boolean to answer the question "what theme is the user using" doesn't really seem like the right thing to me.  Do you really want selectors selecting on the theme name?  Is this really useful only on Windows?  (Are there *really* only two themes, plus the high contrast ones, on Windows?)

In the long run, I think:

 * the desired long-term solution is one where you pick up the characteristics of the system theme rather than have to hard-code them into the Firefox theme

 * The features currently provided by -moz-system-metric belong as part of media queries, not selectors.

 * if you want to provide Firefox themes that are actually specific to system themes, it seems like you want to query theme names, not a boolean is-default value that's going to require continued maintenance over future OS versions

 * the long-term solution to the problems you're dealing with seem like more values of -moz-appearance and maybe more system colors, perhaps combined with media queries against system colors for selecting appropriate icons to use against the background


If you're still seriously planning to add the features that depend on this feature for 1.9 (and planning to have them adequately tested through a range of configurations), I'm willing to mark this superreview+, on the condition that we actually *remove* the feature in a future release.  But given where we are in the schedule I honestly don't see how you can land any new features that depend on this and get appropriate testing on this before rc1 -- and I think we really should be looking at shipping what we've done already rather than trying to cram more new features in at this point.

And I actually still don't see how this is particularly useful given the differences between the default themes on XP and Vista that you *can't* select against currently (unless you're dynamically rewriting your style sheets from script).

I suppose it seems like this isn't really adding any *new* security risk (especially given that it's a boolean), although it would probably be good to have an opinion from dveditz.
(In reply to comment #25)
> two common themes) against the cost of all future widget backend implementors
> trying to figure out "What the heck am I supposed to return for this value?"
> and the cost of future platform users trying to understand when they should 

This bug is Windows only. I don't care about other widget backend implementors, I care about being able to make our default Vista and XP themes look as good as possible without running into accessibility issues.

If the patch needs a comment or the metric needs to be amended to indicate its windows-only-ness, that's fine.

> (Are there *really* only two themes, plus the high contrast ones, on Windows?)

No, there's really only one default theme on each version of Windows, and that's the theme that the vast majority of people using Windows operating systems are using. In order to pick colours and styles that look best with that default theme (especially in the case of Vista) we need to use some colours which aren't otherwise exposed through the nsILookAndFeel code as atoms.

Hardcoding these colours has been problematic for how it impacts:

 - people running in "Windows Classic" or other third party themes
 - people running with high contrast themes

This flag will allow us to know if either of those cases are true, and in those cases, fall back to colours derived from system set values.

A practical example is using the Vista style of the "Media Toolbox" style which has a black background and requires white text for the labels. While the "media toolbox" style degrades gracefully in Windows Classic to a classic window background colour, there's no way for us to change the text colour (none of the exposed system colours seem to go from white to not-white depending on theme mode).

> In the long run, I think:
> 
>  * the desired long-term solution is one where you pick up the characteristics
> of the system theme rather than have to hard-code them into the Firefox theme

I agree, and wherever possible, we *will* continue to use system colours which react based on the user selected theme.

>  * The features currently provided by -moz-system-metric belong as part of
> media queries, not selectors.

I'm not sure what the implication of this critique are, but I'm not attached to the -moz-system-metric family. If another is more appropriate, I'm game.

>  * if you want to provide Firefox themes that are actually specific to system
> themes, it seems like you want to query theme names, not a boolean is-default
> value that's going to require continued maintenance over future OS versions

While technically true, the default theme names haven't changed in Windows XP or Vista. Still, I see what you're saying here, I'm just not sure it's a big deal.

>  * the long-term solution to the problems you're dealing with seem like more
> values of -moz-appearance and maybe more system colors, perhaps combined with
> media queries against system colors for selecting appropriate icons to use
> against the background

Or even an API for colour theory so we can pick foreground text colours based on offsets of the detected background colour, sure. There's lot of things we could do. This is one of them.

> If you're still seriously planning to add the features that depend on this
> feature for 1.9 (and planning to have them adequately tested through a range 

If by "features" you mean "CSS tweaks to the default windows theme", then yes, I am seriously planning to make those changes. We're talking about changing backgrounds and foreground colours here.

> And I actually still don't see how this is particularly useful given the
> differences between the default themes on XP and Vista that you *can't* select
> against currently (unless you're dynamically rewriting your style sheets from
> script).

We can use chrome overrides, and are, to differentiate between our XP and Vista theme.

(In reply to comment #23)
> Guys, it seems to me that this change is REALLY late.  I'll defer the blocking
> decision to others.

If we could have gotten people to focus on this sort of stuff earlier, we would have. This is simply exposing an existing Windows system metric to our theming engine so that we can make smart decisions based off of it and end up looking really good, instead of just kind of good, on the default theme in Vista.
Flags: blocking1.9- → blocking1.9+
Attached patch Patch (v1.1) (obsolete) — Splinter Review
I made a few minor changes to the previous patch based on Beltzner's comments in comment 26:

1. Changed os-default-theme to windows-default-theme, as this will be a Windows specific metric.
2. Added a comment in nsILookAndFeel.h to note that this metric is for Windows only, and other platforms should merely return NS_ERROR_NOT_IMPLEMENTED when faced with it.
3. In nsCSSRuleProcessor.cpp, the patch now ignores NS_ERROR_NOT_IMPLEMENTED return valus.

I'm carrying over the r+ on the patch since this new version doesn't have any major code changes.  Requesting sr from dbaron.
Attachment #313577 - Attachment is obsolete: true
Attachment #313969 - Flags: superreview?(dbaron)
Attachment #313577 - Flags: superreview?(dbaron)
(In reply to comment #26)
> A practical example is using the Vista style of the "Media Toolbox" style which
> has a black background and requires white text for the labels.

Is this specified anywhere? It's not called "Black Rebar" to start with.
It would be nice if we could make stuff like that work in the first place and leave the hacks alone.
(In reply to comment #28) 
> Is this specified anywhere? It's not called "Black Rebar" to start with.
> It would be nice if we could make stuff like that work in the first place and
> leave the hacks alone.

These colors are stored in the Media::Toolbar and Communications::Toolbar themes. I posted Bug 427045 about digging them out, but it does seem a bit late to accept a patch.

Perhaps instead of doing this css hack, its better to just detect the theme and set an attribute on the two things needing special styles. Namely splitters in the browser/Library sidebars and on the Library toolbar. That could then easily be removed in the next version without the chance that some other strange XUL app/web page is depending on this proprietary css rule.
Comment on attachment 313969 [details] [diff] [review]
Patch (v1.1)

>+ *   Ehsan Akhgari <ehsan.akhgari@gmail.com>

I'm not sure what the license requires, but it seems a little odd to add your name to the license header for modifications small enough that somebody else would likely have written them the same way.  (Can one be considered to have copyright on changes of that stope?)

>+  nsresult rv = lookAndFeel->GetMetric

Does redeclaring this in the same scope even compile?  I doubt it.
Comment on attachment 313969 [details] [diff] [review]
Patch (v1.1)

>+    /*
>+     * This metric is not implemented on other platforms.  Other platforms
>+     * should return NS_ERROR_NOT_IMPLEMENTED when queried for this metric.
>+     */
>+    eMetric_WindowsDefaultTheme,                               // Whether the Windows default theme is being used

The "Whether the Windows default theme is being used" should be the start of the main comment, not the additional comment.  (And you should probably say that it's a boolean.)

And in fact, given this wording, it's probably ok if it's false and *implemented* on other platforms, although it doesn't matter (ok with me either way).


I guess I'm fine with this patch with this comment and the previous addressed, but I'm not marking sr+ on a patch that doesn't compile, since somebody might check it in.
Attached patch Patch (v1.2)Splinter Review
(In reply to comment #30)
> (From update of attachment 313969 [details] [diff] [review])
> >+ *   Ehsan Akhgari <ehsan.akhgari@gmail.com>
> 
> I'm not sure what the license requires, but it seems a little odd to add your
> name to the license header for modifications small enough that somebody else
> would likely have written them the same way.  (Can one be considered to have
> copyright on changes of that stope?)

I removed those.

> >+  nsresult rv = lookAndFeel->GetMetric
> 
> Does redeclaring this in the same scope even compile?  I doubt it.

Oops, my mistake.

(In reply to comment #31)
> (From update of attachment 313969 [details] [diff] [review])
> >+    /*
> >+     * This metric is not implemented on other platforms.  Other platforms
> >+     * should return NS_ERROR_NOT_IMPLEMENTED when queried for this metric.
> >+     */
> >+    eMetric_WindowsDefaultTheme,                               // Whether the Windows default theme is being used
> 
> The "Whether the Windows default theme is being used" should be the start of
> the main comment, not the additional comment.  (And you should probably say
> that it's a boolean.)
> 
> And in fact, given this wording, it's probably ok if it's false and
> *implemented* on other platforms, although it doesn't matter (ok with me either
> way).

I changed this comment...
Attachment #313969 - Attachment is obsolete: true
Attachment #314002 - Flags: superreview?(dbaron)
Attachment #313969 - Flags: superreview?(dbaron)
Attachment #314002 - Flags: superreview?(dbaron) → superreview+
Keywords: checkin-needed
(In reply to comment #29)
> Perhaps instead of doing this css hack, its better to just detect the theme and
> set an attribute on the two things needing special styles. Namely splitters in

It's definitely better to use actual OS-defined colours where possible. I didn't even know that those existed, so your help here is invaluable. You might be interested in looking at the dependencies of bug 420232 (especially bug 420236) - I bet your insight and knowledge could help us find good ways of addressing the problems therein.

I would be really, really happy to never have to use this metric. I just don't want to be limited in terms of being able to pick colours and styles that match the default Vista theme by not having it, either.
Blocks: 425999
Blocks: 423718
Blocks: 403147
Checking in layout/style/nsCSSRuleProcessor.cpp;
/cvsroot/mozilla/layout/style/nsCSSRuleProcessor.cpp,v  <--  nsCSSRuleProcessor.cpp
new revision: 1.26; previous revision: 1.25
done
Checking in widget/public/nsILookAndFeel.h;
/cvsroot/mozilla/widget/public/nsILookAndFeel.h,v  <--  nsILookAndFeel.h
new revision: 1.65; previous revision: 1.64
done
Checking in widget/src/beos/nsLookAndFeel.cpp;
/cvsroot/mozilla/widget/src/beos/nsLookAndFeel.cpp,v  <--  nsLookAndFeel.cpp
new revision: 1.31; previous revision: 1.30
done
Checking in widget/src/cocoa/nsLookAndFeel.mm;
/cvsroot/mozilla/widget/src/cocoa/nsLookAndFeel.mm,v  <--  nsLookAndFeel.mm
new revision: 1.17; previous revision: 1.16
done
Checking in widget/src/gtk2/nsLookAndFeel.cpp;
/cvsroot/mozilla/widget/src/gtk2/nsLookAndFeel.cpp,v  <--  nsLookAndFeel.cpp
new revision: 1.38; previous revision: 1.37
done
Checking in widget/src/os2/nsLookAndFeel.cpp;
/cvsroot/mozilla/widget/src/os2/nsLookAndFeel.cpp,v  <--  nsLookAndFeel.cpp
new revision: 1.45; previous revision: 1.44
done
Checking in widget/src/photon/nsLookAndFeel.cpp;
/cvsroot/mozilla/widget/src/photon/nsLookAndFeel.cpp,v  <--  nsLookAndFeel.cpp
new revision: 1.36; previous revision: 1.35
done
Checking in widget/src/windows/nsLookAndFeel.cpp;
/cvsroot/mozilla/widget/src/windows/nsLookAndFeel.cpp,v  <--  nsLookAndFeel.cpp
new revision: 1.70; previous revision: 1.69
done
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9
Comment on attachment 313578 [details]
Test :-moz-system-metric(os-default-theme)

This testcase doesn't actually work atm, as the metric is different; it's (default-windows-theme)
Attachment #313578 - Attachment is obsolete: true
Not sure if I should be filing a new bug or asking for a reopening of this bug (and my apologies if I did the wrong thing)...

What about other officially-signed Microsoft themes?  Notably, the Royale and Zune themes?  Luna, Royale, and Zune are the only three Microsoft-signed themes XP to ever be publicly released.  The latter two are very similar to Luna Silver in terms of style and base color.  I think that these two (royale.msstyles, zune.msstyles) should be granted an exception and be counted as a "default" style since for the purposes of this feature, they really should be lumped in with Luna.
I'm personally in favor of grouping royale and zune with Luna, in particular now that we have bugs like bug 428878.  However, we will probably need to pick up this functionality in the next release since we are really short on time.
(In reply to comment #37)
> I'm personally in favor of grouping royale and zune with Luna, in particular
> now that we have bugs like bug 428878.  However, we will probably need to pick
> up this functionality in the next release since we are really short on time.
> 

I filed bug 429176 with a fairly trivial patch...
I run several tests under Vista and XP the last days and everything works like a charm.

Verified with Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9pre) Gecko/2008050806 Minefield/3.0pre ID:2008050806 and probably a good candidate for Litmus?
Status: RESOLVED → VERIFIED
Flags: in-litmus?
(In reply to comment #39)
> probably a good candidate for Litmus?
> 
This isn't really a feature; it's an internal mechanism that helps winstripe look mostly right on the wildly varying ecosystem known as Windows themeing.  If there is a test, it would be something along the lines of "Does it look Luna-y on Luna, Aero-y on Vista, and Classic-y on Classic?"  Or just point them at attachment 315815 [details]
Keywords: dev-doc-needed
Dao, there's been an entry about this at MDC for some time now:
http://developer.mozilla.org/en/docs/CSS::-moz-system-metric(windows-default-theme)

(Likewise, the Vista toolbar background/foreground CSS values that you also marked have been around at MDC for over a week as well--though not in their own articles.)
if it's complete, add dev-doc-complete?
(In reply to comment #42)
> if it's complete, add dev-doc-complete?
> 

Well, I wasn't sure if your flagging of dev-doc-needed was because you didn't know that it had already been documented or if you had thought that the existing documentation needed more work.
(In reply to comment #43)
> Well, I wasn't sure if your flagging of dev-doc-needed was because you didn't
> know that it had already been documented or if you had thought that the
> existing documentation needed more work.

I didn't know about it and when you told me, I wasn't sure if it's complete.
(In reply to comment #44)
> I wasn't sure if it's complete.
> 

Eh, I'm not really sure what exactly constitutes complete, either.  :)  But they do exist and are documented to a level comparable with other similar Mozilla CSS extensions (which, unfortunately, isn't saying all that much, esp. in the case of the color keywords...)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: