Closed Bug 1529323 Opened 5 years ago Closed 3 years ago

Make prefers-color-scheme respect the Firefox theme rather than the system theme

Categories

(Core :: CSS Parsing and Computation, enhancement, P3)

enhancement

Tracking

()

RESOLVED FIXED
95 Branch
Tracking Status
firefox95 --- fixed

People

(Reporter: ntim, Assigned: emilio)

References

(Blocks 3 open bugs)

Details

Attachments

(2 files)

I think it would make more sense given that an user can have a light system theme, but Firefox theme set to dark. Vice-versa also applies.

-moz-system-dark-theme can be preserved for making the default theme match the dark mode.

Notable side effect: this would enable prefers-color-scheme: dark on OSes that don't currently have a dark mode (e.g. Linux, Windows 7 and 8).

I think this is fine. The harder part would be to communicate theme changes across processes. The theme is currently kept in XULDocument, we'd need a way to broadcast that to all content processes.

(In reply to Emilio Cobos Álvarez (:emilio) from comment #3)

I think this is fine. The harder part would be to communicate theme changes across processes. The theme is currently kept in XULDocument, we'd need a way to broadcast that to all content processes.

There's already a mechanism to do communicate theme changes to the content process, the new tab page uses it.

See: https://searchfox.org/mozilla-central/source/browser/actors/LightweightThemeChild.jsm

That looks all JS, no way I call that from media query evaluation, would need to move that to C++, do you know who would know what's the best way to do that?

We could use a pref, right? I.e. set it from JS, read it in the style system.

Aye, I guess that'd do.

I think it's fine to make Firefox dark theme enable 'prefers-color-scheme: dark',
but the default behavior should be that Firefox honors the system theme (and
signals that in 'prefers-color-scheme').

(In reply to Mats Palmgren (:mats) from comment #8)

I think it's fine to make Firefox dark theme enable 'prefers-color-scheme: dark',
but the default behavior should be that Firefox honors the system theme (and
signals that in 'prefers-color-scheme').

The default behavior is that Firefox switches to the dark theme based on the system setting, so that would take care of it. Another question is what should happen if some other non-builtin theme is selected. We should probably just use the system setting then. All of that logic could live in front-end code.

See Also: → 1529897
See Also: → 1523990

I'm not opposed to this, but I would think that if we want to do it we should attempt to clarify this as an option as part of the spec in MQ5: https://drafts.csswg.org/mediaqueries-5/#prefers-color-scheme

That is, what is meant by "system" preferences could include UA preferences which take precedent over the operating system.

Priority: -- → P3

My first instinct is to not do this. It seems light/dark mode is something the user should set for the OS, knowing that setting will affect interfaces and content throughout their experience. Setting the Firefox theme doesn't seem like something that would change the experience of website content. We'd have to change user expectations.

(We want to debate this from the point of view of the users, not the technical perspective of the browser engine.)

But actually, I don't know what web designers would think of this, so I asked the question in a Tweet (super-unscientific-research). https://twitter.com/jensimmons/status/1103007418588454914

Another thought — currently Firefox defaults to the dark toolbar, the dark theme. So would we ship Firefox defaulting all websites to dark mode? Or would we change Firefox's default to the light theme? It seems like a severe choice to default (any website that has a dark mode) to dark mode, even for users who have not set dark mode in their OS, and likely haven't even heard of dark mode. It could create a lot of confusion to update Firefox, and suddenly some sites have dark background and light text.

(In reply to Jen Simmons [:jensimmons] from comment #11)

Another thought — currently Firefox defaults to the dark toolbar, the dark theme. So would we ship Firefox defaulting all websites to dark mode? Or would we change Firefox's default to the light theme? It seems like a severe choice to default (any website that has a dark mode) to dark mode, even for users who have not set dark mode in their OS, and likely haven't even heard of dark mode. It could create a lot of confusion to update Firefox, and suddenly some sites have dark background and light text.

This bit is not right, IIUC. Firefox defaults to the system setting (so dark in dark mode, light in light mode). So doing this would only affect users that configure Firefox to disagree with their system settings.

I think making the media query agree with the browser theme in that case is a sensible thing to do, but I don't feel strongly either way.

Oh I see. I thought the default theme — with its dark toolbar — was the same as a Firefox "dark theme". Actually nope. There are three themes, and the true dark mode has an even-darker toolbar than the default theme.

My mistake.

Here's a screenshot for anyone's who's confused like I was. https://monosnap.com/direct/RjZGGvY7bOQTFRdgQRyaaAR8Qrdbi1

Thanks, Emilio.

Another point of consideration (not sure if I should open a separate bug for this):

Currently prefers-color-scheme is stuck to light once resistFingerprinting is enabled, making it impossible for users to both communicate their color preference to a website and enable general fingerprinting resistance. There should be an option (pref?) to set prefers-color-scheme to light/dark/no-preference regardless of system, browser or resistFingerprinting setting or at least a way to enable "correct" (by whatever metric is decided) prefers-color-scheme, even if general fingerprinting resistance is enabled.

That should probably be a separate bug. There is already a pref (ui.systemUsesDarkTheme), it's just checked after resistFingerprinting.

OK, thanks. I filed bug 1535189 for that.

See Also: → 1535189
Blocks: 1546540

I've been thinking more about this, and I'm wondering if this should be based on the theme ID or based on a certain theme property.

If it's based on the theme ID, then the default theme (default-theme@mozilla.org) would never match, even in dark mode.

If it's based on a theme property (eg. colors.frame), then themes like this one: https://addons.mozilla.org/en-US/firefox/addon/arc-darker/ would always match. I guess the most accurate theme property to be based against would probably be colors.ntp_background, since it's the only one that matches content, but that seems pretty wrong too.

BTW, I like the current way quite much, because why not use a light theme for Firefox and dark for the system? It looks decent anyway.

What I could agree on would be that new installations (/profiles) of Firefox actually use the "corresponding" color/theme.

Blocks: 1553682
Summary: Consider making prefers-color-scheme respect the Firefox theme rather than the system theme → Make prefers-color-scheme respect the Firefox theme rather than the system theme

I come at this with the perspective of a user - so take my ignorance of Firefox internals as both unique insight as well as obliviousness to practicality.

It seems light/dark mode is something the user should set for the OS, knowing that setting will affect interfaces and content throughout their experience. Setting the Firefox theme doesn't seem like something that would change the experience of website content. We'd have to change user expectations.

I agree this is how it should work when Firefox's "default" theme is chosen, and that this should be the default for Firefox. However note that detection of the system theme is not always available or correct. On my system - XFCE with a dark theme - Firefox incorrectly determines that this is a light theme. For Firefox's UI itself, there is an easy workaround: select the dark theme in Firefox. It seems clear to me that this setting should affect prefers-color-scheme media query. As a user it was completely surprising that I could have "dark" theme selected while prefers-color-scheme reported "light".

This doesn't sound smart, it is contrary to how Dark Mode works everywhere else across all other apps.

A hidden about:config option for this is fine, but it should not be default.

Users of the the Firefox Developer Edition for example, just because it has a dark theme as default, would get a really different web experience than users of the other versions.

Normal users would try some of the other themes and Dark Mode support in FF would apparently break. They would enable Dark Mode or it would be auto-enabled (based on things like time or sunset), but Firefox would stay in light mode, giving away the impression of an outdated application without dark mode support.

I don't really see the need to change the current default.

(In reply to Andrew Kelley from comment #19)

I agree this is how it should work when Firefox's "default" theme is chosen, and that this should be the default for Firefox. However note that detection of the system theme is not always available or correct. On my system - XFCE with a dark theme - Firefox incorrectly determines that this is a light theme. [..] As a user it was completely surprising that I could have "dark" theme selected while prefers-color-scheme reported "light".
A better way to solve this, apart from just improving the detection methods, would be to give the users to override what color theme (dark/light) their themes are.

I messed up the last quote there a bit, the last paragraph above is mine, not Andrew's.

Blocks: 1538522
No longer blocks: 1546540
See Also: → 1546540

BTW, it is worth discussing how

Sorry about that.

BTW, it is worth discussing whether privacy.resistFingerprinting (set to true) is still going to override this preference to light as it does now.

(In reply to Ashutosh Sharma from comment #29)

BTW, it is worth discussing whether privacy.resistFingerprinting (set to true) is still going to override this preference to light as it does now.

That was bug 1535189

Blocks: 1432725

Is this an accessability issue? For me I use a addon to override the colours on all pages so I can see them: https://paul.bone.id.au/blog/2017/11/26/how-i-see-the-web/ But because I can work-around this with a plugin is it still accessability related?

Why not an extra field in the Contect section of about:preferences where people choose one of three options:

  • Ask pages to use dark mode depending on my OS's current dark mode
  • Ask pages to use dark mode depending on my browser's theme
  • Always ask pages for light mode
  • Always ask pages for dark mode

Ideally right next to or instead of the current colour selection stuff that's in that dialog where you already override system settings.

I don't know what the default should be, Maybe 1, on Windows/OSX where dark mode exists but 2 or 3 elsewhere?

Keywords: access

While I fully support making this change, I think calling it an accessibility issue is a bit of a stretch. It sounds like you really want dark high contrast mode, which we have supported for a long time. Even if you use dark mode as an accessibility tool, we support that mode independently from the dark Firefox theme, but we need a signal from the OS. So if your OS doesn't support these modes, please lobby there. As a workaround I believe you can also use the ui.systemUsesDarkTheme hidden pref.

Keywords: access

I gave it some more thought and I also now think it's not an accessability thing.

For my own needs I install the plugin and it affects all pages, whereas with asking sites for a dark theme is only going to work on a small fraction of sites (today at least). Where it might be is for cases where the addon doesn't work (it's not perfect) and if those sites that didn't work also understood this setting and could give me a dark theme, then the addon says "oh look, the site gave us a dark theme, I don't have to change it". that might be nice. Eg slack better with the addon disabled but using its own theme. But I might still want more control. Discord's dark theme isn't dark enough.

Can we expose ui.systemUsesDarkTheme in about:preferences on systems that don't have a dark theme. I didn't even know it existed until now.

(In reply to Lyubomir Parvanov from comment #34)

This isn't going to be hardcoded in stone, is it? As a Firefox user i would hate to spend my time every single day changing the color scheme of both Firefox and system. System-wide is called system-wide for a reason i guess.

See comment 9.

Lots of apps in Windows 10 let me choose if I want the app to use a light theme, a dark theme or to use my system's theme. Windows 10 has separate shell and app modes. Since browsers nowadays are just like operating systems, Firefox could have a similar option. One for the browser and one for websites. Websites will then have the same 3 options. I was expecting the dark theme to affect more than just the chrome. but perhaps paul's options are better. A link to those settings in the customise screen would be really useful.

It really bothers me that while YouTube and Facebook have dark modes, neither use prefers-color-scheme.

Chrome, Edge, and mobile Firefox have all addressed this question by having a simple dropdown in their preferences offering "light", "dark", or "system default" (the latter called "follow device theme" on mobile Firefox). Is there any reason desktop Firefox couldn't offer the same choice?

For Chrome/Edge/mobile Firefox this dropdown controls the browser chrome as well as the prefers-color-scheme value for websites. For desktop Firefox, since the "default" browser theme contains both light and dark modes based on system/device theme, I think this proposed dropdown should override that as well when the "default" theme is active.

If the user has chosen some other theme add-on then it's up to that add-on what to do. If you put this proposed dropdown on the themes tab in about:addons then it will be discoverable by users when they go to switch their theme. They can choose the "dark" option if they are enabling a dark theme, if desired, or whatever they wish.

I also fully support this change and wonder when it will be introduced (not a moment too soon?).

Check out the attached screenshot. That's my Mac with dark mode on, and Firefox with light mode on. Check out how the Github favicon renders. That's just wrong, it's essentially invisible to the human eye. Firefox should signal that light mode is on, so the favicon can render with the foreground/background colors inverted.

I understand this may get tricky with third-party Firefox themes. But start with the default dark/light Firefox themes (which should be what the vast majority of users use). Fix those, then give third-party themes the ability to identify (and report) themselves as either light or dark.

The user's browser's setting should override the user's OS's setting.

If this is gonna be implemented, it should be optional or there should be a way to revert it. Else this will make some users unhappy.
I'm using Developer Edition at home and at work (I'm a programmer).
So If this is implemented, all pages will be in dark mode? And I will have to switch theme to change that?

I don't want to have dark pages at work at all.
And at home my OS changes to dark in the evening and the web gets dark, which is ok. But I don't want my theme to change.

(In reply to juraj.masiar from comment #45)

If this is gonna be implemented, it should be optional or there should be a way to revert it. Else this will make some users unhappy.
I'm using Developer Edition at home and at work (I'm a programmer).
So If this is implemented, all pages will be in dark mode? And I will have to switch theme to change that?

I don't want to have dark pages at work at all.
And at home my OS changes to dark in the evening and the web gets dark, which is ok. But I don't want my theme to change.

An unmodified Firefox already allows you to select:

  • Light: A theme with a light colour scheme.
  • Dark: A theme with a dark colour scheme.
  • Default: A theme with the operating system colour scheme.

If you don't wish to have dark pages at all, then simply use the Light colour scheme. Or, you can use the Default colour scheme if your OS already uses a light theme.

The point of this bug, I think, can be summarized as Firefox overriding (or winning over) the OS colour scheme if the two differ. Otherwise, you get the behaviour I screenshot'ed in comment 43.

I fully agree with comments 19 and 21, but comment 43 is making a good point.

I would propose the following solution:

  • When using the "Default" theme, "prefers-color-scheme" should respect the system dark theme, since on Linux it already respects the system dark theme (because it applies the system GTK theme). Doing otherwise would result in inconsistencies (comment 21). It already works this way, and as a Linux user I would like to keep this behavior, and having to change the theme to one of the other ones as a workaround wouldn't work as it would use its own colors and it would ignore the theme set by the "Night theme switched" GNOME extension.

  • When using the "Light" theme, "prefers-color-scheme" should be light, because that's what the user requested (solving the issue in comment 43).

  • When using the "Dark" theme, "prefers-color-scheme" should be dark, because that's what the user requested.

  • For other third-party or first-party themes, "prefers-color-scheme" should let the theme developer decide whether "prefers-color-scheme" should be light, dark, or follow the system theme, based on how they already theme the "about:" pages. (Disclaimer: I don't know how themes are made, so anyone who knows about this, please fill me in the necessary technical details).

  • Additionally, if there's a mismatch between the system dark theme and the Firefox theme, Firefox should display a prompt to change the theme.

See Also: → 1687128

Looks like the current patch in bug 1701691 gets us half-way there.

Depends on: 1701691
Blocks: 1705661
Blocks: 1593355

Given all our UI is using -moz-toolbar-prefers-color-scheme, this seems
like a more reasonable default nowadays. Allow for it to be
configurable via the existing pref.

Assignee: nobody → emilio
Status: NEW → ASSIGNED
Blocks: 1736038
Pushed by ealvarez@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/09ace42c5e87
Make prefers-color-scheme follow the Firefox theme, not the system theme (by default). r=mstange,dao,extension-reviewers,robwu
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → 95 Branch
See Also: → 1733461

I think the heuristic here might not be right. I have the brown theme from colorways with the light new tab page: Elemental Balanced. Today some pages have started switching to dark mode. Since I have chosen to have the light new tab page, I would have expected it to follow that precedent -- i.e. I'm clearly indicating I want light mode for content. Would it make sense to file a bug for that?

(Also, out of curiousity, I guess setting layout.css.prefers-color-scheme.content-override to 2 is the way to revert this?)

Oddly, it's not entirely consistent. On GitHub I sometimes get the dark theme, sometimes the light theme. If I work out an STR I'll file a bug for that.

(In reply to Brian Birtles (:birtles) from comment #53)

Oddly, it's not entirely consistent. On GitHub I sometimes get the dark theme, sometimes the light theme. If I work out an STR I'll file a bug for that.

Just saw this on Google too. Some tabs are dark mode, some are light.

(In reply to Brian Birtles (:birtles) from comment #53)

I think the heuristic here might not be right. I have the brown theme from colorways with the light new tab page: Elemental Balanced. Today some pages have started switching to dark mode. Since I have chosen to have the light new tab page, I would have expected it to follow that precedent -- i.e. I'm clearly indicating I want light mode for content. Would it make sense to file a bug for that?

Can you file and ni? me? The balanced themes usually have a dark toolbar so I'm a bit surprised that you have a light newtab pagez but I'll try to repro.

(Also, out of curiousity, I guess setting layout.css.prefers-color-scheme.content-override to 2 is the way to revert this?)

Yes

Oddly, it's not entirely consistent. On GitHub I sometimes get the dark theme, sometimes the light theme. If I work out an STR I'll file a bug for that.

Maybe logged in status applies there? Iirc GitHub is light unless you explicitly switch themes.

Regressions: 1736163

I want to record here that I strongly dislike this change for reasons that I believe apply to a significant number of others, so that I think further change is warranted before shipping this to stable.

Comment 21 is a fair starting point at demonstrating how a theme can be an æsthetic matter so that its darkness need not correlate with desired content darkness. But applied more generally, it’s just about universal for graphics programs to separate chrome and content darkness: chrome moderately dark as a neutral sort of colour to avoid distracting from the content (at least when used maximised or full-screen, otherwise I acknowledge dark may instead draw attention if what lies outside it is light), and content essentially light (or really whatever you make of it, but that generally starts light and is more commonly more light-like than dark-like).

This is the reason and way that I use the dark theme: to draw attention away from the chrome, to the appropriately light mode content. I expect this is a very common desire, though I imagine there may be at least as many who want dark chrome and content. (And I understand that Firefox’s behaviour already varied across platforms so that some users already got dark theme and content, and that this patch was about making it consistent across all platforms, that content match chrome/theme rather than system.)

Anyway, I believe that a substantial number of users will prefer the old behaviour. I hope that before this gets released there will be a better way of getting back to it than through about:config. From bug 1733461 I gather that “Install the ‘prefer light-themed content’ extension” might be one way, but that doesn’t feel like a very good way of achieving it. I feel layout.css.prefers-color-scheme.content-override warrants placement in about:addons → Themes: something like a dropdown “Theme for web page content: {match browser theme (dark)/match OS (light)/light/dark}”. (I guess it might need to get the whole “such-and-such an extension is controlling this” treatment too?)

Anyway, them’s my thoughts. Do what you will with them, down to and including nothing. 🙂

Blocks: 1736218

(In reply to Chris Morgan from comment #56)

Yeah, I understand this is a fairly controversial topic, but given all the other Firefox UI (including the one loaded in the content area) switched to follow the Firefox theme, I believe it's a more consistent default. Note that the Firefox theme by default will follow the OS theme, so this is only a behavior change for users that have changed their theme.

Comment 21 is a fair starting point at demonstrating how a theme can be an æsthetic matter so that its darkness need not correlate with desired content darkness.
[...]

Bug 1736141 will make that better by deriving the content darkness from the newtab page colors of the theme (so you can very easily create a theme that has a dark toolbar but light content).

Anyway, I believe that a substantial number of users will prefer the old behaviour. I hope that before this gets released there will be a better way of getting back to it than through about:config. From bug 1733461 I gather that “Install the ‘prefer light-themed content’ extension” might be one way, but that doesn’t feel like a very good way of achieving it. I feel layout.css.prefers-color-scheme.content-override warrants placement in about:addons → Themes: something like a dropdown “Theme for web page content: {match browser theme (dark)/match OS (light)/light/dark}”. (I guess it might need to get the whole “such-and-such an extension is controlling this” treatment too?)

In any case I agree this is probably worth it. I've filed bug 1736218 for this.

(In reply to Chris Morgan from comment #56)

I want to record here that I strongly dislike this change for reasons that I believe apply to a significant number of others, so that I think further change is warranted before shipping this to stable.

Comment 21 is a fair starting point at demonstrating how a theme can be an æsthetic matter so that its darkness need not correlate with desired content darkness. But applied more generally, it’s just about universal for graphics programs to separate chrome and content darkness: chrome moderately dark as a neutral sort of colour to avoid distracting from the content (at least when used maximised or full-screen, otherwise I acknowledge dark may instead draw attention if what lies outside it is light), and content essentially light (or really whatever you make of it, but that generally starts light and is more commonly more light-like than dark-like).

This is the reason and way that I use the dark theme: to draw attention away from the chrome, to the appropriately light mode content. I expect this is a very common desire, though I imagine there may be at least as many who want dark chrome and content. (And I understand that Firefox’s behaviour already varied across platforms so that some users already got dark theme and content, and that this patch was about making it consistent across all platforms, that content match chrome/theme rather than system.)

Anyway, I believe that a substantial number of users will prefer the old behaviour. I hope that before this gets released there will be a better way of getting back to it than through about:config. From bug 1733461 I gather that “Install the ‘prefer light-themed content’ extension” might be one way, but that doesn’t feel like a very good way of achieving it. I feel layout.css.prefers-color-scheme.content-override warrants placement in about:addons → Themes: something like a dropdown “Theme for web page content: {match browser theme (dark)/match OS (light)/light/dark}”. (I guess it might need to get the whole “such-and-such an extension is controlling this” treatment too?)

Anyway, them’s my thoughts. Do what you will with them, down to and including nothing. 🙂

I agree, there should be a Setting in about:preferences one for Firefox, one for pages.I files a related bug https://bugzilla.mozilla.org/show_bug.cgi?id=1730657 for extension pages in about:addons. That is different, you expect them to use the same background the UI around them jses.

(In reply to Chris Morgan from comment #56)

I also want to record my disagreement with this change, for similar reasons. I use a dark theme because I want a dark menu bar and on the browser chrome in general, not because I want it to affect the content of the pages I browse.

You may think this is a bug, you may think this is a feature. It doesn't matter. We all have to agree that there are users making use of it as a feature. So, to release a change without a proper way to bypass it is a bad idea.

There is a way to bypass it via about:config (setting layout.css.prefers-color-scheme.content-override) and via an web-extensions API.

There's a bug on file to expose it in a more prominent way in the UI (bug 1736218), but that's basically blocked on UX giving me the go-ahead.

Blocks: 1741009
See Also: → 1746117

Is there any SUMO article about updating the setting?

It would also have been nice to have a relnote for this change, with a link to the SUMO page. I guess that it's too late for 95, but perhaps as part of bug 1736218?

Here is a user report about how this change negativity affects the user experience/readability when a custom theme is used: https://github.com/mozilla/FirefoxColor/issues/998

This feature creates accessibility problems. I wrote more about it here:
https://github.com/mozilla/FirefoxColor/issues/998

It has been extremely frustrating trying to find a solution, because I kept getting hit with dark mode while trying to get work done. My regular theme is dark, but highly customized with userChrome.css so that I can distinguish things, and it also helps me distinguish between multiple Firefox profiles, so it isn't easy to just switch to another theme.

Read more about the problems dark mode creates:
https://www.boia.org/blog/dark-mode-can-improve-text-readability-but-not-for-everyone

"People with dyslexia and astigmatism may have issues reading light text on dark backgrounds"

Users aren't going to be able to figure out how to solve the problems that this feature creates.

Are there really users out there who don't want their browser to respect their system theme? Even if there are, I'm sure they are vastly outnumbered by people who want a dark UI with webpages that respect their system theme.

Are there really users out there who don't want their browser to respect their system theme?

That is a fine default, but no, I'd want to set the browser independent of system configuration.

Windows' dark mode is, quite frankly, dreadful in my opinion. The contrast and colors are very poor, and it's clear that no one at Microsoft has ever opened up Windows UI's older than Windows 10's stuff. The older bits of UI tend to fall apart and become unusable (black text on near-black backgrounds is not a rare find).

On Linux there's also the issue of trying to figure out what value the browser looks for in order to set dark/light modes. I've certainly had to create dummy GTK configs in the past while using XFCE or KDE as there's no standardized/global way of setting that the user prefers a certain scheme.

Forcing users to alter system wide configs ignores the reality that many apps do not create good dark mode experiences. Any app, including browsers, should have ways of overriding this internally.

I'm sure they are vastly outnumbered by people who want a dark UI with webpages that respect their system theme.

Being outnumbered isn't relevant, unless you're saying users with other preferences should be ignored entirely.

Any app, including browsers, should have ways of overriding this internally.

That would be fine if there were a simple setting to change it.

It took me a few days to figure out where to get help, and I'm pretty experienced with Firefox (using it since the beginning) and I know what Github and this site are. Most users with that problem will have no idea on how to fix it or give feedback. I'm sure there are people with vision problems out there right now in distress, with no idea about what to do.

Suddenly switching users to dark mode on websites without a clear, easy way to turn it off is a disaster for accessibility. It suddenly forces users to either abandon their custom accessibility configs (like in userChrome.css) or end up with unreadable web pages.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: