GNOME Bugzilla – Bug 121118
Gconf-option "Always use the desktop theme colors" breaks display of images
Last modified: 2005-12-31 18:29:09 UTC
Epiphany does not display all images for me. See the screenshots of http://www.gnomedesktop.org/ , http://slashdot.org/ and http://www.gnome.org/ I attach below. In gconf, /apps/epiphany/filtering/image_loading_type is set to "0", as I think it should be. This happens to me nearly always, and on every site I tried until now. "Nearly", because once it happened that after clicking a link on gnomedesktop.org, everything displayed correctly, and stayed ok also fo other sites, until I closed epiphany. Then it was back to normal, i.e., wrong display
Created attachment 19628 [details] Screenshot of FootNotes with wrong image display
Created attachment 19629 [details] Screenshot of /. with wrong image display
Created attachment 19630 [details] Screenshot of Gnome.org with wrong image display
Can you try to remove .gnome2/epiphany/.../prefs.js ? That gconf key is no more used, maybe you had it enabled or something.
I'm no sure I understand your suggestion, because you're talking about prefs.js, and then say "that gconf key is no more used". However, prefs.js is not a gconf key :) Anyway, I removed ~/gnome2/epiphany/mozilla/epiphany/prefs.js which changed nothing - still wrong
Just looked at shots urgh, even the image colors are wrong. Does it work correctly with mozilla itself (the same mozilla you compiled epiphany with). Can you attach your prefs.js ?
Mozilla (the one used by epiphany) works ok, so does galeon. The issue with epiphany exists for me with every epi version I tried. Epi works ok for all other users. I can't attach my user's prefs.js, as I deleted it :) Also, it probably doesn't matter, since even when I moved ~/.gnome2/epiphany away, the problem still exists. Something in gconf perhaps?
prefs.js is regenerated every time on startup from the gconf prefs, it contains all mozilla related prefs, so it's more likely to have relevant info. Still, if you can try it with a test user could help to exclude it's a prob in the configuration.
As I said in my previous comment, it works ok for all other users, also for a test user I created for the purpose. I'll attach my regular users's prefs.js
Created attachment 19649 [details] ~/.gnome2/epiphany/mozilla/epiphany/prefs.js of problem user
The only thing that sounds sort of related to me is user_pref("browser.display.use_document_colors", false); which is "Always use system colors" in the prefs dialog.
It's called "Always use the desktop theme colors" - but yes, this was it. Turning it off and reloading the page fixes the problem. This behavior does not depend on the theme AFAICT.
Can you try if checking bot "Use system colors" and "use my chosen colors...) in mozilla colors page give the same result ? In that case it's a mozilla bug.
There you go, "use my chosen colors..." in mozilla has the same effect. Similar report is there http://bugzilla.mozilla.org/show_bug.cgi?id=183783 However, it complains only that "use my chosen colors..." was the default, although it gives horrible results. I tend to think that a setting that gives horrible result is stupid anyway (it's like an option "make this app suck"), but maybe Mozilla can justify this setting, since it is not inteded to be an end user browser. Given the goals of epiphany, I'd think it should not offer that option until setting it gives usable results. Or is there actually any use case for the option in this state, which seems just broken to me?
The option is absolutely necessary for accessibility. I'm actually wondering if not showing some images is intentional for that reason. It make sense for the background images (on gnomedesktop) but it doesnt for the logo on gnome.org which seem a normal image.
One thing we could consider like a problem is that it could be hard to understand what happened if you enable it by mistake.
Maybe just a wording change ist needed? Both "Always use the desktop theme colors" and "use my chosen colors..." provoke the naive reaction of "well, sure I want my complete desktop to look consistent", especially right now when linux desktop consistency is such a big topic. Which probably was the reason I enabled it in the first place. Even more so since "Always use the desktop theme colors" is under the innocent-looking header "Colors". Is accessibility the /only/ reason for it? Then: Current: --------------------------------------- Colors |_| Always use the desktop theme colors --------------------------------------- Suggestion: --------------------------------------------- Accessibility |_| Desktop theme colors override page colors ---------------------------------------------
Dave, opinions ?
Yeah a rewording is probably in order. Not quite sure what it should be. Maybe an accessibility tab, with that pref, the caret pref is in order? I'm feeling insecure these days about most stuff...ask seth I guess :)
Hm for new pages creation I'd prolly wait until 1.2 ui is more definite. And stop to be unsecure damn you ;)
> Hm for new pages creation I'd prolly wait until 1.2 ui is more > definite. For sure, I think the porting work is definately more important right now. Also this pref defaults to off right? I guess the string I chose is poor. Maybe "Overide colors specified by webpages with Desktop defaults." Although that is pretty wordy eccchhhh. > And stop to be unsecure damn you ;) Its probably just a phase. btw 1.1 is looking nice :)
`Allow documents to use _other fonts' is intended to eventually have siblings in `Allow documents to use _other colors' and `Allow documents to use _other styles'. Not all pages are written by authors. This is what mpt was suggesting in a mozilla bug. We have the additional problem of the desktop theme colors ... What about "Allow documents to use their own colors" or "Allow documents to specify colors". I think this at least make clear that you are going to break documents colors ...
*** Bug 122978 has been marked as a duplicate of this bug. ***
Dave, it's time to solve this ? What we do ?
Since we don't want to make any "large" changes (ie a11y tab) lets just do a label change to "Desktop theme colors override page colors" as the reporter suggested above. longer term we can do the style sheet thing maybe, but thats for another day to discuss.
I'm just worried "override" is a technical term most people dont understand which could be completely wrong given my english knowledge. If so maybe you can fix it and close this :)
yeah its is somewhat technical true. Ugghh...maybe seth or calum will have a better suggestion.
Agree "override" is a bit technical... I'm thinking a pair of radio buttons might actually be the clearest: Use these colors for drawing pages: ( ) All available colors (o) Desktop theme colors only Otherwise you end up with something like: [x] Use desktop theme colors only when drawing pages or [x] Only use desktop theme colors when drawing pages where the word "only" makes the sentence rather ambiguous in each case :)
As the OP, Calum's idea seems the clearest to me as for how to phrase the option itself. However, much of _my confusion came from the fact that the location at which the option is placed atm is under the heading "Colors" in the "Fonts and Colors" tab. As the discussion of the bug has shown that the only use case for the option seems to be accessibility, I think that making this clear is as important as an unambiguous wording of the option itself. I would combine my suggestion from above with Calum's and change the "Colors" heading to "Accessibility"
Sure, I meant to say I agreed with the 'Accessibility' change too :)
Wouldn't all of these fixes require string or gui changes which we're too late for for 1.2?
Yeah, moving to 1.4.
Using Epiphany 1.2.6 I only see a "Always use the desktop theme colors" checkbox, which seems like a good idea. I'm only missing background images, which seems appropriate; status on this bug?
Using epiphany with moz 1.7, I can still reproduce the problem. Since I can also repro in mozilla (set browser.display.use_document_colors to false in about:config), this seems like a mozilla problem. We need to see if it's been filed yet on b.m.o.
Moving Target Milestone -> 1.6 because of string freeze.
-> Mozilla interaction
Mass reassigning of Epiphany bugs to epiphany-maint@b.g.o
String freeze is over, so I'm removing the BLOCKED_BY_FREEZE keyword.
This bug is reported upstream as: https://bugzilla.mozilla.org/show_bug.cgi?id=306625 which is related to: https://bugzilla.mozilla.org/show_bug.cgi?id=19260
Closing as NOTGNOME as this is a mozilla bug (see previous comment)