Closed Bug 70315 Opened 24 years ago Closed 6 years ago

text in menus and boxes unreadable if using dark GTK theme

Categories

(Core :: Widget: Gtk, defect, P3)

Product:
Core
Component:
Widget: Gtk
Platform:
All
Linux
Type:
defect

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1527048

People

(Reporter: daemonc, Unassigned)

References

Details

(Whiteboard: tpi:+)

Attachments

(7 files)

Downloads info is unreadable
16.29 KB, image/png
Details
URL dropdown with almos unreadable text
15.40 KB, image/png
Details
The awesomebar with the darkilouche theme...
8.86 KB, image/png
Details
The website identification box with the darkilouche theme.
31.45 KB, image/png
Details
Dropdown menus with dark background don't change the text to contrast.
11.47 KB, image/png
Details
Firefox 3.5 vs Dark GTK theme
71.65 KB, image/png
Details
Bug70315Fx24.png
99.40 KB, image/png
Details
As of recent builds (2001022613), Mozilla has been using black text on top of the GTK theme's background color in text boxes (such as the one I'm typing in now) and in the menus of the classic theme. This is a problem if you use a dark GTK theme, as I do, where the background color is almost black. In Mozilla 0.8, the text color from the GTK theme, which is white, was used. In other words, if you are going to use colors from themes, use BOTH the background and foreground colors. If you are going to force the text color to be black, then you had better force the background to be something not black.
Chaning the qa contact on these bugs to me. MPT will be moving to the owner of this component shortly. I would like to thank him for all his hard work as he moves roles in mozilla.org...Yada, Yada, Yada...
QA Contact: mpt → zach
updating to new owner. sorry for the spam.
Assignee: hangas → mpt
Using build 2001030812, text in menus is now white, text in boxes is still black on black background. Also this bug may be related to bug 67448.
What's the name of the GTK theme you use where you see the problems?
Any theme with a dark background and white text will do.
Well, I'm trying to attach it, but bugzilla keeps timing out. The theme I'm using is called Darkalloy. Some you might find on themes.org are Absolute-E, Darkmarble,
I've experimented a little with what we could do to fix this. If I change the two places where we used the |text| color (WindowText and an equivalent non-CSS color type) to use the |fg| color, then Darkmarble improves significantly, but it huts some other themes including LCARS (a dark theme where the default text |fg| color is the same as the default button background) and Metal (where the default text |fg| color is not really intended to be used for significant chunks of text. (That's generally the problem, I think -- that the |fg| color is made to be used for bits of UI, but not the large chunks of text that it's used for in "Use System Colors".) I think part of the problem is coming from our system color use conventions: * there are places where -moz-field is used as a background, and it doesn't have a matching foreground color * there are places where text that is not ButtonText colored is used on a ThreeDFace background. (In the Windows system colors, ThreeDFace was defined to be equivalent to ButtonFace -- the ThreeD* colors were added in Windows 95 when buttons went from a single-border raised appearance to a double-border raised appearance. Is it a bug that we use the ThreeDFace color as a background on things other than buttons?)
The following patch is arguably correct, and it improves the situation in the DarkMarble theme, but makes it worse in Metal (because it's using a color that was intended for labels rather than large chunks of text) and LCARS (because we use WindowText on a ThreeDFace background). I think if we really want to fix this we need to change some of the ways system colors are used in the Classic skin. To do this, it would be helpful to understand exactly what some of the system colors (e.g., WindowText, AppWorkSpace, etc) mean in Windows (since that's where they came from, and the CSS definitions aren't too informative). Index: nsLookAndFeel.cpp =================================================================== RCS file: /cvsroot/mozilla/widget/src/gtk/nsLookAndFeel.cpp,v retrieving revision 1.49 diff -u -d -r1.49 nsLookAndFeel.cpp --- nsLookAndFeel.cpp 2001/03/10 03:17:07 1.49 +++ nsLookAndFeel.cpp 2001/03/10 04:08:04 @@ -224,7 +226,7 @@ break; case eColor_windowtext: - aColor = GDK_COLOR_TO_NS_RGB(mStyle->text[GTK_STATE_NORMAL]); + aColor = GDK_COLOR_TO_NS_RGB(mStyle->fg[GTK_STATE_NORMAL]); break; // from the CSS3 working draft (not yet finalized)
Just so everyone knows, text boxes are still completely unreadable in many GTK themes, and 8.1 will be out in a few days.
Should I back out all my changes for bug 67448? The above patch would be part of such a backout, and wouldn't be such a problem with LCARS if we're not getting real button colors. Or maybe I should just check that in and fix many themes at the expense of LCARS and any other themes where the button colors don't match the window colors?
Well, the only places I see a problem right now is the text boxes and text lables in the personal toolbar. If these can be reverted to the way it was before with your one-line patch, I say go for it. If it messes colors up in other themes, then perhaps it's better to back the whole thing out until we can do it a way that is "right" for all cases.
--> Themes. Coming up with a -moz-CSS set of sane and cross-platform UI colors is an idea which seems more attractive by the minute.
Assignee: mpt → hewitt
Component: User Interface Design → Themes
QA Contact: zach → pmac
Severity: major → normal
Status: NEW → ASSIGNED
Target Milestone: --- → Future
isn't that fixed? at least, with FB gtk2 it is.
Hardware: PC → All
I'm still suffering from this bug on sites which use CSS to set the foreground colour in buttons and text entry widgets, but continue to inherit my gtk background colour. See, eg webmail.unimelb.edu.au (though I've asked them to add a background colour to their style sheets; I'll post the next example I come across). The gtk theme is at http://www.cs.mu.oz.au/~pde/greenstone++.tgz What I'd really like to know: is there a way to make mozilla completely ignore the gtk theme? It's a bit silly to just take the buttons and text entry box colours out of context anyway.
This bug still exists. Attaching 2 examples. These were taken with: Build identifier: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9b2) Gecko/2007121016 Firefox/3.0b2 on Fedora 8 with jimmac's Darkilouche gtk theme.
See above.
What's this bug status regarding the Firefox 3 release?
Is this really that difficult to fix? I'd be willing to work on a patch if there is a chance to get this into Firefox 3
The green urls are almost unreadable...
Another situation where using a dark theme (GTK darkilouche) leads to unreadable text.
Joe appears to be "gone"... flipping assignment to default again.
Assignee: hewitt → nobody
Status: ASSIGNED → NEW
QA Contact: pmac → themes
not sure if its still the same bug, but linking ubuntu bug https://launchpad.net/bugs/220263 ("Bad Firefox integration with dark themes") to this one.
Product: Core → SeaMonkey
Target Milestone: Future → ---
Dark theme in ubuntu firefox 3.0.4, chrome still doesn't respect the dark theme by having contrasting text on its dropdowns, dark dropdowns with nearly unreadable dark text result.
Hmmm, for whatever reason the project says seamonkey, so perhaps this is the wrong bug for the firefox issue in firefox 3.
Confirm the bug on Ubuntu 9.04, GNOME 2.26.1, 'New wave' built-in theme
Component: Themes → Widget: Gtk
Product: SeaMonkey → Core
QA Contact: themes
Attached image Bug70315Fx24.png —
The bug is still present in Firefox(24.0).
Honestly, I understand the complexity of this issue but can we just make Firefox ignore the GTK theme completely from within the viewport? I don't think it makes sense to make the GTK theme dictate what is going on inside of the viewport.
To clarify, instead of Firefox trying to make an informed decision based on the system/GTK theme, can Firefox just default to the colours specified in the Content tab in Colors and pretend that GTK doesn't exist? (only in the viewport) the only alternative to this problem is to install extensions that allow the user to override page themes but that is ultimately messy and can also break things in unexpected ways.
I too am also affected by this (seemingly old) bug, on an Ubuntu Gnome 15.04 using the built-in dark theme. Some text boxes result in using white text on a white background, since Firefox uses a mixture of the webpage CSS and that from the GNOME theme. Dario's suggestion above is sensible, since webpages were meant to look the same, regardless of OS/System/Theme.
As Dario said, it doesn't make sense to use the GTK theme on web pages. In addition to this, there is *already* a setting for not using the system colours: Edit > Preferences > Colors > Use system colors I believe it is off by default and obviously should prevent the system colour scheme from determining form field background colours, but it doesn't. Seems to be the same issue as in bug 519763, similarly disappointing progress there as well though.
For what it's worth, there is a very clean workaround in the ArchWiki: https://wiki.archlinux.org/index.php/Firefox#Unreadable_input_fields_with_dark_GTK.2B_themes I had seen some other userContent.css "fixes" that didn't get everything or overrode too much, breaking legit stylesheets, but this seems to only override the default and shouldn't override any actual website css.
I've tried that work around on form fields on my bank account, and they don't work. Actually GnomishDark theme also provides several recommendations under: /usr/share/themes/GnomishDark/README Which mozilla ones are almost the same suggested by the Arch workaround, and I've also been using for quite a while now. They don't work with FF 45.0.1 and gtk+3 3.20.2 setting gtk+3 to prefer applications' dark themes and to use the dark theme GnomishDark. However it doesn't work on nvidia graphics, but seems to be working on intel graphics with the same settings...
Though my problem is different though, the backgorund is white and the font is white as well
Priority: -- → P4
Whiteboard: tpi:+
Dear Storm, 1. Putting same heated rant in multiple bugs is one good way to achieve two things: a) earn a ban from commenting on this Bugzilla, and b) decrease the likelihood of these bugs being fixed by blurring their scope. I mean, it's surely the easy thing to do, whereas a much more constructive and useful thing would be to figure out which of these issues are duplicates of each other, or have lost focus over time, and propose merging or closing them. For example, this bug seems to have become a catch-all for anything dark_theme-related, and IMO is as good as closed by now anyways, whereas bug 119538 is actually about Firefox for Android, which is a separate product, has nothing to do with GTK, and is irrelevant in any discussion where particular issues on GTK, Windows or Mac are involved. Similarly, bug 1425517 is about Calendar (built-in Thunderbird extension), and as such has very little relevance to Firefox. Another good thing to do would be to file new bugs if you stumble upon issues which aren't on the record yet. The narrower the issue, the more chance you have of it being taken seriously and fixed. You know, because fixing "OMG NOTHING WORKS YOU ALL SUCK" is kinda more difficult than fixing "Checkboxes in this particular dialog are illegible when using dark theme, here's a screenshot and more info". Oh, and of course, you could have proposed a patch instead of complaining. 2. Content colors are user-managed, and default to black-on-white: https://support.mozilla.org/en-US/kb/change-fonts-and-colors-websites-use#w_change-font-color. The option to "Use system colors" is NOT checked by default, and it has always been this way. 3. On the other hand, form fields have always inherited the system-wide look by default. Mozilla even has it documented: https://developer.mozilla.org/en-US/docs/Learn/HTML/Forms/Styling_HTML_forms. 3. Illegible text, whether in form fields or elsewhere, is pretty much ALWAYS the designer's (or rather person's who did the CSS work) fault. It's a rule of thumb that if you're specifying background color, you should also specify text color, and vice-versa. Back in the day, people used to validate their CSS, and specifying just one of those colors would trigger a warning in the validator. Nowadays, everyone just blindly assumes that stuff will work after minimum testing on Chrome, and then blames whatever doesn't work in the other browser on that other browser. Now, aside from all that, I suppose a desire to use back-on-white on form widgets by default (so long as "use system colors" is unchecked) could be a valid feature request. I doubt this would be easy to implement though, especially assuming that some people might prefer native look.
Dear Rimas Kudelis, Let me answer each of your points. I'll leave point 1; to the last > 2. Content colors are user-managed, and default to black-on-white: > https://support.mozilla.org/en-US/kb/change-fonts-and-colors-websites- > use#w_change-font-color. FALSE. Those colors have _nothing_ to do with default colors. They are override colors, that, when apply, override websites' CSS as well. By default they only apply with HighContrast theme, and no, "use system colors" is NOT enabled on my FF. I just set those colors to bright red and neon green - guess what? Writing a review on addons.mozilla.org is _still_ light gray on white. And that light gray is my system color, which shouldn't apply, yet it does. Ever since I use Firefox with a dark theme (about 10+ years) this was broken. And currently there is no any way I know of, or that I could find via hours of Googling, to change the default colors Firefox falls back to if no color is specified. > 3. On the other hand, form fields have always inherited the system-wide look > by default. And they shouldn't. Appearance, sure, but NOT colors. Colors of the host system should not, ever, under any circumstance affect the colors displayed in webpages, since webpages' look is independent of the host system. > 3. Illegible text, whether in form fields or elsewhere, is pretty much > ALWAYS the designer's (or rather person's who did the CSS work) fault. I disagree partly. It is their fault that they didn't specify colors, and relying on the assumption that if no color is specified then background will be white and text will be black. But it is not their fault, that this assumption is true in every single browser, except Firefox with dark theme. It is also not their fault, that Firefox, instead of implementing these common expectations as default, lets system colors bleed into webpages. And since we know that many-many webdesigners will be lazy, why not save our users from all that pain by implementing sane defaults? Also, it's funny how parts of mozilla.org are affected by this issue. > Back in the day, people used to validate their CSS And in a perfect world they would still do it, but we are not living in a perfect world sadly, so we may as well account for that instead of sticking heads into the sand. > Nowadays, everyone just blindly assumes that stuff will > work after minimum testing on Chrome If they don't have a dark system theme, it will work for them in every single browser in existence. Only Firefox, combined with dark system theme does break it. So back to 1; I'm desperate. I started using Firefox about 15 years ago because it was the best, and_most_customizable_ browser out there. It had its flaws, but we loved it regardless. I had high hopes for Quantum, but instead it was a gigantic let down. - It killed off several amazing Addons, that are impossible to port to WebExtension because it's extremely limited. - Addon devs' feature requests for functionality allowing said mods to be ported were simply closed with "WONTFIX". - Even more customization was removed, partly by making it impossible for Addons to customize FF now (eg. Classic Theme Restorer with millions of users), turning firefox into the _least_customizable_ browser on the market. - The dark theme issue became MUCH worse. Until Quantum, I used a simple local CSS that was an effective workaround for 99% of websites. Now the system colors bleed into even more places, that I could only fix by overriding colors that then break other pages that were fine without it, plus local CSS is now unable to affect the Firefox GUI itself, making it impossible to fix this issue in the GUI. Firefox is still better IMHO than all other browsers in many regard, but with every day I have to suffer with unreadable websites I feel more and more tempted to just go to Chrome. This is NOT an issue in Chrome (or any browser other than FF)
I wholly agree with Storm's assessment. As a programmer, a web developer, and a UI designer, the fact that Firefox has sat on this bug for over a decade is shameful, especially since it has been *patched* with extensions before. For anyone affected, install the "Text Contrast for Dark Themes" (https://addons.mozilla.org/en-US/firefox/addon/text-contrast-for-dark-themes/?src=api) extension. I've been using it for the past few weeks, and it resolves 98% of the problems related to this bug. The fact that extension exists should NOT be taken as an excuse for Firefox not to fix this. If anything, it means that Firefox developers have even *less* excuse for taking care of the problem, since the patch code is in the extension!
Please, Firefox devs, fix this! With the rise of themes like Arc-dark, this is a HUGE issue! I just want things to look normal! Is that so much to ask? *begging puppy eyes*
Yeah pretty weird this is still an issue, should be pretty easy to fix. In the mean time. Meanwhile, this fixed my problem: https://github.com/lightradius/firefox-dark-theme-fix (backup your profile, then place the userContent.css file in your ~/.mozille/firefox/XXXXXXXX.default/chrome directory - create it if it doesn't exist)
(In reply to vaaghoofdharry from comment #39) > Yeah pretty weird this is still an issue, should be pretty easy to fix. In > the mean time. Meanwhile, this fixed my problem: > https://github.com/lightradius/firefox-dark-theme-fix > > (backup your profile, then place the userContent.css file in your > ~/.mozille/firefox/XXXXXXXX.default/chrome directory - create it if it > doesn't exist) This is a major improvement already and can also be used in Thunderbird. The directory (on Ubuntu) is ~/.thunderbird/XXXXXXX.default/chrome, which didn't exist initially. Would like to see a built-in complete solution to this for both Firefox and Thunderbird.
Just want to confirm that this bug is still NOT fixed. I use KDE Plasma desktop enviroment with Breeze Dark color scheme. Usually I use Chromium, sometimes Google Chrome, as they don't have issues with dark themes. But I want to use Firefox and because of this bug I can't. I was following Firefox releases past 4-5 years expecting to see a fix for this. Now I use "Text Contrast for Dark Themes" extension which kind of helps, but not enough for daily use. https://addons.mozilla.org/en-US/firefox/addon/text-contrast-for-dark-themes/ It's sad to see that this bug already 17 years old and does not get enough attention to get fixed. As dark themes for GTK+ getting more popular, I hope to see a fix in future. Could be set as a milestone for 2020 or something, that would be really great! No other browser has this issue, only Firefox. If this is super hard to fix, maybe would be good idea to switch to another toolkit instead of GTK+? For example Qt toolkit is very good, has a lot of support and works pretty well. OFFTOPIC: One thing made me happy with recent Firefox releases, that HighDPi display support is improved, and it's possible to get non-integer value scaling of UI and websites. For that I was waiting 2 years and I am really happy it got improved. To get Dark Theme compatibility would be last step to make Firefox usable for me and some other users!
Still not fixed, what an annoying bug
bump! i can't believe a small nuisance is taking 17 years not fixed. workaround https://www.reddit.com/r/firefox/comments/6rbvvw/photon_rectangular_tabs_have_landed_in_nightly/dl4318f/
I suspect that many aspects of this actually were fixed at various times. But the hard part is to prevent all the CSS changes in the browser front-end from triggering some aspect of it again. (At one point I think I'd made a testing mode in which the correct foreground/background pairs were always the same color, so that no text should be visible, that could be used to check that colors were matched correctly. I'm not sure if I even landed the code for it or what happened to it since.) I'd also done some work to document what those pairs were, i.e., the rules for which native-theme-derived foreground color should be matched with which background color so that themes work correctly. (-moz-appearance makes this a bit more complicated, since foreground colors could be matched with a -moz-appearance background as well.) The number of comments recently makes me suspect that something got *worse* recently. In theory fixing this probably requires: * documenting what the valid foreground-color and (background-color or -moz-appearance) pairs are for use of colors from native themes * developing a mechanism to check that the UI uses only those pairs together and nothing else (probably by making each pair render the same (bright) color as a diagnostic * auditing the Firefox UI * checking that the things we're extracting from GTK themes make sense with the rules that we're applying
(In reply to David Baron :dbaron: ⌚UTC+2 from comment #45) > The number of comments recently makes me suspect that something got *worse* > recently. Yes, something did change in GNOME recently. Prior to GNOME 3.28 there was a GTK preference called gtk-application-prefer-dark-theme that could be used to get dark widgets. This could either be set in ~/.config/gnome-terminal/gtk-3.0/settings.ini. This was also exposed as a toggle option in the gnome-tweaks tool, which is probably how most users had set it it. This GTK option has been deprecated in GNOME 3.28, and the new way to get a dark theme is to explicitly set one's GTK theme to Adwaita dark. You can read about this a bit more at [1] and [2]. Firefox apparently has some logic to ignore gtk-application-prefer-dark-theme, but that logic no longer works on GNOME 3.28 with the Adwaita dark theme. As was mentioned in comment #43, the work around for GNOME 3.28 is to set a user pref (i.e. in about:config or user.js) that sets widget.content.gtk-theme-override to Adwaita:light. As I suspect the overwhelming majority of Firefox users with dark GTK themes are using Adwaita dark (which is bundled with GNOME), I would suggest updating the Firefox dark them detection logic to handle the new case with the Adwait theme names hard coded. This is hacky, but probably mitigates the issue for most users. [1] https://jeremy.bicha.net/2017/08/29/gnome-tweaks-3-25-91/ [2] https://jeremy.bicha.net/2018/01/29/gnome-tweaks-3-28-progress-report-1/
I've got a patch up to try to mitigate the issue for GNOME 3.28 over at bug #1461538.
Evan, what that patch will not do is fix the input field issue on explicitly chosen dark themes. What I would recommend instead is simply making this bit of userContent.css equivalent completely override Gtk regardless of theme, to produce the desired output: INPUT, TEXTAREA {color: black ; background: #ffffff ; } This is the general case which websites expect, and which users expect, and in my testing does not interfere with sites that explicitly set up a different color combination for text input areas. I don't even think it's -possible- to recreate this bug on the Windows or Mac ports without manually messing with userContent.css, so forcibly overriding Gtk here seems like the intelligent thing to do.
(possible way to solve this issue?) Sir, One option might be to remove all dependency on system themes. Firefox shouldn't care about the system themes. No dependence. All text should be rendered: 1. like the .css developer wanted or, 2. if he uses !important, render it simply black on white. In a nutshell, default FF canvas(for everything, including input boxes) and font should be white and black respectively. We shouldn't inherit this from the system theme. Why should we? Do we really need to? Hope this would nullify @dbaron sir's requirements and make it easier to implement this, sooner. Thank You [Please do not ban me if this does not help. Ping me and I'll remove it myself. This is my first time coming out with ideas as stupid as this :)]
I predict that Apple is going to fix this bug in a few years, by evangelizing @media(prefers-color-theme: dark) all over the Web.

I hit this bug today by choosing the dark Adwaita theme in Gnome 3.28 and Firefox 65.0. It's amazing that this is an 18 year old bug. I found it surprising the system theme did anything to webpages and had two consecutive surprises:

  • First setting the system theme to Adwaita-dark changed the Firefox theme. That makes sense. What was surprising was that the Firefox theme then changed the content of the web pages. My mental model of a browser is that within the page view it's a different world and there's no reason for the web to look different to match the browser chrome or the system theme.
  • Because I didn't actually like the dark version of Firefox I switched it to the Light theme manually (webpages are usually light colored and so dark chrome in browsers looks weird). And yet even after doing this pages still had dark buttons and input areas. That was even stranger. Now Firefox had a light theme and yet the webpages were still picking up broken colors from the system theme inconsistent with the Firefox chrome theme.

I fixed this after some web searches by setting "widget.content.gtk-theme-override:Adwaita". That at least sets a light theme for UI controls and is back to looking reasonable. I found that in bug #1283086 which seems to be a 3 year old duplicate of this 18 year old bug. The proposal for removal of all native theming in #1411425 makes perfect sense.

In the mean time, could widget.content.gtk-theme-override be set to Adwaita by default? This would fix the issue (except for the settings page), and Adwaita is always present on systems with GTK+. I opened https://bugzilla.mozilla.org/show_bug.cgi?id=1527048 for this change, everyone please go comment on that bug :)

So I think it would be useful to know, for the current round of complaints, are the problems the result of:

  1. Firefox incorrectly gets data out of the GTK theme, so that its default appearance for controls doesn't match the native one, or
  2. Firefox gets the data out of the theme correctly, but then web pages override one but not both of color and background (while assuming that color is dark and background is light), leading to an unreadable result

We've had both problems in the past, and it would be useful to know which of them is happening in the set of problems that have spiked in the past few months.

I use this extension as a workaround: fix-dark-theme-input-boxes (source)

David: The problem here is point 2. Just setting widget.content.gtk-theme-override to Adwaita by default would fix this for web pages, but the General -> Startup section of the Settings page still looks wrong (white text on a white background), along with a couple of other spots in Settings, despite setting this pref.

If you uncheck "Use System Colors" it's no longer a problem.

I have "Use System Colors" unchecked, widget.content.gtk-theme-override set to Adwaita and the Light theme selected. And yet even then the Ctrl-F input has white text over white background.

re comment 57, with those settings (on Ubuntu 18.04), I see white text on a dark background.

I'm also using Ubuntu 18.04 but using the vanilla GNOME session (that uses Wayland) with the dark Adwaita theme selected. Could you please test with that to see if you get the same result?

System colors (and it's override) is covered by Bug 1422563
Dark Gtk theme is covered by Bug 1527048

btw. widget.content.gtk-theme-override should be set to "Adwaita:light" and works only when e10s is enabled.

I seem to have e10s enabled:

Multiprocess Windows 1/1 Enabled by default

and have set Adwaita:light:

widget.content.gtk-theme-override;Adwaita:light

I still get white text on white background on the Find textbox within webpages.

Here's a simple way to replicate this bug for me. In both cases I have the Light theme selected:

$ GTK_THEME="Adwaita:dark" firefox
(firefox runs and the Find box has white text on white background)

$ GTK_THEME="Adwaita:light" firefox
(firefox runs and the Find box has the correct black text on white background)

This should be fix as of https://bugzilla.mozilla.org/show_bug.cgi?id=1527048#c14

Testing appreciated.

Can this be resolved fixed due to Bug 1527048 being fixed?

Flags: needinfo?(stransky)
Flags: needinfo?(stransky)
Priority: P4 → P3

Yes, duplicate of Bug 1527048.

Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: